Android进程与线程[转]

当某个组件第一次运行的时候，Android启动了一个进程。默认的，所有的组件和程序运行在这个进程和线程中。

也可以安排组件在其他的进程或者线程中运行

进程

组件运行的进程由manifest file控制。组件的节点 — <activity>, <service>, <receiver>, 和 <provider> — 都包含一个 process 属性。这个属性可以设置组件运行的进程：可以配置组件在一个独立进程运行，或者多个组件在同一个进程运行。甚至可以多个程序在一个进程中运行——如果这些程序共享一个User ID并给定同样的权限。<application> 节点也包含 process 属性，用来设置程序中所有组件的默认进程。

所有的组件在此进程的主线程中实例化，系统对这些组件的调用从主线程中分离。并非每个对象都会从主线程中分离。一般来说，响应例如View.onKeyDown()用户操作的方法和通知的方法也在主线程中运行。这就表示，组件被系统调用的时候不应该长时间运行或者阻塞操作（如网络操作或者计算大量数据），因为这样会阻塞进程中的其他组件。可以把这类操作从主线程中分离。

当更加常用的进程无法获取足够内存,Android可能会关闭不常用的进程。下次启动程序的时候会重新启动进程。

当决定哪个进程需要被关闭的时候， Android会考虑哪个对用户更加有用。如Android会倾向于关闭一个长期不显示在界面的进程来支持一个经常显示在界面的进程。是否关闭一个进程决定于组件在进程中的状态，参见后面的章节Component Lifecycles.

线程

即使为组件分配了不同的进程，有时候也需要再分配线程。比如用户界面需要很快对用户进行响应，因此某些费时的操作，如网络连接、下载或者非常占用服务器时间的操作应该放到其他线程。

线程通过java的标准对象Thread 创建. Android 提供了很多方便的管理线程的方法：— Looper 在线程中运行一个消息循环； Handler 传递一个消息； HandlerThread 创建一个带有消息循环的线程。

远程调用Remote procedure calls

Android有一个远程调用(RPCs) 的轻量级机制— 通过这个机制，方法可以在本地调用，在远程执行（在其他进程执行），还可以返回一个值。要实现这个需求，必须分解方法调用，并且所有要传递的数据必须是操作系统可以访问的级别。从本地的进程和内存地址传送到远程的进程和内存地址并在远程处理和返回。返回值必须向相反的方向传递。Android提供了做以上操作的代码，所以开发者可以专注于实现RPC的接口。

一个RPC接口只能包含方法。所有的方法都是同步执行的（直到远程方法返回，本地方法才结束阻塞），没有返回值的时候也是如此。

简单来说，这个机制是这样的：使用IDL (interface definition language)定义你想要实现的接口， aidl 工具可以生成用于java的接口定义，本地和远程都要使用这个定义。它包含2个类，见下图：

inner类包含了所有的管理远程程序（符合IDL描述的接口）所需要的代码。所有的inner类实现了IBinder 接口.其中一个在本地使用，可以不管它的代码；另外一个叫做Stub继承了 Binder 类。为了实现远程调用，这个类包含RPC接口。开发者可以继承Stub类来实现需要的方法。

一般来说，远程进程会被一个service管理（因为service可以通知操作系统这个进程的信息并和其他进程通信），它也会包含aidl 工具产生的接口文件，Stub类实现了远处那个方法。服务的客户端只需要aidl 工具产生的接口文件。

以下是如何连接服务和客户端调用：

• ·服务的客户端（本地）会实现onServiceConnected() 和onServiceDisconnected() 方法，这样，当客户端连接或者断开连接的时候可以获取到通知。通过 bindService() 获取到服务的连接。
• · 服务的 onBind() 方法中可以接收或者拒绝连接，取决它收到的intent (intent通过 bindService()方法连接到服务). 如果服务接收了连接，会返回一个Stub类的实例.
• · 如果服务接受了连接，Android会调用客户端的onServiceConnected() 方法，并传递一个Ibinder对象（系统管理的Stub类的代理），通过这个代理，客户端可以连接远程的服务。

以上的描述省略很多RPC的机制。请参见Designing a Remote Interface Using AIDL 和 IBinder 类。

线程安全的方法

在某些情况下，方法可能调用不止一个的线程，因此需要注意方法的线程安全。

对于可以远程调用的方法，也要注意这点。当一个调用在Ibinder对象中的方法的程序启动了和Ibinder对象相同的进程，方法就在Ibinder的进程中执行。但是，如果调用者发起另外一个进程，方法在另外一个线程中运行，这个线程在和IBinder对象在一个线程池中；它不会在进程的主线程中运行。例如，一个service从主线程被调用onBind() 方法，onBind() 返回的对象（如实现了RPC的Stub子类）中的方法会被从线程池中调用。因为一个服务可能有多个客户端请求，不止一个线程池会在同一时间调用IBinder的方法。因此IBinder必须线程安全。

简单来说，一个content provider 可以接收其他进程的数据请求。即使ContentResolver和ContentProvider类没有隐藏了管理交互的细节，ContentProvider中响应这些请求的方法（query(), insert(), delete(), update(), and getType() ）— 是在content provider的线程池中被调用的，而不是ContentProvider的本身进程。因为这些方法可能是同时从很多线程池运行的，所以这些方法必须要线程安全。