IBinder物件在程序間傳遞的形式(一)
阿新 • • 發佈：2019-01-29
命題
當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的過程
