Use traps for Android static variables

Static variables everyone is familiar with it, there is no good repetition. The cause is this, the recent test over there is the reaction is doing a product is always inexplicably show some data, and even the collapse of the crash, carefully checked a few times to find no problem, finally a lot of trouble to find in the test machine running on the time of this problem will occur. So all kinds of log, all kinds of breakpoints debugging, the last discovery are reported java.lang.NullPointerException, found to be static variable problem, think not ah ...

The cause of the bug, test sister paper with the test machine perennial for testing, deputy public phone, inside everyone installed a variety of applications, probably less than 50 applications, although the mobile phone is 1G RAM, but also can not afford to make such a small amount of usable memory. During debugging, when you find exaggeration, you return to the previous activity, and the back is immediately recycled. Although it seems to be external factors, but still have to change ah. Summary: Android phones when available memory and its small, will be recycled everything, is everything of course including static.

How to solve, various solution. Android is developed in Java, and its static variable life cycle adheres to the Java design. Static variables, which are easy to use, are available in different classes and packages, take up memory in a virtual machine, yes, these are the advantages of static variables that are allocated memory when the class is load, and exist 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. Static variables allocate 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, and when is the class unloaded? At the end of the process, in general, all classes are loaded by default ClassLoader, and as long as the ClassLoader exists, the class is not unloaded, and the default ClassLoader life cycle is consistent with the process. When the Android process ends, this is Android's 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 can 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.

Solutions, two ways of thinking:

First, according to Google's official recommendations and Baidu to the great God of the recommendation, we should try to use inherited from the application custom class, in our inherited class to define the variables that need to be used globally, and through Getapplicationcontext () To get and save the related variables.

Like what:

public class TestApplication extends application {
private int curindex;
public int Getcurindex () {
return curindex;
}
public void Setcurindex (int curindex) {
This.curindex = Curindex;
}
@Override
public void OnCreate () {
Super.oncreate ();
}
@Override
public void Onterminate () {
Super.onterminate ();
}
}

How to use:

Save variables
Application.setcurindex (5);
Get variable
Application.getcurindex ();

TestApplication application = (testapplication) this.getapplicationcontext ();
Application is used in conjunction with the application, which is where it is, and will not be recycled by GC, so it's safer to use this method. I finally adopted this method, did not find the problem.

Second, the view is not quite the same, even with the first kind of a little conflict

application is just as unreliable, Application is actually a singleton object, also put in memory, when the process is killed, it is completely emptied, but the Android system will help rebuild the application, and we stored in the application data naturally no, or have to deal with their own. Objects that are statically referenced are not garbage collected, as long as the static variables are not destroyed or null, their objects remain referenced, that is, the reference count cannot be 0, and therefore will not be garbage collected. Therefore, singleton objects are not recycled at run time.

Related information: http://blog.csdn.net/ctcwri/article/details/8858414

http://blog.csdn.net/weihan1314/article/details/8033052

Http://www.2cto.com/kf/201205/133951.html

Use traps for Android static variables