Activity, Task, application, and process

Http://www.cnblogs.com/franksunny/archive/2012/04/17/2453403.html

Very want to find out the relationship between starting an Activity and task (Task), there are a lot of relevant information on the Internet, from the source to specific analysis, but also for Launchmode to analyze, but are not their own, it is not so easy to understand, to try to understand the logic of it. But two questions need to be clarified beforehand:

Who is responsible for managing activity?

The Android framework uses the C/s approach to manage specific acitivity instances by the backend service Activitymanagerservice (which is referred to as AMS in many books). Although AMS is named Activitymanagerservice, it does not only manage the activity, he also manages the other three components except acitvity, including intent, pendingintent, apk process and task, etc. Specifically, you can view the source code frameworks\base\services\java\com\android\server\am the following AMS source code and related *record class.

Online data show in the SDK after 2.3, AMS renamed the original Historyrecord class as the Activityrecord class, and some of its original AMS was extracted to become a activitystack class, each activity instance corresponds to an activity Record object, and stored in the Activitystack, once the phone is started, a AMS service is launched, and a Activitystack instance in the AMS service is dedicated to managing Activityrecord instances on the phone. In this way, no specific analysis of the source code, only from an architectural perspective, who is responsible for managing the activity of the problem is much clearer.

What exactly is a task?

According to the answer to the above question, since the activity is managed by AMS through Activitystack, then what does this task do?

In the past, application (application)-based program development, the program has a clear boundary, a program is an application, an application in order to implement the function can be used to open up new threads and even new processes to assist, but the application and application cannot reuse resources and functions. While Android introduced a software architecture based on component development, although we developed the Android program, still use an APK project a application development form, but for the development of aplication has used the activity, Service, such as the four components, each of which can be reused across applications, oh, this is the magic of Android.

It is also worth mentioning that although components can be called across applications, the process in which a component resides must be in the aplication process where the component resides. Because Android strengthens the concept of components, weakening the concept of aplication, so in the development of Android program, a component of a application want to use the function of photo or video can not be developed for the camera class, Directly call the system's own camera application (called its B-component) in the component (called its B-components) can be, but this raises a new problem, a component run in a application, B components run in the B application, naturally not in the same process, then return from the B component, how to implement the correct return to a component? Task is responsible for implementing this function, which is an abstract concept created from the perspective of the user to understand the application. Because the component that the user can see is activity, the task can be understood to implement a function and be responsible for managing all the stacks of the activity instances that are used.

Actually look at the source code, inside AMS, not really have such a storage activity of task stack, activity or through activitystack to manage, In Activityrecord, there is a Taskrecord object that records which task the real activity instance belongs to. The task is uniquely identified by an int type of taskid that will be zeroed when the phone is restarted.

Say so much, or find a task tasks the most intuitive embodiment of it. First restart the phone, long press the home button, found that the most recent task is not a task, and then open a application, long press the home key, you will find a application of a task, see the mobile phone process, should not have B process; B component of the B application in a component of a application, at this time to see the mobile phone process, In addition to a process, there is a process of B, but long press the home key, you can see only a application of a task. In fact, this time, b application has run, but for the user, he actually did not open the B application, so the task is from the user's point of view from the beginning of the concept of design, to ensure that the user's call logic.

The relationship between Activity, application and process

Before we get into the relationship between the start of the activity and the task, let's understand the relationship between starting an activity and the APK application and process. The activity START process specific analysis, the project time is very large, online has an old Luo finishing three blog, I watched half a day or foggy, interested can see the following link: http://blog.csdn.net/luoshengyang/article/ details/6685853. I am through my current understanding and now through the demo test, the start of an activity, AMS first will go to query the activity where the application is open, if not open will start a process to run the application, So whether you start an activity either through launcher or by calling StartActivity from within a regular program, the activity that you want to start is running in the application process where its registered apk is located (or the component android: Processes specified in the process), and its taskid is generally the taskid of the component that started it, but not necessarily, it depends on the following specific analysis.

In addition, through the application of the service, it can be concluded that an APK, an application (application) can run in multiple processes, a process running in a virtual machine, that is, an APK can start multiple virtual machines.

With Shareuserid, you can run multiple apk runs in the same process.

The conclusion is that a virtual machine can only run one process, one process may run multiple applications, and one application can run in multiple processes, and that is their relationship.

The relationship between activity and task

There are two ways to start an activity, one is through launcher, Another is to call the StartActivity function through program code implementation (verify that Appwidget is actually consistent with this way) in fact, there are three factors that affect the activity startup key: Launchmode in the activity registration information, Taskaffinity, Allowtaskreparenting, Cleartaskonlaunch, launchflags and activity registration information in intent when you start activity Alwaysretaintaskstate, Finishontasklaunch and other information. In general, we only need to set the first factor reasonably to meet the needs of our application development.

Four ways to Launchmode

The Launchmode method is set in the APK's manifest file for each activity's Android:launchmode property, and there are four modes that can be set, namely standard, Singletop, Singletask, SingleInstance, explained below separately (because of several factors have set, will affect the four modes of Lauchmode, so under the circumstances, other factors are not set by default situation).

Standard

Standard is the default mode, which assumes that the default startup mode is standard if the user does not specify Android:launchmode for activity in manifest. When launching an activity with standard Launchmode, AMS simply creates a new activity instance and puts it into activitystack (for the sake of ease of writing, Activitystack is referred to as AS), The TaskID is the same as the caller who initiates the activity (that is, even if a new process is created, its taskid is consistent with the caller to ensure consistency in the user fallback operation). This is the most common way to use it.

Singletop

When you start a singletop-lauchmode activity, AMS queries as: If it is the activity instance that is to be started at the top of the AS, then AMS will not restart an activity instance, Instead, it calls the onnewintent function of the activity instance at the top of the as stack (which naturally does not modify the original TaskID value), and if it is not an instance of the activity at the top of the as stack, a new instance is created, pressed into as, The TaskID is the same as the caller activity. This approach is primarily used to avoid situations where multiple instances are generated from the self-tuning process.

Singletask

When you start a singletask-lauchmode activity, AMS queries as: If there is an instance of that activity in the AS, The instance is then placed at the top of the TS (the other instance of the TaskID activity that originally resides on that instance will be destroyed), and the onnewintent function of the instance is called, and if there is no instance of the class within the AS, a new instance is started and pressed into as, The taskid is not necessarily related to the caller who initiated it, but depends on whether the activity is in the APK process with TaskID, and if not, a new taskid is created. It is found that if the activity initiated by the Singletask mode is the bottom of the same as in the TaskID (or the root instance of the task stack), then long press through the desktop, in the recent task to jump to the activity of the task, Even if the activity instance is not at the top of the stack, it is placed at the top of the stack (which also calls its onnewintent function), and the other activity instances of the as on the TaskID are destroyed, which can be verified by the accompanying demo. Where TaskOne in the Activity1 into the Singletask startup mode, the other is the default standard, the log output is as follows:

Start Activity1 in Tasktwo, TaskOne apk is not running, so start Activity1 will request a new Taskid,2afcfbd8 this Activity1 becomes a task stack base instance of TaskID 53

04-05 16:21:27.144:e/activityb @2b003230 (17933): OnPause pid 17933 TaskID 52

04-05 16:21:27.404:e/activity1 @2afcfbd8 (18489): onCreate pid 18489 taskid 53

04-05 16:21:29.214:e/activityb @2afecaf0 (17933): onCreate pid 17933 taskid 53

04-05 16:21:30.254:e/activity2 @2afdeef0 (18489): onCreate pid 18489 taskid 53

04-05 16:21:30.894:e/activityb @2aff9328 (17933): onCreate pid 17933 taskid 53

04-05 16:21:31.454:e/activity2 @2afe9330 (18489): onCreate pid 18489 taskid 53

04-05 16:21:31.864:e/activityb @2b009910 (17933): onCreate pid 17933 taskid 53

04-05 16:21:32.424:e/activity2 @2aff2570 (18489): onCreate pid 18489 taskid 53

Jump to the TaskOne task by long Press, at this time in the as in the ID 53 on Activity1 with 6

04-05 16:22:35.144:e/activityb @2afecaf0 (17933): OnDestroy pid 17933 taskid 53

04-05 16:22:35.144:e/activity2 @2afdeef0 (18489): OnDestroy pid 18489 taskid 53

04-05 16:22:35.234:e/activityb @2aff9328 (17933): OnDestroy pid 17933 taskid 53

04-05 16:22:35.254:e/activity2 @2afe9330 (18489): OnDestroy pid 18489 taskid 53

04-05 16:22:35.324:e/activityb @2b009910 (17933): OnDestroy pid 17933 taskid 53

04-05 16:22:35.344:e/activity2 @2aff2570 (18489): OnPause pid 18489 taskid 53

04-05 16:22:35.394:e/activity1 @2afcfbd8 (18489): onnewintent pid 18489 taskid 53

04-05 16:22:35.394:e/activity1 @2afcfbd8 (18489): OnStart pid 18489 taskid 53

04-05 16:22:35.394:e/activity1 @2afcfbd8 (18489): Onresume pid 18489 taskid 53

04-05 16:22:35.524:e/activity2 @2aff2570 (18489): onStop pid 18489 taskid 53

04-05 16:22:35.524:e/activity2 @2aff2570 (18489): OnDestroy pid 18489 taskid 53

SingleInstance

When you start a singleinstance-launchmode activity, call its onnewintent function if there is already an instance of that class in as, or a new taskid is created. The taskid is completely different from the APK process where the activity is located, and this taskid value will not be used in any other activity instances.

Simple summary

In general, when we develop common applications, we only need to use the default standard and Singtop methods, do not need to use Singletask and singleinstance to declare the registered activity, because it will destroy the user feeling of the fallback operation, To the user to bring confusion, so generally use the two for very resource-intensive activity, by viewing the source code found in the source Packages\apps program, some of the following applications use the two advanced settings

Androidmanifest.xml (packages\apps\browser): android:launchmode= "Singletask"

Androidmanifest.xml (Packages\apps\calendar): <activity android:name= "alertactivity" android:launchMode= "single Instance "

Androidmanifest.xml (packages\apps\contacts): android:launchmode= "Singletask"

Androidmanifest.xml (packages\apps\deskclock): android:launchmode= "SingleInstance"

Androidmanifest.xml (packages\apps\deskclock): android:launchmode= "SingleInstance"

Androidmanifest.xml (packages\apps\deskclock): android:launchmode= "SingleInstance"

Androidmanifest.xml (packages\apps\email): android:launchmode= "Singletask"

Androidmanifest.xml (packages\apps\launcher2): android:launchmode= "Singletask"

Androidmanifest.xml (packages\apps\music): android:launchmode= "Singletask"

Androidmanifest.xml (packages\apps\phone): android:launchmode= "SingleInstance"

Androidmanifest.xml (packages\apps\phone): android:launchmode= "SingleInstance" >

Androidmanifest.xml (Packages\apps\quicksearchbox): android:launchmode= "Singletask"

Androidmanifest.xml (packages\apps\settings): android:launchmode= "Singletask"

Androidmanifest.xml (Packages\providers\downloadprovider): android:launchmode= "Singletask"

In the above analysis did not introduce the other two factors, mainly on their own in this area of contact is also relatively small, and the combination of these three factors will produce a lot of different effects, so there is no specific deployment. Reproduced some of the information collected by netizens are as follows:

Description of the activity's attribute value in the manifest file associated with the task

Android:allowtaskreparenting

Used to mark whether an activity can move from a started task to a task with affinity (when the task enters the foreground)

"true", which means that it can be moved, "false", indicating that it must stay in the task in which it was started.

If this feature is not set, the value of the Allowtaskreparenting attribute set to the <application> element is applied to the activity. The default value is "false".

In general, when activity starts, it is associated with the task that started it, and it runs out of its entire life cycle. When the current task is no longer displayed, you can use this feature to force the activity to move to a task that has affinity. The typical usage is to move the activity of one application into the main task of another application.

For example, if an email contains a link to a Web page, clicking it launches an activity to display the page. This activity is defined by the browser application, but now it is part of the email task. If it is re-hosted into the browser task, it can be seen when the next time browser enters the foreground, and it will not be visible when the email task enters the foreground again.

The affinity of actvity is defined by the Taskaffinity attribute. The affinity of a task is determined by reading the affinity of the root activity. Therefore, the root activity is always in the same affinity task. Because activity with the startup mode of "Singletask" and "singleinstance" can only be at the bottom of a task, the re-hosting can only be limited to "standard" and "Singletop" mode.

Android:alwaysretaintaskstate

Used to mark whether the state of the task in which the activity resides is always maintained by the system.

"true", which means always; "false", which means that in some cases the system is allowed to restore a task to its initialization state. The default value is "false".

This feature is only meaningful for the root activity of a task, and is ignored for other activity.

In general, a particular situation, such as when the user re-selects the task from the main screen, cleans up the task (removing all activivity from the stack that is above the root activity). Typically, this is done when the user does not have access to the task for a period of time, such as 30 minutes.

However, when this feature is set to "true", users will always be able to return to the latest state of the task, no matter how they start. This is useful, for example, like the browser application, where there are many states (for example, multiple open tabs), and users do not want to lose these states.

Android:cleartaskonlaunch

Used to mark whether all activity is purged from the task except for the root activity (each time it restarts from the main screen)

"true", which means that always clears to its root activity, "false" means no. The default value is "false".

This feature is only meaningful for activity (root activity) that initiates a new task, and is ignored for other activity in the task.

When this value is "true", each time a user restarts the task, it goes into its root activity, regardless of what the task is doing at last, regardless of whether the user left it using back or home. When this value is "false", the activity of the task may be purged in some cases (refer to the Alwaysretaintaskstate attribute), but not always.

Suppose someone launches activity P from the main screen and migrates from there to activity Q. Next the user presses home and returns to activity P. In general, the user may see activity Q because it is the last work content of P's task. However, if P sets this feature to "true", all activity (in this case, Q) will be cleared when the user presses home and puts the task back into the foreground. Therefore, when you return to this task, the user sees only p.

If this attribute and allowtaskreparenting are set to "true", the activity that can be re-hosted will be moved to the shared affinity task, and the remaining activity will be discarded as described above.

Android:finishontasklaunch

Used to mark whether an activity instance that already exists when the user starts it again (selecting this task on the main screen) will be closed (end)

"True", indicating that it should be closed, "false" means no shutdown. The default value is "false".

If this feature and allowtaskreparenting are set to "true", this feature wins. The activity's affinity is ignored. This activity will not be re-hosted, but will be destroyed.

Android:launchmode

Used to indicate how activity starts. There are four modes that work with the activity Flags (flag_activity_* variables) in the intent object to determine how the activity starts to handle intent. They are:

"Standard"

"Singletop"

"Singletask"

"SingleInstance"

The default mode is "standard".

The previous article: "Android four activity loading mode" has been described in detail, here do not describe.

Android:nohistory

Used to mark whether the activity clears and ends from the activity stack when the user leaves the activity and it is no longer visible on the screen (call the Finish () method)--"true", indicating that it should be closed, "false", indicating that it is not required. The default value is "false".

A value of "true" means that activity does not leave traces of history. Because it is not persisted in the activity stack's task, the user cannot return it.

For example, the interface can be used to borrow this.

Android:taskaffinity

This is the task sharing described in this article.

Activity is a affinity owned by a task. Activity with the same affinity is theoretically the same task (the same "application" in the user's perspective). The affinity of a task is determined by its root activity.

Affinity determines that two things--activity the task of the re-host (reference allowtaskreparenting attribute) and the ACTIVITY host initiated with the FLAG_ACTIVITY_NEW_TASK flag.

By default, all activity in an application has the same affinity. Pinch can set this feature to reorganize them, and can even put the activity defined in different applications into the same task. To make it clear that the activity does not host a particular task, set the string with an empty attribute.

If this feature is not set, the activity will inherit from the application's settings (refer to the taskaffinity feature of the <application> element). The default affinity name of the application is the package name set in the <manifest> element.

Flag set in the intent object associated with the task

Flag_activity_brought_to_front

This flag is generally not set by the program code, such as the Launchmode set Singletask mode when the system to help you set.

Flag_activity_clear_top

If set, and the activity is already running in the current task, it is no longer an instance of the activity being restarted, but all activity above the activity will be closed, The intent will then be delivered as a new intent to the old activity (now on the top).

For example, suppose a task contains these activity:a,b,c,d. If D calls StartActivity () and contains a intent that points to activity B, then both C and D will end, and B receives the intent, so the current state of the stack is: A, B.

Activity B, which is running in the example above, can either receive this new intent in onnewintent () or shut itself down and restart to receive the intent. If its startup mode is declared as "multiple" (the default), and you do not set the FLAG_ACTIVITY_SINGLE_TOP flag in this intent, it will be closed and recreated, and for other startup modes, or set the FLAG_ACTIVITY_SINGLE_TOP flag in this intent, this intent will be posted to the current instance of the Onnewintent ().

This startup mode can also be used in conjunction with Flag_activity_new_task: Used to start the root activity in a task, which takes any running instance of that task into the foreground and clears it until the root activity. This is useful, for example, when an activity is started from Notification Manager.

Flag_activity_clear_when_task_reset

If set, this sets a restore point in the activity stack of the task, and when the task resumes, the activity needs to be cleaned up. That is, when the next TASK enters the foreground with the flag_activity_reset_task_if_needed tag (typically the user restarts it on the main screen), the ACTIVITY and it will be closed so that the user can no longer return to them. But you can go back to your previous activity.

This is useful when your program has a split point. For example, an e-mail application may have an action to view an attachment that needs to start a picture browse activity to display. This activity should be part of the e-mail application task because this is the action that the user triggers in this task. However, when the user leaves this task and then chooses the e-mail app from the main screen, we may want to go back to the viewing session, but not to view the picture attachment, as this is confusing. By setting this flag when the image is started, browsing and other startup activity will be cleared all the next time the user returns to the mail program.

Flag_activity_exclude_from_recents

If set, the new activity is not saved in the list of recently launched activity.

Flag_activity_forward_result

If set, and the intent is used to initiate a new activity from an existing activity, the activity that is the target of the response will be propagated to the new activity. In this way, the new activity can call Setresult (int), and the resulting value will be sent to the activity that is the target of the reply.

Flag_activity_launched_from_history

This flag is generally not set by the application code, and if the activity is initiated from the history (often by pressing the home key), then the system will set it up for you.

Flag_activity_multiple_task

Do not use this flag unless you implement the Application Launcher yourself. Used in conjunction with Flag_activity_new_task, you can disable the behavior of sending a saved task into the foreground. When set, the new task will always start to handle intent, regardless of whether this is already a task that can handle the same thing.

Because the default system does not contain graphics task management functionality, you should not use this flag unless you provide a way for the user to return to a task that has already been started.

If the FLAG_ACTIVITY_NEW_TASK flag is not set, this flag is ignored.

Flag_activity_new_task

If set, this activity will be the beginning of a new task in the history stack. A task (from its activity to the activity in the next task) defines the group of activity atoms that the user can migrate. Tasks can be moved to foreground and background, and all activity in a particular task is always kept in the same order.

This flag is typically used to render the behavior of a "startup" type: They provide a series of things that a user can do independently, regardless of the activity that started them.

With this flag, if the activity task that is being started is already running, the new activity will not start, instead, the current task will simply move into the foreground. Refer to the FLAG_ACTIVITY_MULTIPLE_TASK flag to disable this behavior.

This flag cannot be used for the result of an activity request that has been initiated by the caller.

Flag_activity_no_animation

If set in intent and passed to Context.startactivity (), this flag will prevent the system from entering the next activity when the acitivity migration animation is applied. This does not mean that the animation will never run-if another activity does not specify this flag before the display is started, then the animation will be applied. This flag can be used to perform a series of operations, and animations are seen as drivers of higher-level events.

Flag_activity_no_history

If set, the new activity will no longer be retained in the history stack. Once the user has left it, the activity is closed. This can also be done by setting the Nohistory attribute.

Flag_activity_no_user_action

If set, this flag will block the Onuserleavehint () from the front activity callback until the activity is paused as the newly initiated activity enters the foreground.

Typically, an activity can rely on this callback to refer to an activity that is caused by an explicit user action to move out of the background. This callback marks an appropriate point in the activity's life cycle and closes some notification.

If an activity is initiated through a non-user-driven event, such as a call or alarm, this flag should also be passed to context.startactivity, which ensures that the inactive activity does not assume that the user is aware of its notification.

Flag_activity_previous_is_top

If set and this intent are being used to launch a new activity from an existing one, the current activity would not be count Ed as the top activity for deciding whether the new intent should is delivered to the top instead of starting a new one. The previous activity is used as the top, with the assumption being that the current activity would finish itself imme Diately.

Flag_activity_reorder_to_front

If set in intent and passed to Context.startactivity (), this flag will cause the activity that is already running to move to the top of the history stack.

For example, suppose a task consists of four activity: A,b,c,d. If D calls StartActivity () to start activity B, then B moves to the top of the history stack, and now the order becomes a,c,d,b. If the FLAG_ACTIVITY_CLEAR_TOP flag is also set, then this flag will be ignored.

flag_activity_reset_task_if_needed

If set, and this activity are either being started in a new task or bringing to the top an existing task, then it'll be l Aunched as the front door of the task. This would result in the application of any affinities needed to having that task in the proper state (either moving Activiti Es to or from it), or simply resetting this task to its initial state if needed.

Flag_activity_single_top

If set, when the activity is running at the top of the history stack, a new one is no longer started.

Activity, Task, application, and process