Application Fundamentals——應用程序基礎知識

Key classes——關鍵類

1. Activity
2. Service
3. BroadcastReceiver
4. ContentProvider
5. Intent

   In this document——在這篇文章中

   1. Application Components——應用程序組件
      1. Activating components: intents——激活組件：意圖
      2. Shutting down components——關閉組件
      3. The manifest file——清單文件
      4. Intent filters——意圖匹配器
      5. Activities and Tasks——活動和任務
         1. Affinities and new tasks——親和力和新任務
         2. Launch modes——加載樣式
         3. Clearing the stack——清除棧
         4. Starting tasks——開始任務
         5. Processes and Threads——進程和線程
            1. Processes——進程
            2. Threads——線程
            3. Remote procedure calls——遠程過程調用
            4. Thread-safe methods——線程保險技術的方法
            5. Component Lifecycles——組件生命周期
               1. Activity lifecycle——活動生命周期
               2. Service lifecycle——服務生命周期
               3. Broadcast receiver lifecycle——廣播接收器生命周期
               4. Processes and lifecycles——進程和生命周期

                  Android applications are written in the Java programming language. The compiled Java code — along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an .apk suffix. This file is the vehicle for distributing the application and installing it on mobile devices; it's the file users download to their devices. All the code in a single .apk file is considered to be one application.
                  Android應用程序是用Java編程語言編寫的。編譯好的Java代碼——隨同所有應用程序要使用的數據和資源文件一起——使用aapt tool打包成一個Android包，即一個後綴為.apk的歸檔文件。此文件是發布應用程序和在移動設備上安裝應用程序的有媒介；它是用戶下載到他們設備上的文件。在一個.apk文件中的所有代碼被認為是一個應用程序。

                  In many ways, each Android application lives in its own world:
                  從很多方面來講，每一個Android程序都運行在自己的空間裡：

                  • By default, every application runs in its own Linux process. Android starts the process when any of the application's code needs to be executed, and shuts down the process when it's no longer needed and system resources are required by other applications. 默認的，每一個程序運行在其自己的Linux進程中。Android在應用程序中某段代碼需要被執行時啟動一個進程，不再使用或系統資源被其他應用程序請求時關閉這個進程。
                  • Each process has its own Java virtual machine (VM), so application code runs in isolation from the code of all other applications. 每一個進程都有自己的Java虛擬機（VM），一個應用程序代碼運行時同其他程序代碼分開，不受任何其他程序的代碼的影響。
                  • By default, each application is assigned a unique Linux user ID. Permissions are set so that the application's files are visible only that user, only to the application itself — although there are ways to export them to other applications as well. 默認的，每個應用程序享有一個獨自的Linux用戶ID。由於權限設定原因，一個應用程序的文件只有本用戶（其自己）可見——當然，也有把他們導出給其他應用程序的機制。
                    

                    It's possible to arrange for two applications to share the same user ID, in which case they will be able to see each other's files. To conserve system resources, applications with the same ID can also arrange to run in the same Linux process, sharing the same VM.
                    可以為兩個應用程序安排為使用同一個用戶ID，這樣，他們的文件相互可見。為為了節省系統資源，擁有相同ID的程序可以作為一個Linux進程運行，分享同一個虛擬機。
                    
                     

                    Application Components——應用程序組件

                    A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
                    Android的一個中心功能就是應用程序可以使用其他應用程序的元素（在提供元素的應用程序允許的情況下）。例如，如果您的應用程序想要顯示一系列帶有滑屏效果功能的圖片，然後某個應用程序正巧開發出了合適的滑屏的模塊，並且同意共享，您就可以調用哪個滑屏模塊處理這些圖片並顯示出來，而不是您自己再去開發一個。您的應用程序並沒有包含或鏈接到了其他的應用程序的代碼。但是當請求發出後，您的應用程序確實可以簡單的使用其他程序的部分功能。

                    For this to work, the system must be able to start an application process when any part of it is needed, and instantiate the Java objects for that part. Therefore, unlike applications on most other systems, Android applications don't have a single entry point for everything in the application (no main() function, for example). Rather, they have essentialcomponents that the system can instantiate and run as needed. There are four types of components:
                    為了達成這個過程，系統必須可以再應用程序的某個部分被請求時啟動這個程序的進程。然後為那個部分的Java對象創建實例。因此不像其他操作系統上的應用程序那樣，Android程序沒有一個單一的應用程序入口（例如沒有main()函數）。然而他們含有當系統需要時創建實例的實質的組件。組件有四種：

                    Activities——活動

                    An activity presents a visual user interface for one focused endeavor the user can undertake. For example, an activity might present a list of menu items users can choose from or it might display photographs along with their captions. A text messaging application might have one activity that shows a list of contacts to send messages to, a second activity to write the message to the chosen contact, and other activities to review old messages or change settings. Though they work together to form a cohesive user interface, each activity is independent of the others. Each one is implemented as a subclass of the Activity base class.

                    
                    

                    Whenever there's a request that should be handled by a particular component, Android makes sure that the application process of the component is running, starting it if necessary, and that an appropriate instance of the component is available, creating the instance if necessary.
                    當有應被特殊的組件操作的請求時，Android會確認這個組件是否正在運行，如果未在運行，則啟動它，如果正在運行則檢測需要的類是否實例化，如未實例化，則為類創建實例。

                    Activating components: intents——激活別的組件的組件：意圖

                    Content providers are activated when they're targeted by a request from a ContentResolver. The other three components — activities, services, and broadcast receivers — are activated by asynchronous messages called intents. An intent is an Intent object that holds the content of the message. For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things. For example, it might convey a request for an activity to present an image to the user or let the user edit some text. For broadcast receivers, the Intent object names the action being announced. For example, it might announce to interested parties that the camera button has been pressed.
                    內容提供者獲得ContentResolver請求的指向後，會被激活。另外的三種組件——活動，服務，廣播接收器——是靠異一種叫做intents（意圖）的異步消息激活的。意圖是 承載了這種異步消息內容的 Intent的對象。對於活動和服務，它主要是為被請求的動作命名，然後指定操作此數據的URI。例如，它可能攜帶讓一個活動為用戶展現一張圖片或者讓用戶編輯文本的請求。對廣播接收器，Intent對象為將要廣播的內容命名。例如，它可能會向有興趣的接收器發布照相鍵被按下的廣播。

                    There are separate methods for activiating each type of component:
                    激活不同的組件需使用不同的方法：

                    • An activity is launched (or given something new to do) by passing an Intent object to Context.startActivity() or Activity.startActivityForResult(). The responding activity can look at the initial intent that caused it to be launched by calling its getIntent() method. Android calls the activity's onNewIntent() method to pass it any subsequent intents. 向Context.startActivity()或Activity.startActivityForResult()傳遞Intent對象可以激活（或獲得新的任務）一個活動。響應的活動可以通過調用getIntent()方法查看導致自己被激活的最初的意圖。Android調用活動的onNewIntent()方法來傳遞之後的意圖。
                      

                      One activity often starts the next one. If it expects a result back from the activity it's starting, it calls startActivityForResult() instead of startActivity(). For example, if it starts an activity that lets the user pick a photo, it might expect to be returned the chosen photo. The result is returned in an Intent object that's passed to the calling activity's onActivityResult() method. 一個活動通常會開啟另一個活動。如果前一個活動希望從新啟動的活動獲得一個運行結果，可以調用startActivityForResult()方法來代替startActivity()方法。例如，如果一個老活動開啟了一個讓用戶照相的新活動，又希望從新活動獲得這張照片。新活動的運行結果是通過一個 傳遞給老活動的onActivityResult()方法的 Intent對象傳遞的。

                    • A service is started (or new instructions are given to an ongoing service) by passing an Intent object to Context.startService(). Android calls the service's onStart() method and passes it the Intent object.

                      Similarly, an intent can be passed to Context.bindService() to establish an ongoing connection between the calling component and a target service. The service receives the Intent object in an onBind() call. (If the service is not already running, bindService() can optionally start it.) For example, an activity might establish a connection with the music playback service mentioned earlier so that it can provide the user with the means (a user interface) for controlling the playback. The activity would call bindService() to set up that connection, and then call methods defined by the service to affect the playback. 服務通過向Context.startService()傳遞一個Intent對象啟動（或給予新任務）Android調用服務的onStart()方法然後將Intent對象傳遞給服務。類似的，一個意圖可以被傳給Context.bindService()來建立呼叫組件和被叫組件的實時連接。調用服務的onBind()來使其接受Intent對象。（如果服務未在運行，您可以選擇使用bindService()來啟動它。）例如上面提到過的音樂播放服務，活動會希望建立一個與此服務的連接以向用戶提供控制播放的功能（例如一個UI界面）。這時活動就會調用bindService()來建立連接，然後調用服務中定義的方法來控制播放。

                    • A later section, Remote procedure calls, has more details about binding to a service. 之後的章節會講到Remote procedure calls，那有更詳細的綁定服務的信息。

                    • An application can initiate a broadcast by passing an Intent object to methods like Context.sendBroadcast(), Context.sendOrderedBroadcast(), and Context.sendStickyBroadcast() in any of their variations. Android delivers the intent to all interested broadcast receivers by calling their onReceive() methods. 程序可以通過向類似 Context.sendBroadcast()，Context.sendOrderedBroadcast()，Context.sendStickyBroadcast()，及它們的變種 的方法傳遞一個Intent對象來初始化一條廣播。

                      For more on intent messages, see the separate article, Intents and Intent Filters.
                      獲得更多關於意圖的信息，查看單獨的章節Intents and Intent Filters。

                      Shutting down components——關閉組件

                      A content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.

                      內容提供者只有在響應來自ContentResolver的請求時才會處於激活狀態。廣播接收器只有在響應廣播信息時才處於激活狀態。所以沒有必要顯式地關閉這些組件。

                      Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:

                      活動，相反的，提供了用戶界面。他們會與用戶長時間地對話，而且可能在整個對話過程，即使處於空閒狀態，都保持運行狀態。同樣的，服務也可能會運行很長時間。因此，Android提供了下列的關閉活動和服務的方法：

                      • An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().

                        活動可以通過調用他的finish()方法進行關閉。一個活動也可以調用finishActivity()關閉另一個活動（但只能是由他調用startActivityForResult()啟動的）。

                        • A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().

                          一個服務可以通過調用他的stopSelf()方法關閉，或者調用Context.stopService()方法關閉。

                          Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components. A later section, Component Lifecycles, discusses this possibility and its ramifications in more detail.

                          當組件不會再被使用時，或Android必須回收內存以運行其他組件時，系統會自動關閉組件。後續的Component Lifecycles章節中詳細討論了這種可能和其後果。

                          The manifest file——清單文件

                          Before Android can start an application component, it must learn that the component exists. Therefore, applications declare their components in a manifest file that's bundled into the Android package, the .apk file that also holds the application's code, files, and resources.

                          Android啟動一個新的應用程序組件之前，他必須知道這個組件確實存在。因此，應用程序在清單文件中聲明了他的全部組件。清單文件隨同應用程序的代碼、文件、資源一同打包在了Android包中，即.apk文件中。

                          The manifest is a structured XML file and is always named AndroidManifest.xml for all applications. It does a number of things in addition to declaring the application's components, such as naming any libraries the application needs to be linked against (besides the default Android library) and identifying any permissions the application expects to be granted.

                          清單文件是一個結構化的XML文件，同時在所有的應用程序都被命名為AndroidManifest.xml。除了聲明應用程序的組件他還有很多功用，例如為所有應用程序需要進行連接的庫命名（除了默認的Android庫）還有識別所有應用程序期望獲得的權限。

                          But the principal task of the manifest is to inform Android about the application's components. For example, an activity might be declared as follows:

                          但是清單文件的主要任務還是為Android提供應用程序的組件信息。例如，一個活動可能會像下面這樣定義：

                          
                          
                              
                                  
                                  
                                  . . .
                              
                          

                          The name attribute of the element names the Activity subclass that implements the activity. The icon and label attributes point to resource files containing an icon and label that can be displayed to users to represent the activity.

                          元素的name屬性命名了實現了activity的Activity子類。icon和label屬性指向了 包含被顯示給用戶來代表這個活動的圖標和標題 的文件。

                          The other components are declared in a similar way — elements for services, elements for broadcast receivers, and elements for content providers. Activities, services, and content providers that are not declared in the manifest are not visible to the system and are consequently never run. However, broadcast receivers can either be declared in the manifest, or they can be created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling Context.registerReceiver().
                          其他的組件的聲明方式類似——聲明服務用元素，使用聲明廣播接收器，使用聲明內容提供者。沒被聲明的活動，服務，內容提供者對Android系統是不可見的，因此永遠都不會被運行。但是廣播接收器可以在清單文件中聲明也可在代碼中動態的創建（創建BroadcastReceiver對象），然後調用Context.registerReceiver()向系統注冊。

                          For more on how to structure a manifest file for your application, see The AndroidManifest.xml File.
                          更多有關如何為您的應用程序構造一個清單文件，請參見The AndroidManifest.xml File。

                          Intent filters——意圖匹配器

                          An Intent object can explicitly name a target component. If it does, Android finds that component (based on the declarations in the manifest file) and activates it. But if a target is not explicitly named, Android must locate the best component to respond to the intent. It does so by comparing the Intent object to the intent filters of potential targets. A component's intent filters inform Android of the kinds of intents the component is able to handle. Like other essential information about the component, they're declared in the manifest file. Here's an extension of the previous example that adds two intent filters to the activity:
                          Intent對象會詳細地指明一個目標組件。Android會找到那個組件（根據清單文件中的聲明）然後激活它。但是如果目標沒有被明確指出， Android就必須找到能響應這個意圖的最佳組件。Android將Intent對象和可能的目標組件的意圖匹配器進行比較來找出這個最佳組件。組件的意圖匹配器告訴Android這個組件能操作什麼樣的意圖。就像組件的其他重要信息一樣，它們聲明於清單文件中。這裡是上邊那個例子的增擴版，向活動中添加了兩個意圖匹配器。

                          
                          
                              
                                  
                                      
                                          
                                          
                                      
                                      
                                          
                                          
                                          
                                      
                                  
                                  . . .
                              
                          

                          The first filter in the example — the combination of the action "android.intent.action.MAIN" and the category "android.intent.category.LAUNCHER" — is a common one. It marks the activity as one that should be represented in the application launcher, the screen listing applications users can launch on the device. In other words, the activity is the entry point for the application, the initial one users would see when they choose the application in the launcher.
                          例子中的第一個意圖匹配器——"android.intent.action.MAIN"動作和"android.intent.category.LAUNCHER目錄的結合——是常見的一種。它標明這個活動要在程序菜單上列出，就是要在列出設備上用戶可用的應用程序的那一屏。換句話說，這個活動是這個應用程序的入口點，用戶從菜單中選擇運行這個程序後見到的初始的活動。

                          The second filter declares an action that the activity can perform on a particular type of data.
                          第二個匹配器聲明了這個活動能處理某種形式的數據。

                          A component can have any number of intent filters, each one declaring a different set of capabilities. If it doesn't have any filters, it can be activated only by intents that explicitly name the component as the target.
                          一個組件可以有任意多個意圖匹配器，每一個聲明這個組件的一種能力。如果一個組件沒有任何意圖匹配器，他就只能被明確的指明他作為目標組件的意圖激活。

                          For a broadcast receiver that's created and registered in code, the intent filter is instantiated directly as an IntentFilter object. All other filters are set up in the manifest.
                          對在代碼運行時創建並注冊的廣播接收器，意圖匹配器被作為IntentFilter對象直接實例化。

                          For more on intent filters, see a separate document, Intents and Intent Filters.
                          有關意圖匹配器更多信息，參見單獨的Intents and Intent Filters文檔。

                          Activities and Tasks——活動和任務

                          As noted earlier, one activity can start another, including one defined in a different application. Suppose, for example, that you'd like to let users display a street map of some location. There's already an activity that can do that, so all your activity needs to do is put together an Intent object with the required information and pass it to startActivity(). The map viewer will display the map. When the user hits the BACK key, your activity will reappear on screen.
                          上邊提到過，一個活動能啟動另一個活動，甚至是在別的應用程序中定義的活動。設想，例如，您想讓用戶顯示某地的街區地圖。而且已經有了一個可以完成此事的活動，所以您的活動要做的僅僅是將請求信息放進一個Intent對象中，將這個Intent對象傳遞給startActivity()。地圖查看器這個活動就會顯示出地圖。當用戶點擊BACK按鈕之後，您的活動就會重新出現在屏幕上。

                          To the user, it will seem as if the map viewer is part of the same application as your activity, even though it's defined in another application and runs in that application's process. Android maintains this user experience by keeping both activities in the same task. Simply put, a task is what the user experiences as an "application." It's a group of related activities, arranged in a stack. The root activity in the stack is the one that began the task — typically, it's an activity the user selected in the application launcher. The activity at the top of the stack is one that's currently running — the one that is the focus for user actions. When one activity starts another, the new activity is pushed on the stack; it becomes the running activity. The previous activity remains in the stack. When the user presses the BACK key, the current activity is popped from the stack, and the previous one resumes as the running activity.
                          對用戶來說這個地圖查看器就好像您的應用程序中的活動一樣，雖然這個地圖查看器是定義在其他應用程序中而且運行在那個應用程序的進程中。Android將您的活動和那個借用的活動放在同一個task中，以維持用戶體驗。簡單來講任務就是用戶覺得好像是一個“應用程序”的東西。任務就是以棧的形式組織起來起來的相互關聯的一組活動。棧中最底部的是任務的起始活動——一般是用戶在滑出的程序列表中選擇啟動的活動。最頂部的是正在運行的活動——用戶正在關注操作的。當一個活動開啟另一個時，新啟動的活動被壓入棧中；並且成為正在運行的活動。舊一個活動還在棧中。當用戶按下BACK鍵後，正在運行的活動被彈出棧，舊一個恢復成為正在運行的活動。

                          The stack contains objects, so if a task has more than one instance of the same Activity subclass open — multiple map viewers, for example — the stack has a separate entry for each instance. Activities in the stack are never rearranged, only pushed and popped.
                          棧中包含了對象，因此如果一個任務中開啟了 同一個Activity子類的 多個對象——例如，多個地圖浏覽——則棧對每一個實例都有一個分開的入口。棧中的活動不會被重新排序，只會被壓入、彈出。

                          A task is a stack of activities, not a class or an element in the manifest file. So there's no way to set values for a task independently of its activities. Values for the task as a whole are set in the root activity. For example, the next section will talk about the "affinity of a task"; that value is read from the affinity set for the task's root activity.
                          任務是由棧中的活動組成的，而不是清單文件中聲明的某個類或元素。所以無法單獨為一個任務設定確定的活動的信息。任務的所有信息都是設定在根活動中的。例如，下一個章節會講到“任務的親和度”；親和度信息就是從任務的根活動中獲取的。

                          All the activities in a task move together as a unit. The entire task (the entire activity stack) can be brought to the foreground or sent to the background. Suppose, for instance, that the current task has four activities in its stack — three under the current activity. The user presses the HOME key, goes to the application launcher, and selects a new application (actually, a new task). The current task goes into the background and the root activity for the new task is displayed. Then, after a short period, the user goes back to the home screen and again selects the previous application (the previous task). That task, with all four activities in the stack, comes forward. When the user presses the BACK key, the screen does not display the activity the user just left (the root activity of the previous task). Rather, the activity on the top of the stack is removed and the previous activity in the same task is displayed.
                          任務中的所有活動是作為一個整體運轉的。整個任務（一個棧的所有活動）可以被送到前台或推到後台。假設，例如，現在有一個正在運行的任務，棧中有四個活動 ——正在運行的活動下邊有三個，這是用戶按下了HOME鍵，回到了應用程序的列表然後運行了一個新的應用程序（事實上，是一個新的任務）。則舊一個任務就被推到了後台，新一個任務的根活動被現實。一段時間過後用戶回到了應用程序列表，又選擇了舊一個應用程序（舊一個任務）。則舊一個任務的所有棧中的四個活動就都被送到了前台。這時用戶如果按下BACK建屏幕不會回到用戶剛離開的活動（就是新一個任務的跟活動）。而是舊一個任務的棧頂活動被彈出，下一個活動頂上，並被顯示出來。

                          The behavior just described is the default behavior for activities and tasks. But there are ways to modify almost all aspects of it. The association of activities with tasks, and the behavior of an activity within a task, is controlled by the interaction between flags set in the Intent object that started the activity and attributes set in the activity's element in the manifest. Both requester and respondent have a say in what happens.

                          上面描述的過程是活動和任務的默認動作流程。但是那個流程很多方面都是可修改的。活動和任務的組合還有任務中的活動是由 開啟活動的Intent對象中設定的控制標 和 清單文件中活動的元素的屬性 共同控制的。

                          In this regard, the principal Intent flags are:

                          這種情況下，重要的Intent控制標有：

                          FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
FLAG_ACTIVITY_SINGLE_TOP

                          The principal attributes are:

                          重要的屬性有：

                          taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch

                          The following sections describe what some of these flags and attributes do, how they interact, and what considerations should govern their use.

                          下面的章節描述了這些控制標和屬性的作用，如何相連發生作用，在使用過程中的注意事項。

                          Affinities and new tasks——親和度和新任務

                          By default, all the activities in an application have an affinity for each other — that is, there's a preference for them all to belong to the same task. However, an individual affinity can be set for each activity with the taskAffinity attribute of the element. Activities defined in different applications can share an affinity, or activities defined in the same application can be assigned different affinities. The affinity comes into play in two circumstances: When the Intent object that launches an activity contains the FLAG_ACTIVITY_NEW_TASK flag, and when an activity has its allowTaskReparenting attribute set to "true".

                          默認的，一個應用程序中的所有活動之間都互有 親和度——就是他們屬於一個任務的優先權。但是，您可以通過每個活動的元素的taskAffinity屬相為某個活動設定單獨的親和度。不同程序中定義的活動可以共享一個親和度，一個應用程序中的不同活動可以定義不同的親和度。親和度在兩種情況下有用：一種情況是當激活活動的Intent對象包含了FLAG_ACTIVITY_NEW_TASK控制標，另一種情況是活動將allowTaskReparenting屬性設置為了"true"。

                          If an .apk file contains more than one "application" from the user's point of view, you will probably want to assign different affinities to the activities associated with each of them.

                          如果一個.apk 文件包含了多個用戶看來的“應用程序”，您可能會為和每個“應用程序”相關的活動設定不同的親和度。

                          Launch modes——啟動模式

                          There are four different launch modes that can be assigned to an element's launchMode attribute:

                          下面是可以被設為元素launchMode屬性的四種啟動模式：

                          "standard" (the default mode) ——標准（默認的）
                          "singleTop"
                          "singleTask"
                          "singleInstance"

                          The modes differ from each other on these four points:

                          每個任務都有以下四方面的特點：

                          • Which task will hold the activity that responds to the intent. For the "standard" and "singleTop" modes, it's the task that originated the intent (and called startActivity()) — unless the Intent object contains theFLAG_ACTIVITY_NEW_TASK flag. In that case, a different task is chosen as described in the previous section, Affinities and new tasks.
                            響應意圖的活動會被裝入哪個任務。"standard"和"singleTop"模式，是裝入發出意圖（調用了startActivity()）的任務——除非Intent對象含有FLAG_ACTIVITY_NEW_TASK控制標。後種情況流程如前邊Affinities and new tasks章節所述。

                            In contrast, the "singleTask" and "singleInstance" modes mark activities that are always at the root of a task. They define a task; they're never launched into another task.

                            相反的，使用"singleTask"標記和"singleInstance"標記始終為根活動的活動。開啟這樣的活動會新建一個任務；而不是裝入某個正在運行的任務。

                          • Whether there can be multiple instances of the activity. A "standard" or "singleTop" activity can be instantiated many times. They can belong to multiple tasks, and a given task can have multiple instances of the same activity.

                            是否允許產生多個活動實例。2一個"standard"或"singleTop"活動可以被多次實例化。他們可以屬於多個任務，同樣的活動可以在一個確定的任務中有多個實例。
                            

                            In contrast, "singleTask" and "singleInstance" activities are limited to just one instance. Since these activities are at the root of a task, this limitation means that there is never more than a single instance of the task on the device at one time.

                            相反的，"singleTask和"singleInstance"的活動只能有一個實例。因為這些活動是任務的根活動，這種限制意味著一個任務在同一時間只能有一個。

                          • Whether the instance can have other activities in its task. A "singleInstance" activity stands alone as the only activity in its task. If it starts another activity, that activity will be launched into a different task regardless of its launch mode — as if FLAG_ACTIVITY_NEW_TASK was in the intent. In all other respects, the "singleInstance" mode is identical to "singleTask".

                            所在任務中是否允許有其他活動。"singleInstance"活動單獨運行在一個任務中。如果他開啟另一個活動，新一個活動不論啟動模式都會運行在新任務中——就好像用帶有FLAG_ACTIVITY_NEW_TASK控制標的Intent對象激活似的。其他方面"singleInstance"與"singleTask"相同。

                            The other three modes permit multiple activities to belong to the task. A "singleTask" activity will always be the root activity of the task, but it can start other activities that will be assigned to its task. Instances of "standard" and "singleTop" activities can appear anywhere in a stack.

                            另外三個模式允許任務中存在多個活動。"singleTask"活動將總是任務的根活動，但是由他啟動的其他活動會被裝入他所在的任務。"standard"和"singleTop"活動能在任務棧中任何任何位置出現。

                          • Whether a new instance of the class will be launched to handle a new intent. For the default "standard" mode, a new instance is created to respond to every new intent. Each instance handles just one intent. For the "singleTop" mode, an existing instance of the class is re-used to handle a new intent if it resides at the top of the activity stack of the target task. If it does not reside at the top, it is not re-used. Instead, a new instance is created for the new intent and pushed on the stack.
                            獲得新意圖時是否使用新 類的 實例來操作。對於默認"standard"的模式，每次獲得新意圖時都會用新的實例響應。每個實例響應一個意圖。"singleTop"模式中，如果意圖響應類實例存在且在 意圖的目標任務 棧的棧頂，那麼意圖響應類實例將會被重用。如果存在但不再棧頂，則不會被重用。新實例被創建並壓入棧頂。

                            For example, suppose a task's activity stack consists of root activity A with activities B, C, and D on top in that order, so the stack is A-B-C-D. An intent arrives for an activity of type D. If D has the default "standard" launch mode, a new instance of the class is launched and the stack becomes A-B-C-D-D. However, if D's launch mode is "singleTop", the existing instance is expected to handle the new intent (since it's at the top of the stack) and the stack remains A-B-C-D.

                            例如，假設 一個任務的幾個活動是 根活動A，活動B，C，D 的順序，棧內就是A-B-C-D。這時收到一個類D進行響應的意圖。如果D是"standard"啟動模式，則將創建類的新實例，棧內變成A-B-C-D-D。但是如果D是"singleTop"啟動模式，用以響應新意圖的實例已經存在（而且已經在棧頂），棧保持A-B-C-D不變。

                            If, on the other hand, the arriving intent is for an activity of type B, a new instance of B would be launched no matter whether B's mode is "standard" or "singleTop" (since B is not at the top of the stack), so the resulting stack would be A-B-C-D-B.

                            如果，另一種情況，收到一個類B響應的意圖，不管B的啟動類型是"standard"還是"singleTop"（因為B不在棧頂），新實例都會被創建，之後的棧會變成A-B-C-D-B。

                            As noted above, there's never more than one instance of a "singleTask" or "singleInstance" activity, so that instance is expected to handle all new intents. A "singleInstance" activity is always at the top of the stack (since it is the only activity in the task), so it is always in position to handle the intent. However, a "singleTask" activity may or may not have other activities above it in the stack. If it does, it is not in position to handle the intent, and the intent is dropped. (Even though the intent is dropped, its arrival would have caused the task to come to the foreground, where it would remain.)

                            就像前面已經提到過的，"singleTask"和"singleInstance"活動的類永遠不可能會出現多個實例。所以他們的類就會處理所有的收到的意圖。"singleInstance"活動永遠是任務的棧的最頂活動（因為他是任務中的唯一活動），因此他也總可以處理一個意圖。但是在"singleTask"活動棧位之上可能也可能沒有另外的活動。如果有，那麼他就不能對新到的意圖進行處理，這個意圖就丟失了。（即使意圖已經丟失，意圖的收到也會出發任務使其被送到並保持在前台。）

                            When an existing activity is asked to handle a new intent, the Intent object is passed to the activity in an onNewIntent() call. (The intent object that originally started the activity can be retrieved by calling getIntent().)

                            當一個已有的活動被請求去處理一個新的意圖，Intent對象會通過onNewIntent()的調用傳遞給這個活動。（傳遞進來的原始的Intent對象可以通過調用getIntent()獲取。）

                            Note that when a new instance of an Activity is created to handle a new intent, the user can always press the BACK key to return to the previous state (to the previous activity). But when an existing instance of an Activity handles a new intent, the user cannot press the BACK key to return to what that instance was doing before the new intent arrived.

                            注意，當創建一個新的Activity類的實例來處理一個新收到的意圖時，用戶可以按BACK鍵回到上一個狀態（上一個活動）。但是使用一個已有的Activity類實例操作新收到的意圖時，用戶不能通過按下BACK鍵回到這個實例在接受到新意圖之前的狀態。

                            For more on launch modes, see the description of the element.

                            啟動模式的更多信息，參見清單文件元素的描述。

                            Clearing the stack——清理棧

                            If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it's as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.

                            如果用戶長時間沒有使用一個運行著的任務，系統會將任務和其中除根活動以外的所有活動清理掉。當用戶再次使用這個任務時，也是用戶當初離開的原因，希望只顯示第一個活動，即初始狀態。我們認為，用戶很長時間不用這個任務，就是放棄了先前做出的修改，再次回到這個任務是要重新開始。

                            That's the default. There are some activity attributes that can be used to control this behavior and modify it:

                            這是默認的情況，但是您可以更改下列的活動的屬性來控制這個機制：

                            There's another way to force activities to be removed from the stack. If an Intent object includes the FLAG_ACTIVITY_CLEAR_TOP flag, and the target task already has an instance of the type of activity that should handle the intent in its stack, all activities above that instance are cleared away so that it stands at the top of the stack and can respond to the intent. If the launch mode of the designated activity is "standard", it too will be removed from the stack, and a new instance will be launched to handle the incoming intent. That's because a new instance is always created for a new intent when the launch mode is "standard".

                            還有一種方法能將活動從棧中強行移除。如果一個Intent對象包含有FLAG_ACTIVITY_CLEAR_TOP控制標，而且目標任務中已經有一個處理此意圖的活動的實例，則所有此活動棧位之上的所有活動實例都被移除，然後此活動可以對意圖進行響應。如果此活動的啟動模式是"standard"，那麼他自己也會被移除，新活動被建立，啟動，來響應這個意圖。因為如果啟動模式是"standard"，則每一個意圖都會用一個新的實例進行處理。

                            FLAG_ACTIVITY_CLEAR_TOP is most often used in conjunction with FLAG_ACTIVITY_NEW_TASK. When used together, these flags are a way of locating an existing activity in another task and putting it in a position where it can respond to the intent.

                            FLAG_ACTIVITY_CLEAR_TOP通常會和FLAG_ACTIVITY_NEW_TASK聯合使用。一起使用時，這個組合是 找到另一個任務中的已有活動然後將它轉入新的任務中以響應一個意圖的 一種方法。

                            Starting tasks——啟動任務

                            An activity is set up as the entry point for a task by giving it an intent filter with "android.intent.action.MAIN" as the specified action and "android.intent.category.LAUNCHER" as the specified category. (There's an example of this type of filter in the earlier Intent Filters section.) A filter of this kind causes an icon and label for the activity to be displayed in the application launcher, giving users a way both to launch the task and to return to it at any time after it has been launched.

                            您可以 通過給活動添加一個"android.intent.action.MAIN" 的意圖匹配器來指定動作，一個"android.intent.category.LAUNCHER"來指定其顯示在應用程序列表中 來將這個活動設置為任務的入口活動。（上邊的Intent Filters章節中有這兩個類型的意圖匹配器的例子。）這樣的匹配器會使應用程序在應用程序列表中顯示其圖標和標題，使用戶能運行他或在運行後的任何時候回到他。

                            This second ability is important: Users must be able to leave a task and then come back to it later. For this reason, the two launch modes that mark activities as always initiating a task, "singleTask" and "singleInstance", should be used only when the activity has a MAIN and LAUNCHER filter. Imagine, for example, what could happen if the filter is missing: An intent launches a "singleTask" activity, initiating a new task, and the user spends some time working in that task. The user then presses the HOME key. The task is now ordered behind and obscured by the home screen. And, because it is not represented in the application launcher, the user has no way to return to it.

                            第二個功能很重要：用戶必須能夠在離開這個任務後能再回到當初的狀態。由於這個原因，將活動設定為切回後初始化任務的"singleTask"和"singleInstance"啟動模式只能用在有MAIN和LAUNCHER匹配器的活動裡。設想，例如，如果用在沒有這兩個匹配器的活動中會出現什麼現象：一個意圖激活了一個"singleTask"活動，初始化了一個新的任務，用戶在這個任務中做了點什麼，然後用戶按下HOME鍵。這個活動就被退到後台，並被桌面屏幕掩蓋，然後，由於他不在應用程序列表中顯示，用戶沒法再回到那個活動中去了。

                            A similar difficulty attends the FLAG_ACTIVITY_NEW_TASK flag. If this flag causes an activity to begin a new task and the user presses the HOME key to leave it, there must be some way for the user to navigate back to it again. Some entities (such as the notification manager) always start activities in an external task, never as part of their own, so they always put FLAG_ACTIVITY_NEW_TASK in the intents they pass to startActivity(). If you have an activity that can be invoked by an external entity that might use this flag, take care that the user has a independent way to get back to the task that's started.

                            相似的難題在使用FLAG_ACTIVITY_NEW_TASK控制標時也會出現。如果這個控制標使活動開啟了一個新的任務然後用戶按下HOME鍵離開這個活動，他也沒有辦法再回來了。有些東西（例如通知管理器）總是在一個新的任務中打開活動，從來不在自己的任務中打開，所以他們總將包含FLAG_ACTIVITY_NEW_TASK的意圖傳遞給startActivity()。所以如果您有一個會被其他東西以這個控制標調用的活動，請注意用戶有獨立的回到這個活動的方法。

                            For those cases where you don't want the user to be able to return to an activity, set the element's finishOnTaskLaunch to "true". See Clearing the stack, earlier.

                            如果您希望用戶離開活動後就不能再回到這個活動，可以將元素的finishOnTaskLaunch設為"true"。查看上邊提到過的Clearing the stack。

                            Processes and Threads——進程和線程

                            When the first of an application's components needs to be run, Android starts a Linux process for it with a single thread of execution. By default, all components of the application run in that process and thread.

                            當應用程序的第一個組件需要運行是，Android為其分配一個Linux進程，這個進程只有一個運行線程。默認的，這個應用程序的所有組件運行在那個進程的線程中。

                            However, you can arrange for components to run in other processes, and you can spawn additional threads for any process.

                            但是，您可以將一些組件安排在別的進程中，而且您可以為任何進程添加線程。

                            Processes——進程

                            The process where a component runs is controlled by the manifest file. The component elements — , , , and — each have a process attribute that can specify a process where that component should run. These attributes can be set so that each component runs in its own process, or so that some components share a process while others do not. They can also be set so that components of different applications run in the same process — provided that the applications share the same Linux user ID and are signed by the same authorities. The element also has a process attribute, for setting a default value that applies to all components.

                            組件運行在那個進程中是由清單文件進行設定的。組件元素——， ，和——都有一個process屬性來指定組件應該運行在哪個進程中。您可以設定這個屬性，使每個組件運行在自己的進程中，或者讓某些組件共享一個進程而其他的不。您甚至可以設定不同的應用程序的組件運行在同一個進程中——這兩個不同的應用程序須是由同一作者簽名，且分享同一個Linux 用戶ID。元素也有一個process屬性，來設定對所有組件的默認設定。

                            All components are instantiated in the main thread of the specified process, and system calls to the component are dispatched from that thread. Separate threads are not created for each instance. Consequently, methods that respond to those calls — methods like View.onKeyDown() that report user actions and the lifecycle notifications discussed later in the Component Lifecycles section — always run in the main thread of the process. This means that no component should perform long or blocking operations (such as networking operations or computation loops) when called by the system, since this will block any other components also in the process. You can spawn separate threads for long operations, as discussed under Threads, next.

                            所有的組件都是在指定進程的主線程中實例化的，對組件的系統調用也是由主線線程發出的。系統不會為每個實例建立新的線程。所以，對系統調用進行響應的方法，那些像 報告用戶操作的 View.onKeyDown()和在後邊Component Lifecycles章節提到的指示生命周期 的方法總是運行在進程的主線程中。這就是說當系統對組件進行調用時，組件不應進行長時間的或等待性的操作（例如網絡操作或循環運算），因為這樣會使同在這個進程中的其他組件運行受阻。您可以像下邊Threads中講的那樣，為耗時的操作建立單獨的進程。

                            Android may decide to shut down a process at some point, when memory is low and required by other processes that are more immediately serving the user. Application components running in the process are consequently destroyed. A process is restarted for those components when there's again work for them to do.

                            Android系統可能會在某些時候結束一個進程，當內存不足且被其他對用戶來說更緊要的進程請求時。因此，在此進程中的Android組件會被銷毀。當這些組件有新的事要做時，系統會為他們重啟進程。

                            When deciding which processes to terminate, Android weighs their relative importance to the user. For example, it more readily shuts down a process with activities that are no longer visible on screen than a process with visible activities. The decision whether to terminate a process, therefore, depends on the state of the components running in that process. Those states are the subject of a later section, Component Lifecycles.

                            Android權衡對用戶的重要性關系來決定結束哪個進程。例如，一個不是正在顯示的進程比正在顯示的進程更容易被結束。是否要結束某個進程是由裡邊運行的組件的狀態決定的。組建的狀態是下邊Component Lifecycles章節的主題。

                            Threads——線程

                            Even though you may confine your application to a single process, there will likely be times when you will need to spawn a thread to do some background work. Since the user interface must always be quick to respond to user actions, the thread that hosts an activity should not also host time-consuming operations like network downloads. Anything that may not be completed quickly should be assigned to a different thread.

                            即使您將您的應用程序限制在了一個進程中，那您也很可能有需要新建一個線程來進行後台工作的可能。因為用戶界面必須總是能快速地響應用戶的動作，承載著活動的線程不能同時還承載者像網絡下載這種耗時的操作。所有不能立刻完成的操作都應為其單獨建立線程。

                            Threads are created in code using standard Java Thread objects. Android provides a number of convenience classes for managing threads — Looper for running a message loop within a thread, Handler for processing messages, andHandlerThread for setting up a thread with a message loop.

                            線程在代碼中使用標准的Java Thread對象建立。Android提供了很多方便的管理線程的類——使用一個線程運行消息循環可以使用Looper，Handler響應消息，HandlerThread 創建帶有消息循環的線程。

                            Remote procedure calls——遠程過程調用

                            Android has a lightweight mechanism for remote procedure calls (RPCs) — where a method is called locally, but executed remotely (in another process), with any result returned back to the caller. This entails decomposing the method call and all its attendant data to a level the operating system can understand, transmitting it from the local process and address space to the remote process and address space, and reassembling and reenacting the call there. Return values have to be transmitted in the opposite direction. Android provides all the code to do that work, so that you can concentrate on defining and implementing the RPC interface itself.

                            Android 有一個輕量級的遠程過程調用的機制（RPCs）——使得方法在本地調用，然後遠程執行（在另一個進程中），並將所有結果返回本地。這需要將方法的調用和隨之的數據解釋成操作系統可以識別的級別，將其從本地進程和地址空間傳送到遠程端的進程和地址空間中，在遠程端重新裝配和組織。返回數據傳遞過程相反。 Android提供了所有完成這些過程的代碼，所以您可以將精力集中在RPC接口的定義和實現上。

                            An RPC interface can include only methods. All methods are executed synchronously (the local method blocks until the remote method finishes), even if there is no return value.

                            RPC接口可以只包含方法。所有的方法都是同步執行的（本地方法會等待遠程方法），在沒有返回值的情況下也是這樣。

                            In brief, the mechanism works as follows: You'd begin by declaring the RPC interface you want to implement using a simple IDL (interface definition language). From that declaration, the aidl tool generates a Java interface definition that must be made available to both the local and the remote process. It contains two inner class, as shown in the following diagram:

                            簡單來講，RPC機制是這樣的流程：首先，您使用簡單的IDL（接口定義語言）對您想要實現的RPC接口進行聲明。在生聲明中，您需要使用aidl工具生成一個本地和遠程端進程都可以使用的Java接口定義。定義中含有兩個內部類，下面圖標顯示了這個結構：

                            

                            The inner classes have all the code needed to administer remote procedure calls for the interface you declared with the IDL. Both inner classes implement the IBinder interface. One of them is used locally and internally by the system; the code you write can ignore it. The other, called Stub, extends the Binder class. In addition to internal code for effectuating the IPC calls, it contains declarations for the methods in the RPC interface you declared. You would subclass Stub to implement those methods, as indicated in the diagram.

                            內部類中含有所有 用以管理您使用IDL聲明的接口的遠程過程調用 的代碼。兩個內部類都實現了IBinder接口。一個被系統本地地，內部地使用；您自己寫的代碼會忽略掉它們。另一個，叫做Stub，由Binder類派生。不僅含有執行IPC調用的代碼，還含有您聲明的RPC接口中方法的聲明。就像圖標中顯示的，您應該繼承Stub類來實現這些方法。

                            Typically, the remote process would be managed by a service (because a service can inform the system about the process and its connections to other processes). It would have both the interface file generated by the aidl tool and the Stub subclass implementing the RPC methods. Clients of the service would have only the interface file generated by the aidl tool.

                            典型的情況是，遠程端的進程是由一個服務進行管理的（因為服務能向系統告知 這個進程 還有 這個進程和其他進程間連接的 信息）。您應在aidl工具產生的接口文件和Stub子類中均實現RPC方法。服務器的客戶端應該只有aidl工具生成的接口文件。

                            Here's how a connection between a service and its clients is set up:
                            這是服務器和其客戶端建立連接的流程：

                            • Clients of the service (on the local side) would implement onServiceConnected() and onServiceDisconnected() methods so they can be notified when a successful connection to the remote service is established, and when it goes away. They would then call bindService() to set up the connection. 服務器的客戶端（即本地端）會實現onServiceConnected()和onServiceDisconnected()方法，然後客戶端在在遠程服務連接建立或丟失時得知這一信息。然後客戶端會調用bindService()來對連接進行設定。
                            • The service's onBind() method would be implemented to either accept or reject the connection, depending on the intent it receives (the intent passed to bindService()). If the connection is accepted, it returns an instance of the Stub subclass. 根據接收的意圖（意圖被傳遞到bindService()）服務的onBind()方法會被實現於接受或拒絕連接。如果連接被接受，方法返回一個Stub子類的實例。
                            • If the service accepts the connection, Android calls the client's onServiceConnected() method and passes it an IBinder object, a proxy for the Stub subclass managed by the service. Through the proxy, the client can make calls on the remote service. 如果服務接受了連接，Android調用客戶端的onServiceConnected()方法並且傳遞給它一個IBinder對象，IBinder對象是由服務管理的Stub類的一個代理。通過這個代理，客戶端可以調用遠程端上的服務。

                              This brief description omits some details of the RPC mechanism. For more information, see Designing a Remote Interface Using AIDL and the IBinder class description.這個簡要的RPC機制介紹省略了一些細節。更多信息請看Interface Using AIDL和IBinder類的介紹。

                              Thread-safe methods——線程保險的方法

                              In a few contexts, the methods you implement may be called from more than one thread, and therefore must be written to be thread-safe.
                              在某些情況下，您實現的方法可能會從多個線程進行調用，因此您的實現必須是線程上講安全的。

                              This is primarily true for methods that can be called remotely — as in the RPC mechanism discussed in the previous section. When a call on a method implemented in an IBinder object originates in the same process as the IBinder, the method is executed in the caller's thread. However, when the call originates in another process, the method is executed in a thread chosen from a pool of threads that Android maintains in the same process as the IBinder; it's not executed in the main thread of the process. For example, whereas a service's onBind() method would be called from the main thread of the service's process, methods implemented in the object that onBind() returns (for example, a Stub subclass that implements RPC methods) would be called from threads in the pool. Since services can have more than one client, more than one pool thread can engage the same IBinder method at the same time. IBinder methods must, therefore, be implemented to be thread-safe.
                              這種情況主要出現在能被遠程調用的方法中——像在上邊討論的RPC機制。當一個對 IBinder對象中實現的一個方法 進行的調用來自IBinder本身所在線程時，方法就運行在調用者所在線程中。但是，當調用來自另外一個進程時，方法會運行在從 Android為IBinder進程保持的線程池 中選擇的一個線程中，而不是運行在另外那個進程的主線程中。例如，服務的onBind()方法的的調用來自服務的進程的主線程，onBind()返回的對象的實現的方法（例如，Stub類實現的RPC方法）會被在池中的線程調用。因為服務可以有很多客戶，因此在同一時間可能有多個池中的線程調用了IBinder方法。因此，IBinder的實現對多進程調用必須是安全的。

                              Similarly, a content provider can receive data requests that originate in other processes. Although the ContentResolver and ContentProvider classes hide the details of how the interprocess communication is managed, ContentProvider methods that respond to those requests — the methods query(), insert(), delete(), update(), and getType() — are called from a pool of threads in the content provider's process, not the main thread of the process. Since these methods may be called from any number of threads at the same time, they too must be implemented to be thread-safe.
                              相似的，內容提供者可以接受來自其他進程的數據請求。盡管ContentResolver和ContentProvider類隱藏了實現管理進程間通信的方法的細節，可是響應這些請求的ContentProvider方法——query()，insert()，delete()，update()和getType()方法——是從內容提供者進程的線程池中調用的，而不是主線程。因此，這些方法可能會在同一時間被多個線程調用，他們的實現對多進程調用也必須是安全的。

                              Component Lifecycles——組件生命周期

                              Application components have a lifecycle — a beginning when Android instantiates them to respond to intents through to an end when the instances are destroyed. In between, they may sometimes be active or inactive,or, in the case of activities, visible to the user or invisible. This section discusses the lifecycles of activities, services, and broadcast receivers — including the states that they can be in during their lifetimes, the methods that notify you of transitions between states, and the effect of those states on the possibility that the process hosting them might be terminated and the instances destroyed.
                              應用程序的組建有生命周期——從Android為其實例化以響應意圖開始 到 實例被銷毀結束。中間這段時間，這些組件可能正在活動，也可能不在，或者對活動來講是可見或不可見。這一節討論了 活動、服務、廣播接收器的生命周期——包括他們在生命周期內可能的狀態 ，狀態轉換時的通知方式 ，和這些狀態對承載組建的進程被結束（同時進程中的實例被銷毀）的可能性的影響。

                              Activity lifecycle——活動的生命周期

                              An activity has essentially three states:
                              活動本質上有三個狀態：

                              • It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions. 當他在前台時（在當前任務的活動棧的棧頂）是active或running的（活動的或運行中的）。這種活動是正在關注用戶動作的。

                              • It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations. 失去用戶關注，但是仍然是可見的 是paused（暫停）狀態。就是說，另一個透明或不覆蓋整個屏幕的活動覆蓋在了這個活動之上，因此部分paused的活動的界面還是顯示出來的。暫停的活動依然是存活的（他保持著所有的狀態和成員信息並且保持著和窗口管理器的聯系），但是會在系統運行內存極低的情況下被關閉。

                              • It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere. 當一個活動被另一個活動完全覆蓋時，就是stopped（停止）狀態。停止的活動保留著所有的狀態和成員信息。但是，因為他已經處於不可見狀態，他的窗口就被隱藏了，而且通常系統會在內存需要用在別的地方時關閉停止的活動。

                                If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
                                如果一個活動處於暫停或停止狀態，系統會通過 勒令其完成工作並推出（調用其finish()方法）或簡單的結束其所在進程 來將其從內存中清理掉。當他再次顯示給用戶是=時，他必須請完全的重新啟動並恢復到之前的狀態。

                                As an activity transitions from state to state, it is notified of the change by calls to the following protected methods:
                                活動在上述幾種狀態間變動時，系統會調用下列的protected（受保護）的方法對其進行通知：

                                void onCreate(Bundle savedInstanceState)
void onStart()
void onRestart()
void onResume()
void onPause()
void onStop()
void onDestroy()

                                All of these methods are hooks that you can override to do appropriate work when the state changes. All activities must implement onCreate() to do the initial setup when the object is first instantiated. Many will also implement onPause()to commit data changes and otherwise prepare to stop interacting with the user.
                                所有這些方法都是掛鉤，你可以重寫狀態變化時的動作。所有活動都必須實現onCreate()，從而在對象第一次實例化後進行初始化設置。許多活動還要實現onPause()來確認數據變化或者准備停止與用戶的交互。

                                Calling into the superclass——調用父類方法

                                An implementation of any activity lifecycle method should always first call the superclass version. For example:
                                所有的活動的生命周期方法的實現都應首先調用父類的實現。例如：

                                protected void onPause() {
                                    super.onPause();
                                    . . .
                                }

                                Taken together, these seven methods define the entire lifecycle of an activity. There are three nested loops that you can monitor by implementing them:
                                總的來說，這七種方法確定活動的整個生命周期。實現生命周期後，您可以對生命周期的這幾個嵌套循環進行監控：

                                • call to onCreate() through to a single final call to onDestroy(). An activity does all its initial setup of "global" state in onCreate(), and releases all remaining resources inonDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread inonDestroy(). 從調用onCreate()一直到結束性的onDestroy()的調用。活動在onCreate()中進行所有“全局”狀態的初始化，後釋放所有占用的資源例如，如果一個活動有一個後台的從網絡上下載數據的線程，活動可能會使用onCreate()創建線程，使用onDestroy()停止線程。

                                • The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time, the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods, you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user can no longer see what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible and hidden to the user. 活動可見的時間是onStart()的調用到相應的onStop()的調用之間的時間。這段時間用戶可以在屏幕上看到這個活動，即便這個活動可能不在前台，沒在和用戶進行交互。在這兩個方法的調用之間的時間，您可以保持將活動展現給用戶的資源。例如，您可以在onStart()中注冊一個BroadcastReceiver來監控UI的變化，然後在用戶不能再看到您要顯示的後在onStop()中注銷它。活動在可見和隱藏間切換過程中，onStart()和onStop()會被調用多次。

                                • The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states — for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight. 活動的前台時間是onResume()和對應的onPause()的調用之間的時間。這段時間中，活動處在其他活動之上，並和用戶進行交互。活動可以在暫停和繼續之間多次切換——例如，當設備休眠或啟動了新的活動，onPause()會被調用，收到新啟動活動返回結果或舊活動收到新意圖時，onResume()會被調用。所以這兩個方法中的代碼應絕對輕量。

                                  The following diagram illustrates these loops and the paths an activity may take between states. The colored ovals are major states the activity can be in. The square rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.
                                  下面的圖標演示了這三個循環還有活動在狀態間轉換的步驟。彩色的橢圓是活動可能處於的狀態。直角矩形是您可以實現的 在狀態改變時執行操作的 回調方法。

                                  

                                  The following table describes each of these methods in more detail and locates it within the activity's overall lifecycle:
                                  下面的表格描述了這些方法的詳情，和在整個活動生命周期中的位置：

                                  Method——方法 Description——詳情 Killable?——是否可結束？ Next——下一步 onCreate() Called when the activity is first created. This is where you should do all of your normal static set up — create views, bind data to lists, and so on. This method is passed a Bundle object containing the activity's previous state, if that state was captured (see Saving Activity State, later).

                                  Always followed by onStart().
                                  活動啟動時調用。在這個方法裡您應完成所有靜態的常規的設定——建立view、將數據綁定到列表等等。這個方法調用時如果有先前狀態可用，會接受到一個包含這個活動之前的狀態的Bundle對象。（參見後面的Saving Activity State）。
                                  下一步總是onStart()。

                                  No
                                  不可 onStart()   onRestart() Called after the activity has been stopped, just prior to it being started again.
                                  活動被停止之後，重新啟動之前被調用。
                                  

                                  Always followed by onStart()
                                  下一步總是onStart()

                                  No
                                  不可 onStart() onStart() Called just before the activity becomes visible to the user.

                                  Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.
                                  活動對用戶可見之前被調用。
                                  如果活動切到前台，下一步是調用onResume()；如果活動被隱藏，下一步是調用onStop()。

                                  No
                                  不可 onResume()
                                  or
                                  onStop()

onResume()或是onStop()   onResume() Called just before the activity starts interacting with the user. At this point the activity is at the top of the activity stack, with user input going to it.

                                  Always followed by onPause().
                                  在活動和用戶交互之前被調用。這是活動在棧頂，響應用戶的輸入。
                                  下一步總是 onPause()。

                                  No
                                  不可 onPause() onPause() Called when the system is about to start resuming another activity. This method is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, and so on. It should do whatever it does very quickly, because the next activity will not be resumed until it returns.
                                  系統要開始繼續其他活動時被調用。這個方法典型的用法是將為保存的數據存入穩定存儲，停止動畫或其他占用CPU的動作等等。這個方法中動作應盡快完成，因為完成後，下一個活動才會開始。
                                  

                                  Followed either by onResume() if the activity returns back to the front, or by onStop() if it becomes invisible to the user.
                                  如果活動之後回到前台，下一步是onResume()；如果他對用戶不再可見，下一步是onStop()。

                                  Yes
                                  可以 onResume()
                                  or
                                  onStop() onStop() Called when the activity is no longer visible to the user. This may happen because it is being destroyed, or because another activity (either an existing one or a new one) has been resumed and is covering it.
                                  活動對用戶不再可見時被調用。這種情況一般發生在活動被銷毀時或者另一個活動（已存在的或新啟動的）被繼續，並且覆蓋了這個活動。
                                  

                                  Followed either by onRestart() if the activity is coming back to interact with the user, or by onDestroy() if this activity is going away.
                                  如果活動回到前台進行與用戶的交互，下一步是onRestart()；如果活動將被銷毀，下一步是onDestroy()。

                                  Yes
                                  可以 onRestart()
                                  or
                                  onDestroy() onDestroy() Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.
                                  活動被銷毀之前被調用。這是活動接到的最後一個調用。當活動完成之後（有些人調用finish()）或系統為了節約空間將這個實例暫時銷毀 時會被調用。您應該可以看出和調用isFinishing()方法之間的區別。 Yes
                                  可以 nothing
                                  無

                                  Note the Killable column in the table above. It indicates whether or not the system can kill the process hosting the activity at any time after the method returns, without executing another line of the activity's code. Three methods (onPause(), onStop(), and onDestroy()) are marked "Yes." Because onPause() is the first of the three, it's the only one that's guaranteed to be called before the process is killed — onStop() and onDestroy() may not be. Therefore, you should use onPause() to write any persistent data (such as user edits) to storage.
                                  注意上邊的表格中Killable？——是否可結束？一欄。它表示了系統會不會 在方法動作結束後不再執行活動的代碼就 結束承載著這個活動的進程。有三個方法（onPause()，onStop()和onDestroy()）標志著"Yes."。因為onPause()是這三個方法中第一個，所以他是唯一一個被允許在進程被結束之前調用的方法——onStop()和onDestroy()則可能不行。所以，將數據（例如用戶修改信息）存入穩定存儲的過程應在onPause()中完成。

                                  Methods that are marked "No" in the Killable column protect the process hosting the activity from being killed from the moment they are called. Thus an activity is in a killable state, for example, from the time onPause() returns to the timeonResume() is called. It will not again be killable until onPause() again returns.
                                  Killable？——是否可結束？一欄標注著“No”的方法保護了其所在進程在這個方法調用之時起不被結束。就是說，例如在onPause()方法完成之後到onResume()被調用之前這段時間之內，進程是可能被結束的。然後到下一次onPause()完成之前，進程是不可結束的。

                                  As noted in a later section, Processes and lifecycle, an activity that's not technically "killable" by this definition might still be killed by the system — but that would happen only in extreme and dire circumstances when there is no other recourse.
                                  像下邊Processes and lifecycle章節提到的，上邊定義的技術上講不會被結束的活動還是有可能被系統結束的——但只是在極端的沒有一點其他資源時才會發生。

                                  Saving activity state——保存活動狀態

                                  When the system, rather than the user, shuts down an activity to conserve memory, the user may expect to return to the activity and find it in its previous state.
                                  當系統，而不是用戶，為了釋放內存而關閉這個活動時，用戶當然希望再次進入這個活動時狀態還是之前的狀態。

                                  To capture that state before the activity is killed, you can implement an onSaveInstanceState() method for the activity. Android calls this method before making the activity vulnerable to being destroyed — that is, before onPause() is called. It passes the method a Bundle object where you can record the dynamic state of the activity as name-value pairs. When the activity is again started, the Bundle is passed both to onCreate() and to a method that's called afteronStart(), onRestoreInstanceState(), so that either or both of them can recreate the captured state.
                                  截獲活動被結束之前的狀態，您需要實現活動的onSaveInstanceState()方法。Android會在使這個活動實例接近銷毀條件之前調用這個方法——就是說，onPause()調用之前。Android傳遞給這個方法一個Bundle對象，從而您可以以 名稱-值 對的形式記錄這個活動的動態狀態。當這個活動再次開啟之時，Bundle對象會傳遞給 onCreate() 和 onStart()之後調用的一個方法——onRestoreInstanceState() ，然後，您可以用這兩個中任一個重建 處於截獲的狀態的 活動。

                                  Unlike onPause() and the other methods discussed earlier, onSaveInstanceState() and onRestoreInstanceState() are not lifecycle methods. They are not always called. For example, Android calls onSaveInstanceState() before the activity becomes vulnerable to being destroyed by the system, but does not bother calling it when the instance is actually being destroyed by a user action (such as pressing the BACK key). In that case, the user won't expect to return to the activity, so there's no reason to save its state.
                                  不像onPause()和前面講的其他方法，onSaveInstanceState()和onRestoreInstanceState()不是生命周期方法。他們不是總會被調用。例如，Android在活動合乎有可能被系統銷毀的條件的時候會調用onSaveInstanceState()，但是在用戶發出動作（例如按下BACK鍵）將實例實際銷毀時不會調用。但在這種情況下，用戶也沒有希望回到這個活動，因此也沒有保存狀態的必要。

                                  Because onSaveInstanceState() is not always called, you should use it only to record the transient state of the activity, not to store persistent data. Use onPause() for that purpose instead.

                                  因為onSaveInstanceState()不是一定會被調用，因此您只能用它保存過渡狀態，而不能用來保存穩定數據。如要保存穩定數據，請使用onPause()。

                                  Coordinating activities——協調活動

                                  When one activity starts another, they both experience lifecycle transitions. One pauses and may stop, while the other starts up. On occasion, you may need to coordinate these activities, one with the other.

                                  當一個活動開啟了另一個活動時，這兩個活動都經歷了生命周期的變化。就一個活動暫停或停止，新一個活動開啟。有些情況下，您可能需要協調這些活動。

                                  The order of lifecycle callbacks is well defined, particularly when the two activities are in the same process:

                                  生命周期回調方法的順序已經定義好，特別是當這兩個活動在同一個進程中：

                                  1. The current activity's onPause() method is called.——當前的活動的onPause()方法被調用·。
                                  2. Next, the starting activity's onCreate(), onStart(), and onResume() methods are called in sequence.——然後，新一個活動的onCreate()、onStart()和onResume()方法依次被調用。
                                  3. Then, if the starting activity is no longer visible on screen, its onStop() method is called.——然後，如果舊一個活動在屏幕上不再可見，他的onStop()方法會被調用。

                                     Service lifecycle——服務的生命周期

                                     A service can be used in two ways:

                                     服務可用於以下兩種方式：

                                     • It can be started and allowed to run until someone stops it or it stops itself. In this mode, it's started by calling Context.startService() and stopped by calling Context.stopService(). It can stop itself by callingService.stopSelf() or Service.stopSelfResult(). Only one stopService() call is needed to stop the service, no matter how many times startService() was called.——他可以啟動並運行指導什麼將它停止或她自己停止。在這種模式中，他通過調用Context.startService()開啟，通過調用Context.stopService()停止。服務能通過調用Service.stopSelf()或Service.stopSelfResult()停止自己。停止一個服務只需一個stopService()的調用，不管用了多少次startService()。

                                     • It can be operated programmatically using an interface that it defines and exports. Clients establish a connection to the Service object and use that connection to call into the service. The connection is established by callingContext.bindService(), and is closed by calling Context.unbindService(). Multiple clients can bind to the same service. If the service has not already been launched, bindService() can optionally launch it. ——對服務可以使用他定義和導出的接口進行 編程性的操作。客戶端建立一個到Service對象的連接，然後使用這個連接對服務進行請求。連接使用Context.bindService()建立，使用Context.unbindService()斷開。多個客戶端可以綁定到一個服務。如果服務還未被啟動，可用bindService()啟動它。

                                       The two modes are not entirely separate. You can bind to a service that was started with startService(). For example, a background music service could be started by calling startService() with an Intent object that identifies the music to play. Only later, possibly when the user wants to exercise some control over the player or get information about the current song, would an activity establish a connection to the service by calling bindService(). In cases like this,stopService() will not actually stop the service until the last binding is closed.

                                       這兩個方式不是完全分開的。您可以綁定到一個使用startService()啟動的服務上。例如，一個後台的音樂播放服務可以調用startService()並傳遞一個包含識別要播放的音樂的意圖來啟動。片刻後，當 用戶想對播放器進行控制或獲取正在播放的音樂的信息 時，您可能就要需要一個活動調用bindService()來建立到這個服務的連接。像這個情況，stopService()不會真的停止服務，直到最後一個綁定解開。

                                       Like an activity, a service has lifecycle methods that you can implement to monitor changes in its state. But they are fewer than the activity methods — only three — and they are public, not protected:

                                       像活動一樣，服務也有您可以對其進行實現以監視服務狀態的生命周期方法。但是比活動的少——只有三個——而且是公共的，而不是受保護的：

                                       void onCreate()
void onStart(Intent intent)
void onDestroy()

                                       By implementing these methods, you can monitor two nested loops of the service's lifecycle:

                                       實現後，您可以監控服務的這兩個生命周期嵌套循環：

                                       • The entire lifetime of a service happens between the time onCreate() is called and the time onDestroy() returns. Like an activity, a service does its initial setup in onCreate(), and releases all remaining resources in onDestroy(). For example, a music playback service could create the thread where the music will be played in onCreate(), and then stop the thread in onDestroy().——服務的整個存在時間是從onCreate()被調用到onDestroy()完成。像活動一樣，服務在onCreate()被調用時進行初始化設置，在onDestroy()中完成占有的資源的釋放。例如，音樂播放服務會在onCreate()中為音樂的播放建立新的線程，然後在onDestroy()中結束線程。

                                       • The active lifetime of a service begins with a call to onStart(). This method is handed the Intent object that was passed to startService(). The music service would open the Intent to discover which music to play, and begin the playback.——服務的動作時間是從onStart()的調用開始的。傳遞給startService()的Intent對象又被傳遞給這個方法。音樂播放服務會打開這個意圖找到要播放哪個歌曲，然後開始播放。

                                         There's no equivalent callback for when the service stops — no onStop() method.

                                         服務沒有像活動的停止時的回調方法——就是沒有onStop()方法。

                                         The onCreate() and onDestroy() methods are called for all services, whether they're started by Context.startService() or Context.bindService(). However, onStart() is called only for services started by startService().

                                         無論服務是否由Context.startService()或Context.bindService()啟動，onCreate()和onDestroy()方法都會被調用。但是，系統只會為由startService()啟動的服務調用onStart()。

                                         If a service permits others to bind to it, there are additional callback methods for it to implement:

                                         如果服務允許別人綁定到他，您還需要實現以下幾個回調方法：

                                         IBinder onBind(Intent intent)
boolean onUnbind(Intent intent)
void onRebind(Intent intent)

                                         The onBind() callback is passed the Intent object that was passed to bindService and onUnbind() is handed the intent that was passed to unbindService(). If the service permits the binding, onBind() returns the communications channel that clients use to interact with the service. The onUnbind() method can ask for onRebind() to be called if a new client connects to the service.

                                         onBind()方法獲得傳遞給bindService的Intent對象，onUnbind()方法獲得傳遞unbindService()給的Intent對象如果服務允許綁定，onBind()返回客戶端用以和服務交互的信道。onUnbind()方法可以在新的客戶連接到服務時讓系統調用onRebind()。

                                         The following diagram illustrates the callback methods for a service. Although, it separates services that are created via startService from those created by bindService(), keep in mind that any service, no matter how it's started, can potentially allow clients to bind to it, so any service may receive onBind() and onUnbind() calls.

                                         下面的圖表演示了服務的回調方法。雖然，使用startService和bindService()開啟的服務稍有不同，但是請記住，所有服務，無論是怎麼啟動的，一般都會允許服務綁定到他，因此所有的服務都有可能收到onBind()和onUnbind()調用。

                                         

                                         Broadcast receiver lifecycle——廣播接收器生命周期

                                         A broadcast receiver has single callback method:

                                         廣播接收器只有一個回調方法：

                                         void onReceive(Context curContext, Intent broadcastMsg)

                                         When a broadcast message arrives for the receiver, Android calls its onReceive() method and passes it the Intent object containing the message. The broadcast receiver is considered to be active only while it is executing this method. When onReceive() returns, it is inactive.

                                         廣播消息到達接收器時，Android 調用他的onReceive()方法並且將一個包含有廣播信息的Intent對象傳遞給這個方法。我們認為廣播接收器只有在執行這個方法時是被激活的。onReceive()方法完成之後，他就不再活動。

                                         A process with an active broadcast receiver is protected from being killed. But a process with only inactive components can be killed by the system at any time, when the memory it consumes is needed by other processes.
                                         一個承載著激活的廣播接收者的進程是不會被結束的。但是只有不活動的接收者組件的進程可能被系統 在別的進程需要他所占用的內存時 隨時結束。

                                         This presents a problem when the response to a broadcast message is time consuming and, therefore, something that should be done in a separate thread, away from the main thread where other components of the user interface run. IfonReceive() spawns the thread and then returns, the entire process, including the new thread, is judged to be inactive (unless other application components are active in the process), putting it in jeopardy of being killed. The solution to this problem is for onReceive() to start a service and let the service do the job, so the system knows that there is still active work being done in the process.
                                         當對廣播信息的響應是一個耗時的事，然後，因此應該單獨給他一個線程運行，而不是在其他組件所在的與用戶交互的線程中時，問題就出現了。如果創建了新的線程然後在新線程中運行，整個進程，包括新線程 就都被認為是不活動的了（除非進程中有其他活動的應用程序組件），而且有被結束的危險。解決的方法是，讓啟動一個服務，然後讓服務做這個耗時的事，然後系統就知道了進程中還有活動的正在做的事。

                                         The next section has more on the vulnerability of processes to being killed.
                                         下一節講了更多有關進程被結束的容易程度。

                                         Processes and lifecycles——進程和生命周期

                                         The Android system tries to maintain an application process for as long as possible, but eventually it will need to remove old processes when memory runs low. To determine which processes to keep and which to kill, Android places each process into an "importance hierarchy" based on the components running in it and the state of those components. Processes with the lowest importance are eliminated first, then those with the next lowest, and so on. There are five levels in the hierarchy. The following list presents them in order of importance:
                                         Android系統試圖將應用程序的進程保持最長的時間，但是最終當內存不足時，還是需要將不用的進程結束掉。為了判斷哪些進程該結束，哪些不該， Android將每個進程按照當中運行的組件和組件的狀態 排放到一個“重要程度排行表”中。最不重要的最先結束，然後是次不重要的，依此類推。“重要程度排行表”中有五層重要程度。下面的表按重要程度順序列出了他們：

                                         1. A foreground process is one that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions hold:——前台進程是需要獲取用戶正在做得事情的進程。進程有下列情況的，即認定為前台進程：
                                            • It is running an activity that the user is interacting with (the Activity object's onResume() method has been called).——正在運行一個用戶正與之交互的活動（即活動的onResume()方法被調用了）

                                            • It hosts a service that's bound to the activity that the user is interacting with.——承載了一個 用戶正在與之交互的活動所屬的 服務。

                                            • It has a Service object that's executing one of its lifecycle callbacks (onCreate(), onStart(), or onDestroy()).——承載著一個正在執行其生命周期回調方法（onCreate()，onStart()或onDestroy()）的Service對象。

                                            • It has a BroadcastReceiver object that's executing its onReceive() method.——承載了一個正在運行其onReceive()方法的BroadcastReceiver對象。

                                              Only a few foreground processes will exist at any given time. They are killed only as a last resort — if memory is so low that they cannot all continue to run. Generally, at that point, the device has reached a memory paging state, so killing some foreground processes is required to keep the user interface responsive.——任一時刻只會有很少的前台進程存在。結束他們是沒有辦法的辦法——只有當內存不足到他們都沒法運行了。通常情況下，到了這種狀況，設備就到了內存分頁狀態，結束一些前台進程是為了保持用戶界面的響應。

                                            • A visible process is one that doesn't have any foreground components, but still can affect what the user sees on screen. A process is considered to be visible if either of the following conditions holds:——可見進程是沒有任何前台組件，但是依舊可以被用戶看見的進程。進程有下列情況之一的，即認定為前台進程：

                                              • It hosts an activity that is not in the foreground, but is still visible to the user (its onPause() method has been called). This may occur, for example, if the foreground activity is a dialog that allows the previous activity to be seen behind it.——承載著不在前台的活動，但是活動依舊能被用戶看到（活動的onPause()方法被調用了）。例如當前台活動是一個沒有完全蓋住舊一個活動對話框時這種情況就可能發生。

                                              • It hosts a service that's bound to a visible activity.——承載了一個屬於可見活動的服務。

                                                A visible process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.——可見進程也是極為重要的，除非結束可見進程是為了保持前台進程的運行，否則可見進程是不會被結束的。

                                              • A service process is one that is running a service that has been started with the startService() method and that does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing an mp3 in the background or downloading data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.——服務進程是 運行著一個由startService()方法啟動的並且不在前兩種所述情況中的服務的 進程。雖然服務進程不與任何用戶可見部分直接相連，但他們通常是在做一些用戶關心的事（例如在後台播放音樂或從網上下載數據），所以除非內存不足以盛放前台和可見進程，系統是不會結束服務進程的。

                                              • A background process is one holding an activity that's not currently visible to the user (the Activity object's onStop() method has been called). These processes have no direct impact on the user experience, and can be killed at any time to reclaim memory for a foreground, visible, or service process. Usually there are many background processes running, so they are kept in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. If an activity implements its lifecycle methods correctly, and captures its current state, killing its process will not have a deleterious effect on the user experience.——後台進程是承載目前用戶不可見的活動（Activity的onStop()方法被調用後）的進程。後台進程不直接影響用戶體驗，而且隨時可以結束以回收供前台進程、可見進程和服務進程使用。通常同一時間會有很多正在運行的後台進程，因此他們被存放在LRU（最近使用過的）列表中以保證最後含有用戶最後使用的活動的進程是最後被結束的。如果活動正確地實現了其生命周期方法截獲了當前狀態，那麼結束他所在進程不會對用戶體驗有壞的影響。

                                              • An empty process is one that doesn't hold any active application components. The only reason to keep such a process around is as a cache to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.——空進程是不包含任何活動的進程。保留空進程的唯一原因是作為緩存以提升組件下次使需要用他的開始速度。系統經常會結束這樣的進程以平衡 在進程緩存和底層內核緩存之間的 整體系統資源。

                                                Android ranks a process at the highest level it can, based upon the importance of the components currently active in the process. For example, if a process hosts a service and a visible activity, the process will be ranked as a visible process, not a service process.
                                                Android依據在進程中正在活動的組件的重要程度 將進程排在他能處在的最高級。例如，如果一個進程承載了一個服務和一個可見進程，那麼此進程就被排為可見進程，而不是服務進程。

                                                In addition, a process's ranking may be increased because other processes are dependent on it. A process that is serving another process can never be ranked lower than the process it is serving. For example, if a content provider in process A is serving a client in process B, or if a service in process A is bound to a component in process B, process A will always be considered at least as important as process B.
                                                另外，如果有其他進程依賴於此進程，那此進程的排位會上升。一個正服務於其他進程 的進程的排位不會低於他服務於的進程的排位。例如，進程A中的一個內容提供者正在為一個進程B中的客戶服務，或者如果進程A中的服務屬於進程B的一個組件，那麼認為進程A至少與B重要性相同。

                                                Because a process running a service is ranked higher than one with background activities, an activity that initiates a long-running operation might do well to start a service for that operation, rather than simply spawn a thread — particularly if the operation will likely outlast the activity. Examples of this are playing music in the background and uploading a picture taken by the camera to a web site. Using a service guarantees that the operation will have at least "service process" priority, regardless of what happens to the activity. As noted in the Broadcast receiver lifecycle section earlier, this is the same reason that broadcast receivers should employ services rather than simply put time-consuming operations in a thread.
                                                因為運行著服務的進程排位比運行著後台活動的進程高，因此相比於只是簡單的新建一個線程進行耗時的操作——特別是進行可能會超過活動生命時間的操作，新建一個服務進行那項操作使您更好的選擇。例如在後台播放音樂和拍照後將照片上傳到網上。使用服務確保了操作會持續“服務進程”那麼長的時間，不管活動發生了什麼。就像上邊Broadcast receiver lifecycle章節提到的那樣，這也是廣播服務器應該借助一個服務進行耗時的操作，而不是將其簡單地放到新的線程中。

                                                 

                                                From:

                                                developer.android.com/guide/components/fundamentals.html

                                                www.cnitblog.com/seedshopezhong/archive/2010/03/29/64914.html

                            The alwaysRetainTaskState attribute——alwaysRetainTaskState屬性

                            If this attribute is set to "true" in the root activity of a task, the default behavior just described does not happen. The task retains all activities in its stack even after a long period.

                            如果任務的根活動的此項屬性設置成了"true"，上面描述的默認的流程就不會發生。任務會保持其棧中所有的活動，無論用戶有多長時間沒有使用。

                            The clearTaskOnLaunch attribute——clearTaskOnLaunch屬性

                            If this attribute is set to "true" in the root activity of a task, the stack is cleared down to the root activity whenever the user leaves the task and returns to it. In other words, it's the polar opposite of alwaysRetainTaskState. The user always returns to the task in its initial state, even after a momentary absence.

                            如果任務的根活動的此項屬性設置成了"true"，用戶離開任務後一回來，系統就清除棧中除根活動外的所有活動。換句話說，這是alwaysRetainTaskState的極端反面情況。即使用戶只是離開一會，任務也會變回初始的狀態。

                            The finishOnTaskLaunch attribute——finishOnTaskLaunch屬性

                            This attribute is like clearTaskOnLaunch, but it operates on a single activity, not an entire task. And it can cause any activity to go away, including the root activity. When it's set to "true", the activity remains part of the task only for the current session. If the user leaves and then returns to the task, it no longer is present.

                            這個屬性和很相像clearTaskOnLaunch，但是finishOnTaskLaunch針對對單一活動，不是整個任務。而且他能關閉棧中任何活動，包括根活動。當他被設為"true"時，這個活動只是當前屬於這個任務，用戶離開，再回到這個任務，他就被關閉了。

                          The FLAG_ACTIVITY_NEW_TASK flag——FLAG_ACTIVITY_NEW_TASK控制標

                          As described earlier, a new activity is, by default, launched into the task of the activity that called startActivity(). It's pushed onto the same stack as the caller. However, if the Intent object passed to startActivity() contains theFLAG_ACTIVITY_NEW_TASK flag, the system looks for a different task to house the new activity. Often, as the name of the flag implies, it's a new task. However, it doesn't have to be. If there's already an existing task with the same affinity as the new activity, the activity is launched into that task. If not, it begins a new task.

                          正如上邊提到的，默認情況下，調用startActivity()向任務中添加一個活動。新添加的活動會壓入添加他的活動所在棧。但是，如果傳遞給startActivity()的Intent對象中含有FLAG_ACTIVITY_NEW_TASK控制標，系統會將新活動壓入別的棧。通常，就像控制標的字面意思一樣，會是一個新的任務。但是，不是一定要壓入新的棧。如果已經有了一個親和度和新活動相同的任務，活動就被壓入那個任務的棧中。如果沒有，才會新建任務。

                          The allowTaskReparenting attribute——allowTaskReparenting屬性

                          If an activity has its allowTaskReparenting attribute set to "true", it can move from the task it starts in to the task it has an affinity for when that task comes to the fore. For example, suppose that an activity that reports weather conditions in selected cities is defined as part of a travel application. It has the same affinity as other activities in the same application (the default affinity) and it allows reparenting. One of your activities starts the weather reporter, so it initially belongs to the same task as your activity. However, when the travel application next comes forward, the weather reporter will be reassigned to and displayed with that task.

                          如果活動將allowTaskReparenting屬性設為"true"，他可以 在具有親和度的任務被送到前台時 從開啟他的任務移到親和的任務中。例如，假設有一個已經做好的旅行的應用程序，定義了一個報告選擇的城市的天氣情況的活動。這個活動和這個應用程序中其他活動有相同親和度（默認的親和度），同時允許重定父級。您自己的一個應用程序中的一個活動開啟了這個天氣報告活動，他初始情況是處於您自己的應用程序的任務中。但是當這個旅行應用程序運行並被切換到前台後，天氣報告活動就會被重新連接 到旅行應用程序中，並在那個任務中顯示。

                    活動為需要用戶關注和確認的部分顯示一個可見的用戶界面。例如，活動會顯示一個用戶可選的菜單項的列表，或是顯示帶有標簽的照片。一個文本信息應用程序可能有一個顯示聯系人列表來發送信息，又有一個為選定的聯系人撰寫信息的活動，還有其他回顧舊信息或改變設定的活動。雖然他們整體組成一個相互關聯的用戶界面，但是每一個活動都是相對獨立的。每一個都作為Activity基類的一個子類來實現。

                    An application might consist of just one activity or, like the text messaging application just mentioned, it may contain several. What the activities are, and how many there are depends, of course, on the application and its design. Typically, one of the activities is marked as the first one that should be presented to the user when the application is launched. Moving from one activity to another is accomplished by having the current activity start the next one.

                    一個應用程序可能只含有一個活動，或者像上邊提到的文本信息程序一樣含有幾個。有幾個活動，這些活動是什麼樣的取決於您的應用程序是如何設計的。最典型的是將一個活動設計為第一個活動，應用程序被加載時呈現給用戶。從一個活動轉到另一個是通過在當前活動開始另一個來實現的。

                    Each activity is given a default window to draw in. Typically, the window fills the screen, but it might be smaller than the screen and float on top of other windows. An activity can also make use of additional windows — for example, a pop-up dialog that calls for a user response in the midst of the activity, or a window that presents users with vital information when they select a particular item on-screen.

                    每一個活動提供了一個用以繪制的默認窗口。典型的，窗口填滿整個屏幕，但是它覆蓋在其他窗口上時，會變得略小一點。一個活動可以使用多個窗口——例如，在窗口中央顯示一個需要用戶回應的彈出窗口，或者在用戶選擇屏幕上一個特定項目是時為他顯示重要信息的窗口。

                    The visual content of the window is provided by a hierarchy of views — objects derived from the base View class. Each view controls a particular rectangular space within the window. Parent views contain and organize the layout of their children. Leaf views (those at the bottom of the hierarchy) draw in the rectangles they control and respond to user actions directed at that space. Thus, views are where the activity's interaction with the user takes place. For example, a view might display a small image and initiate an action when the user taps that image. Android has a number of ready-made views that you can use — including buttons, text fields, scroll bars, menu items, check boxes, and more.

                    窗口的可見內容由一組view層提供——從View基類衍生出來的對象。每一個view控制窗口中的一塊矩形區域。父view包含並組織子view的布局。頁view（底層的view）繪制它們管理的矩形，並響應在“空白”的地方的動作。就是說，view就是活動和用戶互動的地方。例如，一個view顯示一個小圖片，然後初始化用戶點擊這個小圖片後的動作。 Android有很多已做好的view供您選擇——包括按鈕，文本輸入框，滾動條，菜單項，多選列表等。

                    A view hierarchy is placed within an activity's window by the Activity.setContentView() method. The content view is the View object at the root of the hierarchy. (See the separate User Interface document for more information on views and the hierarchy.)

                    通過使用Activity.setContentView()方法將一組view層放置在一個活動的窗口中。content view是在層的最底部的View對象。（參見獨立User Interface的文檔獲取更多有關view和層的信息。）

                     

                    Services——服務

                    A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it. Each service extends the Service base class.

                    服務沒有可見的用戶界面，但是可以在後台運行任意長的時間。例如，一個服務可以在用戶轉向其他工作後仍在後台播放音樂，或從網上下載數據，或計算什麼然後在活動需要的時候提供給活動。服務是從Service基類繼承來的。

                    A prime example is a media player playing songs from a play list. The player application would probably have one or more activities that allow the user to choose songs and start playing them. However, the music playback itself would not be handled by an activity because users will expect the music to keep playing even after they leave the player and begin something different. To keep the music going, the media player activity could start a service to run in the background. The system would then keep the music playback service running even after the activity that started it leaves the screen.

                    一個主要的例子就是一個從列表中播放音樂的媒體播放器。播放器程序可能會有一個或幾個允許用戶選擇希望播放的音樂然後顯示播放的活動。但是音樂的回放過程本身不會使用一個活動因為用戶希望在切出播放器界面做別的事時音樂也能一直放下去。為了保持播放繼續，活動可以啟動一個服務在後台運行。然後即使啟動這個服務的活動退出，音樂播放服務也能繼續運行。

                    It's possible to connect to (bind to) an ongoing service (and start the service if it's not already running). While connected, you can communicate with the service through an interface that the service exposes. For the music service, this interface might allow users to pause, rewind, stop, and restart the playback.

                    您可以連接到（綁定到）一個正在運行的服務（若果服務沒在運行，就會啟動這個服務）。連接後，您就可以通過服務暴露出來的接口與其進行通信。對音樂播放服務，這個接口可能允許用戶對播放進行暫停、回退、停止、重播等操作。

                    Like activities and the other components, services run in the main thread of the application process. So that they won't block other components or the user interface, they often spawn another thread for time-consuming tasks (like music playback). See Processes and Threads, later.

                    像活動和其他組件一樣，服務運行在程序進程的主線程中。這樣它們就不會阻礙其他組件或是用戶界面，它們通常是運行一個子線程來進行實時的任務（例如音樂回放）。過後請參見Processes and Threads。

                     

                    Broadcast receivers——廣播接受器

                    A broadcast receiver is a component that does nothing but receive and react to broadcast announcements. Many broadcasts originate in system code — for example, announcements that the timezone has changed, that the battery is low, that a picture has been taken, or that the user changed a language preference. Applications can also initiate broadcasts — for example, to let other applications know that some data has been downloaded to the device and is available for them to use.

                    broadcast receiver只是接受並對廣播信息做出反應。多數的廣播是由系統代碼發出的——例如，時區變化的通知、電量低的通知、照了一張照了一張照片 或者用戶改變了語言設定。應用程序也可以初始化一條廣播——例如讓其他應用程序知道有些數據下載完成可以使用難過了。

                    An application can have any number of broadcast receivers to respond to any announcements it considers important. All receivers extend the BroadcastReceiver base class.

                    應用程序可以含有任意數量的廣播接收器對任意其認為重要的的廣播進行響應。所有的廣播接收器均由BroadcastReceiver基類衍生

                    Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or they may use the BroadcastReceiver to alert the user. Notifications can get the user's attention in various ways — flashing the backlight, vibrating the device, playing a sound, and so on. They typically place a persistent icon in the status bar, which users can open to get the message.

                    廣播接收器不顯示用戶界面。但是它可以啟動一個活動來對接收到的信息進行響應或者是使用一個BroadcastReceiver來通知警告用戶。Notification（通知）可以一各種方式引起用戶注意——使背景燈閃爍，使設備振動，播放聲音等等。通常是在狀態條上顯示一個不會消失圖標，用戶可以拉下狀態條獲得通知。

                     

                    Content providers——內容提供者

                    A content provider makes a specific set of the application's data available to other applications. The data can be stored in the file system, in an SQLite database, or in any other manner that makes sense. The content provider extends the ContentProvider base class to implement a standard set of methods that enable other applications to retrieve and store data of the type it controls. However, applications do not call these methods directly. Rather they use aContentResolver object and call its methods instead. A ContentResolver can talk to any content provider; it cooperates with the provider to manage any interprocess communication that's involved.

                    content provider 使程序中特定的數據可被其他程序使用。共享的數據可以存儲在文件系統中、SQLite數據庫中或其他任何可用的介質。內容提供者由ContentProvider基類派生，實現了一系列的 使其他程序獲取和存儲其支持的數據格式的 方法。但是應用程序不會直接調用這些方法。而是使用ContentResolver對象，然後調用這個對象的方法。ContentResolver能與任何內容提供者對話，它與提供者合作來管理所有涉及到的進程間通信。

                    See the separate Content Providers document for more information on using content providers.

                    獲取更多使用內容提供者的詳細信息請參見單獨的文檔——Content Providers。