Binder学习指南
毫不夸張地說，Binder是Android系統(tǒng)中最重要的特性之一；正如其名“粘合劑”所喻，它是系統(tǒng)間各個(gè)組件的橋梁，Android系統(tǒng)的開放式設(shè)計(jì)也很大程度上得益于這種及其方便的跨進(jìn)程通信機(jī)制。
理解Binder對(duì)于理解整個(gè)Android系統(tǒng)有著非常重要的作用，Android系統(tǒng)的四大組件，AMS，PMS等系統(tǒng)服務(wù)無一不與Binder掛鉤；如果對(duì)Binder不甚了解，那么就很難了解這些系統(tǒng)機(jī)制，從而僅僅浮游與表面，不懂Binder你都不好意思說自己會(huì)Android開發(fā)；要深入Android，Binder是必須邁出的一步。
現(xiàn)在網(wǎng)上有不少資料介紹Binder，個(gè)人覺得最好的兩篇如下：
其中, 《Binder設(shè)計(jì)與實(shí)現(xiàn)》以一種宏觀的角度解釋了Android系統(tǒng)中的Binder機(jī)制，文章如行云流水；如果對(duì)于Binder有一定的了解再來看著篇文章，有一種打通任督二脈的感覺；每看一次理解就深一層。老羅的系列文章則從系統(tǒng)源碼角度深入分析了Binder的實(shí)現(xiàn)細(xì)節(jié)；具有很大的參考意義；每當(dāng)對(duì)于Binder細(xì)節(jié)有疑惑，看一看他的書就迎刃而解。
但是遺憾的是，Binder機(jī)制終究不是三言兩語就能解釋清楚的，一上來就扒出源碼很可能深陷細(xì)節(jié)無法自拔，老羅的文章那不是一般的長，如果看不懂強(qiáng)行看很容易睡著；勉強(qiáng)看完還是云里霧里；相反如果直接大談特談Binder的設(shè)計(jì)，那么完全就是不知所云；因此上述兩篇文章對(duì)于初學(xué)者并不友好，本文不會(huì)深入源碼細(xì)節(jié)，也不會(huì)對(duì)于Binder的設(shè)計(jì)高談闊論；重點(diǎn)如下：
讀完本文，你應(yīng)該對(duì)于Java層的AIDL了如指掌，對(duì)于Binder也會(huì)有一個(gè)大體上的認(rèn)識(shí)；再深入學(xué)習(xí)就得靠自己了，本人推薦的Binder學(xué)習(xí)路徑如下：
背景知識(shí)
為了理解Binder我們先澄清一些概念。為什么需要跨進(jìn)程通信（IPC），怎么做到跨進(jìn)程通信？為什么是Binder？
由于Android系統(tǒng)基于Linux內(nèi)核，因此有必要了解相關(guān)知識(shí)。
進(jìn)程隔離
進(jìn)程隔離是為保護(hù)操作系統(tǒng)中進(jìn)程互不干擾而設(shè)計(jì)的一組不同硬件和軟件的技術(shù)。這個(gè)技術(shù)是為了避免進(jìn)程A寫入進(jìn)程B的情況發(fā)生。 進(jìn)程的隔離實(shí)現(xiàn)，使用了虛擬地址空間。進(jìn)程A的虛擬地址和進(jìn)程B的虛擬地址不同，這樣就防止進(jìn)程A將數(shù)據(jù)信息寫入進(jìn)程B。
以上來自維基百科；操作系統(tǒng)的不同進(jìn)程之間，數(shù)據(jù)不共享；對(duì)于每個(gè)進(jìn)程來說，它都天真地以為自己獨(dú)享了整個(gè)系統(tǒng)，完全不知道其他進(jìn)程的存在；(有關(guān)虛擬地址，請自行查閱）因此一個(gè)進(jìn)程需要與另外一個(gè)進(jìn)程通信，需要某種系統(tǒng)機(jī)制才能完成。
用戶空間/內(nèi)核空間
詳細(xì)解釋可以參考Kernel Space Definition；簡單理解如下：
Linux Kernel是操作系統(tǒng)的核心，獨(dú)立于普通的應(yīng)用程序，可以訪問受保護(hù)的內(nèi)存空間，也有訪問底層硬件設(shè)備的所有權(quán)限。
對(duì)于Kernel這么一個(gè)高安全級(jí)別的東西，顯然是不容許其它的應(yīng)用程序隨便調(diào)用或訪問的，所以需要對(duì)Kernel提供一定的保護(hù)機(jī)制，這個(gè)保護(hù)機(jī)制用來告訴那些應(yīng)用程序，你只可以訪問某些許可的資源，不許可的資源是拒絕被訪問的，于是就把Kernel和上層的應(yīng)用程序抽像的隔離開，分別稱之為Kernel Space和User Space。
系統(tǒng)調(diào)用/內(nèi)核態(tài)/用戶態(tài)
雖然從邏輯上抽離出用戶空間和內(nèi)核空間；但是不可避免的的是，總有那么一些用戶空間需要訪問內(nèi)核的資源；比如應(yīng)用程序訪問文件，網(wǎng)絡(luò)是很常見的事情，怎么辦呢？
Kernel space can be accessed by user processes only through the use of system calls.
用戶空間訪問內(nèi)核空間的唯一方式就是系統(tǒng)調(diào)用；通過這個(gè)統(tǒng)一入口接口，所有的資源訪問都是在內(nèi)核的控制下執(zhí)行，以免導(dǎo)致對(duì)用戶程序?qū)ο到y(tǒng)資源的越權(quán)訪問，從而保障了系統(tǒng)的安全和穩(wěn)定。用戶軟件良莠不齊，要是它們亂搞把系統(tǒng)玩壞了怎么辦？因此對(duì)于某些特權(quán)操作必須交給安全可靠的內(nèi)核來執(zhí)行。
當(dāng)一個(gè)任務(wù)（進(jìn)程）執(zhí)行系統(tǒng)調(diào)用而陷入內(nèi)核代碼中執(zhí)行時(shí)，我們就稱進(jìn)程處于內(nèi)核運(yùn)行態(tài)（或簡稱為內(nèi)核態(tài)）此時(shí)處理器處于特權(quán)級(jí)最高的（0級(jí)）內(nèi)核代碼中執(zhí)行。當(dāng)進(jìn)程在執(zhí)行用戶自己的代碼時(shí)，則稱其處于用戶運(yùn)行態(tài)（用戶態(tài)）。即此時(shí)處理器在特權(quán)級(jí)最低的（3級(jí)）用戶代碼中運(yùn)行。處理器在特權(quán)等級(jí)高的時(shí)候才能執(zhí)行那些特權(quán)CPU指令。
內(nèi)核模塊/驅(qū)動(dòng)
通過系統(tǒng)調(diào)用，用戶空間可以訪問內(nèi)核空間，那么如果一個(gè)用戶空間想與另外一個(gè)用戶空間進(jìn)行通信怎么辦呢？很自然想到的是讓操作系統(tǒng)內(nèi)核添加支持；傳統(tǒng)的Linux通信機(jī)制，比如Socket，管道等都是內(nèi)核支持的；但是Binder并不是Linux內(nèi)核的一部分，它是怎么做到訪問內(nèi)核空間的呢？Linux的動(dòng)態(tài)可加載內(nèi)核模塊（Loadable Kernel Module，LKM）機(jī)制解決了這個(gè)問題；模塊是具有獨(dú)立功能的程序，它可以被單獨(dú)編譯，但不能獨(dú)立運(yùn)行。它在運(yùn)行時(shí)被鏈接到內(nèi)核作為內(nèi)核的一部分在內(nèi)核空間運(yùn)行。這樣，Android系統(tǒng)可以通過添加一個(gè)內(nèi)核模塊運(yùn)行在內(nèi)核空間，用戶進(jìn)程之間的通過這個(gè)模塊作為橋梁，就可以完成通信了。
在Android系統(tǒng)中，這個(gè)運(yùn)行在內(nèi)核空間的，負(fù)責(zé)各個(gè)用戶進(jìn)程通過Binder通信的內(nèi)核模塊叫做Binder驅(qū)動(dòng);
驅(qū)動(dòng)程序一般指的是設(shè)備驅(qū)動(dòng)程序（Device Driver），是一種可以使計(jì)算機(jī)和設(shè)備通信的特殊程序。相當(dāng)于硬件的接口，操作系統(tǒng)只有通過這個(gè)接口，才能控制硬件設(shè)備的工作；
驅(qū)動(dòng)就是操作硬件的接口，為了支持Binder通信過程，Binder使用了一種“硬件”，因此這個(gè)模塊被稱之為驅(qū)動(dòng)。
好了，說了這么多枯燥的概念，看張美圖緩解一下。
為什么使用Binder？
Android使用的Linux內(nèi)核擁有著非常多的跨進(jìn)程通信機(jī)制，比如管道，System V，Socket等；為什么還需要單獨(dú)搞一個(gè)Binder出來呢？主要有兩點(diǎn)，性能和安全。在移動(dòng)設(shè)備上，廣泛地使用跨進(jìn)程通信肯定對(duì)通信機(jī)制本身提出了嚴(yán)格的要求；Binder相對(duì)出傳統(tǒng)的Socket方式，更加高效；另外，傳統(tǒng)的進(jìn)程通信方式對(duì)于通信雙方的身份并沒有做出嚴(yán)格的驗(yàn)證，只有在上層協(xié)議上進(jìn)行架設(shè)；比如Socket通信ip地址是客戶端手動(dòng)填入的，都可以進(jìn)行偽造；而Binder機(jī)制從協(xié)議本身就支持對(duì)通信雙方做身份校檢，因而大大提升了安全性。這個(gè)也是Android權(quán)限模型的基礎(chǔ)。
Binder通信模型
對(duì)于跨進(jìn)程通信的雙方，我們姑且叫做Server進(jìn)程（簡稱Server），Client進(jìn)程（簡稱Client）；由于進(jìn)程隔離的存在，它們之間沒辦法通過簡單的方式進(jìn)行通信，那么Binder機(jī)制是如何進(jìn)行的呢？
回想一下日常生活中我們通信的過程：假設(shè)A和B要進(jìn)行通信，通信的媒介是打電話（A是Client，B是Server）；A要給B打電話，必須知道B的號(hào)碼，這個(gè)號(hào)碼怎么獲取呢？通信錄.
這個(gè)通信錄就是一張表；內(nèi)容大致是：
| 1 2 | B -> 12345676 C -> 12334354 |
先查閱通信錄，拿到B的號(hào)碼；才能進(jìn)行通信；否則，怎么知道應(yīng)該撥什么號(hào)碼？回想一下古老的電話機(jī)，如果A要給B打電話，必須先連接通話中心，說明給我接通B的電話；這時(shí)候通話中心幫他呼叫B；連接建立，就完成了通信。
另外，光有電話和通信錄是不可能完成通信的，沒有基站支持；信息根本無法傳達(dá)。
我們看到，一次電話通信的過程除了通信的雙方還有兩個(gè)隱藏角色：通信錄和基站。Binder通信機(jī)制也是一樣：兩個(gè)運(yùn)行在用戶空間的進(jìn)程要完成通信，必須借助內(nèi)核的幫助，這個(gè)運(yùn)行在內(nèi)核里面的程序叫做Binder驅(qū)動(dòng)，它的功能類似于基站；通信錄呢，就是一個(gè)叫做ServiceManager的東西（簡稱SM）
OK，Binder的通信模型就是這么簡單，如下圖：
整個(gè)通信步驟如下：
那么Binder驅(qū)動(dòng)干什么去了呢？這里Client與SM的通信，以及Client與Server的通信，都會(huì)經(jīng)過驅(qū)動(dòng)，驅(qū)動(dòng)在背后默默無聞，但是做著最重要的工作。驅(qū)動(dòng)是整個(gè)通信過程的核心，因此完成跨進(jìn)程通信的秘密全部隱藏在驅(qū)動(dòng)里面；這個(gè)我們稍后討論。
OK，上面就是整個(gè)Binder通信的基本模型；做了一個(gè)簡單的類比，當(dāng)然也有一些不恰當(dāng)?shù)牡胤?#xff0c;(比如通信錄現(xiàn)實(shí)中每個(gè)人都有一個(gè)，但是SM整個(gè)系統(tǒng)只有一個(gè)；基站也有很多個(gè)，但是驅(qū)動(dòng)只有一個(gè)）；但是整體上就是這樣的；我們看到其實(shí)整個(gè)通信模型非常簡單。
Binder機(jī)制跨進(jìn)程原理
上文給出了Binder的通信模型，指出了通信過程的四個(gè)角色: Client, Server, SM, driver; 但是我們?nèi)匀徊磺宄?strong>Client到底是如何與Server完成通信的。
兩個(gè)運(yùn)行在用戶空間的進(jìn)程A和進(jìn)程B如何完成通信呢？內(nèi)核可以訪問A和B的所有數(shù)據(jù)；所以，最簡單的方式是通過內(nèi)核做中轉(zhuǎn)；假設(shè)進(jìn)程A要給進(jìn)程B發(fā)送數(shù)據(jù)，那么就先把A的數(shù)據(jù)copy到內(nèi)核空間，然后把內(nèi)核空間對(duì)應(yīng)的數(shù)據(jù)copy到B就完成了；用戶空間要操作內(nèi)核空間，需要通過系統(tǒng)調(diào)用；剛好，這里就有兩個(gè)系統(tǒng)調(diào)用：copy_from_user,?copy_to_user。
但是，Binder機(jī)制并不是這么干的。講這么一段，是說明進(jìn)程間通信并不是什么神秘的東西。那么，Binder機(jī)制是如何實(shí)現(xiàn)跨進(jìn)程通信的呢？
Binder驅(qū)動(dòng)為我們做了一切。
假設(shè)Client進(jìn)程想要調(diào)用Server進(jìn)程的object對(duì)象的一個(gè)方法add;對(duì)于這個(gè)跨進(jìn)程通信過程，我們來看看Binder機(jī)制是如何做的。 （通信是一個(gè)廣泛的概念，只要一個(gè)進(jìn)程能調(diào)用另外一個(gè)進(jìn)程里面某對(duì)象的方法，那么具體要完成什么通信內(nèi)容就很容易了。）
Alt text
首先，Server進(jìn)程要向SM注冊；告訴自己是誰，自己有什么能力；在這個(gè)場景就是Server告訴SM，它叫zhangsan，它有一個(gè)object對(duì)象，可以執(zhí)行add?操作；于是SM建立了一張表：zhangsan這個(gè)名字對(duì)應(yīng)進(jìn)程Server;
然后Client向SM查詢：我需要聯(lián)系一個(gè)名字叫做zhangsan的進(jìn)程里面的object對(duì)象；這時(shí)候關(guān)鍵來了：進(jìn)程之間通信的數(shù)據(jù)都會(huì)經(jīng)過運(yùn)行在內(nèi)核空間里面的驅(qū)動(dòng)，驅(qū)動(dòng)在數(shù)據(jù)流過的時(shí)候做了一點(diǎn)手腳，它并不會(huì)給Client進(jìn)程返回一個(gè)真正的object對(duì)象，而是返回一個(gè)看起來跟object一模一樣的代理對(duì)象objectProxy，這個(gè)objectProxy也有一個(gè)add方法，但是這個(gè)add方法沒有Server進(jìn)程里面object對(duì)象的add方法那個(gè)能力；objectProxy的add只是一個(gè)傀儡，它唯一做的事情就是把參數(shù)包裝然后交給驅(qū)動(dòng)。(這里我們簡化了SM的流程，見下文)
但是Client進(jìn)程并不知道驅(qū)動(dòng)返回給它的對(duì)象動(dòng)過手腳，畢竟偽裝的太像了，如假包換。Client開開心心地拿著objectProxy對(duì)象然后調(diào)用add方法；我們說過，這個(gè)add什么也不做，直接把參數(shù)做一些包裝然后直接轉(zhuǎn)發(fā)給Binder驅(qū)動(dòng)。
驅(qū)動(dòng)收到這個(gè)消息，發(fā)現(xiàn)是這個(gè)objectProxy；一查表就明白了：我之前用objectProxy替換了object發(fā)送給Client了，它真正應(yīng)該要訪問的是object對(duì)象的add方法；于是Binder驅(qū)動(dòng)通知Server進(jìn)程，調(diào)用你的object對(duì)象的add方法，然后把結(jié)果發(fā)給我，Sever進(jìn)程收到這個(gè)消息，照做之后將結(jié)果返回驅(qū)動(dòng)，驅(qū)動(dòng)然后把結(jié)果返回給Client進(jìn)程；于是整個(gè)過程就完成了。
由于驅(qū)動(dòng)返回的objectProxy與Server進(jìn)程里面原始的object是如此相似，給人感覺好像是直接把Server進(jìn)程里面的對(duì)象object傳遞到了Client進(jìn)程；因此，我們可以說Binder對(duì)象是可以進(jìn)行跨進(jìn)程傳遞的對(duì)象
但事實(shí)上我們知道，Binder跨進(jìn)程傳輸并不是真的把一個(gè)對(duì)象傳輸?shù)搅肆硗庖粋€(gè)進(jìn)程；傳輸過程好像是Binder跨進(jìn)程穿越的時(shí)候，它在一個(gè)進(jìn)程留下了一個(gè)真身，在另外一個(gè)進(jìn)程幻化出一個(gè)影子（這個(gè)影子可以很多個(gè)）；Client進(jìn)程的操作其實(shí)是對(duì)于影子的操作，影子利用Binder驅(qū)動(dòng)最終讓真身完成操作。
理解這一點(diǎn)非常重要；務(wù)必仔細(xì)體會(huì)。另外，Android系統(tǒng)實(shí)現(xiàn)這種機(jī)制使用的是代理模式, 對(duì)于Binder的訪問，如果是在同一個(gè)進(jìn)程（不需要跨進(jìn)程），那么直接返回原始的Binder實(shí)體；如果在不同進(jìn)程，那么就給他一個(gè)代理對(duì)象（影子）；我們在系統(tǒng)源碼以及AIDL的生成代碼里面可以看到很多這種實(shí)現(xiàn)。
另外我們?yōu)榱撕喕麄€(gè)流程，隱藏了SM這一部分驅(qū)動(dòng)進(jìn)行的操作；實(shí)際上，由于SM與Server通常不在一個(gè)進(jìn)程，Server進(jìn)程向SM注冊的過程也是跨進(jìn)程通信，驅(qū)動(dòng)也會(huì)對(duì)這個(gè)過程進(jìn)行暗箱操作：SM中存在的Server端的對(duì)象實(shí)際上也是代理對(duì)象，后面Client向SM查詢的時(shí)候，驅(qū)動(dòng)會(huì)給Client返回另外一個(gè)代理對(duì)象。Sever進(jìn)程的本地對(duì)象僅有一個(gè)，其他進(jìn)程所擁有的全部都是它的代理。
一句話總結(jié)就是：Client進(jìn)程只不過是持有了Server端的代理；代理對(duì)象協(xié)助驅(qū)動(dòng)完成了跨進(jìn)程通信。
OK，該休息一下了。
Binder到底是什么？
我們經(jīng)常提到Binder，那么Binder到底是什么呢？
Binder的設(shè)計(jì)采用了面向?qū)ο蟮乃枷?#xff0c;在Binder通信模型的四個(gè)角色里面；他們的代表都是“Binder”，這樣，對(duì)于Binder通信的使用者而言，Server里面的Binder和Client里面的Binder沒有什么不同，一個(gè)Binder對(duì)象就代表了所有，它不用關(guān)心實(shí)現(xiàn)的細(xì)節(jié)，甚至不用關(guān)心驅(qū)動(dòng)以及SM的存在；這就是抽象。
- 通常意義下，Binder指的是一種通信機(jī)制；我們說AIDL使用Binder進(jìn)行通信，指的就是Binder這種IPC機(jī)制。
- 對(duì)于Server進(jìn)程來說，Binder指的是Binder本地對(duì)象
- 對(duì)于Client來說，Binder指的是Binder代理對(duì)象，它只是Binder本地對(duì)象的一個(gè)遠(yuǎn)程代理；對(duì)這個(gè)Binder代理對(duì)象的操作，會(huì)通過驅(qū)動(dòng)最終轉(zhuǎn)發(fā)到Binder本地對(duì)象上去完成；對(duì)于一個(gè)擁有Binder對(duì)象的使用者而言，它無須關(guān)心這是一個(gè)Binder代理對(duì)象還是Binder本地對(duì)象；對(duì)于代理對(duì)象的操作和對(duì)本地對(duì)象的操作對(duì)它來說沒有區(qū)別。
- 對(duì)于傳輸過程而言，Binder是可以進(jìn)行跨進(jìn)程傳遞的對(duì)象；Binder驅(qū)動(dòng)會(huì)對(duì)具有跨進(jìn)程傳遞能力的對(duì)象做特殊處理：自動(dòng)完成代理對(duì)象和本地對(duì)象的轉(zhuǎn)換。
面向?qū)ο笏枷氲囊雽⑦M(jìn)程間通信轉(zhuǎn)化為通過對(duì)某個(gè)Binder對(duì)象的引用調(diào)用該對(duì)象的方法，而其獨(dú)特之處在于Binder對(duì)象是一個(gè)可以跨進(jìn)程引用的對(duì)象，它的實(shí)體（本地對(duì)象）位于一個(gè)進(jìn)程中，而它的引用（代理對(duì)象）卻遍布于系統(tǒng)的各個(gè)進(jìn)程之中。最誘人的是，這個(gè)引用和java里引用一樣既可以是強(qiáng)類型，也可以是弱類型，而且可以從一個(gè)進(jìn)程傳給其它進(jìn)程，讓大家都能訪問同一Server，就象將一個(gè)對(duì)象或引用賦值給另一個(gè)引用一樣。Binder模糊了進(jìn)程邊界，淡化了進(jìn)程間通信過程，整個(gè)系統(tǒng)仿佛運(yùn)行于同一個(gè)面向?qū)ο蟮某绦蛑小Ｐ涡紊腂inder對(duì)象以及星羅棋布的引用仿佛粘接各個(gè)應(yīng)用程序的膠水，這也是Binder在英文里的原意。
驅(qū)動(dòng)里面的Binder
我們現(xiàn)在知道，Server進(jìn)程里面的Binder對(duì)象指的是Binder本地對(duì)象，Client里面的對(duì)象值得是Binder代理對(duì)象；在Binder對(duì)象進(jìn)行跨進(jìn)程傳遞的時(shí)候，Binder驅(qū)動(dòng)會(huì)自動(dòng)完成這兩種類型的轉(zhuǎn)換；因此Binder驅(qū)動(dòng)必然保存了每一個(gè)跨越進(jìn)程的Binder對(duì)象的相關(guān)信息；在驅(qū)動(dòng)中，Binder本地對(duì)象的代表是一個(gè)叫做binder_node的數(shù)據(jù)結(jié)構(gòu)，Binder代理對(duì)象是用binder_ref代表的；有的地方把Binder本地對(duì)象直接稱作Binder實(shí)體，把Binder代理對(duì)象直接稱作Binder引用（句柄），其實(shí)指的是Binder對(duì)象在驅(qū)動(dòng)里面的表現(xiàn)形式；讀者明白意思即可。
OK，現(xiàn)在大致了解Binder的通信模型，也了解了Binder這個(gè)對(duì)象在通信過程中各個(gè)組件里面到底表示的是什么。
深入理解Java層的Binder
IBinder/IInterface/Binder/BinderProxy/Stub
我們使用AIDL接口的時(shí)候，經(jīng)常會(huì)接觸到這些類，那么這每個(gè)類代表的是什么呢？
- IBinder是一個(gè)接口，它代表了一種跨進(jìn)程傳輸?shù)哪芰?/strong>；只要實(shí)現(xiàn)了這個(gè)接口，就能將這個(gè)對(duì)象進(jìn)行跨進(jìn)程傳遞；這是驅(qū)動(dòng)底層支持的；在跨進(jìn)程數(shù)據(jù)流經(jīng)驅(qū)動(dòng)的時(shí)候，驅(qū)動(dòng)會(huì)識(shí)別IBinder類型的數(shù)據(jù)，從而自動(dòng)完成不同進(jìn)程Binder本地對(duì)象以及Binder代理對(duì)象的轉(zhuǎn)換。
- IBinder負(fù)責(zé)數(shù)據(jù)傳輸，那么client與server端的調(diào)用契約（這里不用接口避免混淆）呢？這里的IInterface代表的就是遠(yuǎn)程server對(duì)象具有什么能力。具體來說，就是aidl里面的接口。
- Java層的Binder類，代表的其實(shí)就是Binder本地對(duì)象。BinderProxy類是Binder類的一個(gè)內(nèi)部類，它代表遠(yuǎn)程進(jìn)程的Binder對(duì)象的本地代理；這兩個(gè)類都繼承自IBinder, 因而都具有跨進(jìn)程傳輸?shù)哪芰?#xff1b;實(shí)際上，在跨越進(jìn)程的時(shí)候，Binder驅(qū)動(dòng)會(huì)自動(dòng)完成這兩個(gè)對(duì)象的轉(zhuǎn)換。
- 在使用AIDL的時(shí)候，編譯工具會(huì)給我們生成一個(gè)Stub的靜態(tài)內(nèi)部類；這個(gè)類繼承了Binder, 說明它是一個(gè)Binder本地對(duì)象，它實(shí)現(xiàn)了IInterface接口，表明它具有遠(yuǎn)程Server承諾給Client的能力；Stub是一個(gè)抽象類，具體的IInterface的相關(guān)實(shí)現(xiàn)需要我們手動(dòng)完成，這里使用了策略模式。
AIDL過程分析
現(xiàn)在我們通過一個(gè)AIDL的使用，分析一下整個(gè)通信過程中，各個(gè)角色到底做了什么，AIDL到底是如何完成通信的。（如果你連AIDL都不熟悉，請先查閱官方文檔）
首先定一個(gè)一個(gè)簡單的aidl接口：
| 1 2 3 4 5 | // ICompute.aidl package com.example.test.app; interface ICompute { int add(int a, int b); } |
然后用編譯工具編譯之后，可以得到對(duì)應(yīng)的ICompute.java類，看看系統(tǒng)給我們生成的代碼：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 | package com.example.test.app; public interface ICompute extends android.os.IInterface { /** * Local-side IPC implementation stub class. */ public static abstract class Stub extends android.os.Binder implements com.example.test.app.ICompute { private static final java.lang.String DESCRIPTOR = "com.example.test.app.ICompute"; /** * Construct the stub at attach it to the interface. */ public Stub() { this.attachInterface(this, DESCRIPTOR); } /** * Cast an IBinder object into an com.example.test.app.ICompute interface, * generating a proxy if needed. */ public static com.example.test.app.ICompute asInterface(android.os.IBinder obj) { if ((obj == null)) { return null; } android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) && (iin instanceof com.example.test.app.ICompute))) { return ((com.example.test.app.ICompute) iin); } return new com.example.test.app.ICompute.Stub.Proxy(obj); } @Override public android.os.IBinder asBinder() { return this; } @Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { switch (code) { case INTERFACE_TRANSACTION: { reply.writeString(DESCRIPTOR); return true; } case TRANSACTION_add: { data.enforceInterface(DESCRIPTOR); int _arg0; _arg0 = data.readInt(); int _arg1; _arg1 = data.readInt(); int _result = this.add(_arg0, _arg1); reply.writeNoException(); reply.writeInt(_result); return true; } } return super.onTransact(code, data, reply, flags); } private static class Proxy implements com.example.test.app.ICompute { private android.os.IBinder mRemote; Proxy(android.os.IBinder remote) { mRemote = remote; } @Override public android.os.IBinder asBinder() { return mRemote; } public java.lang.String getInterfaceDescriptor() { return DESCRIPTOR; } /** * Demonstrates some basic types that you can use as parameters * and return values in AIDL. */ @Override public int add(int a, int b) throws android.os.RemoteException { android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); int _result; try { _data.writeInterfaceToken(DESCRIPTOR); _data.writeInt(a); _data.writeInt(b); mRemote.transact(Stub.TRANSACTION_add, _data, _reply, 0); _reply.readException(); _result = _reply.readInt(); } finally { _reply.recycle(); _data.recycle(); } return _result; } } static final int TRANSACTION_add = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0); } /** * Demonstrates some basic types that you can use as parameters * and return values in AIDL. */ public int add(int a, int b) throws android.os.RemoteException; } |
系統(tǒng)幫我們生成了這個(gè)文件之后，我們只需要繼承ICompute.Stub這個(gè)抽象類，實(shí)現(xiàn)它的方法，然后在Service 的onBind方法里面返回就實(shí)現(xiàn)了AIDL。這個(gè)Stub類非常重要，具體看看它做了什么。
Stub類繼承自Binder，意味著這個(gè)Stub其實(shí)自己是一個(gè)Binder本地對(duì)象，然后實(shí)現(xiàn)了ICompute接口，ICompute本身是一個(gè)IInterface，因此他攜帶某種客戶端需要的能力（這里是方法add)。此類有一個(gè)內(nèi)部類Proxy，也就是Binder代理對(duì)象；
然后看看asInterface方法，我們在bind一個(gè)Service之后，在onServiceConnecttion的回調(diào)里面，就是通過這個(gè)方法拿到一個(gè)遠(yuǎn)程的service的，這個(gè)方法做了什么呢？
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | /** * Cast an IBinder object into an com.example.test.app.ICompute interface, * generating a proxy if needed. */ public static com.example.test.app.ICompute asInterface(android.os.IBinder obj) { if ((obj == null)) { return null; } android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) && (iin instanceof com.example.test.app.ICompute))) { return ((com.example.test.app.ICompute) iin); } return new com.example.test.app.ICompute.Stub.Proxy(obj); } |
首先看函數(shù)的參數(shù)IBinder類型的obj，這個(gè)對(duì)象是驅(qū)動(dòng)給我們的，如果是Binder本地對(duì)象，那么它就是Binder類型，如果是Binder代理對(duì)象，那就是BinderProxy類型；然后，正如上面自動(dòng)生成的文檔所說，它會(huì)試著查找Binder本地對(duì)象，如果找到，說明Client和Server都在同一個(gè)進(jìn)程，這個(gè)參數(shù)直接就是本地對(duì)象，直接強(qiáng)制類型轉(zhuǎn)換然后返回，如果找不到，說明是遠(yuǎn)程對(duì)象（處于另外一個(gè)進(jìn)程）那么就需要?jiǎng)?chuàng)建一個(gè)Binde代理對(duì)象，讓這個(gè)Binder代理實(shí)現(xiàn)對(duì)于遠(yuǎn)程對(duì)象的訪問。一般來說，如果是與一個(gè)遠(yuǎn)程Service對(duì)象進(jìn)行通信，那么這里返回的一定是一個(gè)Binder代理對(duì)象，這個(gè)IBinder參數(shù)的實(shí)際上是BinderProxy;
再看看我們對(duì)于aidl的add?方法的實(shí)現(xiàn)；在Stub類里面，add是一個(gè)抽象方法，我們需要繼承這個(gè)類并實(shí)現(xiàn)它；如果Client和Server在同一個(gè)進(jìn)程，那么直接就是調(diào)用這個(gè)方法；那么，如果是遠(yuǎn)程調(diào)用，這中間發(fā)生了什么呢？Client是如何調(diào)用到Server的方法的？
我們知道，對(duì)于遠(yuǎn)程方法的調(diào)用，是通過Binder代理完成的，在這個(gè)例子里面就是Proxy類；Proxy對(duì)于add方法的實(shí)現(xiàn)如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Override public int add(int a, int b) throws android.os.RemoteException { android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); int _result; try { _data.writeInterfaceToken(DESCRIPTOR); _data.writeInt(a); _data.writeInt(b); mRemote.transact(Stub.TRANSACTION_add, _data, _reply, 0); _reply.readException(); _result = _reply.readInt(); } finally { _reply.recycle(); _data.recycle(); } return _result; } |
它首先用Parcel把數(shù)據(jù)序列化了，然后調(diào)用了transact方法；這個(gè)transact到底做了什么呢？這個(gè)Proxy類在asInterface方法里面被創(chuàng)建，前面提到過，如果是Binder代理那么說明驅(qū)動(dòng)返回的IBinder實(shí)際是BinderProxy, 因此我們的Proxy類里面的mRemote實(shí)際類型應(yīng)該是BinderProxy；我們看看BinderProxy的transact方法：(Binder.java的內(nèi)部類)
| 1 2 | public native boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException; |
這是一個(gè)本地方法；它的實(shí)現(xiàn)在native層，具體來說在frameworks/base/core/jni/android_util_Binder.cpp文件，里面進(jìn)行了一系列的函數(shù)調(diào)用，調(diào)用鏈實(shí)在太長這里就不給出了；要知道的是它最終調(diào)用到了talkWithDriver函數(shù)；看這個(gè)函數(shù)的名字就知道，通信過程要交給驅(qū)動(dòng)完成了；這個(gè)函數(shù)最后通過ioctl系統(tǒng)調(diào)用，Client進(jìn)程陷入內(nèi)核態(tài)，Client調(diào)用add方法的線程掛起等待返回；驅(qū)動(dòng)完成一系列的操作之后喚醒Server進(jìn)程，調(diào)用了Server進(jìn)程本地對(duì)象的onTransact函數(shù)（實(shí)際上由Server端線程池完成）。我們再看Binder本地對(duì)象的onTransact方法（這里就是Stub類里面的此方法）：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | @Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { switch (code) { case INTERFACE_TRANSACTION: { reply.writeString(DESCRIPTOR); return true; } case TRANSACTION_add: { data.enforceInterface(DESCRIPTOR); int _arg0; _arg0 = data.readInt(); int _arg1; _arg1 = data.readInt(); int _result = this.add(_arg0, _arg1); reply.writeNoException(); reply.writeInt(_result); return true; } } return super.onTransact(code, data, reply, flags); } |
在Server進(jìn)程里面，onTransact根據(jù)調(diào)用號(hào)（每個(gè)AIDL函數(shù)都有一個(gè)編號(hào)，在跨進(jìn)程的時(shí)候，不會(huì)傳遞函數(shù)，而是傳遞編號(hào)指明調(diào)用哪個(gè)函數(shù)）調(diào)用相關(guān)函數(shù)；在這個(gè)例子里面，調(diào)用了Binder本地對(duì)象的add方法；這個(gè)方法將結(jié)果返回給驅(qū)動(dòng)，驅(qū)動(dòng)喚醒掛起的Client進(jìn)程里面的線程并將結(jié)果返回。于是一次跨進(jìn)程調(diào)用就完成了。
至此，你應(yīng)該對(duì)AIDL這種通信方式里面的各個(gè)類以及各個(gè)角色有了一定的了解；它總是那么一種固定的模式：一個(gè)需要跨進(jìn)程傳遞的對(duì)象一定繼承自IBinder，如果是Binder本地對(duì)象，那么一定繼承Binder實(shí)現(xiàn)IInterface，如果是代理對(duì)象，那么就實(shí)現(xiàn)了IInterface并持有了IBinder引用；
Proxy與Stub不一樣，雖然他們都既是Binder又是IInterface，不同的是Stub采用的是繼承（is 關(guān)系），Proxy采用的是組合（has 關(guān)系）。他們均實(shí)現(xiàn)了所有的IInterface函數(shù)，不同的是，Stub又使用策略模式調(diào)用的是虛函數(shù)（待子類實(shí)現(xiàn)），而Proxy則使用組合模式。為什么Stub采用繼承而Proxy采用組合？事實(shí)上，Stub本身is一個(gè)IBinder（Binder），它本身就是一個(gè)能跨越進(jìn)程邊界傳輸?shù)膶?duì)象，所以它得繼承IBinder實(shí)現(xiàn)transact這個(gè)函數(shù)從而得到跨越進(jìn)程的能力（這個(gè)能力由驅(qū)動(dòng)賦予）。Proxy類使用組合，是因?yàn)樗魂P(guān)心自己是什么，它也不需要跨越進(jìn)程傳輸，它只需要擁有這個(gè)能力即可，要擁有這個(gè)能力，只需要保留一個(gè)對(duì)IBinder的引用。如果把這個(gè)過程做一個(gè)類比，在封建社會(huì)，Stub好比皇帝，可以號(hào)令天下，他生而具有這個(gè)權(quán)利（不要說宣揚(yáng)封建迷信。。）如果一個(gè)人也想號(hào)令天下，可以，“挾天子以令諸侯”。為什么不自己去當(dāng)皇帝，其一，一般情況沒必要，當(dāng)了皇帝其實(shí)限制也蠻多的是不是？我現(xiàn)在既能掌管天下，又能不受約束（Java單繼承）；其二，名不正言不順啊，我本來特么就不是（Binder），你非要我是說不過去，搞不好還會(huì)造反。最后呢，如果想當(dāng)皇帝也可以，那就是asBinder了。在Stub類里面，asBinder返回this，在Proxy里面返回的是持有的組合類IBinder的引用。
再去翻閱系統(tǒng)的ActivityManagerServer的源碼，就知道哪一個(gè)類是什么角色了：IActivityManager是一個(gè)IInterface，它代表遠(yuǎn)程Service具有什么能力，ActivityManagerNative指的是Binder本地對(duì)象（類似AIDL工具生成的Stub類），這個(gè)類是抽象類，它的實(shí)現(xiàn)是ActivityManagerService；因此對(duì)于AMS的最終操作都會(huì)進(jìn)入ActivityManagerService這個(gè)真正實(shí)現(xiàn)；同時(shí)如果仔細(xì)觀察，ActivityManagerNative.java里面有一個(gè)非公開類ActivityManagerProxy, 它代表的就是Binder代理對(duì)象；是不是跟AIDL模型一模一樣呢？那么ActivityManager是什么？他不過是一個(gè)管理類而已，可以看到真正的操作都是轉(zhuǎn)發(fā)給ActivityManagerNative進(jìn)而交給他的實(shí)現(xiàn)ActivityManagerService?完成的。
OK，本文就講到這里了，要深入理解Binder，需要自己下功夫；那些native層以及驅(qū)動(dòng)里面的調(diào)用過程，用文章寫出來根本沒有意義，需要自己去跟蹤；接下來你可以：
總結(jié)
以上是生活随笔為你收集整理的Binder学习指南的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android的服务（Service）（
- 下一篇： Android插件化原理解析——概要