Assignment of Task stack in Android, androidtask
First, let's take a look at the definition of a Task. Google defines a Task as follows: a task is what the user experiences as an "application. "It's a group of related activities, arranged in a stack. A task is a stack of activities, not a class or an element in the manifest file. this means that a Task is actually an Activity stack, and an Application that users usually feel is a Task. From this definition, the Task has no connection with the Service or other Components. It is only for the Activity.
Activity has different startup modes, which can affect task allocation.
Task, in short, is a set of Activity components that are aggregated in stack mode. They have potential pre-and post-drive associations. Newly Added Activity components are located at the top of the stack. Only the Activity at the top of the stack can have the opportunity to interact with users. When the Activity at the top of the stack exits its mission, the Task will unstack it and let the next Activity at the top of the stack face to face, until no more Activity exists in the stack, the Task ends.
Event |
Task Stack (the top component of the stack in bold) |
Click Open Email application to enter the inbox (Activity) |
A |
Select an email and click View Details (Activity B) |
AB |
Click "reply" to start writing a new email (Activity C) |
ABC |
A few lines of words are written. Click "select contact" to go to the "select contact" Page (Activity D) |
ABCD |
Select the contact and continue to write the email. |
ABC |
Write the email, send the email, and return to the original email. |
AB |
Click Back to return to the inbox |
A |
Exit the Email program |
Null |
As shown in the table above, it is an instance. The Task stack changes from the user's entry into the mailbox to the completion of the reply and exit the application. This is a standard stack mode. For most situations, such a Task model is sufficient. However, it will become much more cruel to involve actual performance and overhead.
For example, starting a browser is a heavy process in Android. It requires a lot of initialization work and has a large memory overhead. But at the same time, opening some content with a browser is a common requirement for applications. Imagine how cruel it would be to start a browser if there are ten running applications (multiple tasks) at the same time, the ten Task stacks are stacked with similar browser activities,
What a gorgeous waste.
Therefore, you may have the idea that a browser Activity may exist as a separate Task. The browser tasks will not be merged, regardless of the request from that Task. In this way, although the browser Activity itself needs to maintain more states, but the overall overhead will be greatly reduced, this kind of behavior for everyone is worthy of praise
Standard "," singleTop "," singleTask "," singleInstance ".
Standard ModeIs the default and standard Task mode. Without the influence of other factors, the Activity that uses this mode constructs an Activity instance and adds it to the caller's Task stack, the standard mode is undoubtedly the most suitable for activities with average usage frequency and overhead, because its logic is simple and clear, so it is the default choice.
While
SingleTop Mode, Which is basically the same as standard. It is different only when the requested Activity is located at the top of the stack. In this case, the Activity configured as singleTop will no longer construct a new instance and add it to the Task stack. Instead, it will send the new Intent to the top Activity of the stack, the Activity at the top of the stack can handle the new Intent by reloading onNewIntent (of course, you can ignore it ...). This mode reduces the repetitive overhead at the top of the stack and avoids some strange behaviors. (imagine, if several of them are the same Activity at the top of the stack and exit at the same level, what is the user experience ...), it is suitable for displaying updated list activities. A living example is that in applications provided by Android by default, Browser bookmarks (BrowserBookmarkPage) Use singleTop.
SingleTask, and singleInstance, take another path of the Task.
Mark
SingleTaskActivity, only one instance exists at most, and is located in the Task with it as the root. All requests to the Activity will jump to the Task of the Activity to expand. SingleTask, like the single-piece mode in concept, all modifications are based on an instance, which is usually used in Activity with a high construction cost but a low switching cost. The most typical example is the main Activity of the Browser application (called Browser...), which displays the current tab and the content window of the current page. It has a high construction cost, but the page switching is still fast. It works well with singleTask.
SingleInstanceMore extreme. In most cases, singleInstance and singleTask are identical. The only difference is that the singleInstance Activity is the only Activity in its stack. If other activities are involved, all are handed over to other tasks. This makes singleInstance Activity, like an isolated island, a thorough black box. It does not care where the request comes from or who will execute it later. In Android's default applications, there are very few such activities. In my personal engineering practice, I tried to use them in the quick word Activity of youdao dictionary,
It is because I think it is convenient to get the word quickly (click to enter from notification) and it will be used in various occasions and should be completely independent.
Split large apk into many small apk
● Android: affinity attribute of Activity
1. After configuration, when this activity is started, check whether the affinity attribute of the activity is the same.
The task where the activity is located does not have a new task.
2. affinity:
1. intent contains FLAG_ACTIVITY_NEW_TASK tag
2. The allowTaskReparenting attribute is enabled for the activity element.