首页 > 代码库 > 5.3 Static
5.3 Static
相信很多人都遇到过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