[Android Q & A] How to Deal with activity process killing?

We need to understand the main difference between Android mobile phone Development and desktop development: an Android mobile phone usually runs multiple applications (Apps) at the same time, and each app corresponds to a system process, when the system requires more resources (such as memory) and the idle resources are insufficient, the android system will kill some low-priority processes to release the required resources.

How does the Android system determine the priority of processes?

• If an app is interacting with users, the process in which it is located has the highest priority;
• Second, if an app is visible, for example, partially blocked by a dialog box, its process has a second highest priority;
• Again, if the app is not visible at present, that is, it is switched to the background, the process in which it is located has the highest priority, if the background app starts a service, it has a higher priority than the general background app.
• Finally, if a process does not contain any app, the priority of the process is the lowest.

When system resources are seriously insufficient, any process may be killed. When a user wants to return to an activity that does not exist in the memory, the system has to create such an activity object and call its oncreate () method to restore it. So sometimes this situation occurs: an app runs well most of the time, and occasionally a null pointer exception occurs during activity switching, causing forced shutdown, which is mostly in oncreate () this method uses an object that has been reset to null (such as a variable in intent. Even if no exception occurs, it may cause forms data loss and other problems that seriously affect the user experience.

To solve this kind of problem, you must be cautious about the concept of "the current mobile phone memory is large, and the process will not be killed, the following describes the recommended methods for Google.

Solution

Because the activity may need to be rebuilt at any time, what we need to do is to persist the data required by the activity at the appropriate location (copy from Ram to Rom or SD card), and in oncreate () use these methods to recover data to the site.

There are two types of activity data that need to be processed persistently: "document-type data" and "internal state-type data". The former is the form that the user is editing, and the latter is the user's preference.

1. To persist document-type data, Google recommends using the "edit in place" Editing Policy. The specific method is as follows:

• When you create a document, you can also create a new record in the SQLite database (you can also use preference as needed. (In contrast, a "save" button is provided for the user to save the document to the database only when the user presses the button .)
• When the user leaves the current activity, the onpause () method will be triggered, in which the document being edited Will be persisted to the database. In this way, if you switch from this activity to another activity, you can still see the saved content.

This method can avoid data loss to the maximum extent. As long as the onpause () method is triggered for execution, even if the process of the activity is killed by the system, data will not be lost. The only thing to note is that it is best to provide a "cancel" button or menu on the interface so that users can selectDo not saveChanges to the document.

2. To persist internal state data, you can use the activity # getpreferences (INT) method in onpause (). This method returns objects of the sharedpreferences type, it can be used to record users' preferences for this activity. For example, a calendar application can be displayed as a weekly or monthly view. Such information is recorded as the internal status after the sharedpreferences object, the next time you open this activity, you can display the calendar as selected by the user.

BelowCodeThis document demonstrates how to persist and restore the current display mode of an activity:

  Public  Class Calendaractivity Extends  Activity {...  Static   Final   Int Day_view_mode = 0 ;  Static   Final   Int Week_view_mode = 1 ;  Private  Sharedpreferences mprefs;  Private   Int Mcurviewmode;  Protected   Void  Oncreate (bundle savedinstancestate ){  Super  . Oncreate (savedinstancestate );  //  Retrieve the previous persistent calendar display mode Sharedpreferences mprefs = Getsharedpreferences (); mcurviewmode = Mprefs. getint ("view_mode" , Day_view_mode );}  Protected   Void  Onpause (){ Super  . Onpause ();  //  Persistent calendar display mode Sharedpreferences. Editor ED = Mprefs. Edit (); ed. putint ( "View_mode" , Mcurviewmode); ed. Commit ();}} 

It is a little troublesome, but it is worth it to make the app run stably.

Some may ask, why is it persistent in onpause () instead of in onsaveinstancestate? The following section briefly explains the reason: the former is more reliable than the latter because onsaveinstancestate () is not part of the activity lifecycle. -- In this case, I can't think of any other usage of onsaveinstancestate (). Let's just forget it and there is onrestoreinstancestate ().

Note that it is important to save persistent data in onpause () instead of onsaveinstancestate (bundle) because the latter is not part of the lifecycle callbacks, so will not be called in every situation as described in its documentation.

Note 1: I personally prefer persistence in onpause () due to some disputes on the Internet. The only drawback is that the number of calls is slightly higher.

NOTE 2: Starting from Android 3.0 (honeycomb), before the activity process is killed by the system, the onstop () method is executed first, therefore, if the application we develop only runs more than 3.0, you can put the persistence work in onstop () to reduce the number of persistence times.

Best practices

Do not be lucky. Your activity may be destroyed at any time.

Solution:Persist activity data in onpause () and restore the site in oncreate ().

References:

Activitysaving activity state in Android