1 binder层级架构总览

读过前文的小伙伴可以知道，由于进程隔离的存在，两个用户进程需要传递 或者交换数据都是需要内核层作为中转缓冲进行中转。
就好比在两座大厦上办公的人，在没有瞬移之类的超能力前提之下，传送文件包裹都需要下楼穿过大厅，然后再上楼交给对应的人。
这大厅之上的两座大楼就可以理解为两个用户进程，而最底下的大厅可以理解为为用户进程进行数据中转的内核层。

而现实生活中，我们要把文件资料给别人，可能手边的工作脱不开身，或者距离太远，我们就需要把文件交给快递公司去处理。
这个过程需要快递员，一层一层地上门取件，对文件进行打包编号，交由一层的快递运输系统给运送到客户所在地点，然后再交由快递小哥上楼进行派送。

而binder也是如此，client进程要发送到server进程需要将数据一步步向下传递到内核层的binder驱动中，再交由binder驱动将数据传送到server进程，再自底向上一步步解析传递给 server。

整个binder通信过程，完成整个通信流程的任务可以分工为三个部分

1.1 第一个部分Framework层概述 - 取件打包分装一条龙

我们平时寄送的快递要经过打包、分装、编号，才能够运送到另一个地方的目的地，而送到另一个地方时也要根据编号分拣，派送，到收货人手上也还要进行拆包才能拿到真正想要的东西，

这一整套流程就对应着binder数据自定向下数据封装以及 自底向上数据解析流程，而这个流程除了最底层的数据传输，都是framework层所负责的工作。

由于framework还有许多更为细化的分工，Framework层自上而下又可以进一步分为三层。分别为

1 java层

2 JNI层

3 Native层

1.2 serverManager - binder世界的快递公司

除了取件派件快递小哥 和 分装编号转发的快递站点之外，还需要整个运输体系快递站点的调度和任务安排，在现实生活中这样的角色就是物流体系背后的快递公司。
在binder世界中则是 servicemanager。

1.3 kernel binder 驱动层

至于最后的binder驱动层，则是对应现实生活中任劳任怨的货车司机了，负责着最基础的运输工作。

讲到这里大家对binder的架构有个大体概念就行，后续文章会逐层细致地展开讲解。