Loading interface activity of Android system programming introduction series

Referring to the application initialization loading and its life cycle last time, after the Android system calls applicaiton. Oncreate(), continue to create and load the first interface registered in the manifest file, that is, the main activity, which can also be called the entry interface. The determination rules of the main activity are introduced in the list file of the Android system programming introduction series. This paper mainly introduces the life cycle process after the Android system creates an activity. All interfaces registered in the manifest file are user-defined activities, and their parent classes trace back to the upper level and must inherit from android.content.activity.

As the first of the four components, activity is mainly responsible for visual interactive response with system users. Only by deeply mastering the life cycle of activity and related concepts can we be comfortable in development and design. Note that the life cycle introduction here is different from the official life cycle definition, and the scope in this article is broader.

The life cycle of Android components is called by the main thread of Android system. If there is a time-consuming operation in the called life cycle method, the subsequent life cycle method will not be called in time. If it is reflected on the interactive interface, the application is stuck or even the operation is not responding. To prevent this from happening, the Android system defines that when the application timeout no response time exceeds a certain length of time (interface activity defaults to 5 seconds), the application no response error anr will be triggered, and a prompt dialog box will pop up on the interface for users to choose to exit, stop responding or continue waiting. Therefore, time-consuming operations are not allowed in the life cycle method.

The startup of interface activity needs to be operated through android.content.intent intent intent. The creation of intent can be divided into two types: display intent and implicit intent. As the name suggests, the display intention is to specify the specific package name and class name of the activity, while the implicit intention only needs to specify the action and category tag information embedded when the activity is registered in the manifest file. The created intention can be used as a parameter to start the interface activity. The display diagram is often used to start the interface activities in the current application, while the implicit diagram is mostly used to start the interface between different applications.

Recall that in the listing file article of the introduction to Android system programming series, it is said that when registering the main activity, the < intent Filter > < / intent Filter > tag must be embedded in its tag, and the contents of the < action > and < category > tags are fixed and unique in the tag. The reason for this writing is that the Android system is created to implicitly start the main activity in the application. Draw inferences from one example and leave a question to consider. If there are fixed < intent Filter > < / intent Filter > tags of the above main activities in the manifest file of an application, how will the Android system call these activities after starting the application? (the answer will be revealed in the corresponding video tutorial)

After the Android system finds the intended interface activity through the manifest file, it will instantiate the interface activity object and put it into the specified task stack of the current application. The task stack, as its name suggests, uses the first in last out mode to manage the data structure of all interface activity objects launched by the current application.

When the interface activity starts, it is put into the task stack. When the interface activity exits, its object is taken out of the task stack and destroyed. However, if an application only corresponds to one task stack, in some scenarios of frequent startup and exit of a single interface, the interface instances will be frequently created and destroyed, wasting a lot of CPU time. In order to optimize the instantiation process of the interface, the Android system allows an application to use multiple task stacks. This leads to two questions. One is how to specify a specific task stack from multiple task stacks as the interface startup management task stack? Second, what are the rules for putting different task stacks when the interface is started?

For the first question, when statically registering the interface activity in the manifest file, you can assign a value to the attribute name taskAffinity in the < activity > < / activity > tag. The attribute value defaults to the current application package name, so as to specify the task stack to which the current interface activity belongs. This attribute can also be used in the < Application > < / Application > tag, indicating that all interfaces in the current application use the task stack management corresponding to the attribute value when starting. Meanwhile, in the interface activity, you can use gettaskid () to obtain the ID value corresponding to the task stack to which the current interface activity belongs.

For the second problem, you can determine the rules to put into the task stack according to the startup mode of the interface activity. When the < activity > < / activity > tag is statically registered in the manifest file, the startup mode can specify its attribute launchmode assignment; It can also be set dynamically by calling its setflags (int flags) method after the intention intent operation is created. If the dynamic setting mode overrides the static setting mode, if the startup mode is not set, the default mode will be used for startup. There are four main startup modes. Refer to the following table for specific modes and corresponding attribute values.

Like application, activity inherits from android.content.contentwrapper and binds the context environment when it is used. In particular, among all android.content.contentwrapper subclasses defined by Android SDK, only android.content.activity class overrides attachbasecontext (context base) method. Therefore, after the interface activity is instantiated, the system will finally call the android.content.activity.attachbasecontext (context base) method to complete the task of binding the current interface to the context environment.

Similarly, it is not recommended to rewrite this method when the interface activity loads the running environment. All operations in the interface should be completed after this method.

After the interface loads the running environment, the Android system completes the creation of the interface. After that, the system calls back the oncreate () method, which is officially called the created state. At this time, the current activity is still in the background and not displayed to the user, so you can override this method to complete the initialization of relevant variables in the interface.

After the interface is created or re displayed, the system will call back the OnStart () method to draw the current activity to the user. Officially, it is called the started state. If you override this method, you can complete the interface initialization shown to the user.

After the interface is displayed, the system will call back onresume () method to enable the interface to interact with the user, which is officially called restored state. At this time, the system begins to respond to user interaction in the interface, which also indicates that the current interface activity is running.

After calling the life cycle method, the system will always be running in the interface until some operations of the user change the state of the interface. These user actions include but are not limited to:

When the running state of the interface is changed, the system will first call onpause() method. At this time, the system has stopped the interactive response operation between the current interface activity and the user, which is officially called suspended state. This method can be rewritten to release some unnecessary but power consuming system resources to prevent invalid holding of power consumption. However, the interface is still visible to the user at this time, so it is not recommended to perform time-consuming release operation in this method to avoid the illusion of jamming to the user.

After this state, the Android system judges the subsequent life cycle process according to the previous user operation type. Operations 1, 2, 3, 6 and 7 may continue to stop the display of the current interface activity. Operations 4 and 5 may return when the user clicks the interface again. At this time, they will return to the life cycle of the interface.

When the system stops the display of the current interface Activiy, it will call the onstop () method to make the current interface invisible to the user. Officially, it is called the stopped state. When rewriting this method, you can release the interface resources and unnecessary CPU time-consuming resources for other places to obtain in time.

After this state, the Android system continues to judge the subsequent life cycle process according to the previous user operation type. Operation 1 will put the newly started interface activity into the task stack where the current activity is located. When the newly started interface returns, the current interface will be displayed again. Operation 2 takes the current interface from the task stack and destroys it. Operation 3 may take all interfaces of the current application, including the current interface, from the task stack and destroy them when the mobile phone memory is insufficient. Operation 6 will sleep the current application and re display the current interface after the device is re illuminated; Some devices may also be killed by the system after the current application exceeds a certain time or the sleep period occupied by memory, that is, all interfaces of the current application, including the current interface, are taken out from the task stack and destroyed. Operation 7 will destroy all interfaces of the current application and will not call any life cycle of the current interface.

When the interface changes from invisible to visible, if the interface has been created before, onrestart () method will be called to indicate that the current interface will be displayed again. Overriding this method can handle the operation after it is re visible to the user.

After the method is called, the system will continue to call the interface display and operation to re run the interaction between the interface and the user.

After the interface activity is removed from the task stack, if the application is still under the control of the Android system, the system will destroy the interface after calling the ondestroy () method, which is officially called the destroyed state. Overriding this method frees up all unnecessary resources to prevent memory leak oom problems.

The above content is for the loading process of a single interface activity. What is the communication mode between the two interface activities involved, and how to deal with the interaction with users after the interface is running? Please pay attention to the following articles for details.