Android-Framework：Binder全解析（一

最新推荐文章于 2024-07-15 23:09:31 发布

2301_79987255

最新推荐文章于 2024-07-15 23:09:31 发布

阅读量622

点赞数 28

分类专栏： 2024年程序员学习文章标签： android binder java

本文链接：https://blog.csdn.net/2301_79987255/article/details/137215286

版权

2024年程序员学习专栏收录该内容

186 篇文章 0 订阅

订阅专栏

在用户空间，使用ioctl方法系统调用来控制设备。这是方法原型：

/*
fd:文件描述符
cmd:控制命令
…:可选参数:插入argp，具体内容依赖于cmd/
int ioctl(int fd,unsigned long cmd,…);

用户程序所作的只是通过命令码告诉驱动程序它想做什么，至于怎么解释这些命令和怎么实现这些命令，这都是驱动程序要做的事情。所以在用户空间我们想做什么事情都是通过这个方法以命令的形式告诉Binder驱动，Binder驱动收到命令执行相应的操作。

mmap

在刚才的注释2处就是大名鼎鼎的内存映射。内存映射函数mmap，给binder分配一块虚拟地址空间。它会在内核虚拟地址空间中申请一块与用户虚拟内存相同大小的内存，然后再申请物理内存，将同一块物理内存分别映射到内核虚拟地址空间和用户虚拟内存空间，实现了内核虚拟地址空间和用户虚拟内存空间的数据同步操作。

这是函数原型：

//原型
/*
addr: 代表映射到进程地址空间的起始地址，当值等于0则由内核选择合适地址，此处为0；
size: 代表需要映射的内存地址空间的大小，此处为1M-8K；
prot: 代表内存映射区的读写等属性值，此处为PROT_READ(可读取);
flags: 标志位，此处为MAP_PRIVATE(私有映射，多进程间不共享内容的改变)和 MAP_NORESERVE(不保留交换空间)
fd: 代表mmap所关联的文件描述符，此处为mDriverFD；
offset：偏移量，此处为0。

此处 mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
/
void mmap(void* addr, size_t size, int prot, int flags, int fd, off_t offset)

总的来说，ProcessState做了两件事情，一是打开Binder驱动并返回文件操作符fd，二是通过mmap为Binder分配了一块虚拟内存空间，以达到内存映射的目的。

MediaPlayerService::instantiate

这个方法呢就是注册服务：

void MediaPlayerService::instantiate() {
//注册服务
defaultServiceManager()->addService(String16(“media.player”), new MediaPlayerService());
}

defaultServiceManager返回的是BpServiceManager，这里先不讲BpServiceManager，你只需要知道BpServiceManager它实现了IServiceManager，并且通过内部有一个变量mRemote= BpBinder，BpBinder用来实现跨进程通信。故此处等价于调用BpServiceManager->addService。

BpBinder是Client端与Server交互的代理类，而BBinder则代表了Server端。BpBinder和BBinder是一一对应的。BpBinder会通过handle来找到对应的BBinder。在ServiceManager中创建了BpBinder，通过handle(值为0)可以找到对应的BBinder。

来看一下具体代码

//frameworks/native/libs/binder/IServiceManager.cpp
virtual status_t addService(const String16& name, const sp& service, bool allowIsolated) {
Parcel data, reply; //Parcel是数据通信包
//写入头信息"android.os.IServiceManager"
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name); // name为 “media.player”
data.writeStrongBinder(service); // MediaPlayerService对象
data.writeInt32(allowIsolated ? 1 : 0); // allowIsolated= false
//remote()指向的是BpBinder对象
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}

服务注册过程：向ServiceManager注册服务MediaPlayerService，服务名为”media.player”。addService函数的作用就是将请求数据打包成data，然后传给BpBinder的transact函数。

data.writeStrongBinder(service)这行代码中，将Binder对象进行了扁平化，转换成flat_binder_object对象。

对于Binder实体，则cookie记录Binder实体的指针；
对于Binder代理，则用handle记录Binder代理的句柄；(句柄这个翻译真的是脑残，你可以直接理解为ID或者编号)

BpBinder::transact

我们看一下transact函数:

// frameworks/native/libs/binder/BpBinder.cpp
status_t BpBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
if (mAlive) {
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}

return DEAD_OBJECT;
}

Binder代理类调用transact()方法，真正工作还是交给IPCThreadState来进行transact工作。先来看看IPCThreadState::self的过程。

IPCThreadState::self

//frameworks/native/libs/binder/IPCThreadState.cpp
IPCThreadState* IPCThreadState::self()
{
if (gHaveTLS) {
restart:
const pthread_key_t k = gTLS;
IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k);
if (st) return st;
return new IPCThreadState; //初始IPCThreadState
}

if (gShutdown) return NULL;

pthread_mutex_lock(&gTLSMutex);
if (!gHaveTLS) { //首次进入gHaveTLS为false
if (pthread_key_create(&gTLS, threadDestructor) != 0) { //创建线程的TLS
pthread_mutex_unlock(&gTLSMutex);
return NULL;
}
gHaveTLS = true;
}
pthread_mutex_unlock(&gTLSMutex);
goto restart;
}

TLS是指Thread local storage(线程本地储存空间)，每个线程都拥有自己的TLS，并且是私有空间，线程之间不会共享。通过pthread_getspecific/pthread_setspecific函数可以获取/设置这些空间中的内容。从线程本地存储空间中获得保存在其中的IPCThreadState对象。这里可以得知IPCThreadState::self()实际上是为了创建IPCThreadState.

IPCThreadState

//frameworks/native/libs/binder/IPCThreadState.cpp
IPCThreadState::IPCThreadState()
: mProcess(ProcessState::self()),
mMyThreadId(gettid()),
mStrictModePolicy(0),
mLastTransactionBinderFlags(0)
{
pthread_setspecific(gTLS, this);
clearCaller();
mIn.setDataCapacity(256);
mOut.setDataCapacity(256);
}

pthread_setspecific函数用于设置TLS，将IPCThreadState::self()获得的TLS和自身传进去。每个线程都有一个IPCThreadState，每个IPCThreadState中都有一个mIn、一个mOut,它们都是Parcel对象。成员变量mProcess保存了ProcessState变量(每个进程只有一个)。

mIn 用来接收来自Binder设备的数据，默认大小为256字节；
mOut用来存储发往Binder设备的数据，默认大小为256字节。

那这里构造完了，看一下IPCThreadState的transact函数：

IPCThreadState::transact

status_t IPCThreadState::transact(int32_t handle,
uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags)
{
status_t err = data.errorCheck(); //数据错误检查
flags |= TF_ACCEPT_FDS;
…
if (err == NO_ERROR) { // 传输数据
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 {
//oneway，则不需要等待reply的场景
err = waitForResponse(NULL, NULL);
}
return err;
}

IPCThreadState进行transact事务处理分3部分：

errorCheck() //数据错误检查
writeTransactionData() // 传输数据
waitForResponse() //等待响应

其中writeTransactionData函数用于传输数据，其中第一个参数BC_TRANSACTION代表向Binder驱动发送命令协议，向Binder设备发送的命令协议都以BC_开头，而Binder驱动返回的命令协议以BR开头。

我们就要看看到底是怎么写进去数据的：

IPCThreadState.writeTransactionData

//frameworks/native/libs/binder/IPCThreadState.cpp
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.ptr = 0;
tr.target.handle = handle; // handle = 0
tr.code = code; // code = ADD_SERVICE_TRANSACTION
tr.flags = binderFlags; // binderFlags = 0
tr.cookie = 0;
tr.sender_pid = 0;
tr.sender_euid = 0;

// data为记录Media服务信息的Parcel对象
const status_t err = data.errorCheck();
if (err == NO_ERROR) {
tr.data_size = data.ipcDataSize(); // mDataSize
tr.data.ptr.buffer = data.ipcData(); //mData
tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t); //mObjectsSize
tr.data.ptr.offsets = data.ipcObjects(); //mObjects
} else if (statusBuffer) {
…
} else {
return (mLastError = err);
}

mOut.writeInt32(cmd); //cmd = BC_TRANSACTION
mOut.write(&tr, sizeof(tr)); //写入binder_transaction_data数据
return NO_ERROR;
}

binder_transaction_data结构体是binder驱动通信的数据结构，该过程最终是把Binder请求码BC_TRANSACTION和binder_transaction_data结构体写入到mOut。其中handle的值用来标识目的端，注册服务过程的目的端为service manager，此处handle=0所对应的是binder_context_mgr_node对象，正是service manager所对应的binder实体对象。

transact方法中执行完writeTransactionData方法后，接下来就会执行waitForResponse()方法

IPCThreadState.waitForResponse

//frameworks/native/libs/binder/IPCThreadState.cpp
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
uint32_t cmd;
int32_t err;
while (1) {
if ((err=talkWithDriver()) < NO_ERROR) break;//1
err = mIn.errorCheck();
if (err < NO_ERROR) break;
if (mIn.dataAvail() == 0) continue;
cmd = (uint32_t)mIn.readInt32();
switch (cmd) {
case BR_TRANSACTION_COMPLETE:
if (!reply && !acquireResult) goto finish;
break;

case BR_DEAD_REPLY:
err = DEAD_OBJECT;
goto finish;
…
default:
//处理各种命令协议
err = executeCommand(cmd);
if (err != NO_ERROR) goto finish;
break;
}
}
finish:
…
return err;
}

这里开启了一个死循环，然后从talkWithDriver()方法中发送并读取数据。在waitForResponse过程, 首先执行BR_TRANSACTION_COMPLETE；另外，目标进程也就是Server端收到事务后，处理BR_TRANSACTION事务。然后发送给当前进程也就是Client端，再执行BR_REPLY命令。这是通信的具体流程：

[图片上传中…(image-683419-1599468127794-12)]

Binder协议包含在IPC数据中，分为两类:

BINDER_COMMAND_PROTOCOL：binder请求码，以”BC_“开头，简称BC码，用于从IPC层传递到Binder Driver层；
BINDER_RETURN_PROTOCOL ：binder响应码，以”BR_“开头，简称BR码，用于从Binder Driver层传递到IPC层；

在这个过程中, 收到以下任一BR_命令，处理后便会退出waitForResponse()的状态:

BR_TRANSACTION_COMPLETE: binder驱动收到BC_TRANSACTION事件后的应答消息; 对于oneway transaction,当收到该消息,则完成了本次Binder通信;
BR_DEAD_REPLY: 回复失败，往往是线程或节点为空. 则结束本次通信Binder;
BR_FAILED_REPLY:回复失败，往往是transaction出错导致. 则结束本次通信Binder;
BR_REPLY: Binder驱动向Client端发送回应消息; 对于非oneway transaction时,当收到该消息,则完整地完成本次Binder通信;

talkWithDriver()这个方法是真正的向内核发送消息的方法。这是talkWithDriver：

IPCThreadState.talkWithDriver()

//frameworks/native/libs/binder/IPCThreadState.cpp
status_t IPCThreadState::talkWithDriver(bool doReceive)
{
…
//和Binder驱动通信的结构体
binder_write_read bwr;
//mIn是否有可读的数据，接收的数据存储在mIn
const bool needRead = mIn.dataPosition() >= mIn.dataSize();
const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;

bwr.write_size = outAvail;
//将要发送给Binder设备的消息填充到与Binder通信的结构体中
bwr.write_buffer = (uintptr_t)mOut.data();

if (doReceive && needRead) {
//接收数据缓冲区信息的填充。如果以后收到数据，就直接填在mIn中了。
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} else {
bwr.read_size = 0;
bwr.read_buffer = 0;
}
//当读缓冲和写缓冲都为空，则直接返回
if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;

bwr.write_consumed = 0;
bwr.read_consumed = 0;
status_t err;
do {
//通过ioctl不停的读写操作，跟Binder Driver进行通信
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
…
} while (err == -EINTR); //当被中断，则继续执行
…
return err;
}

跟内核通讯都是通过ioctl方法进行的。在前面的介绍中已经讲解了这个方法的原型。binder_write_read结构体用来与Binder设备交换数据的结构, 通过ioctl与mDriverFD通信，是真正与Binder驱动进行数据读写交互的过程。主要是操作mOut和mIn变量。

binder_write_read是整个Binder IPC过程，最为核心的数据结构之一。

看懵了？捋一下思路，数据的转变是这样的：

IServiceManager.addService()方法将数据打包为Parcel---->IPCThreadState.writeTransactionData()将Parcel打包为binder_transaction_data----->IPCThreadState.talkWithDriver()方法将binder_transaction_data打包为binder_write_read。

接下来就要进入到内核Binder中了。

Binder Driver

在了解Binder驱动之前，首先我们来了解一个概念，就是 binder_procs。什么是 binder_procs，binder_procs是一个链表。对于底层Binder驱动，通过 binder_procs 链表记录所有创建的 binder_proc 结构体，binder 驱动层的每一个 binder_proc 结构体都与用户空间的一个用于 binder 通信的进程一一对应。可以理解为，一个binder_proc 结构体对应一个服务进程，而binder_procs记录了所有的binder_proc 结构体。

每个进程有且只有一个 ProcessState 对象(上文中用来打开Binder驱动并分配内存的那个家伙)，这是通过单例模式来保证的。在每个进程中可以有很多个线程，每个线程对应一个 IPCThreadState(上文中用来发送通信数据给Binder驱动的那个家伙)对象，IPCThreadState 对象也是单例模式，即一个线程对应一个 IPCThreadState 对象，在 Binder 驱动层也有与之相对应的结构，那就是 Binder_thread 结构体。在 binder_proc 结构体中通过成员变量 rb_root threads，来记录当前进程内所有的 binder_thread。

对于一个binder_proc，也就是一个服务进程来说。它有四个非常重要的结构体，分别是binder_thread，binder_node，binder_ref，binder_buffer。

Binder实体对象binder_node，表示当前进程提供了哪些binder服务；

可以将binder_proc理解为一个进程，而将binder_noder理解为一个Service。binder_proc里面有一个红黑树，用来保存所有在它所描述的进程里面创建Service。而每一个Service在Binder驱动里面都有一个binder_node来描述。

Binder引用对象binder_ref，表示哪些进程持有当前进程的binder的引用；每一个Clinet在驱动中都有一个binder_ref和他对应，内部有对应的进程信息binder_proc和binder_node信息。client端拿着BpBinder引用对象，在驱动层对应着binder_ref，就可以找到binder_proc和binder_node信息，找到指定的进程可以实现交互。
Binder_thread，进程在启动时会创建一个binder线程池，并向其中注册一个Binder线程；驱动发现没有空闲binder线程时会向Server进程注册新的的binder线程。对于一个Server进程有一个最大Binder线程数限制，默认为16个binder线程。对于所有Client端进程的binder请求都是交由Server端进程的binder线程来处理的。
binder_buffer 内核缓冲区，用以在进程间传递数据。Binder驱动将Binder进程的内存分成一段一段进行管理，而这每一段则是使用binder_buffer来描述的。

上图是从结构体的角度来看待binder_procs，我们换个角度，从进程与线程的角度来看一下是什么样

有的小伙伴会发现，在Binder_proc或者binder_thread中有个list_head todo这样的东西。这是个什么东西呢？list_head看名字就知道了是个头结点，todo呢？是要做的事情。没错，这个是用来保存要做的事情的队列。

在Binder驱动层，每个接收端进程都有一个todo队列，用于保存发送端进程发送过来的binder请求，这类请求可以由接收端进程的任意一个空闲的binder线程处理；接收端进程存在一个或多个binder线程，在每个binder线程里都有一个todo队列，也是用于保存发送端进程发送过来的binder请求，这类请求只能由当前binder线程来处理。也就是说对于进程间的通信，就是发送端把binder_transaction节点，插入到目标进程或其子线程的todo队列中，等目标进程或线程不断循环地从todo队列中取出数据并进行相应的操作。

那么接下来看一下内核中是怎么做的吧。

先看一下调用链:

ioctl -> binder_ioctl -> binder_ioctl_write_read

binder_ioctl_write_read

//binder.c
static int binder_ioctl_write_read(struct file *filp,
unsigned int cmd, unsigned long arg,
struct binder_thread *thread)
{
struct binder_proc *proc = filp->private_data;
void __user *ubuf = (void __user *)arg;
struct binder_write_read bwr;

//将用户空间bwr结构体拷贝到内核空间
copy_from_user(&bwr, ubuf, sizeof(bwr));
…

if (bwr.write_size > 0) {
//将数据放入目标进程
ret = binder_thread_write(proc, thread,
bwr.write_buffer,
bwr.write_size,
&bwr.write_consumed);
…
}
if (bwr.read_size > 0) {
//读取自己队列的数据
ret = binder_thread_read(proc, thread, bwr.read_buffer,
bwr.read_size,
&bwr.read_consumed,
filp->f_flags & O_NONBLOCK);
if (!list_empty(&proc->todo))
wake_up_interruptible(&proc->wait);
…
}

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

最后

下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。希望能够帮助到大家提升技术

高级UI，自定义View

UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。

不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！

体系化！**

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-JthUf30n-1711915586470)]

最后

下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。希望能够帮助到大家提升技术

[外链图片转存中…(img-cLshNSBK-1711915586470)]

高级UI，自定义View

UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。

不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！

[外链图片转存中…(img-uTCktlos-1711915586471)]

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录

2301_79987255

关注

28
点赞
踩
16

收藏

觉得还不错? 一键收藏
0
评论
Android-Framework：Binder全解析（一

下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。希望能够帮助到大家提升技术高级UI，自定义ViewUI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！体系化！**由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新。
复制链接

扫一扫