IBinder对象在进程间传递的形式

最新推荐文章于 2023-02-08 01:05:19 发布
最新推荐文章于 2023-02-08 01:05:19 发布
阅读量516 收藏
点赞数
文章标签： service null server descriptor interface struct

命题   

    当service经常被远程调用时，我们常常用到aidl来定一个接口供service和client来使用，这个其实就是使用Binder机制的IPC通信。当client bind service成功之后，系统AM会调用回调函数onServiceConnected将service的IBinder传递给client， client再通过调用aidl生成的asInterface()方法获得service的调用接口，此时一个bind过程结束了，我们在client端就可以远程调用service的方法了。例如

view plain print ?
  1. public void onServiceConnected(ComponentName className,  
  2.         IBinder service) {  
  3.     mSecondaryService = ISecondary.Stub.asInterface(service);  
  4. }  

    我们再看aidl生成的asInterface()的定义

view plain print ?
  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的即可),

view plain print ?
  1. status_t Parcel::writeStrongBinder(const sp<IBinder>& val)  
  2. {  
  3.     return flatten_binder(ProcessState::self(), val, this);  
  4. }  

view plain print ?
  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()


view plain print ?
  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本地对象的引用。
    通过上述的处理，我们可以得出下面结论：
    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的过程



qingtian_zhen
关注
Android进程间通信之binder - 几个重要数字
over666的点滴记载
02-24 3604
本文Android代码来源androidxref.com的Android11版本。从binder环境初始化开始，讲述这几个在binder中需要掌握的数字。首先我们思考这么几个问题；1，binder环境是什么时候初始化的？2，这些数字是如何被设置的？3，binder传输malloc内存是谁的内存？4，binder线程池线程是如何增长的？5，为什么zygote没有初始化binder？6，ams启动进程，跟zygote通信方式为什么选用socket？
IBinder对象在进程间传递的形式(二)
杜文涛的专栏
10-29 1万+
这篇文章是对IBinder对象在进程间传递的形式(一)这篇文章的补充，首先还是把service启动过程的流程图贴上来   Android中主要通过2种方法来获得service IBinder： 1.       通过ServiceManager.getService(String Descriptor)来获得Service Manager管理的service的IBinder。 2.
IBinder对象在进程间传递的形式(一)
热门推荐
杜文涛的专栏
07-22 2万+
命题        当service经常被远程调用时，我们常常用到aidl来定一个接口供service和client来使用，这个其实就是使用Binder机制的IPC通信。当client bind service成功之后，系统AM会调用回调函数onServiceConnected将service的IBinder传递给client， client再通过调用aidl生成的asInterfac
Android开发：IBinder对象在进程间传递的形式
weixin_33744854的博客
03-17 451
2019独角兽企业重金招聘Python工程师标准>>> ...
进程间通讯：Binder：支持类型，同步/异步的AIDL
C++ JAVA的专栏
03-22 2879
1：AIDL支持的数据类型 1、基本数据类型 2、String和CharSequence 3、ArrayList（里面的每个元素必须支持aidl） 4、HashMap（里面的每个元素必须支持aidl,包括key和value） 5、Parcelable 值得注意的是除了基本类型，其他类型参数需要加上流向：in（只能客户端流向服务端），out(只能服务端流向客户端)，inout(可以在客户端和服务端双向流动) 2： 同步/异步 2.1：bindService是异步的 ，详见我的另一篇博客 Binder
从Context说到Binder
weixin_34044273的博客
05-09 161
前情提要当我们在Android项目中，希望使用系统服务时，可以通过Context的getSystemService ()方法来获得。例如，当我们想要判断当前网络状态是否可用，可以通过下面的代码实现：public static boolean isNetworkAvailable(@NonNull Context context) { // 获取系统服务（核心代码） Connecti...
android 进程间的数据传递
bencheng06的博客
04-17 2136
android进程间通信 - IPC 定义多进程 Android应用中使用多进程只有一个办法（用NDK的fork来做除外），就是在AndroidManifest.xml中声明组件时，用android:process属性来指定。进程的指定分为3种形式，分别是： 当用户不指定process属性，则默认运行在主进程中，主进程名字为包名。 android:process = “:remote” ...
详解Android 进程间通信的几种实现方式
08-31
- 在服务端实现接口，并在Service中返回实现了接口的IBinder对象。 - 客户端通过bindService方法连接服务，获取到远程服务的代理对象，然后就可以调用接口上的方法了。 总结来说，Android的四种进程间通信方式各...
Android 进程间通信——AIDL
奋斗的菜鸟ing
01-12 2863
AIDL(Android Interface Definition Language)——进程间通信的一种机制。它允许您定义客户端和服务端通过使用进程间通信（IPC）进行通信的编程接口。在Android上，一个进程无法正常访问另一个进程的内存。所以说，他们需要将他们的对象分解成操作系统能够理解的原语，并且把这些对象放在你的边界上。编写这些代码非常繁琐，所以Android使用AIDL来处理它。 D
Binder 跨进程传递对象的原理
最新发布
Lud的博客
02-08 1051
1. binder 传递有哪些方式 2. binder 在传递过程中是怎样存储的 3. binder 对象序列化和反序列化的过程 4. binder 对象在传递过程中驱动做了什么
使用Binder实现进程间传递对象案例
09-20
本资源使用 Binder 实现2个进程间传输用户自定义对象，在不使用 AIDL 的情况下，重写 Stub 类和 Proxy 类，分别配置在服务端和客户端，帮助初学者更好得理解 Binder
Service概述 生命周期 IBinder
sinat_35073873的博客
11-05 592
/* *Service服务:与Activity最相似;都继承了Context;有自己的生命周期;也可作为可执行的程序. *区别是运行在后台,不会有界面. * 使用中如果需要用户交互应该用Activity;否则应该选用Service. * 生命周期方法5个:onCreate() onBind() onStartCommand() onUnbind() onDestroy() * onCreate()
Android5.0 显示系统（三）————Surface的创建
yangguoyu8023的博客
10-19 1978
sp surfaceControl = client->createSurface(String8("resize"), 160, 240, PIXEL_FORMAT_RGB_565, 0); sp surface = surfaceControl->getSurface();
Android6.0 显示系统（六） 图像的输出过程
kc58236582的博客
10-11 1万+
上篇博客分析到SurfaceFlinger收到了VSync信号后，调用了handleMessageRefresh函数，这篇博客主要就是分析这个函数，我们先看看它的代码： void SurfaceFlinger::handleMessageRefresh() { ATRACE_CALL(); static nsecs_t previousExpectedPresent = 0;
[转]IBinder对象在进程间传递的形式
爱技术的蓝胖子
11-30 946
命题 当service经常被远程调用时，我们常常用到aidl来定一个接口供service和client来使用，这个其实就是使用Binder机制的IPC通信。当client bind service成功之后，系统AM会调用回调函数onServiceConnected()将service的IBinder传递给client， client再通过调用aidl生成的asInterface()方法获得serv...
Binder机制初解
daweibalang717的专栏
11-22 3533
简述.... 3 IPC 与 Binder. 3 Binder IPC 程序结构.... 3 Binder层次划分.... 4 驱动层... 4 驱动适配层... 5 Binder核心框架层... 5 Binder框架层... 6 Binder C++ 框架层实现（nativeservice）：.... 7 Binder Java 框架层实现（framework
由浅入深 学习 Android Binder（五）- binder如何在进程间传递
许佳佳的博客
12-12 2503
概述 前文分析过bindService源码，该文章地址如下： 由浅入深 学习 Android Binder（二）- bindService流程 最终得到时序图如下： 如上图，client进程与server进程是通过系统进程来进行通信的。 实际demo中，有两个场景我们会接触到binder： client进程通过serviceConnection获取到系统进程传递的binder。 server进程将service.onbind()返回的binder传递给系统进程。 我们就以server给系统进程传递bi
IBinder在进程之间传递一个对象的形式(一)
weixin_33869377的博客
06-22 140
主张        什么时候service通常被称为远程时的，用到aidl来定一个接口供service和client来使用。这个事实上就是使用Binder机制的IPC通信。当client bind service成功之后。系统AM会调用回调函数onServiceConnected将service的IBinder传递给client， client再通过调用aidl生成的asI...
理解Android AIDL：进程间通信实战指南
在Android系统中，由于进程间的内存不共享，应用程序之间的通信需要借助特定的机制，这就是IPC（Inter-Process Communication）的一种形式：AIDL（Android Interface Definition Language）。AIDL允许开发者定义...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值