Binder native层源码分析

Binder是Android系统下的IPC通信机制，进程间的通信，包括系统服务的调用，都需要通过Binder来进行。看了很多讲解Binder native层运行原理的书和博客，我大概对native层的Binder运行过程有了一个认识。但总觉得自己对Binder的理解不够深入，无法理解其中很多的实现细节，想要更加深入地理解Binder，还是得自己亲自过一遍源码，做一个总结。

很多书和博客都以系统服务为例子来分析Binder，我曾尝试过抛开系统服务，用一种更一般的方式去分析源码。但Binder实在是太大了，其中牵扯到很多的协议，导致源码中存在众多的分支，多个分支一起分析的方式使得我之前的文章杂乱无章，甚至把我自己也搞晕了。要想讲清楚各种协议，分支间的功能和关系，还是要以某个服务为例子，限定数据的协议，每次分析代码执行过程时仅走一个分支。事实上，分析系统服务的过程基本能把Binder源码中的所有重要分支都走一遍，这也是为什么很多人都选择用系统服务来讲解源码的原因。这是我在写Binder源码分析博文时候绕的弯路，特此记录一下。

在分析之前，首先要知道Binder使用的IPC模型是远程过程调用，是基于消息的IPC，消息在Binder中被称为事务。接收方接收到事务后根据事务的类型和内容调用不同的过程，可以看作跨进程的函数调用。

然后是要知道service manager，它是管理服务端和客户端的机构，并且它自身也是一个服务端。例如当某个服务进程想要在service manager中注册时，这个服务向service manager发送注册请求，此时该服务是本次通信的客户端，service manager是服务端。service manager主要担当一个中间介绍人的作用，当某个客户进程想要获取某个服务时，它会向service manager发送查询请求，service manager会向该客户返回该服务的查询结果。

我分析的是Binder native层的代码，分为六篇。第一篇介绍mediaserver，分析mediaserver的启动过程中获取service manager以及注册服务的过程。同时为之后分析Binder通信过程做好通信数据上的准备，即mediaserver向service manager注册过程中发送的数据内容是什么。

Binder native层源码分析（一）：media_service的启动

第二篇介绍Parcel类，Parcel是Binder通信过程中的数据包，理解Parcel的结构和实现原理有助于我们看懂Binder中服务端客户端很多的处理代码。而Parcel传输的object类型（flat_binder_obj）更是我们之后理解Binder各实体之间是怎么产生联系的关键。

Binder native层源码分析（二）：Parcel类

第三篇介绍BpBinder，分析native层是怎么把数据一步步交给驱动的，在这过程中写入了什么协议，传给了驱动什么参数。

Binder native层源码分析（三）：BpBinder通信类

第四篇分析驱动代码，看驱动是怎么把数据交给service manager，又是怎么处理数据中的object的。没看驱动代码之前我一直困惑object到底是什么？看完驱动代码之后我才弄明白了上面问题的答案。这是最难的一部分，也是理解Binder底层实现最关键的一部分。

Binder native层源码分析（四）：Binder驱动将数据发往sm

第五篇分析service manager，看service manager怎么从驱动中读取数据，又对注册服务的请求作出了怎样的处理。

Binder native层源码分析（五）：sm对数据的接收以及处理

第六篇继续分析service manager，看service manager对查询服务的请求作出什么处理。写这一篇的目的是为了彻底说明白位于不同进程的Binder实体间是怎么知道彼此，产生联系然后进行通信的。

Binder native层源码分析（六）：sm返回查询结果

第七篇介绍BBinder，对第三篇的内容做一个补充。我自己是在看完了驱动和sm的代码后才理解清楚BBiner的工作原理，所以我把BBinder的介绍放到四五六篇之后。

Binder native层源码分析（七）：BBinder

尚未分析的问题

Binder对线程的管理
transaction_stack的作用