The Android task and the return stack are fully parsed, counting the details that you don't know

Reprint Please specify source: http://blog.csdn.net/guolin_blog/article/details/41087993

The main content of this article comes from Android Doc, I have done some processing after translation, English good friends can also directly read the original text.

Http://developer.android.com/guide/components/tasks-and-back-stack.html

Tasks and return stacks

An application usually contains a lot of activity, and each activity should be designed to be a component that has specific functionality and can be manipulated by the user. In addition, the activity should also be able to start each other. For example, a mail application might contain an activity to display a mailing list, and when a user clicks on one of the messages, another activity is opened to show the specific contents of the message.

In addition, an activity can even initiate activity in other applications. For example, if your app wants to send an email, you can define a intent with a "send" action, and pass in some data, such as the email address, the message content, and so on. Thus, if an activity in another application declares that it can respond to such intent, then the activity is opened. In the current scenario, this intent is intended to send mail, so the write activity in the mail application should be opened. When the message is sent out, it still goes back to your application, which makes it seem as if the activity that you just wrote was part of your application. So, even though many of the activity comes from different applications, the Android system can still seamlessly combine them, and the reason for this is that the activity is in one of the same tasks.

A task is a collection of activity that uses a stack to manage its activity, which is called the back stack, and the order of activity in the stack is stored in the order in which they are opened.

The home interface of the phone is where most tasks start, and when the user clicks on an app icon on the home screen, the app's task is transferred to the foreground. If the application does not currently have any task (indicating that the app has not been started recently), the system will create a new task and put the app's main activity into the return stack.

When an activity initiates another activity, the new activity is placed at the top of the stack and will receive the focus. The previous activity remains in the return stack but is in a stopped state. When the user presses the back key, the topmost activity in the stack is removed and the previous activity is returned to the topmost position. The order of activity in the return stack will never change, we can only add activity to the top of the stack, or remove the activity at the top of the stack. Therefore, the return stack is a typical last-in, first-out data structure. The timeline is a very clear way to show us the state change of multiple activity in the return stack:

If the user presses the back key all the time, the activity in the return stack is removed from each other until it is eventually returned to the home screen. When all the activity in the return stack is removed, the corresponding task does not exist.

Tasks can also be transferred to the background, in addition to being transferred to the foreground. When a user opens a new task, or clicks the home button to return to the home screen, the task is moved to the background. When the task is in the background state, all activity in the return stack goes to the stop state, but the activity's order in the stack remains intact, as shown in:

At this point, the user can also switch any background task to the foreground, so the user should see the activity that was at the top of the task before leaving. For example, there are three activity in the current task a stack, and now the user presses the home key and then clicks the icon on the desktop to launch another application. When the system comes back to the desktop, the task A is actually in the background, and then when another application starts, the system will open a new task (Task B) for the program. When the user has finished using the program, press the home button again to return to the desktop, this time the task B also entered the background. Then the user re-opened the first use of the program, this time task A will return to the foreground, a task stack of three activity will still remain in the order, the top of the activity will be re-run state. After that, the user can still switch back to Task B via the home key or multitasking key, or start more tasks, which is an example of multi-task switching in Android.

Because the order of activity in the return stack will never change, so if you allow multiple portals in your application to start the same activity, a new instance of the activity will be created each time it is started. Instead of moving the following activity to the top of the stack. This can easily lead to the creation of a problem where the same activity is likely to be instantiated many times, as shown in:

However, if you do not want the same activity to be instantiated multiple times, then of course it is possible, and we will begin to discuss if this function is implemented, now let's briefly summarize the default tasks and activity behavior:

• When activity a starts activity B, activity a goes into a stopped state, but the system still retains all its relevant information, such as the scrolling position, the contents of the text box input, and so on. If the user presses the back key in activity B, activity A will return to the running state.
• When the user leaves a task through the home key, the task enters the background and all activity in the return stack goes to the stop state. The status of these activity is retained so that the next time the user re-opens the application, the background task can be extracted directly to the foreground and the previous top activity is restored.
• When the user presses the back key, the current topmost activity is removed from the return stack, the removed activity is destroyed, and the previous activity is in the top position of the stack and enters the active state. When an activity is destroyed, no state information is kept for it.
• Each activity can be instantiated many times, even in different tasks.

management tasks

The way Android systems manage tasks and return stacks, as described above, is to put all the activated activity into a single task, managed by a "LIFO" stack. This is not a problem in most cases, and developers do not have to worry about how the activity in the task is stored in the return stack. But, if you want to break this default behavior, say, when you start a new activity, you want it to exist in a separate task, rather than in the existing task. Or, when starting an activity, if the activity already exists in the return stack, you want to be able to move the activity directly to the top of the stack instead of creating an instance of it. Or, you want to be able to erase all the activity in the return stack except for the bottom of the activity. These features, and even more, can be achieved by setting the properties of the <activity> element in the manifest file, or by configuring intent flag when the activity is started.

In the <activity> element, there are several properties that can be used:

• Taskaffinity
• Launchmode
• Allowtaskreparenting
• Cleartaskonlaunch
• Alwaysretaintaskstate
• Finishontasklaunch

Among the intent, the following flags are more commonly used:

• Flag_activity_new_task
• Flag_activity_clear_top
• Flag_activity_single_top

We'll start with a discussion of how to change activity's default behavior in the task through the manifest parameter and intent flag.

Defining the startup mode

Startup mode allows you to define how an activity instance is associated with the current task, and you can define the startup mode in the following two different ways:

1. Using the manifest file

When you declare an activity in the manifest file, you can specify how the activity should be associated with the task when it is started.

2. Using Intent Flag

When you call the StartActivity () method, you can add a flag to the intent to specify how the newly started activity will be associated with the current task.

That is, if activity a initiates activity b,activity B can define how it relates to the current task, and activity A can also require activity B to associate with the current task. If activity B already defines how to associate with the task in manifest, activity A also requires activity B to associate with the current task in intent. Then the definition in intent will overwrite the definition in manifest.

It is important to note that some startup modes can be specified in manifest, but are not specified in intent. Also, some startup modes can be specified in intent, but not in manifest, so let's talk about it in detail.

Using the manifest file

When you define activity in the manifest file, you can specify how the activity should be associated with the task through the Launchmode attribute of the <activity> element. The Launchmode property has the following four optional parameters:

"Standard" (default startup mode)

Standard is the default startup mode, that is, if you do not specify the Launchmode property, this startup mode is used automatically. This startup mode indicates that the system will create a new instance each time the activity is started and always put it into the current task. Activity declared into this startup mode can be instantiated several times, and a task can contain multiple instances of such activity.

"Singletop"

This startup mode indicates that if the activity to be started already exists in the current task and is still at the top of the stack, then the system will not create an instance of the activity, but instead call the Onnewintent () method of the top activity of the stack. An activity declared as a startup mode can also be instantiated several times, and a task can contain multiple instances of such activity.

For example, there is a, B, C, D four activity in the return stack of a task, where a is at the bottom and D is at the top. This time if we ask to start again D, and the start mode of D is "standard", then the system will create a second instance of D into the return stack, when the elements in the stack are: a-b-c-d-d. If the start mode of D is "Singletop", since D is already at the top of the stack, then the system will not create an instance of D, but instead directly call the D activity of the Onnewintent () method, when the stack element is still: a-b-c-d.

"Singletask"

This startup mode indicates that the system creates a new task and puts the activated activity in the bottom position of the new task. However, if an instance of the activity already exists in the existing task, then the system will not create its instance again, but will call its onnewintent () method directly. An activity declared as such a startup mode will only have one instance in the same task. Note that what we call the start activity here is to start activity in other applications, because the "singletask" mode will create a new task by default only activity that starts another program. Starting an activity in your own program will still use the same task, as explained in the section below dealing with affinity .

"SingleInstance"

This startup mode is somewhat similar to "Singletask", except that the system does not add other activity to the task that is declared as "singleinstance" activity. That is, there is always only one activity in this activity, and other activity that is opened by the activity is put into another task.

In another example, Android's built-in browser program declares that its activity on the Web page should always be open in a separate task, which is done by setting the "Singletask" startup mode in the <activity> element. This means that when your program is ready to open the Android built-in browser, the newly opened activity will not be placed in your current task, but will start a new task. If the browser has a task in the background, the task will be switched to the foreground.

In fact, whether the activity starts in a new task or starts in the current task, the return key will always take us back to the previous activity. However, there is a particular case where the activity specifies that the startup mode is "Singletask" and initiates an activity in another application, when the activity is found to be in a background task. The entire background task will be switched directly to the foreground. Pressing the Back button now takes precedence over the current most foreground task (which has just been switched from the background to the foreground) and shows the situation in a more vivid way:

For more information on how to use the startup mode in the manifest file, you can refer to the second section of the first line of code--android .

Using Intent Flags

In addition to using the manifest file, you can also add a flag to the intent to change the way the activity is associated with the task when calling the StartActivity () method, so let's take a look at one by one to explain the role of each flag:

Flag_activity_new_task

With this flag set, the new start activity will be placed in a new task (similar to "Singletask", but not exactly), and of course the discussion here still starts with activity in other programs. The flag's role is usually to simulate a launcher behavior, which is to list what a push can start, but every activity that starts is running in its own separate task.

Flag_activity_single_top

This flag is set, and if the activity to be started already exists in the current task and is still at the top of the stack, then the activity's instance will not be created again, but the Onnewintent () method is called directly. This flag has the same effect as specifying the "Singletop" mode in Launchmode.

Flag_activity_clear_top

With this flag set, if the activity to be started already exists in the current task, it will not create an instance of the activity again, but will shut down all activity on top of the activity. For example, a task with a, B, C, D four ACTIVITY, then D called the StartActivity () method to start B, and the flag is designated as Flag_activity_clear_top, then C and D will be shut down, Now there's only A and b left in the back stack.

Then activity B receives the intent that started it, and you can decide whether to have activity B call the Onnewintent () method (not create a new instance), or destroy activity B and recreate the instance. If activity B does not specify any startup mode (that is, "standard" mode) in manifest, and intent does not include a flag_activity_single_top flag, then the activity B is destroyed, and the instance is recreated. The Onnewintent () method of activity B is called if activity b specifies any of the startup modes in manifest, or if a flag_activity_single_top flag is added to the intent.

The combination of Flag_activity_clear_top and Flag_activity_new_task will also have a better effect, such as the ability to switch a background run task to the foreground, and shut down all other activity on the target activity. This feature is useful in certain situations, such as when you start activity from the notification bar.

Handling affinity

Affinity can be used to specify which task the activity prefers to attach to, and by default all activity in the same application has the same affinity, so the activity is more inclined to run in the same task. Of course, you can also change the affinity value of each activity, which can be achieved by the taskaffinity attribute of the <activity> element.

The Taskaffinity property receives a string parameter that you can specify as an arbitrary value (at least one in my test string), but must not be the same as the package name of the application, because the package name is used as the default affinity value.

Affinity has the following two types of application scenarios:

• When the StartActivity () method is called to start an activity, it is put into the current task by default. However, if a flag_activity_new_task flag is added to the intent (or the ACTIVITY is declared in the manifest file, the startup mode is "Singletask"), The system will attempt to create a separate task for the activity. But the rule is not only so simple, the system will detect the activity to start affinity and the current task affinity is the same, if the same will put it into existing tasks, if different will be to create a new task. The affinity of all activity in the same program is the same by default, which is why the same application does not create a new task for the activity even if it is declared as "Singletask".
• When the activity's Allowtaskreparenting property is set to true, the activity has the ability to transfer the task. Specifically, an activity is now in a certain task, but it has the same affinity value as another task, and when the other task switches to the foreground, the activity can be transferred to the current task.
  Let's take an example of an image point, such as a weather report program, which has an activity that is specifically designed to display weather information, the activity and all other activity of the weather program, the exact same affinity value, It also sets the Allowtaskreparenting property to True. At this point, your own application launches the activity using intent to display the weather information, so this activity should be in the same task as your application. But when the weather-forecasting program is switched to the foreground, the activity is then moved to the task of the weather-forecast program and displayed because they have the same affinity value, and the Allowtaskreparenting property is set to true.

Empty return stack

How the user switches the task to the background after a long period of time, the system will be the task in addition to the bottom of the activity of all other activity out of all. When the user returns to this task, the activity at the bottom will be restored. This is the default behavior of the system, because after such a long period of time, the user is likely to forget what was being done, then back to the task, basically should be to do something new.

Of course, since the default behavior, it means that we have a way to change, in the <activity> element set the following properties can change the system this default behavior:

Alwaysretaintaskstate

If this property of the lowest activity is set to True, the default behavior described above will not occur, and all activity in the task will remain after a long period of time.

Cleartaskonlaunch

If this property of the bottommost activity is set to true, all other activity on top of the underlying activity will be erased as long as the user leaves the current task and returns again. In short, it is a completely opposite mode of working with Alwaysretaintaskstate, which guarantees that every time a task is returned it will be an initialization state, even if the user has only been away for a short period of time.

Finishontasklaunch

This property is similar to Cleartaskonlaunch, but it does not work on the entire task but on a single activity. If an activity sets this property to true, the activity will be erased once the user leaves the current task and returns again.

If you like the article I wrote, please shake the small hand, for me to vote on your precious vote, thank you for your support, vote address:

Http://vote.blog.csdn.net/blogstar2014/details?username=sinyu890807#content

The Android task and the return stack are fully parsed, counting the details that you don't know