The static variable of Android memory restart is recycled causing nullpoint problem

In general, I call the system to keep the current app running stably while the memory cleanup action causes the background app to be forced to clean up as a memory reboot.

One problem with memory restarts is that the corresponding static variables will also be erased when the app is killed. So how to solve this problem.

According to my research, I can use several methods:

Method One:

//Save configuration information before activity is destroyed to prevent static variable data loss@Overrideprotected voidonsaveinstancestate (Bundle outstate) {Super. Onsaveinstancestate (outstate); //This saves the Config object after the parcelable (serialized)Outstate.putparcelable ("config", config); }    //recover saved data when activity resumes@Override Public voidonrestoreinstancestate (Bundle savedinstancestate) {Super. Onrestoreinstancestate (savedinstancestate); ////Restore Config object hereConfig=savedinstancestate.getparcelable ("config"); }

Method Two:

According to Google's official recommendations and the recommendations of the great Gods of Baidu, we should try to use custom classes that inherit from application, define variables that need to be used globally in our inherited classes, and pass Getapplicationcontext () To get and save the related variables.

Specific code reference http://blog.csdn.net/weihan1314/article/details/8033052

Method Three:

The application of suicide is monitored when the activity is quickly recovered by the system. You think that anyway is dead, instead of being killed by the system and reported abnormal, rather than suicide, 18 years later is a hero.

The user opens the app and reloads the static variable, which is a rough and safe way to insure it.

/** * @param  level     */    @Override    public      when     not enough memory   void ontrimmemory (int level ) {        super. Ontrimmemory ( level);         if (level = = trim_memory_moderate)            {// start suicide, clear off all activity
Here's how to write it yourself.

((tmdapplication) getapplication ()). Destroyalldata (NULL);

} }

Appendix: Memory Level Level

Trim_memory_complete: There is not enough memory, and the process will be cleaned up at the end of the list of background processes trim_memory_moderate: Not enough memory, and the process is in the middle of the list of background processes. Trim_memory_background: Insufficient memory, and the process is a background process. Trim_memory_ui_hidden: There is not enough memory, and the UI of the process is not visible trim_memory_complete the listener is sometimes not listening, it is recommended to listen to Trim_memory_moderate, Handle the Exit program operation in this.

Other methods:

For example, save a configuration file to a database, save to a local file, and so on. The disadvantage is that the reading time, not recommended to use.

The static variable of Android memory restart is recycled causing nullpoint problem