Android開發：IBinder對象在進程間傳遞的形式

命題   

    當service常常被遠程調用時，咱們經常用到aidl來定一個接口供service和client來使用，這個其實就是使用Binder機制的IPC通訊。當client bind service成功以後，系統AM會調用回調函數onServiceConnected將service的IBinder傳遞給client， client再經過調用aidl生成的asInterface()方法得到service的調用接口，此時一個bind過程結束了，咱們在client端就能夠遠程調用service的方法了。例如
 
1.public void onServiceConnected(ComponentName className, 
 2.        IBinder service) { 
 3.    mSecondaryService = ISecondary.Stub.asInterface(service); 
 4.} 

 
    咱們再看aidl生成的asInterface()的定義
 
1.public static com.example.Android.apis.app.ISecondary asInterface(android.os.IBinder obj) 
 2.{ 
 3.if ((obj==null)) { 
 4.return null; 
 5.} 
 6.android.os.IInterface iin = (android.os.IInterface)obj.queryLocalInterface(DESCRIPTOR); 
 7.if (((iin!=null)&&(iin instanceof com.example.android.apis.app.ISecondary))) { 
 8.return ((com.example.android.apis.app.ISecondary)iin); 
 9.} 
 10.return new com.example.android.apis.app.ISecondary.Stub.Proxy(obj); 
 11.} 

    首先，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的便可),
 
1.status_t Parcel::writeStrongBinder(const sp<IBinder>& val) 
 2.{ 
 3.    return flatten_binder(ProcessState::self(), val, this); 
 4.} 

 

 
 1.status_t flatten_binder(const sp<ProcessState>& proc, 
 2.    const sp<IBinder>& binder, Parcel* out) 
 3.{ 
 4.    flat_binder_object obj; 
 5.     
 6.    obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS; 
 7.    if (binder != NULL) { 
 8.        IBinder *local = binder->localBinder(); 
 9.        if (!local) { 
 10.            BpBinder *proxy = binder->remoteBinder(); 
 11.            if (proxy == NULL) { 
 12.                LOGE("null proxy"); 
 13.            } 
 14.            const int32_t handle = proxy ? proxy->handle() : 0; 
 15.            obj.type = BINDER_TYPE_HANDLE; 
 16.            obj.handle = handle; 
 17.            obj.cookie = NULL; 
 18.        } else { 
 19.            obj.type = BINDER_TYPE_BINDER; 
 20.            obj.binder = local->getWeakRefs(); 
 21.            obj.cookie = local; 
 22.        } 
 23.    } else { 
 24.        obj.type = BINDER_TYPE_BINDER; 
 25.        obj.binder = NULL; 
 26.        obj.cookie = NULL; 
 27.    } 
28.     
 29.    return finish_flatten_binder(binder, obj, out); 
 30.} 
上面代碼分下面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()
 

 

 
 1.switch (fp->type) { 
 2.        case BINDER_TYPE_BINDER: 
 3.        case BINDER_TYPE_WEAK_BINDER: { 
 4.            struct binder_ref *ref; 
 5.            struct binder_node *node = binder_get_node(proc, fp->binder); 
 6.            if (node == NULL) { 
 7.                node = binder_new_node(proc, fp->binder, fp->cookie); 
 8.                if (node == NULL) { 
 9.                    return_error = BR_FAILED_REPLY; 
 10.                    goto err_binder_new_node_failed; 
 11.                } 
 12.                node->min_priority = fp->flags & FLAT_BINDER_FLAG_PRIORITY_MASK; 
 13.                node->accept_fds = !!(fp->flags & FLAT_BINDER_FLAG_ACCEPTS_FDS); 
 14.            } 
 15.            if (fp->cookie != node->cookie) { 
 16.                binder_user_error("binder: %d:%d sending u%p " 
 17.                    "node %d, cookie mismatch %p != %p\n", 
 18.                    proc->pid, thread->pid, 
 19.                    fp->binder, node->debug_id, 
 20.                    fp->cookie, node->cookie); 
 21.                goto err_binder_get_ref_for_node_failed; 
 22.            } 
 23.            ref = binder_get_ref_for_node(target_proc, node); 
 24.            if (ref == NULL) { 
 25.                return_error = BR_FAILED_REPLY; 
 26.                goto err_binder_get_ref_for_node_failed; 
 27.            } 
 28.            if (fp->type == BINDER_TYPE_BINDER) 
 29.                fp->type = BINDER_TYPE_HANDLE; 
 30.            else 
 31.                fp->type = BINDER_TYPE_WEAK_HANDLE; 
 32.            fp->handle = ref->desc; 
 33.            binder_inc_ref(ref, fp->type == BINDER_TYPE_HANDLE, 
 34.                       &thread->todo); 
 35. 
 36.            binder_debug(BINDER_DEBUG_TRANSACTION, 
 37.                     "        node %d u%p -> ref %d desc %d\n", 
 38.                     node->debug_id, node->ptr, ref->debug_id, 
 39.                     ref->desc); 
 40.        } break; 
 41.        case BINDER_TYPE_HANDLE: 
 42.        case BINDER_TYPE_WEAK_HANDLE: { 
 43.            struct binder_ref *ref = binder_get_ref(proc, fp->handle); 
 44.            if (ref == NULL) { 
 45.                binder_user_error("binder: %d:%d got " 
 46.                    "transaction with invalid " 
 47.                    "handle, %ld\n", proc->pid, 
 48.                    thread->pid, fp->handle); 
 49.                return_error = BR_FAILED_REPLY; 
 50.                goto err_binder_get_ref_failed; 
 51.            } 
 52.            if (ref->node->proc == target_proc) { 
 53.                if (fp->type == BINDER_TYPE_HANDLE) 
 54.                    fp->type = BINDER_TYPE_BINDER; 
 55.                else 
 56.                    fp->type = BINDER_TYPE_WEAK_BINDER; 
 57.                fp->binder = ref->node->ptr; 
 58.                fp->cookie = ref->node->cookie; 
 59.                binder_inc_node(ref->node, fp->type == BINDER_TYPE_BINDER, 0, NULL); 
 60.                binder_debug(BINDER_DEBUG_TRANSACTION, 
 61.                         "        ref %d desc %d -> node %d u%p\n", 
 62.                         ref->debug_id, ref->desc, ref->node->debug_id, 
 63.                         ref->node->ptr); 
 64.            } else { 
 65.                struct binder_ref *new_ref; 
 66.                new_ref = binder_get_ref_for_node(target_proc, ref->node); 
 67.                if (new_ref == NULL) { 
 68.                    return_error = BR_FAILED_REPLY; 
 69.                    goto err_binder_get_ref_for_node_failed; 
 70.                } 
 71.                fp->handle = new_ref->desc; 
 72.                binder_inc_ref(new_ref, fp->type == BINDER_TYPE_HANDLE, NULL); 
 73.                binder_debug(BINDER_DEBUG_TRANSACTION, 
 74.                         "        ref %d desc %d -> ref %d desc %d (node %d)\n", 
 75.                         ref->debug_id, ref->desc, new_ref->debug_id, 
 76.                         new_ref->desc, ref->node->debug_id); 
 77.            } 
 78.        } 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本地對象的引用。
本篇文章來源於 Linux公社網站(www.linuxidc.com)  原文連接：http://www.linuxidc.com/Linux/2011-08/40720.htm