Four data storage restoration methods involved in the restart process of Activity execution in Android

Four data storage restoration methods involved in the restart process of Activity execution in Android

We know that when Configuration Change occurs (such as screen switching), the Activity will be restarted, that is, destroy and restart. Generally, restart takes a short time, to ensure consistent user experience, we should store some data before the Activity restarts, and then update the UI during restart. Of course, you may want to write the data to a physical file or database, but this has some disadvantages, because IO operations consume time and affect the restart process, and even cause the ANR program to be unresponsive, this article describes several methods to restore data when it is cached in the memory for restart.

OnSaveInstanceState

Activity has an onSaveInstanceState callback method. If the onSaveInstanceState method is called, The callback method must be called before onStop, but cannot be called before or after onPause. Generally, some information of the UI persistence is stored in the Bundle, and then restored according to the Bundle when the Activity re-creates and executes the onCreate (Bundle) or onRestoreInstanceState (Bundle. The default implementation of Activity. onSaveInstanceState is to traverse allContains id attributesAnd call the View. onSaveInstanceState () method in sequence. OnSaveInstanceState is the method of android. view. View, so this method is available for all widgets inherited from View. View. onSaveInstanceState () stores some information about the View, such as the selected item.

Because Activity. the onSaveInstanceState method only stores the UI information of the View containing the id attribute in the Activity. Therefore, we recommend that you add the id attribute to the View during encoding, in this way, the onSaveInstanceState method of the View can be called during execution of the preceding method to store the UI information of the View.

To override the onSaveInstanceState method, first call super. onSaveInstanceState (bundle ). During rewriting, persistent data should not be stored here (for example, to write persistent data to SQLite data). In this method, only some transient variables related to the UI should be stored, for example, sometimes some member variables store some UI-related information, which can be stored in onSaveInstanceState.
Bundle is not designed to store a large amount of data (such as bitmap), and the data in the Bundle must be serialized and deserialized. Therefore, the onSaveInstanceState should not store a large amount of data.

OnSaveInstanceState is called only when the Activity is to be killed and it is predicted that it will be re-created after a period of time. That is to say, the onSaveInstanceState is called to re-generate the restore after the Activity is destroyed. If the Android Framework considers that the onSaveInstanceState condition is not met, this method will not be called. Specifically:

If you exit the program explicitly by using the back key, the onSaveInstanceState method is not called.

If Activity A is started, Activity B is opened, and part of A is masked, The onPause METHOD OF A is triggered, however, the Framework may avoid calling the onSaveInstanceState method of a (if A is not killed in the lifecycle of B ).

Use Fragment to store large amounts of data

Because onSaveInstanceState is not suitable for storing a large amount of data, the onSaveInstanceState function cannot be used to access a large amount of data when the Activity destroys and recreates data and recovers data.

When the Activity is destroyed due to configuration change, the Fragment marked as retained by the Activity will not be destroyed. You can use this feature to access data. The specific method is as follows:

Extends the Fragment class, defines the corresponding fields to access data, and exposes methods for setting and obtaining data, such as setData and getData.

Call the setRetainInstance (true) method in the onCreate method of Fragment, and mark this Fragment as retaininstance

Add the Fragment to the Activity.

In the onDestroy method of the Activity, call the setData method defined above in Fragment to save the data to Fragment.

When the Activity is destroyed and re-generated for onCreate, call getData from Fragmet to obtain the previously saved data.

Finally, pay attention to the occurrence of Memory leakage.

Consider using Loader to cache data

In Android, you can use Loader and LoaderManager to obtain data asynchronously. The Loader mechanism has a good feature: You can continue to hold data during restart execution of the Activity, that is, if the Loader has already loaded the data at the beginning, after the Activity restart, the Activity will immediately obtain the previously cached data from the Loader, instead of loading the data with LoaderManager again, this enables data recovery after restart.

If you do not understand the Loader mechanism, see the following two blog posts:
Use of Loader and LoaderManager in Android (with source code download)
In-depth source code parsing: Loader, AsyncTaskLoader, CursorLoader, and LoaderManager in Android

Use static variables to store data

We know that if the member variable of a class in Java is static, the lifecycle of the static member variable is the same as that of the class. Specifically, when the Java Virtual Machine loads the class, the static member variables of the class are allocated with memory space. When the Java Virtual Machine uninstalls the static member variables of the class, the memory of the static member variables of the class is recycled. Android also has this feature. Assume that there is a static member variable in our Activity. During the Activity restart process, the Java Virtual Machine did not uninstall the Activity, because it will be used in the subsequent restart process, during the restart process, the memory of the static member variable of the Activity is not recycled, in this way, we can write a value in the static member variable that goes to the Activity at restart, and read the value from the static member variable of the Activity after restart, so that the data is held across the restart process. Note that when destroy is caused by non-restart, the static member variable of the Activity must be assigned null to prevent memory leakage.