Android Application Fundamentals——Android应用程序基础知识

活动为须要用户关注和确认的部分显示一个可见的用户界面。

比如。活动会显示一个用户可选的菜单项的列表。或是显示带有标签的照片。一个文本信息应用程序可能有一个显示联系人列表来发送信息。又有一个为选定的联系人撰写信息的活动，还有其它回想旧信息或改变设定的活动。

尽管他们总体组成一个相互关联的用户界面，可是每个活动都是相对独立的。每个都作为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。

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提供应用程序的组件信息。比如，一个活动可能会像以下这样定义：

<?xml version="1.0" encoding="utf-8"?

>
<manifest . . . >
    <application . . . >
        <activity android:name="com.example.project.FreneticActivity"
                  android:icon="@drawable/small_pic.png"
                  android:label="@string/freneticLabel"
                  . . .  >
        </activity>
        . . .
    </application>
</manifest>

The name attribute of the <activity> 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.

<activity>元素的name属性命名了实现了activity的Activity子类。icon和label属性指向了   包括被显示给用户来代表这个活动的图标和标题   的文件。

The other components are declared in a similar way — <service> elements for services, <receiver> elements for broadcast receivers, and <provider> 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().
其它的组件的声明方式相似——声明服务用<service>元素，使用<receiver>声明广播接收器。使用<provider>声明内容提供者。

没被声明的活动，服务。内容提供者对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这个组件能操作什么样的意图。就像组件的其它重要信息一样，它们声明于清单文件里。

这里是上边那个样例的增扩版。向活动中加入了两个意图匹配器。

<?

xml version="1.0" encoding="utf-8"?

>
<manifest . . . >
    <application . . . >
        <activity android:name="com.example.project.FreneticActivity"
                  android:icon="@drawable/small_pic.png"
                  android:label="@string/freneticLabel"
                  . . .  >
            <intent-filter . . . >
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
            <intent-filter . . . >
                <action android:name="com.example.project.BOUNCE" />
                <data android:mimeType="image/jpeg" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
        . . .
    </application>
</manifest>

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 <activity> element in the manifest. Both requester and respondent have a say in what happens.

上面描写叙述的过程是活动和任务的默认动作流程。

可是那个流程非常多方面都是可改动的。活动和任务的组合还有任务中的活动是由   开启活动的Intent对象中设定的控制标 和 清单文件里活动的<activity>元素的属性   共同控制的。

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 <activity> attributes are:

重要的<activity>属性有：

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 <activity> 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".

默认的，一个应用程序中的全部活动之间都互有   亲和度——就是他们属于一个任务的优先权。

可是，您能够通过每个活动的<activity>元素的taskAffinity属相为某个活动设定单独的亲和度。不同程序中定义的活动能够共享一个亲和度，一个应用程序中的不同活动能够定义不同的亲和度。亲和度在两种情况下实用：一种情况是当激活活动的Intent对象包括了FLAG_ACTIVITY_NEW_TASK控制标，还有一种情况是活动将allowTaskReparenting属性设置为了"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"，他能够    在具有亲和度的任务被送到前台时   从开启他的任务移到亲和的任务中。比如。假设有一个已经做好的旅行的应用程序。定义了一个报告选择的城市的天气情况的活动。这个活动和这个应用程序中其它活动有同样亲和度（默认的亲和度），同一时候同意重定父级。您自己的一个应用程序中的一个活动开启了这个天气报告活动。他初始情况是处于您自己的应用程序的任务中。可是当这个旅行应用程序执行并被切换到前台后，天气报告活动就会被又一次连接    到旅行应用程序中，并在那个任务中显示。

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 <activity> element‘s launchMode attribute:

以下是能够被设为<activity>元素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 <activity> element.

启动模式的很多其它信息，參见清单文件<activity>元素的描写叙述。

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:

这是默认的情况，可是您能够更改下列的活动的属性来控制这个机制：

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"时，这个活动仅仅是当前属于这个任务，用户离开。再回到这个任务，他就被关闭了。

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 <activity> element‘s finishOnTaskLaunch to "true". See Clearing the stack, earlier.

假设您希望用户离开活动后就不能再回到这个活动，能够将<activity>元素的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 — <activity>, <service>, <receiver>, and <provider> — 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 <application> element also has a process attribute, for setting a default value that applies to all components.

组件执行在那个进程中是由清单文件进行设定的。

组件元素——<activity>， <service>。<receiver>和<provider>——都有一个process属性来指定组件应该执行在哪个进程中。您能够设定这个属性，使每个组件执行在自己的进程中。或者让某些组件共享一个进程而其它的不。您甚至能够设定不同的应用程序的组件执行在同一个进程中——这两个不同的应用程序须是由同一作者签名。且分享同一个Linux 用户ID。<application>元素也有一个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权衡对用户的重要性关系来决定结束哪个进程。

比如，一个不是正在显示的进程比正在显示的进程更easy被结束。是否要结束某个进程是由里边执行的组件的状态决定的。组建的状态是下边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方法。server的client应该仅仅有aidl工具生成的接口文件。

Here‘s how a connection between a service and its clients is set up:
这是server和其client建立连接的流程：

• 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.          server的client（即本地端）会实现onServiceConnected()和onServiceDisconnected()方法。然后client在在远程服务连接建立或丢失时得知这一信息。然后client会调用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调用client的onServiceConnected()方法并且传递给它一个IBinder对象。IBinder对象是由服务管理的Stub类的一个代理。通过这个代理，client能够调用远程端上的服务。

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:
以下的表格描写叙述了这些方法的详情，和在整个活动生命周期中的位置：

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. ——对服务能够使用他定义和导出的接口进行  编程性的操作。client建立一个到Service对象的连接，然后使用这个连接对服务进行请求。连接使用Context.bindService()建立。使用Context.unbindService()断开。多个client能够绑定到一个服务。假设服务还未被启动，可用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()返回client用以和服务交互的信道。

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.
下一节讲了很多其它有关进程被结束的easy程度。

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.——任一时刻仅仅会有非常少的前台进程存在。结束他们是没有办法的办法——仅仅有当内存不足到他们都没法执行了。通常情况下，到了这样的状况，设备就到了内存分页状态。结束一些前台进程是为了保持用户界面的响应。

2. 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.——可见进程也是极为重要的。除非结束可见进程是为了保持前台进程的执行。否则可见进程是不会被结束的。

3. 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()方法启动的并且不在前两种所述情况中的服务的   进程。

   尽管服务进程不与不论什么用户可见部分直接相连。但他们一般是在做一些用户关心的事（比如在后台播放音乐或从网上下载数据），所以除非内存不足以盛放前台和可见进程，系统是不会结束服务进程的。

4. 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（近期使用过的）列表中以保证最后含实用户最后使用的活动的进程是最后被结束的。假设活动正确地实现了其生命周期方法截获了当前状态，那么结束他所在进程不会对用户体验有坏的影响。

5. 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章节提到的那样。这也是广播server应该借助一个服务进行耗时的操作，而不是将其简单地放到新的线程中。

From:

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

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