An application usually contains multiple activities.
Each activity should be designed around a specific kind of action the user can perform and can start other activities.
For example, an email application might have one activity to show a list of new email.
When the user selects an email, a new activity opens to view that email.
An activity can even start activities that exist in other applications on the device.
For example, if your application wants to send an email, you can define an intent to perform a "send" action and include some data, such as an email address and a message.
An activity from another application that declares itself to handle this kind of intent then opens.
In this case, the intent is to send an email, so an email application's "compose" activity starts (if multiple activities support the same intent, then the system lets the user select which one to use).
When the email is sent, your activity resumes and it seems as if the email activity was part of your application.
Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.
A task is a collection of activities that users interact with when performing a certain job.
The activities are arranged in a stack (the "back stack"), in the order in which each activity is opened.
The device Home screen is the starting place for most tasks.
When the user touches an icon in the application launcher (or a shortcut on the Home screen), that application's task comes to the foreground.
If no task exists for the application (the application has not been used recently), then a new task is created and the "main" activity for that application opens as the root activity in the stack.
When the current activity starts another, the new activity is pushed on the top of the stack and takes focus.
The previous activity remains in the stack, but is stopped.
When an activity stops, the system retains the current state of its user interface.
When the user presses the Back button, the current activity is popped from the top of the stack (the activity is destroyed) and the previous activity resumes (the previous state of its UI is restored).
Activities in the stack are never rearranged, only pushed and popped from the stack—pushed onto the stack when started by the current activity and popped off when the user leaves it using the Back button.
As such, the back stack operates as a "last in, first out" object structure.
Figure 1 visualizes this behavior with a timeline showing the progress between activities along with the current back stack at each point in time.
stack中的activity絕不會重新排列，在stack中隻有壓入和彈出 —— 當被當前的activity啟動時壓入stack，當用戶使用back鍵離開它時彈出。
Figure 1. A representation of how each new activity in a task adds an item to the back stack.
When the user presses the Back button, the current activity is destroyed and the previous activity resumes.
If the user continues to press Back, then each activity in the stack is popped off to reveal the previous one, until the user returns to the Home screen (or to whichever activity was running when the task began).
When all activities are removed from the stack, the task no longer exists.
A task is a cohesive unit that can move to the "background" when users begin a new task or go to the Home screen, via the Home button.
While in the background, all the activities in the task are stopped, but the back stack for the task remains intact—the task has simply lost focus while another task takes place, as shown in figure 2.
A task can then return to the "foreground" so users can pick up where they left off.
Suppose, for example, that the current task (Task A) has three activities in its stack—two under the current activity.
The user presses the Home button, then starts a new application from the application launcher.
When the Home screen appears, Task A goes into the background.
When the new application starts, the system starts a task for that application (Task B) with its own stack of activities.
After interacting with that application, the user returns Home again and selects the application that originally started Task A.
Now, Task A comes to the foreground—all three activities in its stack are intact and the activity at the top of the stack resumes.
At this point, the user can also switch back to Task B by going Home and selecting the application icon that started that task (or by touching and holding the Home button to reveal recent tasks and selecting one).
This is an example of multitasking on Android.
這時候，用戶可以通過去Home選擇啟動Task B的應用圖標轉換回到Task B（或者通過長按Home鍵顯示出最近的task，然後選擇）
Note: Multiple tasks can be held in the background at once.
However, if the user is running many background tasks at the same time, the system might begin destroying background activities in order to recover memory, causing the activity states to be lost.
See the following section about Activity state.
Because the activities in the back stack are never rearranged, if your application allows users to start a particular activity from more than one activity, a new instance of that activity is created and pushed onto the stack (rather than bringing any previous instance of the activity to the top).
As such, one activity in your application might be instantiated multiple times (even from different tasks), as shown in figure 3.
As such, if the user navigates backward using the Back button, each instance of the activity is revealed in the order they were opened (each with their own UI state).
However, you can modify this behavior if you do not want an activity to be instantiated more than once.
How to do so is discussed in the later section about Managing Tasks.
To summarize the default behavior for activities and tasks:
When Activity A starts Activity B, Activity A is stopped, but the system retains its state (such as scroll position and text entered into forms).
If the user presses the Back button while in Activity B, Activity A resumes with its state restored.
When the user leaves a task by pressing the Home button, the current activity is stopped and its task goes into the background.
The system retains the state of every activity in the task.
If the user later resumes the task by selecting the launcher icon that began the task, the task comes to the foreground and resumes the activity at the top of the stack.
If the user presses the Back button, the current activity is popped from the stack and destroyed.
The previous activity in the stack is resumed.
When an activity is destroyed, the system does not retain the activity's state.
Activities can be instantiated multiple times, even from other tasks.
當Activity A開啟Activity B時，Activity A進入stop狀態，但是系統保持Activity自己的狀態（比如滾動的位置和文本輸入的形式）
在Activity B中如果用戶按下back鍵，Activity A會和它自己的狀態一起恢復。
As discussed above, the system's default behavior preserves the state of an activity when it is stopped.
This way, when users navigate back to a previous activity, its user interface appears the way they left it.
However, you can—and should—proactively retain the state of your activities using callback methods, in case the activity is destroyed and must be recreated.
When the system stops one of your activities (such as when a new activity starts or the task moves to the background), the system might destroy that activity completely if it needs to recover system memory.
When this happens, information about the activity state is lost.
If this happens, the system still knows that the activity has a place in the back stack, but when the activity is brought to the top of the stack the system must recreate it (rather than resume it).
In order to avoid losing the user's work, you should proactively retain it by implementing the onSaveInstanceState() callback methods in your activity.
For more information about how to save your activity state, see the Activities document.