需要掌握的点
1.一个流程：servier--->binder---->servermanager ** server注册的流程图一个整体的类和方法流向**
2.重要的几个方法：open ,mmap ,iocontro。特别是mmap内存映射 （图片解析）
3.唤醒流程图，bp和br
4.binder_thread_write 和 binder_thread_read 和 copy_from_user 和copy_to_user
5.Java层，分析总的一个流程图，4个角色的关系和代理的关系。从一个activityManager开始！
6.数据流向?
- 流程总结：
[图片上传失败...(image-9fecb0-1643110660184)]
1).Binder 驱动的全局链表 binder_procs 中插入服务端的信息（binder_proc 结构体，每个 binder_proc 结构体中都有 todo 任务队列），然后向 ServiceManager 的 svcinfo 列表中缓存一下注册的服务。
2). 有了服务端，客户端就可以跟服务端通讯了，通讯之前需要先获取到服务，拿到服务的代理，也可以理解为引用
获取服务端的方式就是通过 ServiceManager 向 svcinfo 列表中查询一下返回服务端的代理，svcinfo 列表就是所有已注册服务的通讯录，保存了所有注册的服务信息。
3）.有了服务端的引用我们就可以向服务端发送请求了，通过 BinderProxy 将我们的请求参数发送给 ServiceManager，通过共享内存的方式使用内核方法 copy_from_user() 将我们的参数先拷贝到内核空间，这时我们的客户端进入等待状态，然后 Binder 驱动向服务端的 todo 队列里面插入一条事务，执行完之后把执行结果通过 copy_to_user() 将内核的结果拷贝到用户空间（这里只是执行了拷贝命令，并没有拷贝数据，binder只进行一次拷贝），唤醒等待的客户端并把结果响应回来，这样就完成了一次通讯。
2.重要的几个方法：open ,mmap ,iocontro。特别是mmap内存映射
内存的拷贝次数有几次？
肯定不是 1 次，服务端把数据拷到内核再拷回去 2 次，客户端把数据拷到内核再拷回去 2 次，还有一次是客户端把数据拷到服务端映射的内存中，还有一次是从服务端的映射内存拷贝到驱动层创建的内存。6 次拷贝
[图片上传失败...(image-36616-1643110660185)]
一次拷贝的过程：
发送方进程通过系统调用 copyfromuser() 将数据 copy 到内核中的内(这一次拷贝)，核缓存区，
由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。
Binder在一次拷贝中的作用则是怎么样的？
连接 两个进程，实现了mmap()系统调用，主要负责 创建数据接收的缓存空间 & 管理数据接收缓存
3、唤醒流程图，bp和br 解析
内核层内核层的通信都是通过ioctl来进行的，client打开一个ioctl,进入到轮询队列，一直阻塞直到时间到或者有消息。
[图片上传失败...(image-f9baa9-1643110660185)]
流程：
1.开始servermanager处于等待状态
2.然后media进程发送BP_transation
3.binder收到后发送br_transation。把servermanager唤醒，同时br_transtation_complete发送给客户端
4.客户端收到指令后，客户端处于等待的状态！
5.同上serverManager收到指令后。开始执行执行完后发送br_replay给binder驱动。同时还会发送
br_transtation_complete给servermanager。binder驱动发送br_rep给客户端唤醒
问题：
.是先serverManager在进行循环等待吗？然后客户端进行请求add吗？
4.binder_thread_write 和 binder_thread_read 和 copy_from_user 和copy_to_user 关系
binder_thread_write :主要作用:
binder_thread_read :主要作用：
copy_from_user :主要作用：
copy_to_user :主要作用：
调用流程：
binder_ioctl
binder_ioctl_write_read
copy_from_user
binder_thread_write
binder_thread_read
copy_to_user
binder_thread_write里面又会调用 copy_from_user
static int binder_thread_write(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed)
{
return_error == BR_OK) {
switch (cmd) {
...
case BC_TRANSACTION:
case BC_REPLY: {
struct binder_transaction_data tr;
// 把数据从用户空间拷贝到内核空间 binder_transaction_data
if (copy_from_user(&tr, ptr, sizeof(tr)))
binder_transaction(proc, thread, &tr, cmd == BC_REPLY);
break;
}
}
return 0;
binder_thread_read里面又会调用copy_to_user
static int binder_thread_read(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed, int non_block)
{
// 开始不断循环读取数据
switch (w->type) {
case BINDER_WORK_TRANSACTION: {
ptr += sizeof(uint32_t);
// 把数据拷贝到用户空间
if (copy_to_user(ptr, &tr, sizeof(tr)))
static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
int ret;
// 从 filp 获取 binder_proc
struct binder_proc *proc = filp->private_data;
struct binder_thread *thread;
// 进入休眠直到中断被唤醒
ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);
if (ret)
goto err_unlocked;
// 从 binder_proc 获取 binder 线程
thread = binder_get_thread(proc);
switch (cmd) {
case BINDER_WRITE_READ:
ret = binder_ioctl_write_read(filp, cmd, arg, thread);
static int binder_ioctl_write_read(struct file *filp,
unsigned int cmd, unsigned long arg,
struct binder_thread *thread)
{
int ret = 0;
// 从 filp 中获取 binder_proc
struct binder_proc *proc = filp->private_data;
// arg 是上层传下来的 binder_write_read 的结构体对象地址
struct binder_write_read bwr;
// 将用户空间的 binder_write_read 拷贝到内核空间的 bwr
if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {
ret = -EFAULT;
goto out;
}
// 进入这里不断的读取数据
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);
trace_binder_read_done(ret);
if (!list_empty(&proc->todo))
wake_up_interruptible(&proc->wait);
if (ret < 0) {
if (copy_to_user(ubuf, &bwr, sizeof(bwr)))
ret = -EFAULT;
goto out;
}
}
// 将内核空间的 bwr 数据拷贝到用户空间的 binder_write_read
if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {
ret = -EFAULT;
goto out;
}
out:
return ret;
}
static int binder_thread_read(struct binder_proc *proc,
struct binder_thread *thread,
binder_uintptr_t binder_buffer, size_t size,
binder_size_t *consumed, int non_block)
{
void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
// 如果线程事务栈和 todo 队列都为空，说明此时没有要当前线程处理的任务，将增加空闲线程的计数器（即将 wait_for_proc_work 设为1），让线程等待在**进程**的 wait 队列上
wait_for_proc_work = thread->transaction_stack == NULL && list_empty(&thread->todo);
if (wait_for_proc_work)
proc->ready_threads++;
binder_unlock(__func__);
if (wait_for_proc_work) {
if (!(thread->looper & (BINDER_LOOPER_STATE_REGISTERED | BINDER_LOOPER_STATE_ENTERED))) {
// 线程还未进入 binder 循环，输出错误信息，并阻塞直到 binder_stop_on_user_error 小于2
wait_event_interruptible(binder_user_error_wait,
binder_stop_on_user_error < 2);
}
binder_set_nice(proc->default_priority);
// 非阻塞
if (non_block) {
...
} else{
// 如果是阻塞的读操作，则让进程阻塞在 proc 的 wait 队列上，直到 binder_has_proc_work(thread) 为 true，即进程有工作待处理
ret = wait_event_freezable_exclusive(proc->wait, binder_has_proc_work(proc, thread));
}
} else {
...
}
// 下面的代码目前还执行不到，需要等待 thread 线程的 todo 里面有内容
return 0;
}来源： https://www.jianshu.com/p/4472c7dabe6c
[图片上传失败...(image-c656fd-1643110660184)]
5.java层调用
[图片上传失败...(image-f837a8-1643110660184)]
但是上面还有个问题就是client和service要直接和binder driver打交道，但是实际上client和service并不想知道binder相关协议，所以进一步client通过添加proxy代理，service通过添加stub来进一步处理与binder的交互。
[图片上传失败...(image-b7ea4c-1643110660184)]
这样的好处是client和service都可以不用直接去和binder打交道。上面的图好像已经很完善了，但是Android系统更进一步封装，不让client知道Binder的存在，Android系统提供了Manager来管理client。如下图：
[图片上传失败...(image-14601e-1643110660184)]
这样client只需要交给manager来管理就好了，根本就不用关心进程通信相关的事，关于manager其实是很熟悉的，比如说activity的就是由ActivityManager来控制的，ActivityManager是通过Binder获取ActivityManagerService来控制activity的。这样就不用我们自己来使用Binder来ActivityManagerService通信了。
在service和binder之间还有一个contextManager，也就是serviceManage
总结流程：
注册服务过程：就是前面4篇文章讲的
第一步： service通过调用serviceManager中的addService方法，然后调用ServiceManagerNative类中的addservice(name)方法。
第二步： ServiceManagerNative会通过Binder发送一条SVG_MGR_ADD_SERVICE的指令，然后通过svcmgr_handler()调用do_add_service（）方法往svc_list中添加相应的service。
重点：所有的服务都要先注册到svc_list中才能被client调用到。svc_list以linkedlist的形式保存这些服务。
获取服务过程：
第一步：client要请求服务，比如说在activity中调用context.getSystemService()方法，这个时候serviceManager就会使用getService（name），然后就会调用到native层中的ServiceManagerNative类中的getService(name)方法。
第二步：ServiceManagerNative会通过Binder发送一条SVG_MGR_GET_SERVICE的指令，然后通过svcmgr_handler()调用do_find_service（）方法去svc_list中查找到相关的service。
第三步：查找到相应的服务后就会通过Binder将服务传给ServiceManagerNative，然后传给serviceManager，最后client就可以使用了。
注意： 服务实在svclist中保存的，svclist是一个链表，因此客户端调用的服务必须要先注册到svclist中。