Life cycle of activity in Android

︿(￣︶￣)︿

Confucius said: if you review the old and know the new, you can be a teacher. The Analects of Confucius

Learning technology is the same. For technical documents or classic technical books, it is almost impossible to fully grasp them once. Therefore, we need to often go back and study them carefully several times to understand the author's ideological essence.

Recently, I reviewed the life cycle of activity, read relevant books and official documents, and gained a lot. My previous cognition has been greatly improved. I'll share it with you here.

Friends familiar with Java EE know Servlet Technology. If we want to implement our own servlet, we need to inherit the corresponding base class and rewrite its methods. These methods will be called by the servlet container at the right time. In fact, the activity operation mechanism in Android is similar to that of servlet. Android system is equivalent to servlet container, and activity is equivalent to a servlet. Our activity is in this container, and all processes such as instance creation, initialization and instance destruction are called by the container. This is the so-called "don't call me, I'll call you." mechanism.

Let's take a look at this classic life cycle flowchart:

I believe many friends have seen this flow chart and basically understand several processes in the activity life cycle. Let's talk about these processes.

1. start Activity: the system calls the onCreate method first, then calls the onStart method, finally calls onResume, and Activity enters the running state.

2. The current activity is overwritten or locked by other activities: the system will call onpause method to suspend the execution of the current activity.

3. The current activity returns to the foreground or unlock screen from the overwritten state: the system will call onresume method to enter the running state again.

4. now Activity is going to the new Activity interface or by pressing the Home key back to the main screen and returning to the background itself: the system will first call the onPause method and then call the onStop method to enter the stagnation state.

5. after the user returns to this Activity: the system will call the onRestart method first, then call the onStart method, and finally call the onResume method to enter the running state again.

6. The current activity is in the overwritten state or invisible in the background, that is, in steps 2 and 4, the system memory is insufficient, kill the current activity, and then the user returns to the current activity: call oncreate method, OnStart method and onresume method again to enter the running state.

7. the user exits the current Activity: the system calls the onPause method first, then calls the onStop method, and finally calls the onDestory method to end the current Activity.

But knowing these is not enough. We must try them ourselves in order to deeply understand and master them.

Let's demonstrate the details of several processes in the life cycle with examples. We create a new project named lifecycle and create an activity named lifecycleactivity, as follows:

Note that in addition to several common methods, we have also added onwindowfocuschanged, onsaveinstancestate and onrestoreinstancestate methods:

1. Onwindowfocuschanged method: called when the activity window obtains or loses focus, for example, it is presented to the user for the first time during creation; The current activity is overwritten by other activities; Switch the current activity to another activity or press the home key to return to the main screen and retreat to the background; The user exits the current activity. Onwindowfocuschanged will be called in the above cases, and when the activity is created, it will be called after onresume. When the activity is overwritten or retired in the background or the current activity exits, it will be called after onpause, as shown in the figure:

This method is still useful in some situations. For example, when the program starts, if you want to obtain the size of a specific view component, you may not be able to obtain it in oncreate, because the window object has not been created yet. At this time, we need to obtain it in onwindowfocuschanged; If you have read my article on frame animation of Android animation, you will know that the reason why I tried to load frame animation in oncreate failed was that the window object was not initialized, so finally I put the code for loading animation into onwindowfocuschanged, and the problem was solved. However, you may wonder why I commented it out in the code, because each operation of the current activity has its execution log. I'm worried that this will affect the clarity of the whole process, so you can note it out. You just need to understand its application occasion and execution order.

2. Onsaveinstancestate: (1) after the activity is overwritten or retired to the background, it will be killed due to insufficient system resources. This method will be called; (2) This method will be called when the user changes the screen direction; (3) This method will be called when the current activity jumps to another activity or presses the home key to return to the main screen and retreats to the background. In the first case, we cannot guarantee when it will happen, and the system will schedule according to the resource tension; The second method is to destroy the current activity and then rebuild a new one when the screen is flipped. When this method is called, we can save some temporary data; In the third case, the system calls this method to save the status of each view component of the current window. Onsaveinstancestate is called before onpause.

3. Onrestoreinstancestate: (1) after the activity is overwritten or retreated to the background, it will be killed due to insufficient system resources, and then the user returns to the activity, and this method will be called; (2) This method is called during the reconstruction process when the user changes the screen direction. We can override this method so that we can recover some temporary data. Onrestoreinstancestate is called after OnStart.

After focusing on three relatively unfamiliar methods, let's operate the activity to see what kind of process its life cycle is:

1. Start activity:

After the system calls onCreate and onStart, the onResume is called, and Activity has entered the running state since then.

2. Jump to other activities, or press the home key to return to the main screen:

We can see that the onsaveinstancestate method is called before onpause at this time, and note that onstop is called after onpause when stepping back in the background.

3. Back to the front desk from the background:

When coming from the background to the front desk, the system calls the onRestart method first, then calls the onStart method, and finally calls the onResume method, and Activity goes into the running state again.

4. Modify the configuration of targetActivity in androidmanifest.xml, set the Android: theme property to @ Android: style / theme.dialog, and then click the button in lifecycleactivity. The jump behavior will change to that targetActivity overrides lifecycleactivity. At this time, the method called is:

Note that another situation is that we click the button and just press the lock screen key, and the execution effect is the same as above.

We note that the onpause method of lifecycleactivity is called instead of the onstop method, because lifecycleactivity does not retreat to the background, but is overwritten or locked; Onsaveinstancestate will be called before onpause.

5. Press the back key to return lifecycleactivity from being overwritten to the front, or press the unlock key to unlock the screen:

At this time, only onresume method is called and directly enters the running state again.

6. Exit:

Finally, the ondestory method is called, marking the end of lifecycleactivity.

You seem to notice that there is no onrestoreinstancestate in all processes, which is not surprising, because as we said before, onrestoreinstancestate can only be called in the two reconstruction processes of killing an activity not in the foreground, returning to the activity, or changing the direction of the screen. It is difficult for us to demonstrate the first case. We can demonstrate the specific process in combination with the second case. By the way, I'll also explain to you the strategies to deal with the change of screen direction.

First, let's introduce some knowledge about the screen orientation of activity.

We can specify a specific direction for an activity. After that, even if the screen direction is rotated, the display direction will not change:

1. Specify as vertical screen: set Android: screenorientation = "portal" for the specified activity in androidmanifest.xml, or specify in oncreate method:

1 setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT); Vertical screen

2. Specify as horizontal screen: set Android: screenorientation = "landscape" for the specified activity in androidmanifest.xml, or specify in oncreate method:

1 setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE); Horizontal screen

Setting specific directions for activities in applications is a frequently used method, which can save us a lot of unnecessary trouble. However, today we are talking about the life cycle when the screen direction changes, so we do not adopt the method of fixed screen direction.

Let's explain the life cycle of screen transformation with examples. We create a new activity named orientationactivity, as follows:

First, we need to enter "Settings - > display" and select "auto rotate screen" to indicate that the screen can be rotated automatically according to the direction, and then we can test the process. When we rotate the screen, we find that the system will destroy the current activity first and then rebuild a new one:

The system first calls the onsaveinstancestate method. We save a temporary parameter to the bundle object. Then, after the activity is rebuilt, we successfully take out this parameter.

In order to avoid the destruction and reconstruction process, we need to configure Android: configchanges = "orientation" for the < activity > corresponding to the orientationactivity in androidmainfest.xml, and then we test it again. I tried to rotate it four times, and the print is as follows:

You can see that each time you rotate the direction, only the onconfigurationchanged method is called, and there is no destruction and reconstruction process.

Here are some points to note:

1. If < activity > is configured with Android: screenorientation attribute, Android: configchanges = "orientation" will be invalidated.

2. The simulator is very different from the real machine: if the Android: configchanges attribute is not configured in the simulator or the configuration value is orientation, switch to the horizontal screen for destruction - > reconstruction, and switch to the vertical screen for two times. The real machine is once. In the simulator, if Android: configchanges = "orientation|keyboardhidden" (in the case of Android 4.0, "orientation|keyboardhidden|screensize") is configured, perform onconfigurationchanged once on the vertical screen and twice on the horizontal screen. The real machine is once.

Transferred from: http://blog.csdn.net/liuhe688/article/details/6733407