Research on Android Activity Crash Recovery

The crash recovery of Android Activity is always confused, write a demo test today

premise

a. All boots are standard boots

b. The Main Test startup mode is default, which is standard, and Test2 is singleInstance

 

operate

1. Start Acitvity normally, the startup sequence: Main->Test->Test2->Test The creation process is as follows:

03-15 17:44:11.677 12033-12033/com.dp.kookong_uilib_sample D/App: App: onCreate, pid = 12033
03-15 17:44:11.763 12033-12033/com.dp.kookong_uilib_sample D/MainActivity: DpActivityManagerTestActivity: onCreate
03-15 17:44:14.295 12033-12033/com.dp.kookong_uilib_sample D/DpActivityManagerTestActivity: DpActivityManagerTestActivity: onCreate
03-15 17:44:16.739 12033-12033/com.dp.kookong_uilib_sample D/DpActivityManagerTestActivity2: DpActivityManagerTestActivity2: onCreate
03-15 17:44:17.837 12033-12033/com.dp.kookong_uilib_sample D/DpActivityManagerTestActivity: DpActivityManagerTestActivity: onCreate

2. Trigger NPE in the second Test, the Samsung phone will prompt that XXX has stopped, and then you can choose to restart the App and click to restart (restart the Test directly on the Nubia phone)

03-15 17:44:35.018 12069-12069/com.dp.kookong_uilib_sample D/App: App: onCreate, pid = 12069
03-15 17:44:35.125 12069-12069/com.dp.kookong_uilib_sample D/DpActivityManagerTestActivity: DpActivityManagerTestActivity: onCreate

The App has completed the restart, and now it is a new process, but only the Test has been restored. Now the App has two tests, which one will it be? Look down.

3. Click back

03-15 17:45:04.613 12069-12069/com.dp.kookong_uilib_sample D/MainActivity: MainActivity: onCreate

Returning to Main, confirm that the restored Test is actually the one opened from Main. Where are Test2 and the crashed Test?

4. Click back again, this behavior is the same as the normal operation of the App

03-15 17:45:42.944 12069-12069/com.dp.kookong_uilib_sample D/DpActivityManagerTestActivity2: DpActivityManagerTestActivity2: onCreate

5. Click Return again, the App exits, and the crashed Test is not seen, that is, the system will not restore it.

 

analyze:

A. After the operation of step 1, the status of the Activity stack is as follows, the green color is the same ActivityTask, Test2 has its own Task, and Test2's Task is in the background.

If you click back from Test1 at this time, you can return to the first Test1, then Main, and then Test2

B. After the top Test1 crashes due to NPE, the Android system actually restores the Activity to the first Test1, and the Task of Test2 is still in the background. Note that neither Main nor Test2 has

onCreate

C. Click Return in Test1, the system will create Main, and similarly click Return in Main, the system onCreate Test2, Test2 click Return, and the App exits

 

in conclusion:

1. After the Activity crashes, the Android system will rebuild the ActivityTask, remove the Activity that crashed abnormally from the Task, display the penultimate Activity in the Task, and execute onCreate. 

Other activities in the task will not execute onCreate  (is there a god who analyzes from the source code point of view, whether the activity to be restored is in memory)

2. ActivityTask restoration will also restore all ActivityTasks, as well as the front-end and back-end relationships.

3.  The initialization of singletons, static variables, etc. should not be placed in your StartActivity, which is unreliable. It is recommended to load lazily. If you have to use it, you can put it in the App.   Or directly register the crash Handler and kill the process yourself .The user restarts the App (this is not very reliable, it will be proposed in the extension)

 

Extension: 

The test has encountered in some mobile phones (MIUI system has a high probability), after a period of time in the App background, when the App is launched again, it will restore the Activity that it stayed before, but the singleton and static variables are gone, and finally NPE is exposed. It should also be related to the crash recovery of ActivityTask. In this case, the crashed Handler may not be taken, so the third item may be the bold part. This situation is too difficult to reproduce, sorry it is just an inferred conclusion.