Android应用开发基础 学习笔记（一）

Android开发基础学习笔记（一）

Android 基本架构

Android的系统架构分为5层，从高到低分别是应用程序层(Applications)、应用程序框架层(Application Framework)、系统运行库层(Libralies)、运行环境层(Android Runtime)和Linux核心层(Linux Kernel)。
下面这张图展示了Android系统的主要组成部分：

1、Linux 内核

Android的核心系统服务基于Linux 2.6内核，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。并且改过Linux内核，针对手机进行了专门的优化，主要是电源管理和进程调度方面。Linux核心层也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务，所以只开发应用程序不需要过多了解这一层。

2、运行环境

Android包含一个核心库的集合(Core Libralies)，提供大部分在Java编程语言核心类库中可用的功能。
android虚拟机Dailvk是基于寄存器的，所有的类都经由Java编译器编译成.class文件格式再由Android SDK中的dx工具进行二次编译成适合小内存使用的.dex文件格式再由虚拟机执行，提高了虚拟机的执行效率。
Dalvik虚拟机依赖于Linux 内核提供基本功能，如线程和底层内存管理。

3、系统运行库

核心类库的来源主要有两种，一种是系统类库，android为了提高框架层的执行效率，使用c/c++来实现一些关键模块，基础算法等等。一种是第三方类库，大部分是优秀开源项目的移植，如android的多媒体处理，sqlite。webkit。android会为所有移植而来的第三方类库封装一层JNI接口，以供框架层调用。

4、应用程序框架

框架层是android的核心框架层主要是系统服务组成的，框架层对于android的重要性，相当于大脑对人。这些服务包括组件管理服务，窗口管理服务，电源管理服务，通话管理服务，地理信息服务中。所有服务都寄存在系统核心进程中。在运行时，每个服务都占据一个独立的线程，彼此通过进程间的通信机制发送消息和传输数据。
应用层中的应用，时刻都在与这些服务打交道，了解设备信息等操作，都是在各个系统服务的支持下实现的。
android应用的最大特征是基于组件的设计方式。每个应用都邮若干个组件构成，组件和组件之间并不会建立通信信道，而是通过框架层的系统，集中的调度和传递消息，这样的设计方式相当于一个中间层，该层了解所有组件的状况，可以更智能的进行协调，从而提升了整个系统的灵活性。

5、应用程序

应用层主要是用于和用户进行交互的，包括系统的应用，例如电话，浏览器，联系人。也包括后续安装到设备上的第三方应用，这些统称为android应用层。

Android 组件

Android的一个主要特点是，一个应用程序可以利用其他应用程序的元素（假设这些应用程序允许的话）。例如，如果你的应用程序需要显示一个图像的滚动列表，且其他应用程序已经开发了一个合适的滚动条并可以提供给别的应用程序用，你可以调用这个滚动条来工作，而不用自己开发一个。你的应用程序不用并入其他应用程序的代码或链接到它。相反，当需求产生时它只是启动其他应用程序块。

对于这个工作，当应用程序的任何部分被请求时，系统必须能够启动一个应用程序的进程，并实例化该部分的Java对象。因此，不像其他大多数系统的应用程序，Android应用程序没有一个单一的入口点（例如，没有main()函数）。相反，系统能够实例化和运行需要几个必要的组件。有四种类型的组件：

1. 活动（Activities）
2. 服务（Services）
3. 广播接收者（Broadcast receivers）
4. 内容提供者（Content providers）

然而，并不是所有的应用程序都必须包含上面的四个部分，你的应用程序可以由上面的一个或几个来组建。当你决定使用以上哪些组件来构建Android应用程序时，你应该将它们列在AndroidManifest.xml文件中，在这个文件中你可以声明应用程序组件以及它们的特性和要求。

1、活动（Activities）

一个活动表示一个可视化的用户界面，关注一个用户从事的事件。例如，一个活动可能表示一个用户可选择的菜单项列表，或者可能显示照片连同它的标题。一个文本短信应用程序可能有一个活动，显示联系人的名单发送信息；第二个活动，写信息给选定的联系人；其他活动，重新查看旧信息或更改设置。虽然他们一起工作形成一个整体的用户界面，但是每个活动是独立于其他活动的。每一个都是作为Activity基类的一个子类的实现。

android.app.Activity类：因为几乎所有的活动（activities）都是与用户交互的，所以Activity类关注创建窗口，你可以用方法setContentView(View)将自己的UI放到里面。然而活动通常以全屏的方式展示给用户，也可以以浮动窗口或嵌入在另外一个活动中。有两个方法是几乎所有的Activity子类都实现的：

1. onCreate(Bundle)：初始化你的活动（Activity），比如完成一些图形的绘制。最重要的是，在这个方法里你通常将用布局资源（layout resource）调用``setContentView(int)方法定义你的UI，和用`findViewById(int)在你的UI中`检索你需要编程地交互的小部件（widgets）。`setContentView`指定由哪个文件指定布局（main.xml），可以将这个界面显示出来，然后我们进行相关操作，我们的操作会被包装成为一个意图（Intent），然后这个意图对应有相关的activity进行处理。``
2. onPause()：处理当离开你的活动时要做的事情。最重要的是，用户做的所有改变应该在这里提交（通常ContentProvider保存数据）。

一个应用程序可能只包含一个活动，或者像刚才提到的短信应用，它可能包含几个活动。这些活动是什么，以及有多少，当然这取决于它的应用和设计。一般来讲，当应用程序被启动时，被标记为第一个的活动应该展示给用户。从一个活动移动到另一个活动由当前的活动完成开始下一个。

每一个活动都有一个默认的窗口。一般来讲，窗口会填满整个屏幕，但是它可能比屏幕小或浮在其他窗口上。一个活动还可以使用额外的窗口——例如弹出式对话框，或当一用户选择屏幕上一个特定的项时一个窗口显示给用户重要的信息。

窗口的可视内容是由继承自View基类的一个分层的视图—对象提供。每个视图控件是窗口内的一个特定的矩形空间。父视图包含和组织子女视图的布局。叶子视图（在分层的底层）绘制的矩形直接控制和响应用户的操作。因此，一个视图是活动与用户交互发生的地方。例如，一个视图可能显示一个小的图片和当用户点击图片时发起一个行为。Android有一些现成的视图你可以使用，包括按钮（buttons）、文本域（text fields）、滚动条（scroll bars）、菜单项（menu items）、复选框（check boxes）等等。

通过Activity.setContentView() 方法放置一个视图层次在一个活动窗口中。内容视图（content view）是层次结构的根视图对象。层次结构如下图所示：

Activity.setContentView() 方法：

public void setContentView (int layoutResID)：根据布局资源设置活动的界面。 资源将被夸大，添加布局资源文件中所有的最高层的视图（ top-level views ）到活动.

2、 服务（Services）

一个服务没有一个可视化用户界面，而是在后台无期限地运行。例如一个服务可能是播放背景音乐而用户做其他一些事情，或者它可能从网络获取数据，或计算一些东西并提供结果给需要的活动（activities）。每个服务都继承自Service基类。

每个服务类在AndroidManifest.xml中有相应的<service>声明。服务可以通过Context.startService()和Context.bindService()启动。

一个典型的例子是一个媒体播放器播放一个播放列表中的歌曲。该播放器应用程序将可能有一个或多个活动（activities），允许用户选择歌曲和开始播放。然而，音乐播放本身不会被一个活动处理，因为用户希望保持音乐继续播放，当用户离开播放器去做其他事情时。为了保持音乐继续播放，媒体播放器活动可以启动一个服务运行在后台。系统将保持音乐播放服务运行，甚至媒体播放器离开屏幕时。

可以连接到（绑定到）一个持续运行的服务（并启动服务，如果它尚未运行）。连接之后，你可以通过服务暴露的接口与服务交流。对于音乐服务，这个接口可以允许用户暂停、倒带、停止和重新播放。

像活动（activities）和其他组件一样，服务（services）运行在应用程序进程中的主线程中。因此，他们将不会阻止其他组件或用户界面，他们往往产生其他一些耗时的任务（如音乐播放）。

3、广播接收者（Broadcast receivers）

一个广播接收者是这样一个组件，它不做什么事，仅是接受广播公告并作出相应的反应。许多广播源自于系统代码，例如公告时区的改变、电池电量低、已采取图片、用户改变了语言偏好。应用程序也可以发起广播，例如为了他其他程序知道某些数据已经下载到设备且他们可以使用这些数据。

一个应用程序可以有任意数量的广播接收者去反应任何它认为重要的公告。所有的接受者继承自BroadcastReceiver基类。

BroadcastReceiver类：

是接受sendBroadcast()发送的意图（intents）的基类。可以用Context.registerReceiver()动态地注册这个类的实例，或者通过AndroidManifest.xml中<receiver>标签静态发布。注意：如果你在Activity.onResume() 注册一个接受者，你应该在Activity.onPause()注销它。因为当暂停时你不会收到意图，注销它将削减不必要的系统开销。不要在Activity.onSaveInstanceState()中注销它，因为它将不会被调用，如果用户移动到先前的堆栈。

有两种主要的可接受广播类型：

1. 正常广播（由Context.sendBroadcast发送）是完全异步的。所有的广播接收者以无序方式运行，往往在同一时间接收。这样效率较高，但是意味着接受者不能使用结果或终止广播数据传播。
2. 有序广播（由Context.sendOrderedBroadcast发送）一次传递给一个接收者。由于每个接收者依次执行，因此它可以传播到下一个接收器，也可以完全终止传播以便他不会传递给其他接收者。接收者的运行顺序可由匹配的意图过滤器（intent-filter）的android:priority属性控制。

广播接收者不显示一个用户界面。然而，它们启动一个活动去响应收到的信息，或者他们可能使用NotificationManager去通知用户。通知可以使用多种方式获得用户的注意——闪烁的背光、振动设备、播放声音等等。典型的是放在一个持久的图标在状态栏，用户可以打开获取信息。

4、内容提供者（Content providers）

内容提供者（content provider）使一个应用程序的指定数据集提供给其他应用程序。这些数据可以存储在文件系统中、在一个SQLite数据库、或以任何其他合理的方式。内容提供者继承自ContentProvider 基类并实现了一个标准的方法集，使得其他应用程序可以检索和存储数据。然而，应用程序并不直接调用这些方法。相反，替代的是它们使用一个ContentResolver对象并调用它的方法。ContentResolver能与任何内容提供者通信，它与提供者合作来管理参与进来的进程间的通信。

内容提供者是Android应用程序的主要组成部分之一，提供内容给应用程序。他们封装数据且通过单个ContentResolver接口提供给应用程序。只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。如果你不需要在多个应用程序间共享数据，你可以直接使用SQLiteDataBase。

当ContentResolver发出一个请求时，系统检查给定的URI的权限并传递请求给内容提供者注册。内容提供者能理解URI想要的东西。UriMatcher 类用于帮组解析URIs。

需要实现的方法主要如下：

• query(Uri, String[], String, String[], String) 返回数据给调用者
• insert(Uri, ContentValues) 插入数据到内容提供者
• update(Uri, ContentValues, String, String[]) 更新内容提供者已存在的数据
• delete(Uri, String, String[]) 从内容提供者中删除数据
• getType(Uri) 返回内容提供者中的MIME 类型数据

组件的激活和关闭

1、激活组件：意图（Intents）

当接收到ContentResolver发出的请求后，内容提供者被激活。而其它三种组件——活动、服务和广播接收者，被一种叫做意图（intent）的异步消息激活。意图是一个保存着消息内容的Intent对象。对于活动和服务来说，Intent对象指明了请求的操作名称以及作为操作对象的数据的URI和其它一些信息。例如，它可以传递对活动的一个请求，让它为用户显示一张图片，或者让用户编辑一些文本。而对于广播接收者而言，Intent对象指明了广播的行为。例如当照相按钮被按下，它可以对所有感兴趣的对象广播。

对于每种组件来说，激活的方法是不同的。下面将分别介绍活动、服务、广播接收者组件的激活方法。

1.1、活动（Activity）组件的激活

通过传递一个Intent对象至Context.startActivity()或Activity.startActivityForResult()以载入（或指定新工作给）一个活动。相应的活动可以看到初始的意图，这个意图通过getIntent() 方法来查看激活活动。Android调用活动的onNewIntent()方法传递任何后续的意图。

一个活动经常启动了下一个。如果它期望它所启动的那个活动返回一个结果，它会调用startActivityForResult()而不是startActivity()。例如，如果它启动了一个活动让用户挑选一张照片，它可能会返回被选中的照片。结果以一个Intent对象传递调用活动的onActivityResult() 方法。

1.2、服务（Service）组件的激活

通过传递一个Intent对象至Context.startService()以启动一个服务（或给予正在运行的服务以一个新的指令）。Android调用服务的onStart()方法并将Intent对象传递给它。

与此类似，一个Intent可以传递给Context.bindService()以在调用的组件和目标服务之间建立持续的连接。这个服务会在调用onBind() 方法中接受这个Intent对象（如果服务尚未启动，bindService()会先启动它）。例如，一个活动可以连接至前面讲到的音乐播放服务，并提供给用户一个可操作的（用户界面）以对播放进行控制。这个活动可以调用bindService()来建立连接，然后调用服务中定义的对象来控制播放。

1.3、广播接收者（Broadcast receiver）组件的激活

应用程序可以通过将Intent对象传递给

• Context.sendBroadcast()
• Context.sendOrderedBroadcast()
• Context.sendStickyBroadcast()

及其它类似方法来产生一个广播。Android会通过onReceive()方法将intent传递给所有对此广播有兴趣的广播接收者。

2、关闭组件

内容提供者仅在响应ContentResolver提出请求的时候激活。而一个广播接收者仅在响应广播信息的时候激活。所以，没有必要去显式的关闭这些组件。

而活动则不同，它提供了用户界面。与用户进行会话，所以只要会话依然持续，哪怕对话进程空闲，它都会一直保持激活状态。与此相似，服务也会在很长一段时间内保持运行。所以Android提供方法有序地关闭活动和服务。

• 可以通过调用它的finish()方法来关闭一个活动。一个活动也可以通过调用finishActivity()方法来关闭另外一个活动（它用startActivityForResult() 启动的）。
• 服务可以通过调用它的stopSelf()方法来停止，或者调用 Context.stopService()。

当组件不再被使用的时候或者Android必须要为更多活跃的组件回收内存时，组件也可能会被系统关闭。

3、清单（manifest）文件

当Android启动一个应用程序组件之前，它必须知道那个组件是存在的。所以，应用程序会在一个清单（manifest）文件中声明它的组件，这个文件会被打包到Android包中。这个.apk文件还将包括应用程序的代码、文件以及其它资源。

这个清单文件是XML结构的文件，且所有的Android应用程序都把它叫做AndroidManifest.xml。为声明一个应用程序组件，它还会做很多额外工作，比如指明应用程序所需链接到的库的名称（除了默认的Android库之外）以及声明应用程序期望获得的各种权限。

但清单文件的主要功能仍然是向Android声明应用程序的组件。举例说明，一个活动可以如下声明：

AndroidManifest.xml

<activity>元素的name属性指定了实现了这个活动的Activity类的子类，icon和label属性指向了包含展示给用户的此活动的图标和标签的资源文件。

其它组件也以类似的方法声明——<service> 元素用于声明服务，<receiver> 元素用于声明广播接收者，而<provider>元素用于声明内容提供者。清单文件中未进行声明的活动、服务以及内容提供者将不为系统所见，从而也就不会被运行。然而，广播接收者既可以在清单文件中声明，也可以在代码中动态的创建（作为BroadcastReceiver对象）且调用Context.registerReceiver()方式注册到系统。

4、Intent过滤器

Intent对象可以显式地指定目标组件。如果进行了这种指定，Android会找到这个组件（依据清单文件中的声明）并激活它。但如果Intent没有进行显式的指定，Android就必须为它找到对于intent来说最合适的组件。这个过程是通过比较Intent对象和所有可能对象的intent过滤器完成的。组件的intent过滤器会告知Android它所能处理的intent类型。如同其它关于组件的必要信息一样，它们在清单文件中进行声明的。这里是上面示例的一个扩展，其中加入了针对活动的两个intent过滤器声明：

AndroidManifest.xml

示例中的第一个过滤器——action：“android.intent.action.MAIN”和category：“android.intent.category.LAUNCHER”的组合，是常见的。它标记这个活动显示在应用程序启动器中，用户在设备上看到的可启动的应用程序列表。换句话说，这个活动是应用程序的入口，是用户选择运行这个应用程序后所见到的第一个活动。第二个过滤器声明了这个活动针对特定类型的数据。

一个组件可以拥有任意数量的intent过滤器，每个声明一系列不同的能力。如果它没有包含任何过滤器，它将只能被显式声明了目标组件名称的意图激活。

对于广播接收者，它在代码中创建并注册intent过滤器，直接作为IntentFilter的对象实例化。其它过滤器则在清单文件中设置。

活动与任务

1、活动与任务概述

如前所述，一个活动（activity）能启动另一个活动，包括定义在别的应用程序中的活动。再次举例说明，假设你想让用户显示某地的街道地图。而且已经有了一个活动能做这个事情（假设这个活动叫做地图查看器），因此你的活动要做的就是将请求信息放进一个Intent对象，然后将它传给startActivity()。地图查看器就启动并显示出地图。当用户点击返回按钮之后，你的活动就会重新出现在屏幕上。

对用户来说，这个地图查看器就好像是你的应用程序的活动一样，虽然它定义在其他的应用程序中且运行在那个应用程序的进程中。Android将这些活动保持在同一个任务（task）中以维持用户的体验。简单地讲，任务是用户体验上的一个“应用程序”，是排成堆栈的一组相关活动。栈底的活动（根活动）是起始活动——一般来讲，它是用户在应用程序启动器（也称应用程序列表，下同）中选择的一个活动。栈顶的活动是正在运行的活动——它关注用户的行为（操作）。当一个活动启动另一个，新的活动被压入栈顶，变为正在运行的活动。前面那个活动保存在栈中。当用户点击返回按钮时，当前活动从栈顶中弹出，且前面那个活动恢复成为正在运行的活动。

栈中包含对象，因此如果一个活动启动了多个实例——例如多个地图查看器，则栈对每个实例有一个独立的入口。（可以这样理解：假设有四个活动以这样的顺序排在栈中——A-B-C-D，现在又有一个C的实例，则栈变成A-B-C-D-C，这两个C的实例是独立的。）栈中的活动从不会被重新排列，只会被压入、弹出。这点很好理解，因为活动的调用顺序是固定的。

任务是一栈的活动，而不是清单文件中声明的某个类或元素，因此无法独立于它的活动为任务赋值。整个任务的值是在栈底活动（根活动）设置的。例如，下节将讨论的“任务亲和度”，亲和度信息就是从任务的根活动中获取的。

一个任务的所有活动作为一个整体运行。整个任务（整个活动栈）可置于前台或发送到后台。例如，假设当前任务有四个活动在栈中——三个活动在当前活动下面。用户按下HOME键，切换到程序启动器，并选择一个新的应用程序（实际上是一个新的任务）。当前任务进入后台，新任务的根活动将显示。接着，过了一会，用户回到主屏幕并再次选择之前的应用程序（之前的任务）。那个任务栈中的所有四个活动都变为前台运行。当用户按下返回键时，不是离开当前任务回到之前任务的根活动。相反，栈顶的活动被移除且栈中的下一个活动将显示。

上面所描述的是活动和任务的默认行为，但是有方法来改变所有这些行为。活动与任务之间的联系及任务中活动的行为，是由启动活动的Intent对象的标志（flags）和清单文件中活动<activity>元素的属性共同决定的。

在这方面，主要的Intent标志有：

• FLAG_ACTIVITY_NEW_TASK
• FLAG_ACTIVITY_CLEAR_TOP
• FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
• FLAG_ACTIVITY_SINGLE_TOP

主要的<activity>属性有：

• taskAffinity
• launchMode
• allowTaskReparenting
• clearTaskOnLaunch
• alwaysRetainTaskState
• finishOnTaskLaunch

接下来的小节将讨论这些标志和属性的作用，他们怎么交互，及使用的注意事项。

2、亲和度和新任务（Affinities and new tasks）

默认情况下，一个应用程序的所有活动互相之间都有一个亲和度（affinity）——也就是说，他们属于同一个任务的偏好（preference）。然而，也可以通过<activity>元素的taskAffinity属性为每个活动设置个体亲和度。定义在不同应用程序中的活动能够共享亲和度，同一个应用程序中的活动可以分配不一样的亲和度。亲和度发挥作用的两种情况：1）启动活动的Intent对象包含FLAG_ACTIVITY_NEW_TASK标志时；2）一个活动的allowTaskReparenting属性为"true"时。

• FLAG_ACTIVITY_NEW_TASK标志

如前所述，默认情况下，一个新的活动被启动到调用startActivity()方法的活动所在的任务。它被压入调用它的活动的栈中。但是，如果传递给方法的Intent对象包含FLAG_ACTIVITY_NEW_TASK标志，系统找一个不同的任务容纳活动。通常，顾名思义它表示一个新任务。但是，他并非一定如此。如果已经存在一个任务与新活动亲和度一样，该活动将启动到该任务。如果不是，则启动一个新任务。

• allowTaskReparenting属性

如果一个活动的allowTaskReparenting属性为"true"，它可以从启动它的任务转移到与它有亲和度并转到前台运行的任务中。例如，假设一个天气预报的活动，但选择城市是一个旅游应用程序的一部分。它与同一个应用程序中的其他活动具有相同的亲和度，且允许重新选择父活动（reparenting）。你的一个活动启动天气预报活动，因此他初始是跟你的活动属于同一个任务。但是，当旅游应用程序切换到前台运行时，天气预报活动将被重新分配和显示到该任务。

如果一个.apk文件，从用户的角度看包含不止一个“应用程序”，你可能要为与他们有关的些活动指定不一样的亲和度。

3、启动模式（Launch modes）

有四种不同的启动模式可以分配到<activity>元素的launchMody属性：

• "standard"(默认模式)
• "singleTop "
• "singleTask"
• "singleInstance"

这些模式的在以下四方面不同：

• 哪个任务将持有响应意图（intent）的活动。对"standard"和"singleTop "模式，是产生意图的任务（调用startActivity()方法）——除非Intent对象包含FLAG_ACTIVITY_NEW_TASK标志。在那种情况下，像上一节亲和度和新任务（Affinities and new tasks）所描述的那样选择一个不同的任务。
  相反，"singleTask"和"singleInstance"模式，总是将活动标记为一个任务的根活动。他们定义一个任务，而从不启动到其他任务。
• 活动是否可以实例化多次。"standard"或"singleTop "活动可以实例化多次。这些实例可以属于多个任务，且一个给定任务可以包含同一个活动的多个实例。
  相反，"singleTask"和"singleInstance"活动仅可以被实例化一次。因为这些活动是一个任务的根，这个限制意味着设备上一个时间只有不多于一个任务的实例。
• 是否允许实例所在任务有其他活动。"singleInstance"活动所在任务只有它一个活动。如果他启动别的活动，那些活动将启动到不同的任务中，无论它的模式如何——就好像Intent对象包含FLAG_ACTIVITY_NEW_TASK标志。在所有其他方面，"singleInstance"模式等同于"singleTask"模式。
  其它三种模式允许多个活动属于一个任务。"singleTask"活动总是任务的根活动，但是它能启动其他活动到它的任务。"standard"或"singleTop "活动的实例可以出现的栈中的任何位置。
• 响应一个意图时是否需要生成类的新实例。对于默认的"standard"模式，创建新的实例去响应每一个新的意图。每个实例仅处理一个意图。对于"singleTop "模式，一个类已存在的实例可以重新用了处理新的意图，如果它位于目标任务的活动栈的栈顶。如果不是在栈顶，就不可以重用。相反，将创建一个新的实例并压入栈顶。
  例如，一个任务的活动栈由根活动A、B、C和D组成，顺序为A-B-C-D。当一个意图到达请求类型D时，如果D是默认的"standard"模式，将产生D类的新实例且栈变为A-B-C-D-D。然而，如果D的启动模式是"singleTop "，已存在的D实例将去处理新的意图（因为它在栈顶）且栈仍然是A-B-C-D。
  如果，另一方面，到达的意图是请求类型B时，一个B的新实例将启动而不管B的模式是"standard"还是"singleTop "（因为B不是在栈顶），因此栈的结构为A-B-C-D-B。
  如前所述，"singleTask"和"singleInstance"活动仅可以被实例化一次，因此他们的实例将处理所有的新意图。一个"singleInstance"活动总是在栈顶（因为仅有一个活动在任务中），因此它总是在可以处理意图的位置。然而，一个"singleTask"活动在栈中可能有或可能没有其他活动在它上面。如果有，即它不在处理意图的位置，意图会被丢弃（即使意图被丢弃了，它的到来使任务转到并保持在前台运行）

当一个已存在的活动被请求处理一个新的意图，Intent对象将通过onNewIntent()调用传到活动。（产生启动活动的意图对象可以由getIntent()获取。）

注意到当一个活动的新实例被创建去处理新意图时，用户总是可以按返回键返回到之前的状态（之前的活动）。但是当一个已存在的活动实例去处理新意图是，用户不可以按返回键返回到意图到达之前的状态。

4、清除栈（Clearing the stack）

如果用户离开一个任务很长时间，系统将会清除根活动之外的活动。当用户再次返回到这个任务时，像用户离开时一样，仅显示初始的活动。这个想法是，一段时间后，用户可能已经放弃之前做的东西，及返回任务做新的事情。这是默认情况，有些活动属性可以用来控制和改变这个行为。

• alwaysRetainTaskState属性
  如果在任务的根活动中这个属性被设置为"true"，刚才描述的默认行为将不会发生。任务将保留所有的活动在它的栈中，甚至是离开很长一段时间。
• clearTaskOnLaunch属性
  如果在任务的根活动中这个属性被设置为"true"，只有用户离开就清除根活动之外的活动。换句话说，它与alwaysRetainTaskState截然相反。用户总是返回到任务的初始状态，甚至是只离开一会。
• finishOnTaskLaunch属性
  这个属性类似于clearTaskOnLaunch，但是它作用于单个活动，而不是整个任务。而且它能移除任何活动，包括根活动。当它被设置为"true"，任务本次会话的活动的部分还存在，如果用户离开并返回到任务时，它将不再存在。

有其他的方法强制从栈中移除活动。如果Intent对象包含FLAG_ACTIVITY_CLEAR_TOP标志，目标任务已经有一个指定类型的活动实例，栈中该实例上面的其它活动将被移除而使它置于栈顶响应意图。如果指定的活动的启动类型是"standard"，它自己也将被移除出栈，且一个新的实例将被启动去处理到来的意图。这是因为当模式是"standard"时，总是创建一个新的实例去处理新的意图。

FLAG_ACTIVITY_CLEAR_TOP标志经常与FLAG_ACTIVITY_NEW_TASK一起使用。当一起使用时，这些标志的方式是定位到另一个任务中的已存在的活动并把它放到可以处理意图的位置。

5、启动任务（Starting tasks）

通过给定活动一个意图过滤器"android.intent.action.MAIN"作为指定行为（action）和"android.intent.category.LAUNCHER"指定种类（category），活动就被设置为任务的入口点了。

它的第二个功能非常重要：用户可以离开任务且之后可以返回到它。基于这个原因，两个启动模式"singleTask"和"singleInstance"标记活动总是初始化一个任务来响应意图，仅可以使用在有MAIN和LAUNCHER过滤器的活动中。想象一下，如果没有这个过滤器将会发生什么：一个意图启动一个"singleTask"活动，开始一个新任务，用户在任务中做一些操作。然后用户按下HOME键，任务现在退到后台运行且被主屏幕遮蔽住。而且，由于活动不在应用程序启动器中显示，用户无法再返回。

类似的困难也出现在FLAG_ACTIVITY_NEW_TASK标志。如果这个标志导致一个活动开始一个新的任务且用户按HOME键离开它，就必须要有某种方法是用户能够导航回来。一些实体（如通知管理器）总是在外部任务启动活动，从不作为他们自己的一部分，因此他们总是将带FLAG_ACTIVITY_NEW_TASK标志的意图传到startActivity()方法启动活动。如果你有活动能调用外部实体，可以使用此标志，注意用户有一个独立的方式返回到开始的任务。

如果你希望用户离开活动后就不能再回到这个活动，可以将<activity>元素的finishOnTaskLaunch属性设置为"true"。可以参见清除栈那节。

进程与线程

1、进程

组件运行于哪个进程中由清单文件控制。组件元素——<activity>、<service>、<receiver>、<provider>，都有一个process属性可以指定组件运行在哪个进程中。这个属性可以设置为每个组件运行在自己的进程中，或者某些组件共享一个进程而其他的不共享。他们还可以设置为不同应用程序的组件运行在同一个进程中——假设这些应用程序共享同一个Linux用户ID且被分配了同样的权限。<application>元素也有process属性，为所有的组件设置一个默认值。

所有的组件都在特定进程的主线程中实例化，且系统调用组件是由主线程派遣。不会为每个实例创建单独的线程，因此，对应这些调用的方法——诸如View.onKeyDown()报告用用户的行为和生命周期通知，总是运行在进程的主线程中。这意味着，没有组件当被系统调用时应该执行很长时间或阻塞操作（如网络操作或循环计算），因为这将阻塞进程中的其它组件。你可以为长操作衍生独立的线程。

public boolean onKeyDown(int keyCode,KeyEvent event)：默认实现KeyEvent.Callback.onKeyMultiple()，当按下视图的KEYCODE_DPAD_CENTER或KEYCODE_ENTER然后释放时执行，如果视图可用且可点击。

参数

keyCode-表示按钮被按下的键码，来自KeyEvent
event-定义了按钮动作的KeyEvent对象

返回值

如果你处理事件，返回true；如果你想下一个接收者处理事件，返回false。

当内存剩余较小且其它进程请求较大内存并需要立即分配，Android要回收某些进程，进程中的应用程序组件会被销毁。当他们再次运行时，会重新开始一个进程。

当决定终结哪个进程时，Android会权衡他们对用户重要性的相对权值。例如，与运行在屏幕可见的活动进程相比（前台进程），它更容易关闭一个进程，它的活动在屏幕是不可见（后台进程）。决定是否终结进程，取决于运行在进程中的组件状态。

2、线程

虽然你可能会将你的应用程序限制在一个进程中，但有时候你会需要衍生一个线程做一些后台工作。因为用户界面必须很快地响应用户的操作，所以活动寄宿的线程不应该做一些耗时的操作如网络下载。任何不可能在短时间完成的操作应该分配到别的线程。

线程在代码中是用标准的Java线程对象创建的，Android提供了一些方便的类来管理线程——Looper用于在线程中运行消息循环、Handler用户处理消息、HandlerThread用户设置一个消息循环的线程。

Looper类

该类用户在线程中运行消息循环。线程默认没有消息循环，可以在线程中调用prepare()创建一个运行循环；然后调用loop()处理消息直到循环结束。大部分消息循环交互是通过Handler类。下面是一个典型的执行一个Looper线程的例子，分别使用prepare()和loop()创建一个初始的Handler与Looper交互：

class LooperThread extends Thread {
public Handler mHandler;

  public void run() {  
      Looper.prepare();  
       
      mHandler = new Handler() {  
          public void handleMessage(Message msg) {  
              // process incoming messages here  
          }  
      };  
       
      Looper.loop();  
  }  

}

2.1、远程过程调用（Remote procedure calls，RPCs）

Android有一个轻量级的远程过程调用机制——方法在本地调用却在远程（另外一个进程中）执行，结果返回给调用者。这需要将方法调用和它伴随的数据分解为操作系统能够理解的层次，从本地进程和地址空间传输到远程进程和地址空间，并重新组装调用。返回值以相反方向传输。Android提供了做这些工作的所有代码，这样我们可以专注于定义和执行RPC接口本身。

一个RPC接口仅包含方法。所有的方法同步地执行（本地方法阻塞直到远程方法执行完成），即使是没有返回值。简言之，该机制工作原理如下：首先，你用简单的IDL（interface definition language，接口定义语言）声明一个你想实现的RPC接口。从这个声明中，aidl工具生成一个Java接口定义，提供给本地和远程进程。它包含两个内部类，如下图所示：

内部类有管理你用IDL定义的接口的远程过程调用所需要的所有代码。这两个内部类都实现了IBinder接口。其中之一就是在本地由系统内部使用，你写代码可以忽略它。另外一个是Stub，扩展自Binder类。除了用于有效地IPC（interprocess communication）调用的内部代码，内部类在RPC接口声明中还包含方法声明。你可以定义Stub的子类实现这些方法，如图中所示。

通常情况下，远程过程有一个服务管理（因为服务能通知系统关于进程和它连接的其它进程的信息）。它有由aidl工具生成的接口文件和Stub子类实现的RPC方法。服务的客户端仅有由aidl工具生成的接口文件。

下面介绍服务如何与它的客户端建立连接：

• 服务的客户端（在本地端的）应该实现onServiceConnected() 和onServiceDisconnected() 方法，因此当与远程服务建立连接成功和断开连接是会通知它。然后调用bindService() 建立连接。
• 服务的onBind()方法将实现为接受或拒绝连接，者取决于它接受到的意图（该意图传送到binServive()）。如果连接被接受，它返回一个Stub子类的实例。
• 如果服务接受连接，Android调用客户端的onServiceConnected()方法且传递给它一个IBinder对象，返回由服务管理的Stub子类的一个代理。通过代理，客户端可以调用远程服务。

这里只是简单地描述，省略了一些RPC机制的细节。你可以查阅相关资料或继续关注Android开发之旅，后面将为你奉上。

2.2、线程安全方法

在一些情况下，你实现的方法可能会被不止一个线程调用，因此必须写成线程安全的。这对远程调用方法是正确的——如上一节讨论的RPC机制。当从IBinder进程中调用一个IBinder对象中实现的一个方法，这个方法在调用者的线程中执行。然而，当从别的进程中调用，方法将在Android维护的IBinder进程中的线程池中选择一个执行，它不在进程的主线程中执行。例如，一个服务的onBind()方法在服务进程的主线程中被调用，在onBind()返回的对象中执行的方法（例如，实现RPC方法的Stub子类）将在线程池中被调用。由于服务可以有一个以上的客户端，所以同时可以有一个以上的线程在执行同一个IBinder方法。因此，IBinder的方法必须是线程安全的。

同样，一个内容提供者可以接受其它进程产生的数据请求。虽然ContentResolver 和 ContentProvider 类隐藏进程通信如何管理的，对应哪些请求的ContentResolver 方法——query()、insert()、delete()、update()、getType()，在内容提供者的进程的线程池中被调用，而不是在这一进程的主线程中。因为这些方法可以同时从任意数量的线程中调用，他们也必须实现为线程安全的。

组件的生命周期

1、活动生命周期

一个活动有三个基本状态：

激活状态或运行状态，这时它运行在屏幕的前台（处于当前任务活动栈的最上面）。这个活动有用户的操作的焦点。
暂停状态，这时活动失去焦点但是它对用户仍可见。也就是说，另一个活动在它的上面且那个活动是透明的或者没有覆盖整个屏幕，因此通过它可以看见暂停状态的活动。一个暂停的活动完全是活着的（它维护着所有的状态和成员信息，且仍然依附在窗口管理器），但是当内存极小时可以被系统杀掉。
停止状态，这时活动完全被其他活动掩盖。它仍然保留所有状态和成员信息，但是对用户它不可见，因此它的窗口时隐藏的且当其他地方需要内存时它往往被系统杀掉。

如果一个活动被暂停或停止，系统可以将它从内存移除，通过要求它结束（通过调用它的finish()方法），或简单地杀掉它的进程。当它再次显示给用户时，必须要完全重新启动和恢复到之前的状态。随着活动从一个状态转为另一个状态，通过调用下面的受保护的方法通知该改变：

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

所有这些方法都是钩子，你可以重写当状态改变时做适当的工作。所有的活动必须要实现onCreate()去做一些初始化的设置，当对象第一次实例化的时候。很多活动也会实现onPause()去提交数据修改或准备停止与用户交互。

将他们合并在一起，这七个方法定义了活动的整个生命周期。有三个嵌套的循环，你可以通过这七个方法监视：

活动的整个生命时间，从第一次调用onCreate()开始直到调用onDestroy()结束。一个活动在onCreate()中做所有的“全局”状态的初始设置，在onDestroy()中释放所有保留的资源。举例来说，有一个线程运行在后台从网络上下载数据，它可能会在onCreate()中创建线程，在onDestroy()中结束线程。
活动的可视生命时间，从调用onStart()到相应的调用onStop() 。在这期间，用户可以在屏幕上看见活动，虽然它可能不是运行在前台且与用户交互。在这两个方法之间，你可以保持显示活动所需要的资源。举例来说，你可以在onStart()中注册一个广播接收者监视影响你的UI的改变，在onStop() 中注销。因为活动在可视和隐藏之间来回切换，onStart()和onStop()  可以调用多次。
活动的前台生命时间，从调用onResume()到相应的调用onPause()。在这期间，频繁地在重用和暂停状态转换——例如，当设备进入睡眠状态或一个新的活动启动时调用onPause()，当一个活动返回或一个新的意图被传输时调用onResume()。因此，这两个方法的代码应当是相当轻量级的。

下面这个图解释了这三个循环和状态之间状态的可能路径。着色的椭圆表示活动的主要状态，矩形表示当活动在状态之间转换时你可以执行的回调方法。

下面的表格对每个方法更详细的描述和在活动的整个生命周期中的定位。

注意上面表格的Killable列，它表示当方法返回时没有执行活动的其它代码，系统是否能杀死活动寄宿的进程。三个方法（onPause()、onStop()、onDestroy()）标记为Yes。因为onPause()是唯一一个保证在进程被杀之前会调用的，因此你应该使用onPause()来写任何持久化存储数据。

被标记为No的方法保护活动寄宿的进程在他们调用的时候不会被杀掉。因此活动是可杀掉状态，例如onPause()返回到onResume()调用期间。直到onPause()再次返回，活动是不可杀掉的。其实，没有标记为Killable的活动也是可以系统被杀掉的，不过这仅仅发生在极端困难的情况下，没有有任何其他资源可用。
2、保存活动状态

当系统而不是用户关闭一个活动来节省内存时，用户可能希望返回到活动且是它之前的状态。为了获得活动被杀之前的状态，你可以执行活动的onSaveInstanceState()方法。Android在活动容易被销毁前调用这个方法，也就是调用onPause()之前。该方法的参数是一个Bundle对象，在这个对象你可以以名值对记录活动的动态状态。当活动再次启动时，Bundle同时被传递到onCreate()和调用onCreate()之后的方法，onRestoreInstanceState()，因此使用一个或两个可以重新创建捕获的状态。

因为onSaveInstanceState()方法不总是被调用，你应该仅使用onSaveInstanceState()它来记录活动的临时状态，而不是持久的数据。应该使用onPause()来存储持久数据。
3、协调活动

当一个活动启动另一个活动，他们都经历生命周期转换。一个暂停或许是停止，然而另一个启动。有时，你可能需要协调这些活动。生命周期的回调顺序是明确界定的，特别是当这两个活动在同一个进程中：

当前活动的onPause()方法被调用。
接下来，启动活动的onCreate()、onStart()、onResume()方法按序被调用。
然后，如果获得不再在屏幕上可见，它的onStop()方法被调用。

2、服务生命周期

一个服务可以用在两个方面：

• 它可以启动且允许一直运行直到有人停止它，或者它自己停止。在这种模式，通过调用Context.startService()启动服务及通过调用Context.stopService()停止服务。服务也可以通过调用Service.stopSelf()或Service.stopSelfResult()停止自己。仅需要调用一次stopService()停止服务，而不管调用startService()了多少次。
• 通过使用相关接口可以编程地操作服务。客户端建立与Service对象的一个连接及使用该连接调入服务。连接通过调用Context.bindService()建立，通过调用Context.unbindService()关闭。多个客户端可以绑定到同一个服务。如果服务尚未启动，bindService()可以选择启动它。

这两种模式并不是完全分离的。你可以绑定到一个用startService()启动的服务。例如，一个后台音乐服务可以通过使用定义了音乐播放的Intent对象调用startService()启动。直到后来，用户可能想对播放器做一些控制或者获取当前歌曲的一些信息，一个活动将调用bindService()与服务建立连接。在这种情况下，实际上直到最后一个绑定关闭stopService()并不会停止。

像活动一样，一个服务也有生命周期方法，你可以执行监视它的状态改变。但是比活动的生命周期方法更少，只有三个且它们是公有的（public）而不是受保护的（protected）（说明：活动的生命周期方法是protected的）：

• void onCreate()
• void onStart(Intent intent)
• void onDestory()

通过这三个方法，你可以监视服务生命周期的两个嵌套循环：

• 服务的整个生命时间（entire lifetime），从调用onCreate()到相应地调用onDestory()。像一个活动一样，服务在onCreate()中做一些初始设置，且在中释放所有的资源。例如，一个音乐播放服务可以在onCreate()中创建线程，然后在onDestory()中停止线程。
• 服务的活跃生命时间（active lifetime），从调用onStart()开始。这个方法传递参数是传送给startService()的Intent对象。音乐服务将打开Intent，了解播放哪个音乐并且开始播放。
  没有相应的回调方法，因为服务停止没有onStop()方法。

startService()和onDestory()被所有服务调用，不管是通过Context.startService()启动还是通过Context.bindService()启动的。然而，onStart()仅被通过startService()启动的服务调用。

如果一个服务允许别的绑定到它，有一些额外的回调方法来实现它：

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

onBind()回调传递的参数是传给bindService()的Intent对象，onUnbind()回调传递的参数是传给unbindService()的Intent对象。如果服务允许绑定，onBind()返回客户端与服务交互的通信通道。onUnbind()方法可以要求调用onRebind()，如果一个新的客户端连接到服务。

下图解释了服务的回调方法。虽然，它分离了由startService()启动的服务和由bindService()启动的服务，记住任何服务，无论它怎么启动的，都可能允许客户端绑定到它，因此任何服务可能接收onBind()和onUnbind()调用。

3、广播接收者生命周期

一个广播接收者有一个回调方法：void onReceive(Context curContext, Intent broadcastMsg)。当一个广播消息到达接收者是，Android调用它的onReceive()方法并传递给它包含消息的Intent对象。广播接收者被认为仅当它执行这个方法时是活跃的。当onReceive()返回后，它是不活跃的。

有一个活跃的广播接收者的进程是受保护的，不会被杀死。但是系统可以在任何时候杀死仅有不活跃组件的进程，当占用的内存别的进程需要时。

这带来一个问题，当一个广播消息的响应时费时的，因此应该在独立的线程中做这些事，远离用户界面其它组件运行的主线程。如果onReceive()衍生线程然后返回，整个进程，包括新的线程，被判定为不活跃的（除非进程中的其它应用程序组件是活跃的），将使它处于被杀的危机。解决这个问题的方法是onReceive()启动一个服务，及时服务做这个工作，因此系统知道进程中有活跃的工作在做。