IBinder對象在進程間傳遞的形式(一)

命題   

    當service經常被遠程調用時，我們常常用到aidl來定一個介面供service和client來使用，這個其實就是使用Binder機制的IPC通訊。當client bind service成功之後，系統AM會調用回呼函數onServiceConnected將service的IBinder傳遞給client， client再通過調用aidl產生的asInterface()方法獲得service的調用介面，此時一個bind過程結束了，我們在client端就可以遠程調用service的方法了。例如

            public void onServiceConnected(ComponentName className,                    IBinder service) {                mSecondaryService = ISecondary.Stub.asInterface(service);            }

    我們再看aidl產生的asInterface()的定義

public static com.example.android.apis.app.ISecondary asInterface(android.os.IBinder obj){if ((obj==null)) {return null;}android.os.IInterface iin = (android.os.IInterface)obj.queryLocalInterface(DESCRIPTOR);if (((iin!=null)&&(iin instanceof com.example.android.apis.app.ISecondary))) {return ((com.example.android.apis.app.ISecondary)iin);}return new com.example.android.apis.app.ISecondary.Stub.Proxy(obj);}

    首先，asInterface()會去query傳入的IBinder對象是否有LocalInterface,這裡的LocalInterface是指傳入的IBinder是service本身的引用還是代理。
    1.當asInterface的輸入的IBinder為server的引用(Binder類型)時，則直接返回該引用，那麼此時調用server的方法不為IPC通訊，而是直接的函數調用；
    2.當asInterface的輸入的IBinder為server的代理(BinderProxy類型)時，則需要建立該server的代理並返回，此時調用server的方法為IPC通訊。

    那麼以上兩種情況發生的條件是什麼呢？這裡我們先給出答案，然後再深入到代碼中去研究2種不同的情況。
    1.當client和service處在相同進程中的話，asInterface的輸入的IBinder為server的引用時；
    2.當client和service處在不同進程中的話，asInterface的輸入的IBinder為server的代理。

在研究上述實現代碼之前，我們先介紹一下IBinder作為參數使用IPC進程間傳遞時的狀態變化，其實這個就是我們本篇文章的核心內容，理解了這個機制，我們就會很容易理解我們上述的那個命題的原理了。

    模型

    IBinder作為參數在IPC通訊中進行傳遞，可能會使某些人困惑，IBinder不就是IPC通訊的媒介嗎？怎麼還會被作為參數來傳遞呢，這樣理解就有點狹隘了，拿native層的IPC來說，client從SM(service manager)中擷取service端的Interface，這個Interface同時也是IBinder類型，當C/S兩端需要雙工通訊時，即所謂的Service端需要反過來調用Client端的方法時，就需要client通過前述的那個Interface將Client端的IBinder傳遞給Service。
    拿Java應用程式層的Service來說更是如此，如本文的這個命題，下面我們會分析，首先來介紹原理性的知識。
    Binder IPC通訊中，Binder是通訊的媒介，Parcel是通訊的內容。方法遠程調用過程中，其參數都被打包成Parcel的形式來傳遞的。IBinder對象也不例外，我們看一下Parcel類中的writeStrongBinder()(由於java層和native層的方法是相對應的，java層只是native的封裝，因此我們只需要看native的即可),

status_t Parcel::writeStrongBinder(const sp<IBinder>& val){    return flatten_binder(ProcessState::self(), val, this);}

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

上面代碼分下面2種情況
1. 如果傳遞的IBinder為service的本地IBinder對象，那麼該IBinder對象為BBinder類型的，因此上面的local不為NULL，故binder type為BINDER_TYPE_BINDER。
2. 如果傳遞的IBinder對象代理IBinder對象，那麼binder type則為BINDER_TYPE_HANDLE。

client端將方法調用參數打包成Parcel之後，會發送到核心的Binder模組，因此下面我們將分析一下核心的Binder模組的處理。

kernel/drivers/staging/android/Binder.c中的函數binder_transaction()

switch (fp->type) {        case BINDER_TYPE_BINDER:        case BINDER_TYPE_WEAK_BINDER: {            struct binder_ref *ref;            struct binder_node *node = binder_get_node(proc, fp->binder);            if (node == NULL) {                node = binder_new_node(proc, fp->binder, fp->cookie);                if (node == NULL) {                    return_error = BR_FAILED_REPLY;                    goto err_binder_new_node_failed;                }                node->min_priority = fp->flags & FLAT_BINDER_FLAG_PRIORITY_MASK;                node->accept_fds = !!(fp->flags & FLAT_BINDER_FLAG_ACCEPTS_FDS);            }            if (fp->cookie != node->cookie) {                binder_user_error("binder: %d:%d sending u%p "                    "node %d, cookie mismatch %p != %p\n",                    proc->pid, thread->pid,                    fp->binder, node->debug_id,                    fp->cookie, node->cookie);                goto err_binder_get_ref_for_node_failed;            }            ref = binder_get_ref_for_node(target_proc, node);            if (ref == NULL) {                return_error = BR_FAILED_REPLY;                goto err_binder_get_ref_for_node_failed;            }            if (fp->type == BINDER_TYPE_BINDER)                fp->type = BINDER_TYPE_HANDLE;            else                fp->type = BINDER_TYPE_WEAK_HANDLE;            fp->handle = ref->desc;            binder_inc_ref(ref, fp->type == BINDER_TYPE_HANDLE,                       &thread->todo);            binder_debug(BINDER_DEBUG_TRANSACTION,                     "        node %d u%p -> ref %d desc %d\n",                     node->debug_id, node->ptr, ref->debug_id,                     ref->desc);        } break;        case BINDER_TYPE_HANDLE:        case BINDER_TYPE_WEAK_HANDLE: {            struct binder_ref *ref = binder_get_ref(proc, fp->handle);            if (ref == NULL) {                binder_user_error("binder: %d:%d got "                    "transaction with invalid "                    "handle, %ld\n", proc->pid,                    thread->pid, fp->handle);                return_error = BR_FAILED_REPLY;                goto err_binder_get_ref_failed;            }            if (ref->node->proc == target_proc) {                if (fp->type == BINDER_TYPE_HANDLE)                    fp->type = BINDER_TYPE_BINDER;                else                    fp->type = BINDER_TYPE_WEAK_BINDER;                fp->binder = ref->node->ptr;                fp->cookie = ref->node->cookie;                binder_inc_node(ref->node, fp->type == BINDER_TYPE_BINDER, 0, NULL);                binder_debug(BINDER_DEBUG_TRANSACTION,                         "        ref %d desc %d -> node %d u%p\n",                         ref->debug_id, ref->desc, ref->node->debug_id,                         ref->node->ptr);            } else {                struct binder_ref *new_ref;                new_ref = binder_get_ref_for_node(target_proc, ref->node);                if (new_ref == NULL) {                    return_error = BR_FAILED_REPLY;                    goto err_binder_get_ref_for_node_failed;                }                fp->handle = new_ref->desc;                binder_inc_ref(new_ref, fp->type == BINDER_TYPE_HANDLE, NULL);                binder_debug(BINDER_DEBUG_TRANSACTION,                         "        ref %d desc %d -> ref %d desc %d (node %d)\n",                         ref->debug_id, ref->desc, new_ref->debug_id,                         new_ref->desc, ref->node->debug_id);            }        } break;

    上面代碼也分為了2種不同的分支：
    1. 傳來的IBinder類型為BINDER_TYPE_BINDER時，會將binder type值為BINDER_TYPE_HANDLE；
    2. 傳來的IBinder類型為BINDER_TYPE_HANDLE時，會判斷該IBinder的實體被定義的進程(也就是該IBinder代表的server被定義的進程)與目標進程(也即IBinder被傳遞的目標進程)是否相同，如果相同，則將該IBinder type轉化為BINDER_TYPE_BINDER，同時使其變為IBinder本機物件的引用。
    通過上述的處理，我們可以得出下面結論：
    1.不同進程間傳遞的IBinder本機物件引用(BINDER_TYPE_BINDER類型)，在核心中均會被轉化為代理(BINDER_TYPE_HANDLE類型，目前只是改變其類型，在IBinder接收方會根據其類型轉化為代理)；
    2.由於只有不同進程間傳遞才會將IBinder發送到Binder模組，所以IBinder在多級傳遞的過程中，有下面2種可能 進程A-->進程B-->進程A，進程A-->進程B-->進程C；其對應的IBinder類型就是BINDER_TYPE_BINDER-->BINDER_TYPE_HANDLE-->BINDER_TYPE_BINDER,BINDER_TYPE_BINDER-->BINDER_TYPE_HANDLE-->BINDER_TYPE_HANDLE。
    根據上述結論，我們就會明白Binder IPC通訊過程中，相同進程間的IBinder本機物件，如果不經過不同進程的傳遞，那麼IBinder就不會傳給核心的Binder模組，因此它一直是IBinder的本機物件；如果在進程間傳遞，即使通過再多的進程間的傳遞，只要最後的目標是同一個進程的component，那麼他得到的IBinder對象就是本地的對象。

          

   

    套用模型

    理解了上面的這個模型，我們再回過頭看最開始的那個命題結論就很好理解了
    1.當client和service處在相同進程中的話，asInterface的輸入的IBinder為server的引用時；
    2.當client和service處在不同進程中的話，asInterface的輸入的IBinder為server的代理。

    假如某一個component(例如一個Acitivity)處在進程A，它需要bind一個service，而該service處在進程B中，我們簡單介紹一下bind的過程。
    1. 進程A向AM(進程system_server)發出Bind請求，並將回調ServiceConnection提供給AM(傳遞給AM的也是一個介面(IServiceConnection)，因為AM與A之間是雙工通訊，所以A需要向AM提供IBinder)；
    2. AM啟動進程B並建立service，進程B將service的IBinder對象傳遞給AM，AM再通過IServiceConnection傳遞給進程A。所以service的IBinder對象的傳遞路徑為：進程B-->進程system_server(AM)-->進程A。

    套用上面的模型，就會得出本文最開始命題的結論。

    便於理解給出裡bind 一個service的過程