Android 核心分析 之七------Service深入分析

原文地址：http://blog.csdn.net/maxleng/archive/2010/04/19/5504485.aspx

Service深入分析

上一章我们分析了
Android IPC

架构

,

知道了

Android

服务构建的一些基本理念和原理，本章我们将深入分析

Android

的服务。

Android

体系架构中三种意义上服务：

Native
服务

Android
服务

Init
空间的服务，主要是属性设置，这个ＩＰＣ是利用Ｓｏｃｋｅｔ来完成的，这个我将在另外一章来讨论。

Navite
服务，实际上就是指完全在

C++

空间完成的服务，主要是指系统一开始初始化，通过

Init.rc

脚本起来的服务，例如

Service Manger service,Zygote

service,Media service , ril_demon service
等。

Android
服务是指在

JVM

空间完成的服务，虽然也要使用

Navite

上的框架，但是服务主体存在于

Android

空间。

Android

是二阶段初始（

Init2

）初始化时建立的服务。

1 Service
本质结构

我们还是从
Service

的根本意义分析入手，服务的本质就是响应客户端请求。要提供服务，就必须建立接收请求，处理请求，应答客服端的框架。我想在

Android Service

设计者也会无时不刻把这个服务本质框图挂在脑海中。从程序的角度，服务一定要存在一个闭合循环框架

和请求处理框架



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

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

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

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

（4
）概念框架是如何建立的？

2 Service基本框架分析

Android设计中，
Native Service
和
Android Service
采用了同一个闭合循环框架。这个闭合循环框架放置在
Native
的
C++
空间中，
,ProcessState@ProcessState.cpp
和
IPCThreadState@IPCThreadState.cpp

两个类完成了全部工作。



在服务框架中，
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。
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();
}

Init2()@SystemServer.java中建立了
Android
中所有要用到的服务：

Entropy Service
Power Manager
Activity Manager
Telephony Registry
Package Manager
Account Manager
Content Manager
System Content Providers
Battery Service
Hardware Service
Alarm Manager
Init Watchdog
Sensor Service
Window Manager
Bluetooth Service
statusbar
Clipboard Service
Input Method Service
NetStat Service
Connectivity Service
Accessibility Manager
Notification Manager
Mount Service
Device Storage Monitor
Location Manager
Search Service
Checkin Service
Wallpaper Service
Audio Service
Headset Observer
Backup Service
AppWidget Service

3 ProcessState和
IPCThreadState

从宏观来讲，PocessState
及其
IPCThreadState
处于
IPC
与内核打交道包装层。前面的章节已经提到，下面我将更详细的分析。有关
IPC
的
c++
空间的实现都是从
ProcessState
这个对象完成的。



我们可以得出如下的结论：不管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
通讯的基础，那么
Process
必须在
Binder
通讯之前建立。客户端，服务端都必须建立。由于现在重点讨论服务端，所以重心放置在服务端。在
Android
体系中有
c++
空间的服务，
JVM
空间的服务，这两类服务在本质上相同的，只是形式上不同，由于他们都是建立在ＰｒｏｃｅｓｓＳｔａｔｅ这个基础上，所以在形式上不同就仅仅表现在对
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(...)

}
}