进程和线程

 

进程和线程

当一个应用程序开始运行它的第一个组件时，Android会为它启动一个Linux进程，并在其中执行一个单一的线程。默认情况下，应用程序所有的组件均在这个进程的这个线程中运行。

然而，你也可以安排组件在其他进程中运行，而且可以为任意进程衍生出其它线程。

进程

组件运行所在的进程由manifest文件所控制。组件元素——<activity>， <service>， <receiver>和<provider>——都有一个 process 属性来指定组件应当运行于哪个进程之内。这些属性可以设置为使每个组件运行于它自己的进程之内，或一些组件共享一个进程而其余的组件不这么做。它们也可以设置为令不同应用程序的组件在一个进程中运行——使应用程序的组成部分共享同一个Linux用户ID并赋以同样的权限。<application>元素也有一个process属性，以设定所有组件的默认值。

所有的组件实例都位于特定进程的主线程内，而对这些组件的系统调用也将由那个线程进行分发。一般不会为每个实例创建线程。因此，某些方法总是运行在进程的主线程内，这些方法包括诸如View.onKeyDown()这样报告用户动作以及后面 组件生命周期一节所要讨论的生命周期通告的。这意味着组件在被系统调用的时候，不应该施行长时间的抑或阻塞的操作（诸如网络相关操作或是循环计算），因为这将阻塞同样位于这个进程的其它组件的运行。你应该如同下面线程一节所叙述的那样，为这些长时间操作衍生出一个单独的线程进行处理。

在可用内存不足而又有一个正在为用户进行服务的进程需要更多内存的时候，Android有时候可能会关闭一个进程。而在这个进程中运行着的应用程序也因此被销毁。当再次出现需要它们进行处理的工作的时候，会为这些组件重新创建进程。

在决定结束哪个进程的时候，Android会衡量它们对于用户的相对重要性。比如说，相对于一个仍有用户可见的activity的进程，它更有可能去关闭一个其activity已经不为用户所见的进程。也可以说，决定是否关闭一个进程主要依据在那个进程中运行的组件的状态。这些状态将在后续的一节组件生命周期中予以说明。

线程

尽管你可以把你的应用程序限制于一个单独的进程中，有时，你仍然需要衍生出一个线程以处理后台任务。因为用户界面必须非常及时的对用户操作做出响应，所以，控管activity的线程不应用于处理一些诸如网络下载之类的耗时操作。所有不能在瞬间完成的任务都应安排到不同的线程中去。

线程在代码中是以标准Java Thread对象创建的。Android提供了很多便于管理线程的类： Looper用于在一个线程中运行一个消息循环， Handler用于处理消息，HandlerThread 用于使用一个消息循环启用一个线程。

远程过程调用

Android有一个轻量级的远程过程调用（RPC）机制：即在本地调用一个方法，但在远程（其它的进程中）进行处理，然后将结果返回调用者。这将方法调用及其附属的数据以系统可以理解的方式进行分离，并将其从本地进程和本地地址空间传送至远程过程和远程地址空间，并在那里重新装配并对调用做出反应。返回的结果将以相反的方向进行传递。Android提供了完成这些工作所需的所有的代码，以使你可以集中精力来实现RPC接口本身。

RPC接口可以只包括方法。即便没有返回值，所有方法仍以同步的方式执行（本地方法阻塞直至远程方法结束）。

简单的说，这套机制是这样工作的：一开始，你用简单的IDL（界面描绘语言）声明一个你想要实现的RPC接口。然后用 aidl 工具为这个声明生成一个Java接口定义，这个定义必须对本地和远程进程都可见。它包含两个内部类，如下图所示：

 

 

内部类中有管理实现了你用IDL声明的接口的远程方法调用所需要的所有代码。两个内部类均实现了 IBinder接口。一个用于系统在本地内部使用，你些的代码可以忽略它；另外一个，我们称为Stub，扩展了Binder类。除了实现了IPC调用的内部代码之外，它还包括了你声明的RPC接口中的方法的声明。你应该如上图所示的那样写一个Stub的子类来实现这些方法。

一般情况下，远程过程是被一个服务所管理的（因为服务可以通知系统关于进程以及它连接到别的进程的信息）。它包含着 aidl工具产生的接口文件和实现了RPC方法的Stub的子类。而客户端只需要包括aidl工具产生的接口文件。

下面将说明服务与其客户端之间的连接是如何建立的：

• 服务的客户端（位于本地）应该实现 onServiceConnected() 和 onServiceDisconnected() 方法。这样，当至远程服务的连接成功建立或者断开的时候，它们会收到通知。这样它们就可以调用 bindService() 来设置连接。

• 而服务则应该实现 onBind() 方法以接受或拒绝连接。这取决于它收到的intent（intent将传递给bindService()）。如果接受了连接，它会返回一个Stub的子类的实例。

• 如果服务接受了连接，Android将会调用客户端的onServiceConnected() 方法，并传递给它一个IBinder对象，它是由服务所管理的Stub的子类的代理。通过这个代理，客户端可以对远程服务进行调用。

线程安全方法

在一些情况下，你所实现的方法有可能会被多于一个的线程所调用，所以它们必须被写成线程安全的。

对于我们上一节所讨论的RPC机制中的可以被远程调用的方法来说，这是必须首先考虑的。如果针对一个IBinder对象中实现的方法的调用源自这个IBinder对象所在的进程时，这个方法将会在调用者的线程中执行。然而，如果这个调用源自其它的进程，则这个方法将会在一个线程池中选出的线程中运行，这个线程池由Android加以管理，并与IBinder存在于同一进程内；这个方法不会在进程的主线程内执行。反过来说，一个服务的 onBind() 方法应为服务进程的主线程所调用，而实现了由 onBind() 返回的对象（比如说，一个实现了RPC方法的Stub的子类）的方法将为池中的线程所调用。因为服务可以拥有多于一个的客户端，而同一时间，也会有多个池中的线程调用同一个IBinder方法。因此IBinder方法必须实现为线程安全的。

类似的，一个内容提供者能接受源自其它进程的请求数据。尽管ContentResolver和ContentProvider类隐藏了交互沟通过程的管理细节，ContentProvider会由query()， insert()， delete()， update()和getType()方法来相应这些请求，而这些方法也都是由那个内容提供者的进程中所包涵的线程池提供的，而不是进程的主线程本身。所以这些有可能在同一时间被很多线程调用的方法也必须被实现为线程安全的。

组件生命周期

应用程序组件有其生命周期──由Android初始化它们以相应intent直到这个实例被摧毁。在此之间，它们有时是激活的有时则相反。或者，如果它是一个activity，则是可为用户所见或者不能。这一节讨论了activity、服务以及广播接收器的生命周期，包括它们在生命周期中的状态、在状态之间转变时通知你的方法、以及当这些进程被关闭或实例被摧毁时，这些状态产生的效果。

Activity生命周期

一个activity主要有三个状态：

• 当在屏幕前台时（位于当前任务堆栈的顶部），它是活跃或运行的状态。它就是相应用户操作的activity。

• 当它失去焦点但仍然对用户可见时，它处于暂停状态。即是：在它之上有另外一个activity。这个activity也许是透明的，或者未能完全遮蔽全屏，所以被暂停的activity仍对用户可见。暂停的activity仍然是存活状态（它保留着所有的状态和成员信息并连接至窗口管理器），但当系统处于极低内存的情况下，仍然可以杀死这个activity。

• 如果它完全被另一个activity覆盖是，它处于停止状态。它仍然保留所有的状态和成员信息。然而它不在为用户可见，所以它的窗口将被隐藏，如果其它地方需要内存，则系统经常会杀死这个activity。

如果一个activity处于暂停或停止状态，系统可以通过要求它结束（调用它的 finish() 方法）或直接杀死它的进程来将它驱出内存。当它再次为用户可见的时候，它只能完全重新启动并恢复至以前的状态。

当一个activity从这个状态转变到另一个状态时，它被以下列protected方法所通知：

 

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

你可以重载所有这些方法以在状态改变时进行合适的工作。所有的activity都必须实现 onCreate() 用以当对象第一次实例化时进行初始化设置。很多activity会实现 onPause()以提交数据变化或准备停止与用户的交互。

调用父类

所有activity生命周期方法的实现都必须先调用其父类的版本。比如说：

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

总得来说，这七个方法定义了一个activity完整的生命周期。实现这些方法可以帮助你监察三个嵌套的生命周期循环：

• 一个activity 完整的生命周期 自第一次调用 onCreate()开始，直至调用onDestroy()为止。activity在onCreate()中设置所有“全局”状态以完成初始化，而在onDestroy()中释放所有系统资源。比如说，如果activity有一个线程在后台运行以从网络上下载数据，它会以 onCreate()创建那个线程，而以 onDestroy()销毁那个线程。

• 一个activity的 可视生命周期自 onStart() 调用开始直到相应的 onStop()调用。在此期间，用户可以在屏幕上看到此activity，尽管它也许并不是位于前台或者正在与用户做交互。在这两个方法中，你可以管控用来向用户显示这个activity的资源。比如说，你可以在onStart() 中注册一个BroadcastReceiver 来监控会影响到你UI的改变，而在onStop() 中来取消注册，这时用户是无法看到你的程序显示的内容的。onStart() 和 onStop() 方法可以随着应用程序是否为用户可见而被多次调用。

• 一个activity的 前台生命周期 自 onResume() 调用起，至相应的 onPause()调用为止。在此期间，activity位于前台最上面并与用户进行交互。activity会经常在暂停和恢复之间进行状态转换──比如说当设备转入休眠状态或有新的activity启动时，将调用onPause() 方法。当activity获得结果或者接收到新的intent的时候会调用onResume() 方法。因此，在这两个方法中的代码应当是轻量级的。

 

下图展示了上述循环过程以及activity在这个过程之中历经的状态改变。着色的椭圆是activity可以经历的主要状态。矩形框代表了当activity在状态间发生改变的时候，你进行操作所要实现的回调方法。

 

下表详细描述了这些方法，并在activity的整个生命周期中定位了它们。

方法			描述	可被杀死	下一个
onCreate()			在activity第一次被创建的时候调用。这里是你做所有初始化设置的地方──创建视图、绑定数据至列表等。如果曾经有状态记录（参阅后述Saving Activity State。），则调用此方法时会传入一个包含着此activity以前状态的包对象做为参数。 总继之以onStart()。	否	onStart()
	onRestart()		在activity停止后，在再次启动之前被调用。 总继之以onStart()。	否	onStart()
	onStart()		当activity正要变得为用户所见时被调用。 当activity转向前台时继以onResume()，在activity变为隐藏时继以onStop()。	否	onResume() or onStop()
		onResume()	在activity开始与用户进行交互之前被调用。此时activity位于堆栈顶部，并接受用户输入。 继之以onPause()。	否	onPause()
		onPause()	当系统将要启动另一个activity时调用。此方法主要用来将未保存的变化进行持久化，停止类似动画这样耗费CPU的动作等。这一切动作应该在短时间内完成，因为下一个activity必须等到此方法返回后才会继续。 当activity重新回到前台是继以onResume()。当activity变为用户不可见时继以onStop()。	是	onResume() or onStop()
	onStop()		当activity不再为用户可见时调用此方法。这可能发生在它被销毁或者另一个activity（可能是现存的或者是新的）回到运行状态并覆盖了它。 如果activity再次回到前台跟用户交互则继以onRestart()，如果关闭activity则继以onDestroy()。	是	onRestart() or onDestroy()
onDestroy()			在activity销毁前调用。这是activity接收的最后一个调用。这可能发生在activity结束（调用了它的 finish() 方法）或者因为系统需要空间所以临时的销毁了此acitivity的实例时。你可以用isFinishing() 方法来区分这两种情况。	是	nothing

请注意上表中可被杀死一列。它标示了在方法返回后，还没执行activity的其余代码的任意时间里，系统是否可以杀死包含此activity的进程。三个方法（onPause()、 onStop()和onDestroy()）被标记为“是”。onPause()是三个中的第一个，它也是唯一一个在进程被杀死之前必然会调用的方法──onStop() 和 onDestroy() 有可能不被执行。因此你应该用 onPause() 来将所有持久性数据（比如用户的编辑结果）写入存储之中。

在可被杀死一列中标记为“否”的方法在它们被调用时将保护activity所在的进程不会被杀死。所以只有在onPause()方法返回后到onResume() 方法被调用时，一个activity才处于可被杀死的状态。在onPause()再次被调用并返回之前，它不会被系统杀死。

如后面一节进程和生命周期所述，即使是在这里技术上没有被定义为“可杀死”的activity仍然有可能被系统杀死──但这仅会发生在实在没有其它方法的极端情况之下。

保存activity状态

当系统而不是用户自己出于回收内存的考虑，关闭了一个activity之后。用户会期望当他再次回到那个activity的时候，它仍保持着上次离开时的样子。

为了获取activity被杀死前的状态，你应该为activity实现onSaveInstanceState() 方法。Android在activity有可能被销毁之前（即onPause() 调用之前）会调用此方法。它会将一个以名称-值对方式记录了activity动态状态的Bundle 对象传递给该方法。当activity再次启动时，这个Bundle会传递给onCreate()方法和随着onStart()方法调用的onRestoreInstanceState()，所以它们两个都可以恢复捕获的状态。

与onPause()或先前讨论的其它方法不同，onSaveInstanceState() 和 onRestoreInstanceState() 并不是生命周期方法。它们并不是总会被调用。比如说，Android会在activity易于被系统销毁之前调用 onSaveInstanceState()，但用户动作（比如按下了BACK键）造成的销毁则不调用。在这种情况下，用户没打算再次回到这个activity，所以没有保存状态的必要。

因为onSaveInstanceState()不是总被调用，所以你应该只用它来为activity保存一些临时的状态，而不能用来保存持久性数据。而是应该用onPause()来达到这个目的。

协调activity

当一个activity启动了另外一个的时候，它们都会经历生命周期变化。一个会暂停乃至停止，而另一个则启动。这种情况下，你可能需要协调好这些activity：

生命周期回调顺序是已经定义好的，尤其是在两个activity在同一个进程内的情况下：

1. 调用当前activity的 onPause() 方法。

2. 接着，顺序调用新启动activity的onCreate()、 onStart()和onResume()方法。

3. 然后，如果启动的activity不再于屏幕上可见，则调用它的onStop()方法。