IBinder體系中得到一個(gè)服務(wù)的過(guò)程分析：
ServiceManager是管理所有服務(wù)（如音頻，相機(jī)）的一個(gè)進(jìn)程，它的handle是0
一、總的來(lái)說(shuō)：得到一個(gè)service很簡(jiǎn)單，分成兩步，
1，得到一個(gè)默認(rèn)的serviceManager;
2，然后使用serviceManger->getService（service名稱）得到具體的service

二、詳細(xì)分析
參照網(wǎng)上一些資料（感謝石頭），我們也以得到AudioFlinger服務(wù)為例，詳細(xì)的講述整個(gè)過(guò)程。
1，AudioSystem.cpp中有個(gè)函數(shù)const sp<IAudioFlinger>& AudioSystem:: get_audio_flinger()，顧名思義，該函數(shù)的功能是得到AudioFlinger服務(wù)
2，查看該函數(shù)的實(shí)現(xiàn)，首先我們看到了一個(gè)函數(shù)調(diào)用：
sp<IServiceManager> sm = defaultServiceManager();
該函數(shù)就是我們所說(shuō)的第一步---得到一個(gè)默認(rèn)的serviceManager;
defaultServiceManager()的實(shí)現(xiàn)如下：
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL)
return gDefaultServiceManager;

{
AutoMutex _l(gDefaultServiceManagerLock);
if (gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));
}
}

return gDefaultServiceManager;
}

重點(diǎn)分析gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));
A．ProcessState::self()得到一個(gè)ProcessState的實(shí)例，在它的構(gòu)造函數(shù)中通過(guò)mmap將/dev/binder文件映射到了一段內(nèi)存，并將這段內(nèi)存的地址保存下來(lái)，這段內(nèi)存就是IBinder中進(jìn)行數(shù)據(jù)客戶端和服務(wù)端讀寫(xiě)數(shù)據(jù)的地方
B．ProcessState::self()->getContextObject(NULL)); 通過(guò)getStrongProxyForHandle返回一個(gè)BpBinder對(duì)象
C．根據(jù)上面描述，該語(yǔ)句實(shí)際上就是interface_cast<IServiceManager>(BpBinder)
D．在此，我們有必要關(guān)注一下interface_cast，通過(guò)代碼跟蹤:看到它的實(shí)現(xiàn)
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}
通過(guò)模板替換就是:
inline sp< IServiceManager > interface_cast(const sp<IBinder>& obj)
{
return IServiceManager::asInterface(obj);
}
看來(lái)在asInterface是IServiceManager的一個(gè)成員函數(shù)，我們打開(kāi)IServiceManager.cpp/h文件，我們并沒(méi)有發(fā)現(xiàn)該函數(shù)，那它到底在哪兒呢，仔細(xì)觀察IServiceManager.cpp，發(fā)現(xiàn)里面有個(gè)
IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");
在IServiceManager.h里面發(fā)現(xiàn)了
DECLARE_META_INTERFACE(ServiceManager);
通過(guò)跟蹤這兩個(gè)宏發(fā)現(xiàn)DECLARE_META_INTERFACE聲明了一個(gè)變量和兩個(gè)函數(shù)，代碼如下：
#define DECLARE_META_INTERFACE(INTERFACE)                  \
static const String16 descriptor;                                   \
static sp<I##INTERFACE> asInterface(const sp<IBinder>& obj);        \
virtual String16 getInterfaceDescriptor() const;                    \

IMPLEMENT_META_INTERFACE這個(gè)宏是對(duì)上面聲明的實(shí)現(xiàn)
#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME)         \
const String16 I##INTERFACE::descriptor(NAME);                  \
String16 I##INTERFACE::getInterfaceDescriptor() const {             \
return I##INTERFACE::descriptor;                          \
}                                                       \
sp<I##INTERFACE> I##INTERFACE::asInterface(const sp<IBinder>& obj)  \
{                                                    \
sp<I##INTERFACE> intr;                                \
if (obj != NULL) {                                       \
intr = static_cast<I##INTERFACE*>(                     \
obj->queryLocalInterface(                         \
I##INTERFACE::descriptor).get());         \
if (intr == NULL) {                                    \
intr = new Bp##INTERFACE(obj);                \
}                                                \
}                                             \
return intr;                                      \
}                                                   \
interface_cast<IServiceManager>實(shí)際上返回了一個(gè)BpServiceManager，在創(chuàng)建一個(gè)BpServiceManager時(shí)，有些細(xì)節(jié)還是需要注意：
BpServiceManager(const sp<IBinder>& impl): BpInterface<IServiceManager>(impl){}
BpInterface<IServiceManager>(impl)中的impl實(shí)際就是一個(gè)BpBinder，它調(diào)用了BpInterface的構(gòu)造函數(shù)，然后調(diào)用了BpRefBase(remote)，從而把一個(gè)BpBinder賦值給了mRemote，這個(gè)變量會(huì)在后面?zhèn)鬏數(shù)臅r(shí)候用到

3，AudioSystem.cpp文件中緊接著就執(zhí)行了 binder = sm->getService(String16("media.audio_flinger")); //參數(shù)是服務(wù)名稱
我們知道了sm就是一個(gè)BpServiceManager，可以在BpServiceManager類中看到getService的實(shí)現(xiàn)，它調(diào)用了checkService，checkService先將數(shù)據(jù)打包成Parcel格式，然后調(diào)用remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);進(jìn)行傳輸，remote()是BpServiceManager父類BpRefBase的一個(gè)成員函數(shù)，作用是返回mRemote（在上面講過(guò)它就是一個(gè)BpBinder），那么我們就去BpBinder.cpp中去尋找transact的實(shí)現(xiàn)，代碼如下：
status_t BpBinder::transact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
// Once a binder has died, it will never come back to life.
if (mAlive) {
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}

return DEAD_OBJECT;
}
IPCThreadState是專門(mén)負(fù)責(zé)進(jìn)程間通訊的，包括進(jìn)程間的數(shù)據(jù)傳輸，查看IPCThreadState::self()->transact(mHandle, code, data, reply, flags)的實(shí)現(xiàn)，提取兩行和我們相關(guān)的代碼
………………..
Err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
……………………….
err = waitForResponse(reply);
writeTransactionData的作用是把數(shù)據(jù)寫(xiě)到類型為Parcel的mOut容器中去，方便ServiceManager讀取
waitForResponse等待ServiceManager找到具體的服務(wù)，并把結(jié)果傳回來(lái)
查看status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)的實(shí)現(xiàn)，里面調(diào)用了函數(shù)talkWithDriver()，該函數(shù)通過(guò)ioctl將mOut中的數(shù)據(jù)寫(xiě)到Binder driver中去，同時(shí)等待將返回的數(shù)據(jù)寫(xiě)入mIn。此時(shí)，數(shù)據(jù)的發(fā)送就算完成。
再來(lái)看看ServiceManager是怎么讀取該數(shù)據(jù)的，在Service_manager.c中，調(diào)用了binder_loop(bs, svcmgr_handler)，binder_loop其實(shí)就是一直在等待數(shù)據(jù)的到來(lái)，到來(lái)就就從驅(qū)動(dòng)中讀取數(shù)據(jù)，然后調(diào)用binder_parser解析，在binder_parser中
case BR_TRANSACTION:
…………………..
res = func(bs, txn, &msg, &reply);//這里的func就是svcmgr_handler
binder_send_reply(bs, &reply, txn->data, res); //將結(jié)果返回到Binder driver中
svcmgr_handler在getService的情況下，就是從服務(wù)鏈表中根據(jù)名稱找到對(duì)應(yīng)的服務(wù)的節(jié)點(diǎn)，然后轉(zhuǎn)化成binder_object的格式后返回回去
waitForResponse中將返回結(jié)果寫(xiě)到reply中,然后從reply中就結(jié)果返回給調(diào)用者