Go Life cycle of Android static variables

Original address: https://my.oschina.net/jerikc/blog/137207

Android is developed in Java, and its static variable life cycle adheres to the Java design. We know that a static variable allocates memory when the class is load and exists in the method area. When the class is unloaded, the static variable is destroyed. In a PC's client program, a class is loaded and unloaded, which can be simply equivalent to the start and end of the JVM process. What about Android? The same Dalvik VM is used. However, Android is not a very prominent process concept, so the life cycle of static variables will be blurred, this ambiguity for value types is irrelevant, if it is a static object reference, it is related to memory recovery, memory leaks, it is necessary to deepen research and understanding.

A static variable allocates memory when the class is loaded. When is the class loaded? When we launch an app, the system creates a process that loads an instance of the Dalvik VM, then the code runs on the DVM, the load and unload of classes, garbage collection, and so on are the responsibility of the DVM. This means that when the process starts, the class is loaded and the static variable is allocated memory.

Static variables are destroyed when the class is unloaded. When was the class unloaded? At the end of the process. Note: In general, all classes are default ClassLoader loaded, as long as ClassLoader exist, the class will not be unloaded, and the default ClassLoader life cycle is consistent with the process, this article discusses the general situation.

Third, the process of Android when the end of this is Android to process and memory management is different from the core of the PC-if the resources are sufficient, Android will not kill any process, another means that the process may be killed at any time. Android will restart the process of being killed when resources are sufficient. That is, the value of a static variable, if not done, is unreliable, it can be said that everything in memory is unreliable. If you want to be reliable, you still have to save it to the NAND or SD card and restore it back when you reboot. Another scenario is that you cannot leave all activity equal to the exit of the process, so when the user clicks on the icon to launch the application, the value that was previously stored in the static variable may still exist, so it is necessary to give the empty operation depending on the situation.

Four, application is also the same unreliable application is actually a singleton object, but also put in memory, when the process was killed, it was completely emptied, but the Android system will help rebuild the application, And the data we store in the application is naturally gone, and we have to deal with it ourselves.

V. Objects that are statically referenced are not garbage collected as long as the static variable is not destroyed or NULL, its object has been kept referenced, that is, the reference count cannot be 0, so it will not be garbage collected. Therefore, singleton objects are not recycled at run time.

Go Life cycle of Android static variables