The life cycle of an application mentioned here does not mean the life cycle of an application at the product level from R&D to launch, but the life cycle of the application itself. Although the concepts of these two life cycles are not the same, there is a process from birth to death on the level of life, and the two are the same in this regard.
The life cycle of an application is a description of the process from creation, operation, and death of an application in the host environment. For users, an intuitive feeling is that an application is started, the application is exited, and the application is in the background. In fact, an application will have many life cycle state descriptions in the actual running process. Take an Android application as an example:
The Activity in this picture can be simply understood as the application interface presented to the user. You can see that there are eight states that are switched in a certain order. The upper part belongs to the creation and the lower part belongs to the extinction, but the whole process is not It is not completely impossible to go back, the life cycle on the path of death can also jump to the life cycle on the corresponding creation path. The life cycle of the application is not controlled by the application developer. The developer can only issue some instructions to the host system, such as starting an activity, exiting an activity, and the host system starts to control the activity or create or destroy it, and the key to the whole process The node informs the application developer.
Each node here has its own meaning:
onCreate means that the application has started to be created, but at this time the interface of the application does not show a user. Developers can create the data that needs to be displayed here, and build some views. In fact, the system is relatively fast in processing application drawing, but we often find some The application did not respond after clicking to launch it from the desktop for a long time. After a while, the interface pops up. The problem lies here. Many applications write a lot of time-consuming operations in this life cycle during development, which jams the subsequent interface drawing related operating.
For example, there is a large amount of data in a software database, and the developer hopes that the data can be displayed to the user in the form of a list as soon as the application is started. Therefore, a large amount of data is read in onCreate and a long list is constructed. Before all this is ready, what the user sees is that there is no movement for a long time, and the experience is naturally not good, but the interface is shown to the user before the data and view are ready, and the user sees a blank interface? Yes, but many times the program design adopts some circumvention methods to find a balance between stuck and blank pages, such as reading only a small amount of data, building a small number of views, and presenting the interface to the user as soon as possible. To load more data and views, there is a simple and rude way is the splash screen. OnCreate is the life cycle of the post picture, let the program enter the drawing process as soon as possible, and wait for the user to see the splash screen, and then load slowly. Data view, so at least it won’t be boring and inexplicable. Of course, many users don’t like splash screens, and they still feel slow and salty, so there is another way to save the screenshot of the application when exiting, and use the previous screenshot as the splash screen when starting, so that the application startup at least seems to be faster .
onStart and onResume are called after onCreate in turn, but the application has not yet entered running. Why do you want to remove the intermediate state of this subdivision? This needs to be explained in conjunction with onPause and onStop. From the life cycle diagram, we can see that onCreate is not reentrant (called repeatedly during a complete life cycle), while onStart, onResume, onPause, and onStop are reentrant. When the interface has been presented to the user, but at this time there is a popup block blocking part of the application interface, but the application interface is still visible, then the application enters the onPause state, when the popup disappears, the application enters the onResume state, but if it is not The pop-up window, but the start of other applications completely block the current application interface, then the current application enters the onStop state, when the blocked application disappears, the blocked application will return to the onStart state (there is an onRestart state in the middle) , And the onStart state is that it will not be called during the beginning of this life cycle), of course, not only is it hidden by other applications, the user’s active background, which makes the application invisible, will also trigger onStop, in many During optimization, when the application is not visible, the developer will actively release part of the application’s resources, reduce system consumption, and free up more resources for other applications.
OnDestroy is the opposite of onCreate. Once applied to the onDestroy stage, there is no way to go back like onPause and onStop. Usually this life cycle is called back when the system destroys the Activity after the application developer issues an instruction to exit the application to the system. And exiting the application is also prone to problems like onCreate. For example, we often see that some applications will get stuck after clicking the exit, and then disappear. After reading the previous analysis of onCreate, the reason here is easy to analyze, that is, the user clicks After pressing the exit button, the application developer issued an instruction to close the Activity to the system. At the same time, the developer did many time-consuming operations to destroy resources. At this time, the application interface is still visible. These operations stuck the subsequent interface destruction process. , So the user’s impression is to pause for a while after clicking quit. The solution is also very simple. Do time-consuming operations in the life cycle after the interface is invisible in the program exit process, so that the interface does not block the user from doing other things, and the user will not feel it.
If the above is not easy to understand, we can look at these life cycles like this, onCreate (people are born), onStart (people wake up), onResume (people open their eyes), onPause (people close their eyes), onStop (people sleep)着), onDestroy (people died). Birth and death are irreversible, but waking up and sleeping, opening and closing eyes are repeated in a person’s body. First, you must close your eyes and then fall asleep. When you wake up, you will open your eyes and start activities. After being born, they will experience waking up, opening their eyes, and closing their eyes and falling asleep before worshipping, and responding to Xiao Shenyang’s saying: Once your eyes are closed and opened, a day has passed, and if you don’t open it, a lifetime will pass We don’t consider the special people who sleep with their eyes open, and the special circumstances of the deadly eyes).
After understanding these life cycles, you can feel the pros and cons of program design by playing with your own or other people’s applications, and you can occasionally offer some constructive comments.
