相信很多人都遇到过App 莫名其妙就崩溃的情况，尤其是一些配置很低的手机，重现场景就是在App 切换到后台，闲置了一段时间后再继续使用时，就会崩溃。导致上述崩溃发生的罪魁祸首就是全局变量。

　　在内存不足的时候，系统会回收一部分闲置的资源，由于App 被切换到后台，所以之前存放的全局变量很容易被回收，这时再切换到前台继续使用，在使用某个全局变量的时候，就会因为全局变量的值为空而崩溃。这不是个例，任何页面从后台切换回前台都有崩溃的可能。想彻底解决这个问题，就一定要使用序列化技术。

1 把数据作为Intent 的参数传递

　　想一劳永逸地解决上述问题就是不使用全局变量，使用Intent 来进行页面间数据的传递。因为，即使目标Activity 被系统销毁了，Intent 上的数据仍然存在，所以Intent 是保存数据的一个很好的地方，比本地文件靠谱。但是Intent 能传递的数据类型也必须支持序列化，像JSONObject 这样的数据类型，是传递不过去的。另外，如果Intent 上携带的数据量过大，也会发生崩溃。

2  把全局变量序列化到本地

　　另一个比较稳妥的解决方案是，我们仍然使用全局变量，在每次修改全局变量的值的时候，都要把值序列化到本地文件中，这样的话，即使内存中的全局变量被回收，本地还保存有最新的值，当我们再次使用全局变量时，就从本地文件中再反序列化到内存中。这样就解了燃眉之急，数据不再丢失。但长远之计还是要一个模块一个模块地将全局变量转换为Intent 上可序列化的实体数据。但这是后话，眼前，我们先要把全局变量序列化到本地文件

3 序列化的缺点

　　再次强调，把全局变量序列化到本地的方案，只是一种过渡型解决方案，它有几个硬伤：

1）每次设置全局变量的值都要强制执行一次序列化的操作，容易造成ANR。

2）序列化生成的文件，会因为内存不够而丢失。

3）Android 提供的数据类型并不全都支持序列化（如JSONObject和JSONArray）。

4 如何看待SharedPreferences

　　在我们决定禁止使用全局变量后，曾经一段时间确实有了很好的效果，但是我后来仔细一看项目，新的全局变量倒是真的不再有了，大家都改为存取SharedPreferences 的方式了。

　　在我看来，SharedPreferences 是全局变量序列化到本地的另一种形式。SharedPreferences中也是可以存取任何支持序列化的数据类型的。

　　我们应该严格控制SharedPreferences 中存放的变量的数量。有些数据存在SharedPreferences中是合理的，比如说当前所在城市名称、设置页面的那些开关的状态等等。但不要把页面跳转时要传递的数据放在SharedPreferences 中。这时候，要优先考虑使用Intent 来传递数据。

5 User 是唯一例外的全局变量

　　App 中只有一个全局变量的存在是合理的，那就是User 类。我们在任何地方都有可能使用到User 这个全局变量，比如获取用户名、用户昵称、身份证号码等等。

　　User 这个全局变量的实现，可以参考本章讲解的例子。每次登录，都要把登录成功后获取到的用户信息保存到User 类。以后，每当User 的属性有变动时，我们都要把User 保存一次。退出登录，就把User 类的信息进行清空。与之前我们所设计的全局变量不同，App 启动时不需要清空User 类的数据。因为我们希望App 记住上次用户的登录状态以及用户信息。再讲下去就涉及用户Cookie 的机制了。

5.3 Static