Binder學習指南

jopen 8年前發布 | 33K 次閱讀 AIDL Android開發移動開發

毫不夸張地說，Binder是Android系統中最重要的特性之一；正如其名“粘合劑”所喻，它是系統間各個組件的橋梁，Android系統的開放式設計也很大程度上得益與這種及其方便的跨進程通信機制。

理解Binder對于理解整個Android系統有著非常重要的作用，Android系統的四大組件，AMS，PMS等系統服務無一不與Binder掛鉤；如果對Binder不甚了解，那么就很難了解這些系統機制，從而緊緊浮游與表面，無法深入；要深入Android，Binder是必須邁出的一步。

現在網上有不少資料介紹Binder，個人覺得最好的兩篇如下：

其中, 《Binder設計與實現》以一種宏觀的角度解釋了Android系統中的Binder機制，文章如行云流水；如果對于Binder有一定的了解再來看著篇文章，有一種打通任督二脈的感覺；每看一次理解就深一層。老羅的系列文章則從系統源碼角度深入分析了Binder的實現細節；具有很大的參考意義；每當對于Binder細節有疑惑，看一看他的書就迎刃而解。

但是遺憾的是，Binder機制終究不是三言兩語就能解釋清楚的，一上來就扒出源碼很可能深陷細節無法自拔，老羅的文章那不是一般的長，如果看不懂強行看很容易睡著；勉強看完還是云里霧里；相反如果直接大談特談Binder的設計，那么完全就是不知所云；因此上述兩篇文章對于初學者并不友好，本文不會深入源碼細節，也不會對于Binder的設計高談闊論；重點如下：

一些Linux的預備知識
Binder到底是什么？
Binder機制是如何跨進程的？
一次Binder通信的基本流程是什么樣？
深入理解Java層的Binder

讀完本文，你應該對于Java層的AIDL了如指掌，對于Binder也會有一個大體上的認識；再深入學習就得靠自己了，本人推薦的Binder學習路徑如下：

先學會熟練使用AIDL進行跨進程通信（簡單來說就是遠程Service）
看完本文
看Android文檔， Parcel, IBinder, Binder 等涉及到跨進程通信的類
不依賴AIDL工具，手寫遠程Service完成跨進程通信
看《Binder設計與實現》
看老羅的博客或者書（書結構更清晰）
再看《Binder設計與實現》
學習Linux系統相關知識；自己看源碼。

背景知識

為了理解Binder我們先澄清一些概念。為什么需要跨進程通信（IPC），怎么做到跨進程通信？為什么是Binder？

由于Android系統基于Linux內核，因此有必要了解相關知識。

進程隔離

進程隔離是為保護操作系統中進程互不干擾而設計的一組不同硬件和軟件的技術。這個技術是為了避免進程A寫入進程B的情況發生。進程的隔離實現，使用了虛擬地址空間。進程A的虛擬地址和進程B的虛擬地址不同，這樣就防止進程A將數據信息寫入進程B。

以上來自維基百科；操作系統的不同進程之間，數據不共享；對于每個進程來說，它都天真地以為自己獨享了整個系統，完全不知道其他進程的存在；(有關虛擬地址，請自行查閱）因此一個進程需要與另外一個進程通信，需要某種系統機制才能完成。

用戶空間/內核空間

詳細解釋可以參考 Kernel Space Definition ；簡單理解如下：

Linux Kernel是操作系統的核心，獨立于普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。

對于Kernel這么一個高安全級別的東西，顯然是不容許其它的應用程序隨便調用或訪問的，所以需要對Kernel提供一定的保護機制，這個保護機制用來告訴那些應用程序，你只可以訪問某些許可的資源，不許可的資源是拒絕被訪問的，于是就把Kernel和上層的應用程序抽像的隔離開，分別稱之為Kernel Space和User Space。

系統調用/內核態/用戶態

雖然從邏輯上抽離出用戶空間和內核空間；但是不可避免的的是，總有那么一些用戶空間需要訪問內核的資源；比如應用程序訪問文件，網絡是很常見的事情，怎么辦呢？

Kernel space can be accessed by user processes only through the use of system calls.

用戶空間訪問內核空間的唯一方式就是 系統調用 ；通過這個統一入口接口，所有的資源訪問都是在內核的控制下執行，以免導致對用戶程序對系統資源的越權訪問，從而保障了系統的安全和穩定。用戶軟件良莠不齊，要是它們亂搞把系統玩壞了怎么辦？因此對于某些特權操作必須交給安全可靠的內核來執行。

當一個任務（進程）執行系統調用而陷入內核代碼中執行時，我們就稱進程處于內核運行態（或簡稱為內核態）此時處理器處于特權級最高的（0級）內核代碼中執行。當進程在執行用戶自己的代碼時，則稱其處于用戶運行態（用戶態）。即此時處理器在特權級最低的（3級）用戶代碼中運行。處理器在特權等級高的時候才能執行那些特權CPU指令。

內核模塊/驅動

通過系統調用，用戶空間可以訪問內核空間，那么如果一個用戶空間想與另外一個用戶空間進行通信怎么辦呢？很自然想到的是讓操作系統內核添加支持；傳統的Linux通信機制，比如Socket，管道等都是內核支持的；但是Binder并不是Linux內核的一部分，它是怎么做到訪問內核空間的呢？Linux的動態可加載內核模塊（Loadable Kernel Module，LKM）機制解決了這個問題；模塊是具有獨立功能的程序，它可以被單獨編譯，但不能獨立運行。它在運行時被鏈接到內核作為內核的一部分在內核空間運行。這樣，Android系統可以通過添加一個內核模塊運行在內核空間，用戶進程之間的通過這個模塊作為橋梁，就可以完成通信了。

在Android系統中，這個運行在內核空間的，負責各個用戶進程通過Binder通信的內核模塊叫做 Binder驅動 ;

驅動程序一般指的是設備驅動程序（Device Driver），是一種可以使計算機和設備通信的特殊程序。相當于硬件的接口，操作系統只有通過這個接口，才能控制硬件設備的工作；

驅動就是操作硬件的接口，為了支持Binder通信過程，Binder使用了一種“硬件”，因此這個模塊被稱之為驅動。

好了，說了這么多枯燥的概念，看張美圖緩解一下。

為什么使用Binder？

Android使用的Linux內核擁有著非常多的跨進程通信機制，比如管道，System V，Socket等；為什么還需要單獨搞一個Binder出來呢？主要有兩點，性能和安全。在移動設備上，廣泛地使用跨進程通信肯定對通信機制本身提出了嚴格的要求；Binder相對出傳統的Socket方式，更加高效；另外，傳統的進程通信方式對于通信雙方的身份并沒有做出嚴格的驗證，只有在上層協議上進行架設；比如Socket通信ip地址是客戶端手動填入的，都可以進行偽造；而Binder機制從協議本身就支持對通信雙方做身份校檢，因而大大提升了安全性。這個也是Android權限模型的基礎。

Binder通信模型

對于跨進程通信的雙方，我們姑且叫做Server進程（簡稱Server），Client進程（簡稱Client）；由于進程隔離的存在，它們之間沒辦法通過簡單的方式進行通信，那么Binder機制是如何進行的呢？

回想一下日常生活中我們通信的過程：假設A和B要進行通信，通信的媒介是打電話（A是Client，B是Server）；A要給B打電話，必須知道B的號碼，這個號碼怎么獲取呢？ 通信錄 .

這個通信錄就是一張表；內容大致是：

B -> 12345676
C -> 12334354

先查閱通信錄，拿到B的號碼；才能進行通信；否則，怎么知道應該撥什么號碼？回想一下古老的電話機，如果A要給B打電話，必須先連接通話中心，說明給我接通B的電話；這時候通話中心幫他呼叫B；連接建立，就完成了通信。

另外，光有電話和通信錄是不可能完成通信的，沒有基站支持；信息根本無法傳達。

我們看到，一次電話通信的過程除了通信的雙方還有兩個隱藏角色：通信錄和基站。Binder通信機制也是一樣：兩個運行在用戶空間的進程要完成通信，必須借助內核的幫助，這個運行在內核里面的程序叫做 Binder驅動 ，它的功能類似于基站；通信錄呢，就是一個叫做 ServiceManager 的東西（簡稱SM）

OK，Binder的通信模型就是這么簡單，如下圖：

整個通信步驟如下：

SM建立(建立通信錄)；首先有一個進程向驅動提出申請為SM；驅動同意之后，SM進程負責管理Service（注意這里是Service而不是Server，因為如果通信過程反過來的話，那么原來的客戶端Client也會成為服務端Server）不過這時候通信錄還是空的，一個號碼都沒有。
各個Server向SM注冊(完善通信錄)；每個Server端進程啟動之后，向SM報告，我是zhangsan, 要找我請返回0x1234(這個地址沒有實際意義，類比)；其他Server進程依次如此；這樣SM就建立了一張表，對應著各個Server的名字和地址；就好比B與A見面了，說存個我的號碼吧，以后找我撥打10086；
Client想要與Server通信，首先詢問SM；請告訴我如何聯系zhangsan，SM收到后給他一個號碼0x1234；Client收到之后，開心滴用這個號碼撥通了Server的電話，于是就開始通信了。

那么Binder驅動干什么去了呢？這里Client與SM的通信，以及Client與Server的通信，都會經過驅動，驅動在背后默默無聞，但是做著最重要的工作。驅動是整個通信過程的核心，因此完成跨進程通信的秘密全部隱藏在驅動里面；這個我們稍后討論。

OK，上面就是整個Binder通信的基本模型；做了一個簡單的類比，當然也有一些不恰當的地方，(比如通信錄現實中每個人都有一個，但是SM整個系統只有一個；基站也有很多個，但是驅動只有一個）；但是整體上就是這樣的；我們看到其實整個通信模型非常簡單。

Binder機制跨進程原理

上文給出了Binder的通信模型，指出了通信過程的四個角色: Client, Server, SM, driver; 但是我們仍然不清楚 Client到底是如何與Server完成通信的 。

兩個運行在用戶空間的進程A和進程B如何完成通信呢？內核可以訪問A和B的所有數據；所以，最簡單的方式是通過內核做中轉；假設進程A要給進程B發送數據，那么就先把A的數據copy到內核空間，然后把內核空間對應的數據copy到B就完成了；用戶空間要操作內核空間，需要通過系統調用；剛好，這里就有兩個系統調用： copy_from_user , copy_to_user 。

但是，Binder機制并不是這么干的。講這么一段，是說明進程間通信并不是什么神秘的東西。那么，Binder機制是如何實現跨進程通信的呢？

Binder驅動為我們做了一切。

假設Client進程想要調用Server進程的 object 對象的一個方法 add ;對于這個跨進程通信過程，我們來看看Binder機制是如何做的。（通信是一個廣泛的概念，只要一個進程能調用另外一個進程里面某對象的方法，那么具體要完成什么通信內容就很容易了。）

首先，Server進程要向SM注冊；告訴自己是誰，自己有什么能力；在這個場景就是Server告訴SM，它叫 zhangsan ，它有一個 object 對象，可以執行 add 操作；于是SM建立了一張表： zhangsan 這個名字對應進程Server;

然后Client向SM查詢：我需要聯系一個名字叫做 zhangsan 的進程里面的 object 對象；這時候關鍵來了：進程之間通信的數據都會經過運行在內核空間里面的驅動，驅動在數據流過的時候做了一點手腳，它并不會給Client進程返回一個真正的 object 對象，而是返回一個看起來跟 object 一模一樣的代理對象 objectProxy ，這個 objectProxy 也有一個 add 方法，但是這個 add 方法沒有Server進程里面 object 對象的 add 方法那個能力； objectProxy 的 add 只是一個傀儡，它唯一做的事情就是把參數包裝然后交給驅動。(這里我們簡化了SM的流程，見下文)

但是Client進程并不知道驅動返回給它的對象動過手腳，畢竟偽裝的太像了，如假包換。Client開開心心地拿著 objectProxy 對象然后調用 add 方法；我們說過，這個 add 什么也不做，直接把參數做一些包裝然后直接轉發給Binder驅動。

驅動收到這個消息，發現是這個 objectProxy ；一查表就明白了：我之前用 objectProxy 替換了 object 發送給Client了，它真正應該要訪問的是 object 對象的 add 方法；于是Binder驅動通知Server進程， 調用你的object對象的 add 方法，然后把結果發給我 ，Sever進程收到這個消息，照做之后將結果返回驅動，驅動然后把結果返回給 Client 進程；于是整個過程就完成了。

由于驅動返回的 objectProxy 與Server進程里面原始的 object 是如此相似，給人感覺好像是 直接把Server進程里面的對象object傳遞到了Client進程 ；因此，我們可以說 Binder對象是可以進行跨進程傳遞的對象

但事實上我們知道，Binder跨進程傳輸并不是真的把一個對象傳輸到了另外一個進程；傳輸過程好像是Binder跨進程穿越的時候，它在一個進程留下了一個真身，在另外一個進程幻化出一個影子（這個影子可以很多個）；Client進程的操作其實是對于影子的操作，影子利用Binder驅動最終讓真身完成操作。

理解這一點非常重要；務必仔細體會。另外，Android系統實現這種機制使用的是 代理模式 , 對于Binder的訪問，如果是在同一個進程（不需要跨進程），那么直接返回原始的Binder實體；如果在不同進程，那么就給他一個代理對象（影子）；我們在系統源碼以及AIDL的生成代碼里面可以看到很多這種實現。

另外我們為了簡化整個流程，隱藏了SM這一部分驅動進行的操作；實際上，由于SM與Server通常不在一個進程，Server進程向SM注冊的過程也是跨進程通信，驅動也會對這個過程進行暗箱操作：SM中存在的Server端的對象實際上也是代理對象，后面Client向SM查詢的時候，驅動會給Client返回另外一個代理對象。Sever進程的本地對象僅有一個，其他進程所擁有的全部都是它的代理。

一句話總結就是： Client進程只不過是持有了Server端的代理；代理對象協助驅動完成了跨進程通信。

OK，該休息一下了。

Binder到底是什么？

我們經常提到Binder，那么Binder到底是什么呢？

Binder的設計采用了面向對象的思想，在Binder通信模型的四個角色里面；他們的代表都是“Binder”，這樣，對于Binder通信的使用者而言，Server里面的Binder和Client里面的Binder沒有什么不同，一個Binder對象就代表了所有，它不用關心實現的細節，甚至不用關心驅動以及SM的存在；這就是抽象。

通常意義下，Binder指的是一種通信機制；我們說AIDL使用Binder進行通信，指的就是 Binder這種IPC機制 。
對于Server進程來說，Binder指的是 Binder本地對象
對于Client來說，Binder指的是 Binder代理對象 ，它只是 Binder本地對象 的一個遠程代理；對這個Binder代理對象的操作，會通過驅動最終轉發到Binder本地對象上去完成；對于一個擁有Binder對象的使用者而言，它無須關心這是一個Binder代理對象還是Binder本地對象；對于代理對象的操作和對本地對象的操作對它來說沒有區別。
對于傳輸過程而言，Binder是可以進行跨進程傳遞的對象；Binder驅動會對具有跨進程傳遞能力的對象做特殊處理：自動完成代理對象和本地對象的轉換。

面向對象思想的引入將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法，而其獨特之處在于Binder對象是一個可以跨進程引用的對象，它的實體（本地對象）位于一個進程中，而它的引用（代理對象）卻遍布于系統的各個進程之中。最誘人的是，這個引用和java里引用一樣既可以是強類型，也可以是弱類型，而且可以從一個進程傳給其它進程，讓大家都能訪問同一Server，就象將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界，淡化了進程間通信過程，整個系統仿佛運行于同一個面向對象的程序之中。形形色色的Binder對象以及星羅棋布的引用仿佛粘接各個應用程序的膠水，這也是Binder在英文里的原意。

驅動里面的Binder

我們現在知道，Server進程里面的Binder對象指的是Binder本地對象，Client里面的對象值得是Binder代理對象；在Binder對象進行跨進程傳遞的時候，Binder驅動會自動完成這兩種類型的轉換；因此Binder驅動必然保存了每一個跨越進程的Binder對象的相關信息；在驅動中，Binder本地對象的代表是一個叫做 binder_node 的數據結構，Binder代理對象是用 binder_ref 代表的；有的地方把Binder本地對象直接稱作Binder實體，把Binder代理對象直接稱作Binder引用（句柄），其實指的是Binder對象在驅動里面的表現形式；讀者明白意思即可。

OK，現在大致了解Binder的通信模型，也了解了Binder這個對象在通信過程中各個組件里面到底表示的是什么。

深入理解Java層的Binder

IBinder/IInterface/Binder/BinderProxy/Stub

我們使用AIDL接口的時候，經常會接觸到這些類，那么這每個類代表的是什么呢？

IBinder是一個接口，它代表了 一種跨進程傳輸的能力 ；只要實現了這個接口，就能將這個對象進行跨進程傳遞；這是驅動底層支持的；在跨進程數據流經驅動的時候，驅動會識別IBinder類型的數據，從而自動完成不同進程Binder本地對象以及Binder代理對象的轉換。
IBinder負責數據傳輸，那么client與server端的調用契約（這里不用接口避免混淆）呢？這里的IInterface代表的就是遠程server對象具有什么能力。具體來說，就是aidl里面的接口。
Java層的Binder類，代表的其實就是 Binder本地對象 。BinderProxy類是Binder類的一個內部類，它代表遠程進程的Binder對象的本地代理；這兩個類都繼承自IBinder, 因而都具有跨進程傳輸的能力；實際上，在跨越進程的時候，Binder驅動會自動完成這兩個對象的轉換。
在使用AIDL的時候，編譯工具會給我們生成一個Stub的靜態內部類；這個類繼承了Binder, 說明它是一個Binder本地對象，它實現了IInterface接口，表明它具有遠程Server承諾給Client的能力；Stub是一個抽象類，具體的IInterface的相關實現需要我們手動完成，這里使用了策略模式。

AIDL過程分析

現在我們通過一個AIDL的使用，分析一下整個通信過程中，各個角色到底做了什么，AIDL到底是如何完成通信的。（如果你連AIDL都不熟悉，請先查閱官方文檔）

首先定一個一個簡單的aidl接口：

// ICompute.aidl
package com.example.test.app;
interface ICompute {
     int add(int a, int b);
}

然后用編譯工具編譯之后，可以得到對應的ICompute.java類，看看系統給我們生成的代碼：

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;
}

系統幫我們生成了這個文件之后，我們只需要繼承ICompute.Stub這個抽象類，實現它的方法，然后在Service 的onBind方法里面返回就實現了AIDL。這個Stub類非常重要，具體看看它做了什么。

Stub類繼承自Binder，意味著這個Stub其實自己是一個Binder本地對象，然后實現了ICompute接口，ICompute本身是一個IInterface，因此他攜帶某種客戶端需要的能力（這里是方法 add )。此類有一個內部類Proxy，也就是Binder代理對象；

然后看看 asInterface 方法，我們在bind一個Service之后，在onServiceConnecttion的回調里面，就是通過這個方法拿到一個遠程的service的，這個方法做了什么呢？

/**
         * 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);
        }

首先看函數的參數 IBinder 類型的obj，這個對象是驅動給我們的，如果是Binder本地對象，那么它就是Binder類型，如果是Binder代理對象，那就是 BinderProxy 類型；然后，正如上面自動生成的文檔所說，它會試著查找Binder本地對象，如果找到，說明Client和Server都在同一個進程，這個參數直接就是本地對象，直接強制類型轉換然后返回，如果找不到，說明是遠程對象（處于另外一個進程）那么就需要創建一個Binde代理對象，讓這個Binder代理實現對于遠程對象的訪問。一般來說，如果是與一個遠程Service對象進行通信，那么這里返回的一定是一個Binder代理對象，這個IBinder參數的類型是BinderProxy;

再看看我們對于aidl的 add 方法的實現；在Stub類里面， add 是一個抽象方法，我們需要繼承這個類并實現它；如果Client和Server在同一個進程，那么直接就是調用這個方法；那么，如果是遠程調用，這中間發生了什么呢？Client是如何調用到Server的方法的？

我們知道，對于遠程方法的調用，是通過Binder代理完成的，在這個例子里面就是 Proxy 類； Proxy 對于 add 方法的實現如下：

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 把數據序列化了，然后調用了 transact 方法；這個 transact 到底做了什么呢？這個 Proxy 類在 asInterface 方法里面被創建，前面提到過，如果是Binder代理那么說明驅動返回的IBinder實際是 BinderProxy , 因此我們的 Proxy 類里面的 mRemote 實際類型應該是 BinderProxy ；我們看看 BinderProxy 的 transact 方法：(Binder.java的內部類)

public native boolean transact(int code, Parcel data, Parcel reply,
            int flags) throws RemoteException;

這是一個本地方法；它的實現在native層，具體來說在frameworks/base/core/jni/android_util_Binder.cpp文件，里面進行了一系列的函數調用，調用鏈實在太長這里就不給出了；要知道的是它最終調用到了 talkWithDriver 函數；看這個函數的名字就知道，通信過程要交給驅動完成了；最終通過 ioctl 系統調用，Client進程陷入內核態，Client進程掛起等待返回；驅動完成一系列的操作之后喚醒Server進程，調用了Server進程本地對象的 onTransact 函數。我們在看Binder本地對象的 onTransact 方法（這里就是 Stub 類里面的此方法）：

@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進程里面， onTransact 根據調用號（每個AIDL函數都有一個編號，在跨進程的時候，不會傳遞函數，而是傳遞編號指明調用哪個函數）調用相關函數；在這個例子里面，調用了Binder本地對象的 add 方法；這個方法將結果返回給驅動，驅動喚醒掛起的Client進程并將結果返回。于是一次跨進程調用就完成了。

至此，你應該對AIDL這種通信方式里面的各個類以及各個角色有了一定的了解；它總是那么一種固定的模式：一個需要跨進程傳遞的對象一定繼承自IBinder，如果是Binder本地對象，那么一定繼承Binder實現IInterface，如果是代理對象，那么就實現了IInterface并持有了IBinder引用；

Proxy與Stub不一樣，雖然他們都既是Binder又是IInterface，不同的是Stub采用的是繼承（is 關系），Proxy采用的是組合（has 關系）。他們均實現了所有的IInterface函數，不同的是，Stub又使用策略模式調用的是虛函數（待子類實現），而Proxy則使用組合模式。為什么Stub采用繼承而Proxy采用組合？事實上，Stub本身is一個IBinder（Binder），它本身就是一個能跨越進程邊界傳輸的對象，所以它得繼承IBinder實現transact這個函數從而得到跨越進程的能力（這個能力由驅動賦予）。Proxy類使用組合，是因為他不關心自己是什么，它也不需要跨越進程傳輸，它只需要擁有這個能力即可，要擁有這個能力，只需要保留一個對IBinder的引用。如果把這個過程做一個類比，在封建社會，Stub好比皇帝，可以號令天下，他生而具有這個權利（不要說宣揚封建迷信。。）如果一個人也想號令天下，可以，“挾天子以令諸侯”。為什么不自己去當皇帝，其一，一般情況沒必要，當了皇帝其實限制也蠻多的是不是？我現在既能掌管天下，又能不受約束（Java單繼承）；其二，名不正言不順啊，我本來特么就不是（Binder），你非要我是說不過去，搞不好還會造反。最后呢，如果想當皇帝也可以，那就是asBinder了。在Stub類里面，asBinder返回this，在Proxy里面返回的是持有的組合類IBinder的引用。

再去翻閱系統的ActivityManagerServer的源碼，就知道哪一個類是什么角色了：IActivityManager是一個IInterface，它代表遠程Service具有什么能力，ActivityManagerNative指的是Binder本地對象（類似AIDL工具生成的Stub類），這個類是抽象類，它的實現是 ActivityManagerService ；因此對于AMS的最終操作都會進入 ActivityManagerService 這個真正實現；同時如果仔細觀察，ActivityManagerNative有一個靜態類ActivityManagerProxy, 它代表的就是Binder代理對象；是不是跟AIDL模型一模一樣呢？那么 ActivityManager 是什么？他不過是一個管理類而已，可以看到真正的操作都是轉發給 ActivityManagerNative 進而交給他的實現 ActivityManagerService 完成的。

OK，本文就講到這里了，要深入理解Binder，需要自己下功夫；那些native層以及驅動里面的調用過程，用文章寫出來根本沒有意義，需要自己去跟蹤；接下來你可以：

看Android文檔， Parcel, IBinder, Binder 等涉及到跨進程通信的類；
不依賴AIDL工具，手寫遠程Service完成跨進程通信
看《Binder設計與實現》
看老羅的博客或者書（書結構更清晰）
再看《Binder設計與實現》
學習Linux系統相關知識；自己看源碼。

來自： http://weishu.me/2016/01/12/binder-index-for-newer/

本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1452649194089.html

AIDL Android開發移動開發