Analysis of Android activity management

1. Activity Lifecycle

Activity management is also based on the C/S architecture. All activity management is performed on the server. When the server schedules each activity, the client responds to the functions of each lifecycle.

On the client side, the response to each lifecycle of the activity is operated in activitythread. Locally, the lifecycle of an activity is as follows:

 

 

Activitythread provides the following scheduling interfaces to the server:

Schedulelaunchactivity ()

Scheduleresumeactivity ()

Schedulepauseactivity ()

Schedulestopactivity ()

Scheduledestoryactivity ()

Schedulerelaunchactivity ()

Schedulewindowvisibility ()

In addition to the above interfaces, there are other interfaces such as scheduleconfigurationchanged () and schedulenewintent (). Because these interfaces do not affect the activity lifecycle process, they are not listed here. Next we will pick two main interfaces to analyze the calling process on the local end.

1. schedulelaunchactivity

This interface is used to generate a new local activity object and bring it into the resume status (or pause status ). Normally, AMS calls this interface in two cases: Click the application icon to open a new application; When Activity B returns activity A, Activity A is killed due to insufficient memory. As for how AMS determines when to call this interface, it is the internal scheduling process of AMS for the activity, which will be analyzed later.

The following describes the naming rules and function calling methods of various activitythread functions.

All the interfaces provided with AMS listed above are prefixed with schedule, and all interfaces are sent to the handler of the main thread immediately after the command message is sent. In this way, all operations will be transferred to the main thread. Each schedule *** function has a handle *** function that responds to the operation. In the handle *** function, operations are further divided into several actions as needed, and the actual activity-oriented operations are uniformly named as perform ***. In the perform *** function, the lifecycle function of the activity is actually called (in fact, indirectly through insturmentation ). Therefore, we can layer all interfaces and Methods: Schedule-> handle-> perform-> activity/insturmation.

 

In schedulelaunchactivity, a "launch_activity" message is sent to the main thread handler, and handlelaunchactivity is called. Handlelaunchactivity is divided into two actions:

A) initialize mlaunchactivity

The activity object and the activity living environment are created here. For example, the application object is generated. Then, call activity. Attach () to create the window and windowmanager, and record the activity environment variables such as mtoken and mactivityinfo. So far, an activity object with complete functions has been initialized, And the minstrumentation will be called. callactivityoncreate () and activity. every mstart () responds to the oncreate () method and onstart () method that belong to the activity life cycle respectively.

B) handleresumeactivity

This method is another method of the "handle layer". It mainly completes the response of onstart () and onresume (), which will be described in the second example.

 

2. scheduleresumeactivity

As the name suggests, this method is used to place an activity in the resume state. Correspondingly, all operations are transferred to handleresumeactivity. Handleresumeactivity can be called in either case: scheduleresumeactivity sends the "resume_activity" message; Step 2 in handlelaunchactivity.

Handleresumeactivity is further divided into two actions:

A) receivmresumeactivity

Call activity. restore mresume () method, in activity. when mresume () is called, mrestart () is called by default. The function of receivmrestart () is to check whether the activity is in the stopped status. If yes, call receivmrestart () and then call receivmstart (). Finally, respond to the activity's life cycle method onresume ().

Therefore, the response process for opening a new activity is:

Oncreate ()-> onstart ()-> onresume ()

The Response Process for returning a background activity is:

Onrestart ()-> onstart ()-> onresume ()

B) after completing the response to the activity lifecycle in the first step, in the second step, add the decorview TO THE windowmanager window. After step 2 is completed, the activity content is displayed on the screen. The window adding action is a step in window management. For details, refer to the android window management analysis.

 

The following is the internal call flowchart of the response from some major interfaces to the lifecycle.

 

 

 

 

2. activitymanagerservice and its internal scheduling process

1. Data Structure Analysis

Like the window management system, all client activities have a corresponding activityrecord in activitymanagerservice (AMS). activity management is also the management of activityrecord.

The relevant Code of AMS is in framework/base/services/Java/COM/Android/Server/AM. The main data structures include:

Activitymanagerservice

Activitystack

Activityrecord

Taskrecord

Processrecord

 

1) activitymanagerservice is an android Framework Service that processes the management of four Android components and responds to client requests. It also includes process generation and windowmanagerservice operations.

2) activitystack is a module dedicated to stack-based Management of activityrecord. Before android2.2, activityrecord management and scheduling were implemented in activitymanagerservice. After android2.3, to achieve better decoupling, the management of activityrecord is separated separately. All the scheduling operations on activityrecord are carried out in activitystack. In fact, the so-called "activity stack" in Android is not a real stack structure, but an arraylist list, which records all activityrecord, what activitystack does is to ensure that the first activityrecord (that is, the top of the stack) in the list is running, the running status of the activityrecord after the list is affected by the "top stack" activityrecord.

3) activityrecord indicates a client-side activity, which records various attributes and Management statuses of the activity. There is a key member variable:

Iapplicationtoken. stubapptoken

Apptoken is the unique identifier of the activityrecord, and runs through AMS, activity, and WMS.

 

Taskrecordtask

The task identifies the task to which the activityrecord belongs. In the position adjustment of activityrecord by activitystack, the unit is taskrecord. For example, interfaces such as movetasktofront () and movetasktoback () Move all the activities belonging to the same task at the same time. Taskrecord and activityrecord are one-to-multiple relationships. Multiple activityrecord may point to the same taskrecord.

 

Processrecordapp

The app identifies the process where the activity of the client is located. Similarly, processrecord and activityrecord are one-to-many relationships. Multiple activityrecord may point to the same processrecord. You can access iapplicationthread in processrecord to directly operate the activitythread of the client.

 

4) taskrecord records attributes such as the task id and name.

We know that activity management is performed in the unit of task, and multiple similar activities will be classified into the same task. Generally, all the activities in an APK belong to the same task, and the task is named by the package name of the APK. However, developers can configure different tasks for each activity through the Android: taskaffinity attribute in androidmanifset. xml. When will a new task be created and the name of the new task be determined by the logic in activitystack, depending on the flag passed in the configuration in androidmanifest. xml and when startactivity () is called.

 

5) processrecord records the process ID, process name, and various States used to adjust the priority. It also contains all the activities, services, referers, providers, and other components that run in the process. The iapplicationthread thread records the main thread in the process. When an acitivity is started for the first time, process. Start ("android. App. activitythread") is called to create a new process and generate a processrecord object. When a process runs, the main thread of the process calls the activitythread of the client. the main () function completes the prepare () of logoff in the main () function and generates the activitythread object. call iactivitymanager in attach. attachapplication () is returned to AMS to bind the processrecord and iapplicationthread objects in AMS. The next process binds the new activity to processrecord.

 

The relationship between activitymanagerservice, activitystack, activityrecord, taskrecord, and processrecord can be expressed as follows:

 

 

 

 

2. activitystack internal scheduling process

Throughout the scheduling process, activitystack records the current status of each activityrecord in the list, including the nine States initializing, resumed, pausing, paused, stopping, stopped, finishing, destroying, destroyed. Each activityrecord is in one of the nine States at any time. In addition, activitystack has several variables used to assist the scheduling process:

Activityrecord mresumedactivity

Activityrecord mpausingactivity

Boolean Finishing

Boolean stopped

Arraylist <activityrecord> mstoppingactivities

 

Mresumedactivity points to the "Stack top" activity in the current system. When the "Stack top" activity is about to be paused, mresumedactivity is blank and mpausingactivity points to the paused activity, callback AMS after the client activity responds to onpause (), and The mpausingactivity is left empty. Finishing and stopped are two Boolean variables of activityrecord. If finishing is set to true, the activity will be destroyed; if stopped is true, the activity is in the stopped state (the stopped variable and the stopped state of the activity are suspected to be repeated and can be considered to be the same ).

The internal scheduling of activitystack is centered around these nine States. The following uses an example to analyze the scheduling process.

Open a new application from launcher (a) (B)

1) after a clien request opens a new activity, activitystack first creates an activityrecord and places it on the top of the stack. At this time, activityrecord is in the initializing state.

2) Call resumetopactivitylocked (). In resumetopactivitylocked (), check whether the mresumedactivity is empty. In this case, the mresumedactivity points to a, so it must not be empty.

3) Call startpausinglocked () to suspend. In this case, set mresumedactivity to null, mpausingactivity to A, and set the status of a to pausing. Then, call schedulepauseactivity () on the client side of Activity A to suspend the service.

4) The client-side activity responds to onpause () and calls back the activitypaused () method of AMS. It sets the activityrecord status of a to paused and adds a to mstoppingactivities. After the pause process of a is completed, the system will return to step 2nd. In step 2, The mresumedactivity is empty, and the subsequent process will eventually call schedulelaunchactivity () at the client end of Activity B (). The status of Activity B changes to resumed.

5) The client of activityb completes activity new and initialization, responds to oncreate ()-> onstart ()-> onresume (), and calls back activityidle () of AMS () the method indicates that the AMS is idle.

6) activityidlelocked () is mainly used to complete the "aftermath" after the "stack" is adjusted. For example, you can complete the pending destruction operation based on the finishing status, and process the pending stop operation in mstoppingactivities. After step 1, A is already in mstoppingactivities. Therefore, schedulestopactivity (booleanvisible) on the client side of a will be called NeXT. on the client side, it is determined by the interface parameter visible, if visible is false, onstop () is returned; otherwise, no response is returned. In activitystack, the value of visible is calculated from top to bottom. If the activity on the top of stack is fullscreen, the visible value of all other activities under the activity on the top of stack is false. This computation process is executed once or multiple times in step 1. During the stop operation, the activity
The status of a changes from paused to stopping and then to stopped.

 

In step 4th, the system will continue to call resumetopactivitylocked (). In resumetopactivitylocked (), the system will judge whether the processrecord app in activityrecord is empty. There are two situations:

A) the app is not empty.

The premise of this situation is that activity B is not newly opened but always in the background, and its process is not killed due to memory recycle. In this case, scheduleresumeactivity () is called directly, and the client responds to onrestart ()-> onstart ()-> onresume ()

B) the app is empty.

There are three scenarios where the app is empty. The first is that activityb has been running in the background and is killed due to insufficient memory. The second is that activity B is newly opened and does not have a corresponding process; third, Activity B is newly opened, but its process is still running. In the first and second cases, AMS starts a new process and binds Activity B to the processrecord of the new process.

In these three cases, schedulelaunchactivity () is called at the end, and the client returns oncreate-> onstart ()-> onresume ().

 

Therefore, the lifecycle Response Process for opening a new activity (B) from launcher (a) is as follows:

A-> onpause ()

B-> oncreate ()

B-> onstart ()

B-> onresume ()

A-> onstop () (if B is not fullscreen, this method is not responded)

 

The entire scheduling process can be expressed as follows:

 

 

 

 

Other functions involved in scheduling in activitystack are sorted out and the following function call flowchart is obtained.