轉載於:http://blog.csdn.net/coding_glacier/article/details/7520199
備註: 該篇文章寫的比較細節化,,,重點話,一些細節問題講解的很透徹明瞭。。。。
1.binder通信概述
binder通信是一種client-server的通信結構,
1.從表面上來看,是client通過獲得一個server的代理接口,對server進行直接調用;
2.實際上,代理接口中定義的方法與server中定義的方法是一一對應的;
3.client調用某個代理接口中的方法時,代理接口的方法會將client傳遞的參數打包成爲Parcel對象;
4.代理接口將該Parcel發送給內核中的binder driver.
5.server會讀取binder driver中的請求數據,如果是發送給自己的,解包Parcel對象,處理並將結果返回;
6.整個的調用過程是一個同步過程,在server處理的時候,client會block住。
2.service manager
Service Manager是一個linux級的進程,顧名思義,就是service的管理器。這裏的service是什麼概念呢?這裏的service的概念和init過程中init.rc中的service是不同,init.rc中的service是都是linux進程,但是這裏的service它並不一定是一個進程,也就是說可能一個或多個service屬於同一個linux進程。在這篇文章中不加特殊說明均指Android native端的service。
任何service在被使用之前,均要向SM(Service Manager)註冊,同時客戶端需要訪問某個service時,應該首先向SM查詢是否存在該服務。如果SM存在這個service,那麼會將該service的handle返回給client,handle是每個service的唯一標識符。
SM的入口函數在service_manager.c中,下面是SM的代碼部分
int main(int argc, char **argv)
{
struct binder_state *bs;
void *svcmgr = BINDER_SERVICE_MANAGER;
bs = binder_open(128*1024);
if (binder_become_context_manager(bs)) {
LOGE("cannot become context manager (%s)/n", strerror(errno));
return -1;
}
svcmgr_handle = svcmgr;
binder_loop(bs, svcmgr_handler);
return 0;
}
這個進程的主要工作如下:
1.初始化binder,打開/dev/binder設備;在內存中爲binder映射128K字節空間;
2.指定SM對應的代理binder的handle爲0,當client嘗試與SM通信時,需要創建一個handle爲0的代理binder,這裏的代理binder其實就是第一節中描述的那個代理接口;
3.通知binder driver(BD)使SM成爲BD的context manager;
4.維護一個死循環,在這個死循環中,不停地去讀內核中binder driver,查看是否有可讀的內容;即是否有對service的操作要求, 如果有,則調用svcmgr_handler回調來處理請求的操作。
5.SM維護了一個svclist列表來存儲service的信息。
這裏需要聲明一下,當service在向SM註冊時,該service就是一個client,而SM則作爲了server。而某個進程需要與service通信時,此時這個進程爲client,service才作爲server。因此service不一定爲server,有時它也是作爲client存在的。
由於下面幾節會介紹一些與binder通信相關的幾個概念,所以將SM的功能介紹放在了後面的部分來講。
應用和service之間的通信會涉及到2次binder通信。
1.應用向SM查詢service是否存在,如果存在獲得該service的代理binder,此爲一次binder通信;
2.應用通過代理binder調用service的方法,此爲第二次binder通信。
3.ProcessState
ProcessState是以單例模式設計的。每個進程在使用binder機制通信時,均需要維護一個ProcessState實例來描述當前進程在binder通信時的binder狀態。
ProcessState有如下2個主要功能:
1.創建一個thread,該線程負責與內核中的binder模塊進行通信,稱該線程爲Pool thread;
2.爲指定的handle創建一個BpBinder對象,並管理該進程中所有的BpBinder對象。
3.1 Pool thread
在Binder IPC中,所有進程均會啓動一個thread來負責與BD來直接通信,也就是不停的讀寫BD,這個線程的實現主體是一個IPCThreadState對象,下面會介紹這個類型。
下面是 Pool thread的啓動方式:
ProcessState::self()->startThreadPool();
3.2 BpBinder獲取
BpBinder主要功能是負責client向BD發送調用請求的數據。它是client端binder通信的核心對象,通過調用transact函數向BD發送調用請求的數據,它的構造函數如下:
BpBinder(int32_t handle);
通過BpBinder的構造函數發現,BpBinder會將當前通信中server的handle記錄下來,當有數據發送時,會通知BD數據的發送目標。
ProcessState通過如下方式來獲取BpBinder對象:
ProcessState::self()->getContextObject(handle);
在這個過程中,ProcessState會維護一個BpBinder的vector mHandleToObject,每當ProcessState創建一個BpBinder的實例時,回去查詢mHandleToObject,如果對應的handle已經有binder指針,那麼不再創建,否則創建binder並插入到mHandleToObject中。
ProcessState創建的BpBinder實例,一般情況下會作爲參數構建一個client端的代理接口,這個代理接口的形式爲BpINTERFACE,例如在與SM通信時,client會創建一個代理接口BpServiceManager.
4.IPCThreadState
IPCThreadState也是以單例模式設計的。由於每個進程只維護了一個ProcessState實例,同時ProcessState只啓動一個Pool thread,也就是說每一個進程只會啓動一個Pool thread,因此每個進程則只需要一個IPCThreadState即可。
Pool thread的實際內容則爲:
IPCThreadState::self()->joinThreadPool();
ProcessState中有2個Parcel成員,mIn和mOut,Pool thread會不停的查詢BD中是否有數據可讀,如果有將其讀出並保存到mIn,同時不停的檢查mOut是否有數據需要向BD發送,如果有,則將其內容寫入到BD中,總而言之,從BD中讀出的數據保存到mIn,待寫入到BD中的數據保存在了mOut中。
ProcessState中生成的BpBinder實例通過調用IPCThreadState的transact函數來向mOut中寫入數據,這樣的話這個binder IPC過程的client端的調用請求的發送過程就明瞭了。
IPCThreadState有兩個重要的函數,talkWithDriver函數負責從BD讀寫數據,executeCommand函數負責解析並執行mIn中的數據。
5.主要基類
5.1基類IInterface
爲server端提供接口,它的子類聲明瞭service能夠實現的所有的方法;
5.2基類IBinder
BBinder與BpBinder均爲IBinder的子類,因此可以看出IBinder定義了binder IPC的通信協議,BBinder與BpBinder在這個協議框架內進行的收和發操作,構建了基本的binder IPC機制。
5.3基類BpRefBase
client端在查詢SM獲得所需的的BpBinder後,BpRefBase負責管理當前獲得的BpBinder實例。
6.兩個接口類
6.1 BpINTERFACE
如果client想要使用binder IPC來通信,那麼首先會從SM出查詢並獲得server端service的BpBinder,在client端,這個對象被認爲是server端的遠程代理。爲了能夠使client能夠想本地調用一樣調用一個遠程server,server端需要向client提供一個接口,client在在這個接口的基礎上創建一個BpINTERFACE,使用這個對象,client的應用能夠想本地調用一樣直接調用server端的方法。而不用去關心具體的binder IPC實現。
下面看一下BpINTERFACE的原型:
class BpINTERFACE : public BpInterface<IINTERFACE>
順着繼承關係再往上看
template<typename INTERFACE>
class BpInterface : public INTERFACE, public BpRefBase
BpINTERFACE分別繼承自INTERFACE,和BpRefBase;
● BpINTERFACE既實現了service中各方法的本地操作,將每個方法的參數以Parcel的形式發送給BD。
例如BpServiceManager的
virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
● 同時又將BpBinder作爲了自己的成員來管理,將BpBinder存儲在mRemote中,BpServiceManager通過調用BpRefBase的remote()來獲得BpBinder指針。
6.2 BnINTERFACE
在定義android native端的service時,每個service均繼承自BnINTERFACE(INTERFACE爲service name)。BnINTERFACE類型定義了一個onTransact函數,這個函數負責解包收到的Parcel並執行client端的請求的方法。
順着BnINTERFACE的繼承關係再往上看,
class BnINTERFACE: public BnInterface<IINTERFACE>
IINTERFACE爲client端的代理接口BpINTERFACE和server端的BnINTERFACE的共同接口類,這個共同接口類的目的就是保證service方法在C-S兩端的一致性。
再往上看
class BnInterface : public INTERFACE, public BBinder
同時我們發現了BBinder類型,這個類型又是幹什麼用的呢?既然每個service均可視爲一個binder,那麼真正的server端的binder的操作及狀態的維護就是通過繼承自BBinder來實現的。可見BBinder是service作爲binder的本質所在。
那麼BBinder與BpBinder的區別又是什麼呢?
其實它們的區別很簡單,BpBinder是client端創建的用於消息發送的代理,而BBinder是server端用於接收消息的通道。查看各自的代碼就會發現,雖然兩個類型均有transact的方法,但是兩者的作用不同,BpBinder的transact方法是向IPCThreadState實例發送消息,通知其有消息要發送給BD;而BBinder則是當IPCThreadState實例收到BD消息時,通過BBinder的transact的方法將其傳遞給它的子類BnSERVICE的onTransact函數執行server端的操作。
7. Parcel
Parcel是binder IPC中的最基本的通信單元,它存儲C-S間函數調用的參數.但是Parcel只能存儲基本的數據類型,如果是複雜的數據類型的話,在存儲時,需要將其拆分爲基本的數據類型來存儲。
簡單的Parcel讀寫不再介紹,下面着重介紹一下2個函數
7.1 writeStrongBinder
當client需要將一個binder向server發送時,可以調用此函數。例如
virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
看一下writeStrongBinder的實體
status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
{
return flatten_binder(ProcessState::self(), val, this);
}
接着往裏看flatten_binder
status_t flatten_binder(const sp<ProcessState>& proc,
const sp<IBinder>& binder, Parcel* out)
{
flat_binder_object obj;
obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
if (binder != NULL) {
IBinder *local = binder->localBinder();
if (!local) {
BpBinder *proxy = binder->remoteBinder();
if (proxy == NULL) {
LOGE("null proxy");
}
const int32_t handle = proxy ? proxy->handle() : 0;
obj.type = BINDER_TYPE_HANDLE;
obj.handle = handle;
obj.cookie = NULL;
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = local->getWeakRefs();
obj.cookie = local;
}
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = NULL;
obj.cookie = NULL;
}
return finish_flatten_binder(binder, obj, out);
}
還是拿addService爲例,它的參數爲一個BnINTERFACE類型指針,BnINTERFACE又繼承自BBinder,
BBinder* BBinder::localBinder()
{
return this;
}
所以寫入到Parcel的binder類型爲BINDER_TYPE_BINDER,同時你在閱讀SM的代碼時會發現如果SM收到的service的binder類型不爲BINDER_TYPE_HANDLE時,SM將不會將此service添加到svclist,但是很顯然每個service的添加都是成功的,addService在開始傳遞的binder類型爲BINDER_TYPE_BINDER,SM收到的binder類型爲BINDER_TYPE_HANDLE,那麼這個過程當中究竟發生了什麼?
爲了搞明白這個問題,花費我很多的事件,最終發現了問題的所在,原來在BD中做了如下操作(drivers/staging/android/Binder.c):
static void binder_transaction(struct binder_proc *proc,
struct binder_thread *thread,
struct binder_transaction_data *tr, int reply)
{
..........................................
if (fp->type == BINDER_TYPE_BINDER)
fp->type = BINDER_TYPE_HANDLE;
else
fp->type = BINDER_TYPE_WEAK_HANDLE;
fp->handle = ref->desc;
..........................................
}
閱讀完addService的代碼,你會發現SM只是保存了service binder的handle和service的name,那麼當client需要和某個service通信了,如何獲得service的binder呢?看下一個函數
7.2 readStrongBinder
當server端收到client的調用請求之後,如果需要返回一個binder時,可以向BD發送這個binder,當IPCThreadState實例收到這個返回的Parcel時,client可以通過這個函數將這個被server返回的binder讀出。
sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}
往裏查看unflatten_binder
status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}
發現如果server返回的binder類型爲BINDER_TYPE_BINDER的話,也就是返回一個binder引用的話,直接獲取這個binder;如果server返回的binder類型爲BINDER_TYPE_HANDLE時,也就是server返回的僅僅是binder的handle,那麼需要重新創建一個BpBinder返回給client。
有上面的代碼可以看出,SM保存的service的binder僅僅是一個handle,而client則是通過向SM獲得這個handle,從而重新構建代理binder與server通信。
這裏順帶提一下一種特殊的情況,binder通信的雙方即可作爲client,也可以作爲server.也就是說此時的binder通信是一個半雙工的通信。那麼在這種情況下,操作的過程會比單工的情況複雜,但是基本的原理是一樣的,有興趣可以分析一下MediaPlayer和MediaPlayerService的例子。
8. 經典橋段分析
main_ mediaserver.cpp
int main(int argc, char** argv)
{
//創建進程mediaserver的ProcessState實例
sp<ProcessState> proc(ProcessState::self());
//獲得SM的BpServiceManager
sp<IServiceManager> sm = defaultServiceManager();
LOGI("ServiceManager: %p", sm.get());
//添加mediaserver中支持的service。
AudioFlinger::instantiate();
MediaPlayerService::instantiate();
CameraService::instantiate();
AudioPolicyService::instantiate();
//啓動ProcessState的pool thread
ProcessState::self()->startThreadPool();
//這一步有重複之嫌,加不加無關緊要。
IPCThreadState::self()->joinThreadPool();
}
9. Java 層的binder機制
瞭解了native通信機制後,再去分析JAVA層的binder機制,就會很好理解了。它只是對native的binder做了一個封裝。這一部分基本上沒有太複雜的過程,這裏不再贅述了。