/ java  类加载器 

理解Java类加载器之静态变量总结


Android是用Java开发,其静态变量的生命周期遵守Java的设计。静态变量是在类被load的时候分配内存的,并且存在于方法区。当类被卸载的时候,静态变量被销毁。在PC机的客户端程序中,一个类被加载和卸载,可简单的等同于jvm进程的启动和结束。那么在Android中呢?用的Dalvik vm也是一样的。不过Android不太突出的进程概念,所以对静态变量的生命周期就会感觉模糊,这种模糊对于值类型是无所谓的,如果是静态的对象引用,则与内存回收、内存泄漏这些问题有关,有必要加深研究和理解。

一、静态变量在类被加载的时候分配内存。

类在什么时候被加载?

当我们启动一个app的时候,系统会创建一个进程,此进程会加载一个Dalvik VM的实例,然后代码就运行在DVM之上,类的加载和卸载,垃圾回收等事情都由DVM负责。也就是说在进程启动的时候,类被加载,静态变量被分配内存。

二、静态变量在类被卸载的时候销毁。

类在什么时候被卸载?

在进程结束的时候。

说明:一般情况下,所有的类都是默认的ClassLoader加载的,只要ClassLoader存在,类就不会被卸载,而默认的ClassLoader生命周期是与进程一致的,本文讨论一般情况。

三、Android中的进程什么时候结束

这个是Android对进程和内存管理不同于PC的核心——如果资源足够,Android不会杀掉任何进程,另一个意思就是进程随时可能会被杀掉。而Android会在资源够的时候,重启被杀掉的进程。也就是说静态变量的值,如果不做处理,是不可靠的,可以说内存中的一切都不可靠。如果要可靠,还是得保存到Nand或SD卡中去,在重启的时候恢复回来。

另一种情况就是不能把退出所有Activity等同于进程的退出,所以在用户点击图标启动应用的时候,以前存放于静态变量中的值,有可能还存在,因此要视具体情况给予清空操作。

四、Application也是一样不可靠

Application其实是一个单例对象,也是放在内存中的,当进程被杀掉,就全清空了,只不过Android系统会帮重建Application,而我们存放在Application的数据自然就没有了,还是得自己处理。

五、静态引用的对象不会被垃圾回收

只要静态变量没有被销毁也没有置null,其对象一直被保持引用,也即引用计数不可能是0,因此不会被垃圾回收。因此,单例对象在运行时不会被回收。

static修饰的静态变量,在不同的类和包中都可以使用,在虚拟机中单独占用内存,但是可能会出现NullException的异常。 
static访问是无法跨进程的。Android中的Activity,Service是可以在各自进程中运行的,用static传递参数到不同进程的Activity、Service时会错。 
static占据的那份内存,在接个电话或者长时间待机后,再回到应用也会出现崩溃的现象,而这些崩溃都与静态变量的空指针有关系。 
根据Google官方的推荐,我们应该尽量使用继承自Application的自定义类,在我们继承的类中定义需要全局使用的变量,并通过getApplicationContext()来获取和保存相关的变量即可。 
启动Application时,系统会创建一个PID,即进程ID,所有的Activity就会在此进程上运行。那么我们在Application创建的时候初始化全局变量,同一个应用的所有Activity都可以取到这些全局变量的值,换句话说,我们在某一个Activity中改变了这些全局变量的值,那么在同一个应用的其他Activity中值就会改变。 
如果想在整个应用中使用全局变量,在java中一般是使用静态变量,public类型;而在android中如果使用这样的全局变量就不符合Android的框架架构,但是可以使用一种更优雅的方式就是使用Application context。 

前段时间公司测试人员告诉我,在测试机上有段时间没运行的app再去测试的时候突然崩溃了。

事实上再次启动程序之后,这个问题就不存在了,一切都是那么正常,但是这种莫名其妙的bug怎么可以放任它存在了,最后也是一顿折腾总算是找到了原因,看到标题应该有人明白怎么回事了,就是static,现在就在这里好好说说。

static 修饰的静态变量,在不同的类和包中都可以使用,系统为我们app创建虚拟机之后,类被加载,静态变量被分配内存,并且在虚拟机中单独占用内存,静态变量在类被卸载的时候才会被销毁,而类只有在进程结束的时候才会被卸载,也就是说被static修饰的静态变量只有在进程被销毁的时候才会被回收 。在我之前的概念里,一个app进程只有被主动退出或者主动清理后才会被销毁,但是事实上,android 系统在资源不足的情况下就会kill掉进程已保证系统正常运行,通常情况下会优先kill掉进程优先级比较低的进程,例如处于后台长时间没有运行的进程,但系统在内存极少的情况下,依然会选择kill 掉一些前台进程,系统kill进程顺序:后台进程 -> 服务进程 -> 可见进程 -> 前台进程。说道这里,也就可以解释我程序为什么会崩溃的原因了:在我进入某一特定界面activityA之前,会给某一static静态变量B赋值,这样在activityA我就可以使用B来进行一些逻辑操作,但是在某一未知时间,系统由于资源紧张而kill掉我的进程,然后在资源充足的情况重新恢复了进程恢复了activityA,造成了当前进程未被kill掉的假象,由于进程被重新创建,原来被赋值的静态变量B被重置,那么在我操作B的时候由于没有做空值检测,抛出空指针,so , game over…

详情可以参考:

http://zmywly8866.github.io/2014/12/26/android-do-not-store-data-in-the-application-object.html

http://www.cnblogs.com/meizixiong/p/4493171.html

http://blog.sina.com.cn/s/blog_476d58ef0102vz2n.html

http://blog.csdn.net/nokiaguy/article/details/5998986

找到了原因那么就说说解决办法:

1. 尽量少使用static来修饰变量,尤其是一些关键性的数据,并且对于被修饰过的变量在使用前要进行空值检测;

2. 对于一些重要信息,可以选择本地持久化

3. 善用onSaveInstanceState及onRestoreInstanceState方法对数据进行保存和恢复,当然在oncreat方法里我们也可以使用savedInstanceState对数据进行恢复,

关于onSaveInstanceState及onRestoreInstanceState被调用的时机:

onRestoreInstanceState方法在onStart之后被调用,此时可以进行数据恢复(前提是有进行了数据保存操作); 
onSaveInstanceState方法在onPause之后被调用; 
注意:系统只在Activity异常终止的时候才会调用onSaveInstanceState与onRestoreInstanceState来储存和恢复数据,其他情况不会触发这个过程。但是按Home键或者启动新Activity仍然会单独触发onSaveInstanceState的调用

 参考:https://blog.csdn.net/ithouse/article/details/53319589

https://blog.csdn.net/zhoudaxia/article/details/35824249

https://www.cnblogs.com/hf-cherish/p/4970267.html


发布评论

热门评论区: