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

二、詳細(xì)分析
參照網(wǎng)上一些資料（感謝石頭）,，我們也以得到AudioFlinger服務(wù)為例,，詳細(xì)的講述整個(gè)過程。
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ù)就是我們所說的第一步---得到一個(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ù)中通過mmap將/dev/binder文件映射到了一段內(nèi)存,，并將這段內(nèi)存的地址保存下來,，這段內(nèi)存就是IBinder中進(jìn)行數(shù)據(jù)客戶端和服務(wù)端讀寫數(shù)據(jù)的地方
B．ProcessState::self()->getContextObject(NULL)); 通過getStrongProxyForHandle返回一個(gè)BpBinder對(duì)象
C．根據(jù)上面描述，該語句實(shí)際上就是interface_cast<IServiceManager>(BpBinder)
D．在此,，我們有必要關(guān)注一下interface_cast,，通過代碼跟蹤:看到它的實(shí)現(xiàn)
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}
通過模板替換就是:
inline sp< IServiceManager > interface_cast(const sp<IBinder>& obj)
{
return IServiceManager::asInterface(obj);
}
看來在asInterface是IServiceManager的一個(gè)成員函數(shù)，我們打開IServiceManager.cpp/h文件,，我們并沒有發(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);
通過跟蹤這兩個(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（在上面講過它就是一個(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是專門負(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ù)寫到類型為Parcel的mOut容器中去,，方便ServiceManager讀取
waitForResponse等待ServiceManager找到具體的服務(wù)，并把結(jié)果傳回來
查看status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)的實(shí)現(xiàn),，里面調(diào)用了函數(shù)talkWithDriver(),，該函數(shù)通過ioctl將mOut中的數(shù)據(jù)寫到Binder driver中去，同時(shí)等待將返回的數(shù)據(jù)寫入mIn,。此時(shí),，數(shù)據(jù)的發(fā)送就算完成。
再來看看ServiceManager是怎么讀取該數(shù)據(jù)的,，在Service_manager.c中,，調(diào)用了binder_loop(bs, svcmgr_handler)，binder_loop其實(shí)就是一直在等待數(shù)據(jù)的到來,，到來就就從驅(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é)果寫到reply中,然后從reply中就結(jié)果返回給調(diào)用者