应用程序基础

关键类

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

Android应用程序使用Java做为开发语言。aapt工具把编译后的Java代码连同其它应用程序需要的数据和资源文件一起打包到一个Android包文件中，这个文件使用.apk做为扩展名，它是分发应用程序并安装到移动设备的媒介，用户只需下载并安装此文件到他们的设备。单一.apk文件中的所有代码被认为是一个应用程序。

从很多方面来看，每个Android应用程序都存在于它自己的世界之中：

• 默认情况下，每个应用程序均运行于它自己的Linux进程中。当应用程序中的任意代码开始执行时，Android启动一个进程，而当不再需要此进程而其它应用程序又需要系统资源时，则关闭这个进程。
• 每个进程都运行于自己的Java虚拟机（VM）中。所以应用程序代码实际上与其它应用程序的代码是隔绝的。
• 默认情况下，每个应用程序均被赋予一个唯一的Linux用户ID，并加以权限设置，使得应用程序的文件仅对这个用户、这个应用程序可见。当然，也有其它的方法使得这些文件同样能为别的应用程序所访问。

使两个应用程序共有同一个用户ID是可行的，这种情况下他们可以看到彼此的文件。从系统资源维护的角度来看，拥有同一个ID的应用程序也将在运行时使用同一个Linux进程，以及同一个虚拟机。

应用程序组件

Android的核心功能之一就是一个应用程序可以使用其它应用程序的元素（如果那个应用程序允许的话）。比如说，如果你的应用程序需要一个图片卷动列表，而另一个应用程序已经开发了一个合用的而又允许别人使用的话，你可以直接调用那个卷动列表来完成工作，而不用自己再开发一个。你的应用程序并没有吸纳或链接其它应用程序的代码，它只是在有需求的时候启动了其它应用程序的那个功能部分。

为达到这个目的，系统必须在一个应用程序的一部分被需要时启动这个应用程序，并将那个部分的Java对象实例化。与在其它系统上的应用程序不同，Android应用程序没有为应用准备一个单独的程序入口（比如说，没有main()方法）， 而是为系统依照需求实例化提供了基本的组件。共有四种组件类型：

Activity

Activity是为用户操作而展示的可视化用户界面。比如说，一个activity可以展示一个菜单项列表供用户选择，或者显示一些包含说明的照片。一个短消息应用程序可以包括一个用于显示做为发送对象的联系人的列表的activity，一个给选定的联系人写短信的activity以及翻阅以前的短信和改变设置的activity。尽管它们一起组成了一个内聚的用户界面，但其中每个activity都与其它的保持独立。每个都是以Activity类为基类的子类实现。

一个应用程序可以只有一个activity，或者，如刚才提到的短信应用程序那样，包含很多个。每个activity的作用，以及其数目，自然取决于应用程序及其设计。一般情况下，总有一个应用程序被标记为用户在应用程序启动的时候第一个看到的。从一个activity转向另一个的方式是靠当前的activity启动下一个。

每个activity都被给予一个默认的窗口以进行绘制。一般情况下，这个窗口是满屏的，但它也可以是一个小的位于其它窗口之上的浮动窗口。一个activity也可以使用超过一个的窗口──比如，在activity运行过程中弹出的一个供用户反应的小对话框，或是当用户选择了屏幕上特定项目后显示的必要信息。

窗口显示的可视内容是由一系列视图构成的，这些视图均继承自?View?基类。每个视图均控制着窗口中一块特定的矩形空间。父级视图包含并组织它子视图的布局。叶节点视图（位于视图层次最底端）在它们控制的矩形中进行绘制，并对用户对其直接操作做出响应。所以，视图是activity与用户进行交互的界面。比如说，视图可以显示一个小图片，并在用户指点它的时候产生动作。Android有很多既定的视图供用户直接使用，包括按钮、文本域、卷轴、菜单项、复选框等等。

视图层次是由Activity.setContentView()?方法放入activity的窗口之中的。上下文视图是位于视图层次根位置的视图对象。（参见用户界面章节获取关于视图及层次的更多信息。）

服务

服务没有可视化的用户界面，而是在一段时间内在后台运行。比如说，一个服务可以在用户做其它事情的时候在后台播放背景音乐、从网络上获取一些数据或者计算一些东西并提供给需要这个运算结果的activity使用。每个服务都继承自Service基类。

一个媒体播放器播放播放列表中的曲目是一个不错的例子。播放器应用程序可能有一个或多个activity来给用户选择歌曲并进行播放。然而，音乐播放这个任务本身不应该为任何activity所处理，因为用户期望在他们离开播放器应用程序而开始做别的事情时，音乐仍在继续播放。为达到这个目的，媒体播放器activity应该启用一个运行于后台的服务。而系统将在这个activity不再显示于屏幕之后，仍维持音乐播放服务的运行。

你可以连接至（绑定）一个正在运行的服务（如果服务没有运行，则启动之）。连接之后，你可以通过那个服务暴露出来的接口与服务进行通讯。对于音乐服务来说，这个接口可以允许用户暂停、回退、停止以及重新开始播放。

如同activity和其它组件一样，服务运行于应用程序进程的主线程内。所以它不会对其它组件或用户界面有任何干扰，它们一般会派生一个新线程来进行一些耗时任务（比如音乐回放）。参见下述?进程和线程?。

广播接收器

广播接收器是一个专注于接收广播通知信息，并做出对应处理的组件。很多广播是源自于系统代码的──比如，通知时区改变、电池电量低、拍摄了一张照片或者用户改变了语言选项。应用程序也可以进行广播──比如说，通知其它应用程序一些数据下载完成并处于可用状态。

应用程序可以拥有任意数量的广播接收器以对所有它感兴趣的通知信息予以响应。所有的接收器均继承自BroadcastReceiver基类。
广播接收器没有用户界面。然而，它们可以启动一个activity来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力──闪动背灯、震动、播放声音等等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。

内容提供者

内容提供者将一些特定的应用程序数据供给其它应用程序使用。数据可以存储于文件系统、SQLite数据库或其它方式。内容提供者继承于ContentProvider?基类，为其它应用程序取用和存储它管理的数据实现了一套标准方法。然而，应用程序并不直接调用这些方法，而是使用一个?ContentResolver?对象，调用它的方法作为替代。ContentResolver可以与任意内容提供者进行会话，与其合作来对所有相关交互通讯进行管理。

参阅独立的内容提供者章节获得更多关于使用内容提供者的内容。

每当出现一个需要被特定组件处理的请求时，Android会确保那个组件的应用程序进程处于运行状态，或在必要的时候启动它。并确保那个相应组件的实例的存在，必要时会创建那个实例。

激活组件：intent

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

对于每种组件来说，激活的方法是不同的：

• 通过传递一个Intent对象至?Context.startActivity()或Activity.startActivityForResult()以载入（或指定新工作给）一个activity。相应的activity可以通过调用?getIntent()?方法来查看激活它的intent。Android通过调用activity的onNewIntent()方法来传递给它继发的intent。
  一个activity经常启动了下一个。如果它期望它所启动的那个activity返回一个结果，它会以调用startActivityForResult()来取代startActivity()。比如说，如果它启动了另外一个activity以使用户挑选一张照片，它也许想知道哪张照片被选中了。结果将会被封装在一个Intent对象中，并传递给发出调用的activity的onActivityResult()?方法。
• 通过传递一个Intent对象至Context.startService()将启动一个服务（或给予正在运行的服务以一个新的指令）。Android调用服务的?onStart()方法并将Intent对象传递给它。
  与此类似，一个Intent可以被调用组件传递给?Context.bindService()以获取一个正在运行的目标服务的连接。这个服务会经由onBind()?方法的调用获取这个Intent对象（如果服务尚未启动，bindService()会先启动它）。比如说，一个activity可以连接至前述的音乐回放服务，并提供给用户一个可操作的（用户界面）以对回放进行控制。这个activity可以调用?bindService()?来建立连接，然后调用服务中定义的对象来影响回放。
  后面一节：远程方法调用将更详细的阐明如何绑定至服务。
• 应用程序可以凭借将Intent对象传递给?Context.sendBroadcast()?，Context.sendOrderedBroadcast()， 以及Context.sendStickyBroadcast()和其它类似方法来产生一个广播。Android会调用所有对此广播有兴趣的广播接收器的?onReceive()方法，将intent传递给它们。

欲了解更多intent消息的信息，请参阅独立章节?Intent和Intent滤过器。

关闭组件

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

而activity则不同，它提供了用户界面，并与用户进行会话。所以只要会话依然持续，哪怕对话过程暂时停顿，它都会一直保持激活状态。与此相似，服务也会在很长一段时间内保持运行。所以Android为关闭activity和服务提供了一系列的方法。

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

系统也会在组件不再被使用的时候或者Android需要为活动组件声明更多内存的时候关闭它。后面的?组件的生命周期一节，将对这种可能及附属情况进行更详细的讨论。

manifest文件

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

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

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

<?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>

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

其它组件也以类似的方法声明──<service>?元素用于声明服务，?<receiver>?元素用于声明广播接收器，而?<provider>?元素用于声明内容提供者。 manifest文件中未进行声明的activity、服务以及内容提供者将不为系统所见，从而也就不会被运行。然而，广播接收器既可以在manifest文件中声明，也可以在代码中进行动态的创建，并以调用Context.registerReceiver()的方式注册至系统。

欲更多了解如何为你的应用程序构建manifest文件，请参阅AndroidManifest.xml文件一章。

Intent过滤器

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

<?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:type="image/jpeg" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
        . . .
    </application>
</manifest>

示例中的第一个过滤器──action “android.intent.action.MAIN”和类别“android.intent.category.LAUNCHER”的组合──是通常具有的。它标明了这个activity将在应用程序加载器中显示，就是用户在设备上看到的可供加载的应用程序列表。换句话说，这个activity是应用程序的入口，是用户选择运行这个应用程序后所见到的第一个activity。

第二个过滤器声明了这个activity能被赋予一种特定类型的数据。

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

对于在代码中创建并注册的广播接收器来说，intent过滤器将被直接以?IntentFilter对象实例化。其它过滤器则在manifest文件中设置。

欲获得更多intent过滤器的信息，请参阅独立章节：?Intent和Intent过滤器。

Activity和任务

如前所述，一个activity可以启动另外一个，甚至包括与它不处于同一应用程序之中的。举个例子说，假设你想让用户看到某个地方的街道地图。而已经存在一个具有此功能的activity了，那么你的activity所需要做的工作就是把请求信息放到一个Intent对象里面，并把它传递给startActivity()。于是地图浏览器就会显示那个地图。而当用户按下BACK键的时候，你的activity又会再一次的显示在屏幕上。

对于用户来说，这看起来就像是地图浏览器是你activity所在的应用程序中的一个组成部分，其实它是在另外一个应用程序中定义，并运行在那个应用程序的进程之中的。Android将这两个activity放在同一个任务中来维持一个完整的用户体验。简单的说，任务就是用户所体验到的“应用程序”。它是安排在一个堆栈中的一组相关的activity。堆栈中的根activity就是启动了这整个任务的那个──一般情况下，它就是用户在应用程序加载器中所选择的。而堆栈最上方的activity则是当前运行的──用户直接对其进行操作的。当一个activity启动另外一个的时候，新的activity就被压入堆栈，并成为当前运行的activity。而前一个activity仍保持在堆栈之中。当用户按下BACK键的时候，当前activity出栈，而前一个恢复为当前运行的activity。

堆栈中保存的其实是对象，所以如果发生了诸如需要多个地图浏览器的情况，就会使得一个任务中出现多个同一Activity子类的实例同时存在，堆栈会为每个实例单独开辟一个入口。堆栈中的Activity永远不会重排，只会压入或弹出。

任务其实就是activity的堆栈，而不是manifest文件中的一个类或者元素。所以你无法撇开activity而为一个任务设置一个值。而事实上整个任务使用的值是在根activity中设置的。比如说，下一节我们会谈及“任务的affinity”，从affinity中读出的值将会设置到任务的根activity之中。

任务中的所有activity是作为一个整体进行移动的。整个的任务（即activity堆栈）可以移到前台，或退至后台。举个例子说，比如当前任务在堆栈中存有四个activity──三个在当前activity之下。当用户按下HOME键的时候，回到了应用程序加载器，然后选择了一个新的应用程序（也就是一个新任务）。则当前任务遁入后台，而新任务的根activity显示出来。然后，过了一小会儿，用户再次回到了应用程序加载器而又选择了前一个应用程序（上一个任务）。于是那个任务，带着它堆栈中所有的四个activity，再一次的到了前台。当用户按下BACK键的时候，屏幕不会显示出用户刚才离开的activity（上一个任务的根activity）。取而代之，当前任务的堆栈中最上面的activity被弹出，而同一任务中的上一个activity显示了出来。

上述的种种即是activity和任务的默认行为模式。但是有一些方法可以改变所有这一切。activity和任务的联系、任务中activity的行为方式都被启动那个activity的Intent对象中设置的一系列标记和manifest文件中那个activity中的<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

接下来的一节会描述这些标记以及属性的作用，它们是如何互相影响的，以及控制它们的使用时必须考虑到的因素。

Affinity（吸引力）和新任务

默认情况下，一个应用程序中的activity相互之间会有一种Affinity──也就是说，它们首选都归属于一个任务。然而，可以在<activity>元素中把每个activity的taskAffinity属性设置为一个独立的affinity。于是在不同的应用程序中定义的activity可以享有同一个affinity，或者在同一个应用程序中定义的activity有着不同的affinity。affinity在两种情况下生效：当加载activity的Intent对象包含了FLAG_ACTIVITY_NEW_TASK?标记，或者当activity的allowTaskReparenting属性设置为“true”。

FLAG_ACTIVITY_NEW_TASK标记

如前所述，在默认情况下，一个新activity被另外一个调用了startActivity()方法的activity载入了任务之中。并压入了调用者所在的堆栈。然而，如果传递给startActivity()的Intent对象包含了FLAG_ACTIVITY_NEW_TASK标记，系统会为新activity安排另外一个任务。一般情况下，如同标记所暗示的那样，这会是一个新任务。然而，这并不是必然的。如果已经存在了一个与新activity有着同样affinity的任务，则activity会载入那个任务之中。如果没有，则启用新任务。

allowTaskReparenting?属性

如果一个activity将allowTaskReparenting属性设置为“true”。它就可以从初始的任务中转移到与其拥有同一个affinity并转向前台的任务之中。比如说，一个旅行应用程序中包含的预报所选城市的天气情况的activity。它与这个应用程序中其它的activity拥有同样的affinity（默认的affinity）而且允许重定父级。你的另一个activity启动了天气预报，于是它就会与这个activity共处与同一任务之中。然而，当那个旅行应用程序再次回到前台的时候，这个天气预报activity就会被再次安排到原先的任务之中并显示出来。

如果在用户的角度看来，一个.apk文件中包含了多于一个的“应用程序”，你可能会想要为它们所辖的activity安排不一样的affinity。

加载模式

<activity>元素的launchMode属性可以设置四种不同的加载模式：

"standard" （默认值）
"singleTop"?
"singleTask"?
"singleInstance"

这些模式之间的差异主要体现在四个方面：

• 哪个任务会把持对intent做出响应的activity。对“standard”和“singleTop”模式而言，是产生intent（并调用?startActivity()）的任务──除非Intent对象包含FLAG_ACTIVITY_NEW_TASK标记。而在这种情况下，如同上面Affinitie和新任务一节所述，会是另外一个任务。

  相反，对“singleTask”和“singleInstance”模式而言，activity总是位于任务的根部。正是它们定义了一个任务，所以它们绝不会被载入到其它任务之中。

• activity是否可以存在多个实例。一个“standard”或“singleTop”的activity可以被多次初始化。它们可以归属于多个任务，而一个任务也可以拥有同一activity的多个实例。

  相反，对“singleTask”和“singleInstance”的activity被限定于只能有一个实例。因为这些activity都是任务的起源，这种限制意味着在一个设备中同一时间只允许存在一个任务的实例。

• 在实例所在的任务中是否会有别的activity。一个“singleInstance”模式的activity将会是它所在的任务中唯一的activity。如果它启动了别的activity，那个activity将会依据它自己的加载模式加载到其它的任务中去──如同在intent中设置了FLAG_ACTIVITY_NEW_TASK?标记一样的效果。在其它方面，“singleInstance”模式的效果与“singleTask”是一样的。

  剩下的三种模式允许一个任务中出现多个activity。“singleTask”模式的activity将是任务的根activity，但它可以启动别的activity并将它们置入所在的任务中。“standard”和“singleTop”activity则可以在堆栈的任意位置出现。

• 是否要载入新的类实例以处理新的intent。对默认的"standard"模式来说，对于每个新intent都会创建一个新的实例以进行响应，每个实例仅处理一个intent。“singleTop”模式下，如果activity位于目的任务堆栈的最上面，则重用目前现存的activity来处理新的intent。如果它不是在堆栈顶部，则不会发生重用。而是创建一个新实例来处理新的intent并将其推入堆栈。

  举例来说，假设一个任务的堆栈由根activityA和activity B、C和位于堆栈顶部的D组成，即堆栈A-B-C-D。一个针对D类型的activity的intent抵达的时候，如果D是默认的“standard”加载模式，则创建并加载一个新的类实例，于是堆栈变为A-B-C-D-D。 然而，如果D的载入模式为“singleTop”，则现有的实例会对新intent进行处理（因为它位于堆栈顶部）而堆栈保持A-B-C-D的形态。

  换言之，如果新抵达的intent是针对B类型的activity，则无论B的模式是“standard”还是“singleTop” ，都会加载一个新的B的实例（因为B不位于堆栈的顶部），而堆栈的顺序变为A-B-C-D-B。

  如前所述，“singleTask”或“singleInstance”模式的activity永远不会存在多于一个实例。所以实例将处理所有新的intent。一个“singleInstance”模式的activity永远保持在堆栈的顶部（因为它是那个堆栈中唯一的一个activity），所以它一直坚守在处理intent的岗位上。然而，对一个“singleTask”模式的activity来说，它上面可能有，也可能没有别的activity和它处于同一堆栈。在有的情况下，它就不在能够处理intent的位置上，则那个intent将被舍弃。（即便在intent被舍弃的情况下，它的抵达仍将使这个任务切换至前台，并一直保留）

当一个现存的activity被要求处理一个新的intent的时候，会调用onNewIntent()方法来将intent对象传递至activity。（启动activity的原始intent对象可以通过调用getIntent()方法获得。）

请注意，当一个新的activity实例被创建以处理新的intent的时候，用户总可以按下BACK键来回到前面的状态（回到前一个activity）。但当使用现存的activity来处理新intent的时候，用户是不能靠按下BACK键回到当这个新intent抵达之前的状态的。

想获得更多关于加载模式的内容，请参阅?<activity>?元素的描述。

清理堆栈

如果用户离开一个任务很长一段时间，系统会清理该任务中除了根activity之外的所有activity。当用户再次回到这个任务的时候，除了只剩下初始化activity尚存之外，其余都跟用户上次离开它的时候一样。这样做的原因是：在一段时间之后，用户再次回到一个任务的时候，他们更期望放弃他们之前的所作所为，做些新的事情。

这些属于默认行为，另外，也存在一些activity的属性用以控制并改变这些行为：

alwaysRetainTaskState?属性

如果一个任务的根activity中此属性设置为“true”，则上述默认行为不会发生。任务将在很长的一段时间内保留它堆栈内的所有activity。

clearTaskOnLaunch属性

如果一个任务的根activity中此属性设置为“true”，则每当用户离开这个任务和返回它的时候，堆栈都会被清空至只留下rootactivity。换句话说，这是alwaysRetainTaskState的另一个极端。哪怕仅是过了一小会儿，用户回到任务时，也是见到它的初始状态。

finishOnTaskLaunch属性

这个属性与clearTaskOnLaunch属性相似，但它仅作用于单个的activity，而不是整个的task。而且它可以使任意activity都被清理，甚至根activity也不例外。当它设置为“true”的时候，此activity仅做为任务的一部分存在于当前回话中，一旦用户离开并再次回到这个任务，此activity将不复存在。

此外，还有别的方式从堆栈中移除一个activity。如果一个intent对象包含FLAG_ACTIVITY_CLEAR_TOP标记，而且目标任务的堆栈中已经存在了一个能够响应此intent的activity类型的实例。则这个实例之上的所有activity都将被清理以使它位于堆栈的顶部来对intent做出响应。如果此时指定的activity的加载模式为“standard”，则它本身也会从堆栈中移除，并加载一个新的实例来处理到来的intent。这是因为加载模式为“standard”的activity总会创建一个新实例来处理新的intent。

FLAG_ACTIVITY_CLEAR_TOP与FLAG_ACTIVITY_NEW_TASK经常合并使用。这时，这些标记提供了一种