In-depth understanding of activity startup mode

see this today, feel good, so the collection of

Author's original connection is divided into 3 articles:

• In-depth understanding of activity startup mode (i) –activity relationship with process, thread
• In-depth understanding of Activity Startup mode (ii) –activity, fallback stack, task relationship
• In-depth understanding of activity startup mode (iii) –activity startup mode features

Overview

The Android website introduces the Activity's startup mode in a vague way, introducing concepts such as application,activity,task,process,thread and the relationship between them, and it doesn't make sense. You may find it confusing when you look at the introduction of the activity startup mode on the Android website. Introduction Singletask startup mode, said that as long as the start Singletask startup mode activity will create a new task, but in the actual operation, if the same application of two activity, If one of the activity's startup modes is Singletask, an activity's startup mode is standard, from which one activity jumps to another activity, and no new task is created.

In order to relieve these puzzles, the Activity start mode has been researched deeply, so we wrote this series of blogs, elaborated the relationship between concept concepts such as application,activity,task,process,thread, and the characteristics of the starting mode, I hope we can help you understand these concepts.

I. The relationship between Application,activity and Process,thread

We know that application can be declared in Androidmanifest.xml, which consists of 4 large components: Activity,service,contentprovider,broadcastreceiver. When declaring application, you can use Android:name to declare the application class used by this app, and if there is no declaration, an instance object is created directly using the application class of the Android framework.

When the application is first started, a new process is started that uses the app's package name as the process name. The process starts the main thread activitythread, also called the UI thread, and the drawing of the UI is done in that thread. There are also binder service threads in the process that are used to communicate with the system.

In addition, we know that when the activity jumps, we can jump across applications, and say that activity a in application App1 can jump to activity B in the app App2. If activity A and Activity B start mode is standard mode, after jumping from A to B, activity A and activity B correspond to the Activityrecord will be placed in the same task (Activityrecord, The task is managed by the system process, and the next blog will describe these concepts, but the instance objects of acitivity A and activity B are placed in different processes. Assuming that the package named Com.cloud.app1,app2 for App1 is named Com.cloud.app2, the instance object of activity A is in the process COM.CLOUD.APP1, and the activity The instance object of B is in the process COM.CLOUD.APP2.

That is, each application's component runs in the corresponding application process, which uses the app's package name as the process name. The process has a main thread, also called the UI thread, and the application components are running in the UI thread. There is only one exception, if the component is declared with Android:process set the process name, the component will run in a new process, not with the application package name as the process name, but with the package name +:+ set value as the process name

So in general, Service,receiver will also run in the UI thread, and if you do some time-consuming operations in the Service,receiver life-cycle approach, the system will prompt the ANR (Activity not Responde) error.

ii. Activity, fallback stack, task relationship

When activity starts, Activitymanagerservice generates a corresponding Activityrecord record for it and adds it to the fallback stack (back stack). The Activityrecord record is also added to a task. Keep in mind that Activityrecord,backstack,task are activitymanagerservice objects that are maintained by the system_server process and not by the application process.

The activityrecord that belong to the same task in the fallback stack will be put together, and the structure of the stack will be formed, that is, the activityrecord of the activity corresponding to the start will be placed at the top of the task's stack.

Assume the activity's jump order: A–>b–>c,a,b,c corresponding Activityrecord belong to the same task, at this point from C to D, then jump to e,c and D do not belong to the same task,d and E belong to the same task, Now the back stack structure looks like this:

Now A,b,c belongs to Task1,c at Task1 's top, d,e belongs to Task2,e at the top of the stack. You can also see that Task2 is located at the top of the stack of the entire fallback stack, that is, task2 on top of Task1. If you press the fallback key at this time, the order of activity you see is e–>d–>c–>b–>a.

It is also important to note that Activitymanagerservice will not only add new Activityrecord back to the stack, but will also move the Activityrecord in the fallback stack, moving as a task unit, Instead of moving a single acitivityrecord. Or for the example above, assuming that the home key is pressed at this point, then the task of the home application (also called the Launcher application) is moved to the top of the stack, then the fallback stack looks like this:

You can see the activity record of activity h for the home application moved to the top of the stack on the fallback stack. The activity H of the home application makes special handling of the response of the fallback button, and if you press the fallback key at this point, the activity e is not visible.

If the application of activity A is then opened through the Launcher program, activity C is displayed because the task that the activity record of activity a corresponds to is moved to the top of the stack, and the fallback stack looks like this:

Now that the TASK1 is moved to the top of the stack, the task for the home application is under Task1, and Task2 is under the task of the home application, and if you press the back key, the activity is displayed in the following order: C–>b–>a–>h, does not show E.

Of course we can also open the app where D resides in the launcher application, which will move the task2 of D,e to the top of the stack.

Now it's time to understand the task, which is actually a stack of Activityrecord, with multiple tasks composing a fallback stack in the form of stacks. Activitymanagerservice moves the Activityrecord in the fallback stack as a task.

We know that when jumping activity across applications, the two activity corresponding Activityrecord can belong to the same task, and under what circumstances will two activityrecord belong to a different task? Or, when the activity jumps, Under what circumstances will a new task be created?

This problem and activity start mode, taskaffinity, start activity for intent set flag and other factors related.

First of all, taskaffinity, each activity's Taskaffinity property value defaults to the package name, that is, if activity A is in the same package name as COM.CLOUD.APP1, then activity The Taskaffinity property value of A is COM.CLOUD.APP1, and we can set special taskaffinity for activity in Androidmanifest.xml through the android:taskaffinity attribute. Suppose we set the android:taskaffinity= ": Test" for activity A in androidmanifest.xml, then the taskaffinity value of activity A is COM.CLOUD.APP1: Test

Then I can now understand that the Taskaffinity attribute value of the activity of the different applications will vary.

It is assumed that activity A and Activity B start mode are standard, the Taskaffinity property value is not the same, from activity a jumps to activity B, Then their corresponding activityrecord will belong to the same task.

Assuming that activity A's startup mode is standard,activity B's startup mode Singletask, both Taskaffinity property values, this time from activity a jumps to activity B, Then their corresponding activityrecord will belong to the same task. Because as long as the Taskaffinity property of the two activity is consistent, even if one of the activity's start mode is Singletask, their corresponding activityrecord will be placed in the same task. This is true whether you jump from an activity to an activity of type singletask or from an activity of type singletask to other activity. Unless you jump to another activity, the startup mode is singleinstance. The description here is very different from the official documentation, and we will introduce the features of the Singletask startup mode later.

It is assumed that activity A's startup mode is standard,activity B's startup mode Singletask, the Taskaffinity property value is different, and from activity a jumps to activity B, Then their corresponding activityrecord will belong to different tasks.

There are many other things that will generate new tasks, and you can look at the following introduction to the features of the startup mode.

three Activity start mode features

Activity has a total of 4 startup modes, the default is standard, and others have singletop,singletask,singleinstance, the following 4 types of startup modes to describe their characteristics.

• 2) Singletop mode

  Singletop mode is similar to standard mode, Singletop mode activity can have more than one activityrecord to join different tasks, the same task can also exist multiple Activityrecord, But the activityrecord of the same task cannot be adjacent.

  Assuming that activity A's startup mode is Singletop, then the fallback stack shown is unreasonable:

  However, the fallback stack can exist as shown:

  Assuming activity a initiates activity B, B is at the top of the task's stack, and B's start mode is Singletop mode. At this point the other activity jumps to activity B, and the task that starts is the task where both A and B are started, or the task itself where A and B are on the top of the stack, then the activityrecord of B is not created. Instead, the intent that initiates activity B is passed to the activityrecrod of the stack top activity b corresponding to the instance object in the application process, calling its Onnewintent method.

  This can be simulated in this way:

  Assuming activity A and activity B are in the same application App1, A is the entry activity,a can jump to the activity b,b the startup mode is Singletop. At this point a jump from A to B, the notification bar has a start B notification, click on the notification, the above situation occurs.

• 3) Singletask mode

  Singletask mode and Standard mode, Singletop mode is very different, Singletask mode activity in the entire fallback stack can only have a activityrecord, that is, it can only belong to a certain task, Activityrecord cannot exist in multiple tasks. But there can be other activity Activityrecord in this task.

  Assuming that activity A's startup mode is Singletask, then the fallback stack shown is unreasonable:

  Assuming that activity A's startup mode is Singletask, then the fallback stack shown is reasonable:

  Assuming that activity A's startup mode is Singletask, the activity that corresponds to Activityrecord in the same task as the activityrecord of activity a must be associated with the activity A taskaffinity the same. In other words, activity A's activityrecord will only be placed in the same task as the other activity Activityrecord of the same application. And these other activity of the same application cannot set special taskaffinity.

  The activity of Singletask mode has another feature:

  Assuming that activity A's startup mode is the task in which Singletask,a is located, A is not at the top of the stack, and if you jump from another activity to activity a, Then all the Activityrecord in a task where a is located above a will be cleared away.

  Jumps before the fallback stack is as follows:

  After jumping from E to a, the fallback stack looks like this:

  This means that the C in the task where bit a resides is cleared.

  Also note that you should:

  As long as the Taskaffinity property of the two activity is consistent, even if one of the activity's startup modes is Singletask, their corresponding activityrecord will be placed in the same task. This is true whether you jump from an activity to an activity of type singletask or from an activity of type singletask to other activity. Unless you jump to another activity, the startup mode is singleinstance. The Android Official document does not accurately describe the Singletask startup mode.

  Examples are as follows:

  Assuming that an application has two activity A and activity b,activity A has started, Activity B's startup mode is singletask,activity B has never been started, There are no special taskaffinity for these two activity in Androidmanifest.xml. When you jump from activity A to activity B, the Activityrecord of activity B is placed in the task where activity A is activityrecord.

• 4) singleinstance mode

  This startup mode is similar to Singletask, where the activity of SingleInstance mode can only have one activityrecord in the entire fallback stack, that is, it can only belong to a task, It is not possible to have activityrecord in multiple tasks, and the task in which it resides cannot have any other activity activityrecord, even if other activity within the same application does not have their acvitityrecord.

  Assuming that activity A's startup mode is SingleInstance, then the fallback stack shown is unreasonable:

  Assuming that activity A's startup mode is SingleInstance, then the fallback stack shown is reasonable:

When you start an activity, you sometimes need to look at the fallback stack to see if there is a task associated with the activity. Activity is related to a task in two cases (assuming activity is a, the associated task is Task1):

• 1) If the start mode of a is singleinstance, then Task1 can only contain 1 Activityrecord, and activityrecord corresponding activity must be a
• 2) A's start mode is not singleinstance,a the Taskaffinity property and the Taskaffinity property of the Task1 must be the same. The Taskaffinity property of a task is determined by the Taskaffinity property of the 1th Activityrecord it contains.

Note

• 1) When starting the application from the Launcher program, all tasks are looked up to see if there is a related task, and if there is already a related task, the related task is moved to the top of the stack, and then the top activity is displayed. When finding related tasks, see if the task is related to the application's entry activity. Entry activity refers to the activity of category Android.intent.category.LAUNCHER when declaring Intentfilter in Androidmanifest.xml. If the startup mode of the ingress activity is singletask, it will not only move the related task to the top of the stack, but will also erase all other activityrecord that are above the entry activity in that task.
• 2) with the recent application, when switching apps, the task that corresponds to the app icon is moved directly to the top of the stack, so even if the task has a singletask type of Activityrecord, the activityrecord above it will not be cleared
• 3) can view system task status through ADB shell Dumpsys activity activties

Thinking Questions

I believe that after you read these 3 blogs, you can answer the following questions about which situations will create new tasks

• 1) Will the application be launched for the first time, creating a new task?
• 2) Assuming that the application App1 entry activity (activity A) boot mode is standard, from A can jump to acitivity b,activity B boot mode is singletask, then when the application is started, Does jumping from Activitya to activityb produce a new task?
• 3) Assume that the entry activity of the application App1 is a, from a can jump to B, from B can jump to c,b start mode for singletask,a and C boot mode for standard,activity jump order of a->b-> Does c produce a new task? What if the startup mode of C is also singletask? What if C's startup mode is SingleInstance?
• 4) Assume that the entry activity of the application App1 is a, from a can jump to B, B's start mode for the Singletask,a boot mode is standard, another application app2 has an activity c,c startup mode for Stanard,c can also jump to B , has now jumped from a to B, and then open the application app2, from C to B, will it produce a new task? If the application App1 does not start, will it produce a new task?
• 5) Assuming that the application App1 entry activity is a, from a can jump to B, from B can jump to C, B's start mode for the Singletask,a,c boot mode is standard, from a jump to B, a will finish, assuming that a has jumped to b,b has jumped to C , the notification bar has a notification, you can start activity B, then click on the notification, what will happen?

In-depth understanding of activity startup mode