|
Android 核心分析 之七------Service深入分析
上一章我們分析了Android IPC架構(gòu),知道了Android服務(wù)構(gòu)建的一些基本理念和原理，本章我們將深入分析Android的服務(wù)。Android體系架構(gòu)中三種意義上服務(wù)：
Native服務(wù)
Android服務(wù)
Init空間的服務(wù)，主要是屬性設(shè)置，這個(gè)ＩＰＣ是利用Ｓｏｃｋｅｔ來完成的，這個(gè)我將在另外一章來討論。
Navite服務(wù)，實(shí)際上就是指完全在C++空間完成的服務(wù)，主要是指系統(tǒng)一開始初始化，通過Init.rc腳本起來的服務(wù)，例如Service Manger service,Zygote service,Media service , ril_demon service等。
Android服務(wù)是指在JVM空間完成的服務(wù)，雖然也要使用Navite上的框架，但是服務(wù)主體存在于Android空間。Android是二階段初始（Init2）初始化時(shí)建立的服務(wù)。
1 Service本質(zhì)結(jié)構(gòu)
我們還是從Service的根本意義分析入手，服務(wù)的本質(zhì)就是響應(yīng)客戶端請(qǐng)求。要提供服務(wù)，就必須建立接收請(qǐng)求，處理請(qǐng)求，應(yīng)答客服端的框架。我想在Android Service設(shè)計(jì)者也會(huì)無時(shí)不刻把這個(gè)服務(wù)本質(zhì)框圖掛在腦海中。從程序的角度，服務(wù)一定要存在一個(gè)閉合循環(huán)框架和請(qǐng)求處理框架
分析清楚服務(wù)框就必須弄清楚以下的機(jī)制及其構(gòu)成。
（1）閉合循環(huán)結(jié)構(gòu)放置在哪里？
（2）處理請(qǐng)求是如何分發(fā)和管理？
（3）處理框架是如何建立的？
（4）概念框架是如何建立的？
2 Service基本框架分析
Android設(shè)計(jì)中，Native Service和Android Service采用了同一個(gè)閉合循環(huán)框架。這個(gè)閉合循環(huán)框架放置在Native的C++空間中，,ProcessState@ProcessState.cpp 和IPCThreadState@IPCThreadState.cpp兩個(gè)類完成了全部工作。
在服務(wù)框架中，ProcessState是公用的部分，這個(gè)公用部分最主要的框架就是閉合循環(huán)框架和接收到從Binder來的請(qǐng)求后的處理框架。我們將服務(wù)框架用ProcessSate來表示,簡言之：
（1） addservice
（2） 建立閉合循環(huán)處理框架。
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();//閉合循環(huán)框架
}
2.1 Native Service
Native Service是在系統(tǒng)Init階段通過Init.rc腳本建立的服務(wù)。
首先來看看一個(gè)例子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();
}
我們將代碼向下展開了一層，更能看到事物的本質(zhì)。
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）服務(wù)進(jìn)程建立了ProcessState對(duì)象，并將給對(duì)象登記在進(jìn)程的上下文中。
（2）建立一個(gè)新AudioFlinger對(duì)象，并將對(duì)象登記Service Manager Service中。
（3）開始就收請(qǐng)求，處理請(qǐng)求，應(yīng)答這個(gè)循環(huán)閉合框架。
2.2 Android Service
Androids service是系統(tǒng)二階段（Init2）初始化時(shí)建立的服務(wù)。
Android的所有服務(wù)循環(huán)框架都是建立SystemServer@(SystemServer.java）上。在SystemServer.java中看不到循環(huán)結(jié)構(gòu)，只是可以看到建立了init2的實(shí)現(xiàn)函數(shù)，建立了一大堆服務(wù)，并AddService到service Manager。
main() @ com/android/server/SystemServer
{
init1();
}
Init1()是在Native空間實(shí)現(xiàn)的（com_andoird_server_systemServer.cpp）。我們一看這個(gè)函數(shù)就知道了，原來這個(gè)閉合循環(huán)處理框架在這里：
init1->system_init() @System_init.cpp
在system_init()我們看到了這個(gè)久違的循環(huán)閉合管理框架。
{
Call "com/android/server/SystemServer", "init2"
…..
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
Init2()@SystemServer.java中建立了Android中所有要用到的服務(wù)：
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與內(nèi)核打交道包裝層。前面的章節(jié)已經(jīng)提到，下面我將更詳細(xì)的分析。有關(guān)IPC的c++空間的實(shí)現(xiàn)都是從ProcessState這個(gè)對(duì)象完成的。
我們可以得出如下的結(jié)論：不管JVM的Binder做了多么復(fù)雜的操作，最終還是需要利用ProcessState 這個(gè)c++空間的對(duì)象把數(shù)據(jù)傳遞給Binder Driver，接收數(shù)據(jù)也是通過ProcessState這個(gè)對(duì)象完成，ProcessState是所有Binder IPC必經(jīng)的通道。
ProcessState放置在全局變量gProcess中，每個(gè)進(jìn)程只有一個(gè)ProcessState對(duì)象，負(fù)責(zé)打開Binder設(shè)備驅(qū)動(dòng)，建立線程池等。而IPCThreadState每個(gè)線程有一個(gè)，IPCThreadState實(shí)例登記在Linux線程程的上下文附屬數(shù)據(jù)中，主要負(fù)責(zé)Binder數(shù)據(jù)讀取，寫入和請(qǐng)求處理框架。IPCThreadSate在構(gòu)造的時(shí)候，獲取進(jìn)程的ProcessSate并記錄在自己的成員變量mProcess中,通過mProcess可以獲取到Binder的句柄。
3.1 ProcessState的生命周期
既然ProcessState是Binder通訊的基礎(chǔ)，那么Process必須在Binder通訊之前建立。客戶端，服務(wù)端都必須建立。由于現(xiàn)在重點(diǎn)討論服務(wù)端，所以重心放置在服務(wù)端。在Android體系中有c++空間的服務(wù)，JVM空間的服務(wù)，這兩類服務(wù)在本質(zhì)上相同的，只是形式上不同，由于他們都是建立在ＰｒｏｃｅｓｓＳｔａｔｅ這個(gè)基礎(chǔ)上，所以在形式上不同就僅僅表現(xiàn)在對(duì)OnTransact的回調(diào)處理的不同。
Native Service
我們直接可以看到使用sp<ProcessState> proc(ProcessState::self())，建立建立ProcessState，一旦調(diào)用ProcessState就建立了，并且這個(gè)self將ProcessSate登記在全局變量中。
Android Service
建立Android Service服務(wù)system_init @System_init.cpp中我們可以看到相同的結(jié)構(gòu)。有一點(diǎn)不同的是所有的Android Service都運(yùn)行在一個(gè)進(jìn)程中：systemsever進(jìn)程。
3.2 Binder Driver包裝 @IPCThreadState
ProcessSate構(gòu)造的時(shí)候，使用open_binder打開/driver/binder，并將句柄記錄在mDriverFD，在ProcessState中并不使用這個(gè)句柄，真正使用這個(gè)Binder設(shè)備句柄的是IPCThreadState，所有關(guān)于Binder的操作放置在IPCThreadState中：
(1)讀取/寫入：talkWithDriver（）@IPCThreadState對(duì)ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)進(jìn)行包裝。
(2)請(qǐng)求處理：executeCommand(...)@ IPCThreadState
(3)循環(huán)結(jié)構(gòu)：joinThreadPool()
joinThreadPool()
{
While(1){
talkWithDriver(...)
...
executeCommand(...)
}
} |