理解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…
详情可以参考：
到了原因那么就说说解决办法：
1. 尽量少使⽤static来修饰变量，尤其是⼀些关键性的数据，并且对于被修饰过的变量在使⽤前要进⾏空值检测；
static修饰的变量2. 对于⼀些重要信息，可以选择本地持久化
3. 善⽤onSaveInstanceState及onRestoreInstanceState⽅法对数据进⾏保存和恢复，当然在oncreat⽅法⾥我们也可以使⽤savedInstanceState对数据进⾏恢复，
关于onSaveInstanceState及onRestoreInstanceState被调⽤的时机：
onRestoreInstanceState⽅法在onStart之后被调⽤，此时可以进⾏数据恢复（前提是有进⾏了数据保存操作）；
onSaveInstanceState⽅法在onPause之后被调⽤；
注意：系统只在Activity异常终⽌的时候才会调⽤onSaveInstanceState与onRestoreInstanceState来储存和恢复数据，其他情况不会触发这个过程。但是按Home键或者启动新Activity仍然会单独触发onSaveInstanceState的调⽤

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。