命题
当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公社网站() 原文链接：