life02

Android 核心分析 之七------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(...)

}

}