binder机制（上篇）

最新推荐文章于 2023-06-14 11:49:28 发布
最新推荐文章于 2023-06-14 11:49:28 发布
阅读量861 收藏 1
点赞数
分类专栏： Android系统源代码分析 文章标签： 工作
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/GetNextWindow/article/details/47293751
版权

问题：binder到底是如何从代理对象找到其对应的binder实体的呢？要回答这个就必须要看Binder驱动如何工作的。

1.Binder设备文件的打开

一个进程在使用Binder机制进行通信之前，必须打开设备文件/dev/binder来获取一个文件描述符，然后才能通过这个文件描述符和Binder驱动进行交互，进程调用open函数打开/dev/binder的时候,binder_open会被调用，实现如下： 

static int binder_open(struct inode *nodp, struct file *filp)
{
    struct binder_proc *proc;
    . . . . . .
    proc = kzalloc(sizeof(*proc), GFP_KERNEL);

    get_task_struct(current);
    proc->tsk = current;
    . . . . . .
    hlist_add_head(&proc->proc_node, &binder_procs);
    proc->pid = current->group_leader->pid;
    . . . . . .
    filp->private_data = proc;
    . . . . . .
}

来自网络
首先创建一个binder_proc结构体，接下来就进行proc的初始化工作，并将proc加入全局双向链表binder_procs当中，Binder驱动程序将所有打开设备文件/dev/binder的进程都加入到binder_procs当中，因此，通过遍历这个链表就可以知道系统当前有多少进程在使用Binder进程间通信机制。filp->private_data=proc;将新创建的proc保存在当前文件的private_data变量中，参数filep指向一个打开的文件结构体。进程以后调用binder_ioctl与驱动程序交互式，会将struct file结构体传过去，从file结构体的private_data字段就可以得到proc。

1.1 binder_proc介绍

struct binder_proc
{
    struct hlist_node proc_node;
    struct rb_root threads;
    struct rb_root nodes;
    struct rb_root refs_by_desc;
    struct rb_root refs_by_node;
    int pid;
    . . . . . .
    . . . . . .
};

binder_proc用来描述正在使用binder机制的进程。上面也提到，每当进程打开/dev/binder时，binder驱动就会为其创建binder_proc
结构体。每一个使用Binder进程通信机制的进程都有一个binder线程池，用来出来通信请求，这个Binder线程池是由Binder驱动程序来维护的。成员变量threads是红黑树节点，它以线程ID作为关键字来组织一个进程中的binder线程池，进程可以调用ioctl函数将线程注册到binder驱动程序当中。
一个进程内部包含了一系列的Binder实体对象和Binder引用对象，进程使用三个红黑树描述。nodes组织binder实体对象，以binder实体对象的ptr作为关键字；refs_by_desc和refs_by_node用来组织Binder引用对象，前者以Binder引用对象的desc作为关键字，后者以node作为关键字。
来自网络
有了binder_ref和binder_node知识，我们就可以解释BpBinder到底如何和BBinder联系上的。OK我们已经可以更深入的说明Binder
句柄的作用了，比如进程1的BpBinder发起跨进程调用，向binder驱动传入自己记录的句柄值，binder驱动就会在进程1对应的binder_proc结构的引用树种查找和句柄值相等的binder_ref节点，一旦找到binder_ref节点，就可以通过该节点的node域找到对应的binder_node节点，这个目标binder_node当然是从属进程2的binder_proc啦，不过不要紧，因为binder_ref和binder_node都处于binder驱动的地址空间中，所以是可以用指针直接指向的。目标binder_node节点的cookie域，记录的其实是进程2中BBinder的地址，binder驱动只需把这个值反映给应用层，应用层就可以直接拿到BBinder了。这就是Binder完成精确打击的大体过程。如下图：
这里写图片描述

2. BpBinder和IPCThreadState

从名字上看，IPCThreadState是“和跨进程通信（IPC）相关的线程状态”。那么很显然，一个具有多个线程的进程里应该会有多个IPCThreadState对象了，只不过每个线程只需一个IPCThreadState对象而已。这有点儿“局部单例”的意思。所以，在实际的代码中，IPCThreadState对象是存放在线程的局部存储区（TLS）里的。
IPCThreadState类中含有一个成员变量mProcess,它指向一个ProcessState对象，从名字上看“进程状态”就知道它是进程相关，是进程范围内唯一的。ProcessState负责初始化Binder设备，即打开设备文件/dev/binder,以及将设备文件映射到进程的地址空间。Binder线程中的每个线程都可以通过它来和Binder驱动建立连接。

2.1 BpBinder的transact函数

每当我们利用BpBinder的transact函数发起一次跨进程事物时，其内部都是调用IPCThreadState对象的transact,如下：

status_t BpBinder::transact(uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags)
{
    // Once a binder has died, it will never come back to life.
    if (mAlive)
    {
        status_t status = IPCThreadState::self()->transact(mHandle, code, data, reply, flags);
        if (status == DEAD_OBJECT) mAlive = 0;
        return status;
    }

    return DEAD_OBJECT;
}

当然进程中的BpBinder可能被多个线程使用，所以发起传输的IPCThreadState对象可能并不是同一个对象，不过没关系，因为这些ICPThreadState对象可能最终使用同一个ProcessState对象。

2.1.1

调用IPCThreadState的transact

status_t IPCThreadState::transact(int32_t handle,
                                  uint32_t code, const Parcel& data,
                                  Parcel* reply, uint32_t flags)
{
    . . . . . .
        // 把data数据整理进内部的mOut包中
        err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
    . . . . . .

    if ((flags & TF_ONE_WAY) == 0)
    {
        . . . . . .
        if (reply)
        {
            err = waitForResponse(reply);
        }
        else
        {
            Parcel fakeReply;
            err = waitForResponse(&fakeReply);
        }
        . . . . . .
    }
    else
    {
        err = waitForResponse(NULL, NULL);
    }

    return err;
}

IPCThreadState::transact()会先调用writeTransactionData()函数将data数据整理进内部的mOut包中，这个函数的代码如下：

status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
                                              int32_t handle, uint32_t code,
                                              const Parcel& data, status_t* statusBuffer)
{
    binder_transaction_data tr;

    tr.target.handle = handle;
    tr.code = code;
    tr.flags = binderFlags;
    tr.cookie = 0;
    tr.sender_pid = 0;
    tr.sender_euid = 0;

    . . . . . .
        tr.data_size = data.ipcDataSize();
        tr.data.ptr.buffer = data.ipcData();
        tr.offsets_size = data.ipcObjectsCount()*sizeof(size_t);
        tr.data.ptr.offsets = data.ipcObjects();
    . . . . . .

    mOut.writeInt32(cmd);
    mOut.write(&tr, sizeof(tr));

    return NO_ERROR;
}

真正完成跨进程事务的是waitForResponse函数，代码如下：

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
    int32_t cmd;
    int32_t err;

    while (1)
    {
        // talkWithDriver()内部会完成跨进程事务
        if ((err = talkWithDriver()) < NO_ERROR)
            break;

        // 事务的回复信息被记录在mIn中，所以需要进一步分析这个回复
        . . . . . .
        cmd = mIn.readInt32();
        . . . . . .
        switch (cmd)
        {
        case BR_TRANSACTION_COMPLETE:
            if (!reply && !acquireResult) goto finish;
            break;

        case BR_DEAD_REPLY:
            err = DEAD_OBJECT;
            goto finish;

        case BR_FAILED_REPLY:
            err = FAILED_TRANSACTION;
            goto finish;
        . . . . . .
        . . . . . .
        default:
            // 注意这个executeCommand()噢，它会处理BR_TRANSACTION的。
            err = executeCommand(cmd);
            if (err != NO_ERROR) goto finish;
            break;
        }

2.1.2 talkWithDriver

waitForResponse是通过talkWithDriver来和Binder驱动打交道的，最终会调用ioctl函数，因为ioctl函数在传递BINDER_WRITE_READ意义时，使用输入缓冲区和输出缓冲区，所以IPCThreadState有Parcel类型的成员变量，mIn、mOut,将mOut内容发出去，发送后的回复写入mIn。
talkWithDriver代码如下：

status_t IPCThreadState::talkWithDriver(bool doReceive)
{
    . . . . . .
    binder_write_read bwr;

    . . . . . .
    bwr.write_size = outAvail;
    bwr.write_buffer = (long unsigned int)mOut.data();
    . . . . . .
        bwr.read_size = mIn.dataCapacity();
        bwr.read_buffer = (long unsigned int)mIn.data();
    . . . . . .
    . . . . . .
    do
    {
        . . . . . .
        if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
            err = NO_ERROR;
        . . . . . .
    } while (err == -EINTR);

    . . . . . .
    . . . . . .
    return err;
}

mIn、mOut会封装成binder_write_read结构，然后在传给ioctl函数。最关键的当然是ioctl了，此时使用的文件描述符就是ProcessState中记录的mDriverFD,说明是想binder驱动传递语义，至此应用程序通过BpBinder向远端传输的过程就清楚了，数据传送到Binder驱动，就看binder驱动做哪些动作，留到中篇解析。

nginux
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Binder概述，快速了解Binder体系
2401_83704159的博客
03-30 959
简历首选内推方式，速度快，效率高啊！然后可以在拉钩，boss，脉脉，大街上看看。简历上写道熟悉什么技术就一定要去熟悉它，不然被问到不会很尴尬！做过什么项目，即使项目体量不大，但也一定要熟悉实现原理！不是你负责的部分，也可以看看同事是怎么实现的，换你来做你会怎么做？做过什么，会什么是广度问题，取决于项目内容。但做过什么，达到怎样一个境界，这是深度问题，和个人学习能力和解决问题的态度有关了。大公司看深度，小公司看广度。大公司面试你会的，小公司面试他们用到的你会不会，也就是岗位匹配度。面试过程一定要有礼貌！
图解Android中的binder机制
02-24
这些问题只是了解binder机制是不够的，需要从Android的整体系统出发来分析，在我找了很多资料后，真正的弄懂了binder机制，相信看完这篇文章大家也可以弄懂binder机制。要理解binder，先要知道IPC，Inter-process...
让你一看就明白的binder机制
关山口男子职业技术学院的猿猴
05-15 1506
写在前面网上有很多学习android binder机制的文章和博客，但是大部分或者是深入native不能自拔，看的云里雾里（本人一直使用java，C语言较渣）；或者是只讲理论缺乏实际编程的过程。所以就想总结下binder的基本理论并附带一个基于Aidl的进程间的通讯的Demo，希望能对初步接触android binder机制的小伙伴们提供些帮助。当然本人能力有限，如有错误之处还请指教。binder机
Binder 服务调用 和主线程的关系（1）
lsdmx2016的总结
12-19 4315
1.Binder服务的调用对象和Binder服务处于同一进程 　　　   在这种情况下，Binder 服务的调用对象调用服务方法的代码所在线程和 Binder服务执行所调用的方法的代码所在的线程，属于同一个线程。这个可以通过打印log 去验证。比如 应用程序A，的某个Activity在 AsyncTask 中访问 Binder 服务，这个Binder服务在应用程序A中的android.app.S
Android Binder机制浅谈以及使用Binder进行跨进程通信的俩种方式（AIDL以及直接利用Binder的transact方法实现）
最新发布
XJ200012的博客
06-14 5166
此篇文章是对Binder的学习以及使用Binder的方式和总结，图文并茂，附上源码说明
Android Binder服务端被调用，一定是运行在Binder线程中吗？
long117long的专栏
07-15 741
不一定。 如果是跨进程调用，即Binder的代理(proxy)端和Binder的服务(Server)端是不同的进程， 则Binder服务端方法执行是在Binder线程中的， 比如：打印线程名，Thread.currentThread().toString()为： Thread[Binder:19118_3,5,main] 但如果，Binder的代理(proxy)端和Binder的服务(Server)端是在同一个进程， 则Binder服务端方法执行的线程跟Binder代理...
Binder工作机制
02-10
Binder是Android系统中的一种核心组件，它作为进程间通信（IPC，Inter-Process ...同时，理解Binder机制还有助于理解Android的组件生命周期、权限管理等高级特性，从而编写出更加健壮和高效的Android应用。
3分钟带你看懂android中的Binder机制
02-24
而且关于整个Binder机制的复杂程度不是三言两语能描叙清楚的，也害怕自己的理解有些偏差，误导一些朋友（ps:反正也没人看....扎心）所以也参考了很多资料,给大家脑子形成一个完整的概念，比如AIDL的实现原理，Binder...
Binder原理深入解析（二）
Android
09-26 1719
1. Binder概述 从IPC角度来说：Binder是Android中的一种跨进程通信方式，该通信方式在linux中没有，是Android独有； 从Android Driver层：Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder； 从Android Native层：Binder是创建Service Manager以及BpBinder/BBinder模型，搭建与binder驱动的桥梁； 从Android Framework层：Binder是各种Manager（Acti
Binder线程池的启动流程分析
深耕安全技术研究
10-04 408
理论基础 Binder Binder它是android中的一种进程间通信机制，它主要采用的是CS架构模式。 Binder框架中主要涉及到4个角色Client、Server、Service Manager及Binder驱动，其中Client、Server、Service Manager运行在用户空间，Binder驱动运行在内核空间。 线程池 线程池它是一种用于多线程处理形式，处理过程中将任务添加到队列，然后在创建线程后自动启动这些任务。线程池线程都是后台线程。每个线程都使用默认的堆栈大小，以默认的优先级运行，
【SpringBoot】编程式获取配置文件并赋值(Binder.get)
比嗨皮兔
06-13 536
BindResult<Config> configBindResult = Binder.get(environment) .bind("配置文件前缀", LlConfig.class); if (configBindResult.isBound()) { this.config = configBindResult.get(); }
SpringBoot属性绑定Environment和Binder
qq_42383787的博客
12-30 2411
Environment springboot 1.x版本的属性绑定方法。 适合简单属性的获取，不适合复杂对象的绑定。 方法： # 判断是否包含键值 boolean containsProperty(String key); # 获取属性值，如果获取不到返回null String getProperty(String key); ...
源码解读Binder机制三（Clent 端如何获取 Service实例）
milan-xiao-tiejiang的博客
03-30 464
上文的篇幅很长，介绍了ServiceManager的启动流程，以SurfaceFlinger为例，介绍了它的简单启动流程和如何将自身添加到ServiceManager中。这篇了解下Clent端如何获取Service。 ContextThemeWrapper @Override public Object getSystemService(String name) { ...
深入SpringBoot源码（十一）SpringApplication与Environment的绑定（下）
现阶段围绕Java展开
04-21 1099
上一章讲到了SpringApplication的bindToSpringApplication的Binder.get(environment)方法， 这章接着讲Binder的bind方法。 bindToSpringApplication方法通过Binder.get(environment)方法得到了Binder实例，再调用bind(String name, Bindable target)方法使用此 binder的property sources绑定指定的目标Bindable。 public <T
IPCThreadState
liuzhengzlh的博客
09-08 1250
IPCThreadState 在Android中，每个参与Binder通信的线程都会有一个IPCThreadState实例与之关联。我最开始接触到这个类是在BpBinder::transact方法中。 transact 其就是调用的IPCThreadState::transact来完成的数据传输工作，其工作可以分为两步： 发送数据 实际上，writeTransactionData只是将数据转换成binder_transaction_data结构并重新写入到IPCThreadState::mOut中。
架构之Binder 核心原理（一）
weixin_35937808的博客
02-28 354
架构之Binder 核心原理（一） 基本概念 什么是Binder Android中特有的一种跨进程的实现方式，模糊了进程边界，淡化了进程通讯的过程。粘贴应用程序的 “胶水”。Binder无处不在，如媒体播放，音视频捕获，手机传感器，加速度，方位，温度，亮度，startActivity/Service等等。都是由不同的服务 端Server 提供一些服务，供应用程序调用。而应用程序作为客户端与提供...
Binder系列6—获取服务(getService)
bob_fly1984的专栏
05-18 3019
一、 获取服务在Native层的服务注册，我们选择以media为例来展开讲解，先来看看media的类关系图。1.1 类图点击查看大图图解：蓝色: 代表获取MediaPlayerService服务相关的类；绿色: 代表Binder架构中与Binder驱动通信过程中的最为核心的两个类；紫色: 代表注册服务和获取服务的公共接口/父类；二. 获取Media服务2.1 getMediaPlayerServi...
Android源码的Binder权限控制
Liu的博客
07-27 9566
链接：https://www.zhihu.com/question/41003297/answer/89328987 一、源码分析 （1）clearCallingIdentity方法，最终调用如下： int64_t IPCThreadState::clearCallingIdentity() { int64_t token = ((int64_t)mCallingUid<
深入解析Android Binder机制：驱动篇
"理解Android Binder机制的关键在于掌握其驱动层面的实现。本文首先概述了Binder机制的整体架构，并深入探讨了Binder驱动的核心功能。Binder源于BeInc公司的OpenBinder框架，经过发展和定制，现已成为Android系统中...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值