Android Binder通信02 - 驱动分析 - 架构介绍

一、前言：

上一篇文章介绍了Binder通信系统Framework（用户态）的架构，并且结合代码说明了下注册ServiceManager，注册服务，注册客户端，客户端和服务端通信的业务场景，本节我们继续深入挖掘下，Framework层调用响应API之后，驱动层（内核态）如何处理的，这才是Binder系统的精髓所在！

二、架构图：

• 在内核态驱动里，会为每一个服务创建一个binder_node，记录了进程的信息，比如：binder_node.proc=server进程；
• ServiceManager启动时候，会在驱动层创建一个全局的binder_node保存到binder_context_mgr_node当中；其他进程都有一个BpServiceManager，它的BpBinder句柄是0，表示binder_context_mgr_node，所以，其他进程都是可以直接和ServiceManager通信的。
• ServiceManager还会再驱动中创建一个binder_ref（是个红黑树），它是binder_node的引用；
• ServiceManager在用户态创建一个服务链表svcinfo，里面保存了name和handle；
• Client向ServiceManager查询某个服务的时候，只需要传入name（因为它好记，友好）；
• ServiceManager就在链表中根据name找到这个节点，将对应的handle（因为它不好记，但是它不容易重复）传给驱动层；
• 驱动程序在ServiceManager的binder_ref红黑树当中，根据handle这个键找到对应的binder_ref;
• 由于binder_ref当中保存了自己是谁的引用，也就是binder_node，因此，我们就获得了binder_node，代表服务；
• 再给Client创建新的binder_ref，驱动就返回一个handle（这里面是desc，从1开始）client；
• 同理，Client要和Service通信，首先，client根据handle找到binder_ref，再根据binder_ref找到binder_node，最后