Service分析

Android 体系架构有三种意义上服务：Native 服务，Android 服务，Init 空间服务。

Navite 服务，指完全在C++空间完成的服务，主要是指系统一开始初始化，通过Init.rc 脚本起来的服务，例如ServiceManger service,Zygote service,Media service , ril_demon

service 等。

Android 服务是指在JVM 空间完成的服务，虽然也要使用Navite 上的框架，但是服务主体存在于Android 空间。

1 .Service 本质结构

服务的本质就是响应客户端请求。从程序的角度，服务一定要存在一个闭合循环框架和请求处理框架

分析服务框架就必须弄清楚以下的机制及其构成：

（1）闭合循环结构放置在哪里？

（2）处理框架是如何建立的？

（3）处理请求是如何分发和管理？

 

2 .Service 基本框架分析

Android 设计中，Native Service 和AndroidService 采用了同一个闭合循环框架。这个

闭合循环框架放置在Native 的C++ 空间中， ,[e-mail] 和

[e-mail] 两个类完成了全部工作。

在服务框架中，ProcessState 是公用的部分，这个公用部分最主要的框架就是闭合循环框架和接收到从Binder 来的请求后的处理框架。我们将服务框架用ProcessSate 来表示,简言之：

（1） addservice
（2） 建立闭合循环处理框架。

int main(int argc, char** argv){    sp<ProcessState> proc(ProcessState::self());    addService(String16("xxx0"), new xxx0Service());    addService(String16("xxx1"), new xxx1Service());     …    ProcessState::self()->startThreadPool();    IPCThreadState::self()->joinThreadPool();//闭合循环框架}

2.1 Native Service
Native Service 是在系统Init 阶段通过Init.rc 脚本建立的服务。

首先来看看一个例子mediaserver@main_mediaserver.cpp 的建立过程。

int main(int argc, char** argv){sp<ProcessState> proc(ProcessState::self());sp<IServiceManager> sm = defaultServiceManager();LOGI("ServiceManager: %p", sm.get());AudioFlinger::instantiate();MediaPlayerService::instantiate();CameraService::instantiate();AudioPolicyService::instantiate();ProcessState::self()->startThreadPool();IPCThreadState::self()->joinThreadPool();}

我们将代码向下展开了一层，更能看到事物的本质。

int main(int argc, char** argv){sp<ProcessState> proc(ProcessState::self());sp<IServiceManager> sm = defaultServiceManager();defaultServiceManager()->addService(String16("media.audio_flinger"), new AudioFlinger());…ProcessState::self()->startThreadPool();IPCThreadState::self()->joinThreadPool();}

（1）服务进程建立了ProcessState 对象，并将给对象登记在进程的上下文中。
（2）建立一个新AudioFlinger 对象，并将对象登记Service Manager Service 中。
（3）开始就收请求，处理请求，应答这个循环闭合框架。
2.2 Android Service
Androids service 是系统二阶段（Init2）初始化时建立的服务。
Android的所有服务循环框架都是建立SystemServer@(SystemServer.java ） 上。在SystemServer.java 中看不到循环结构，只是可以看到建立了init2的实现函数，建立了一大堆服务，并AddService 到service Manager。
Init2()@SystemServer.java 中建立了Android 中所有要用到的服务：

Entropy ServicePower ManagerActivity ManagerTelephony RegistryPackage ManagerAccount ManagerContent ManagerSystem Content ProvidersBattery ServiceHardware ServiceAlarm ManagerInit WatchdogSensor ServiceWindow ManagerBluetooth ServicestatusbarClipboard ServiceInput Method ServiceNetStat ServiceConnectivity ServiceAccessibility ManagerNotification ManagerMount ServiceDevice Storage MonitorLocation ManagerSearch ServiceCheckin ServiceWallpaper ServiceAudio ServiceHeadset ObserverBackup ServiceAppWidget Service

main() @ com/android/server/SystemServer
{
init1();
}
Init1()是在Native 空间实现的（com_andoird_server_systemServer.cpp）。我们一看这个函数就知道了，原来这个闭合循环处理框架在这里：
init1->system_init() @System_init.cpp
在system_init()我们看到了这个久违的循环闭合管理框架。

{Call "com/android/server/SystemServer", "init2"…..ProcessState::self()->startThreadPool();IPCThreadState::self()->joinThreadPool();}

3. ProcessState 和IPCThreadState

有关IPC 的c++空间的实现都是从ProcessState 这个对象完成的。从宏观来讲，PocessState 及其IPCThreadState 处于IPC 与内核打交道包装层。

我们可以得出如下的结论：不管JVM 的Binder 做了多么复杂的操作，最终还是需要利用ProcessState 这个c++ 空间的对象把数据传递给Binder Driver ， 接收数据也是通过
ProcessState 这个对象完成，ProcessState 是所有Binder IPC 必经的通道。

ProcessState 放置在全局变量gProcess 中，每个进程只有一个ProcessState 对象，负责打开Binder 设备驱动，建立线程池等。而IPCThreadState 每个线程有一个，IPCThreadState 实例登记在Linux 线程程的上下文附属数据中，主要负责Binder 数据读取，写入和请求处理框架。IPCThreadSate 在构造的时候，获取进程的ProcessSate 并记录在自己的成员变量mProcess中,通过mProcess 可以获取到Binder 的句柄。

3.1 ProcessState 的生命周期
ProcessState是Binder 通讯的基础，ProcessState必须在Binder通讯之前建立。客户端，服务端都必须建立。在Android体系中有c++空间的服务，JVM 空间的服务，这两类服务在本质上相同的，只是形式上不
同，由于他们都是建立在ProcessState这个基础上，所以在形式上不同就仅仅表现在对OnTransact 的回调处理的不同。
Native Service
我们直接可以看到使用sp<ProcessState> proc(ProcessState::self())，建立建立ProcessState，一旦调用,ProcessState 就建立了，并且这个self 将ProcessSate 登记在全局变量中。
Android Service
建立Android Service服务,system_init @System_init.cpp 中我们可以看到相同的结构。有一点不同的是所有的Android Service 都运行在一个进程中：systemsever 进程。

3.2 Binder Driver包装 @IPCThreadState
ProcessSate构造的时候,使用open_binder 打开/driver/binder,并将句柄记录在mDriverFD，在ProcessState 中并不使用这个句柄，真正使用这个Binder 设备句柄的是
IPCThreadState，所有关于Binder 的操作放置在IPCThreadState 中：
(1)读取\写入:talkWithDriver() @IPCThreadState 对ioctl(mProcess->mDriverFD,BINDER_WRITE_READ, &bwr)进行包装。
(2)请求处理：executeCommand(...) @IPCThreadState
(3)循环结构：joinThreadPool()

joinThreadPool(){While(1){talkWithDriver(...)...executeCommand(...)}}