android 系统核心机制binder（13）binder整体分层总结
系列文章解读&说明：
Android系统核心机制binder的分析主要分为以下部分：
（01）C语言简谈binder
（02）binder驱动层原理
（03）binder C++层实现
（04）binder C++层 TestServer分析
（05）servicemanager详解
（06）binder C++层 TestClient分析
（07）binder挂掉客户端收到通知
（08）匿名service
（09）binder java层实现
（10）binder java层JNI初始化
（11）binder java层 TestServer分析
（12）binder java层 TestClient 分析
（13）binder整体分层总结
本模块分享的内容：binder整体分层总结
本章关键点总结 & 说明：
本部分仅仅是重新整理了一下导图，并无其他内容上上的更新。关键是总结。
1 谈谈binder 的 分层设计
binder 的系统分层在设计上分成了3层，IPC层（进程间通信），RPC层（基于IPC层，进行远程过程调用），业务层（仅限于业务逻辑）接下来分别对着三层进行一个简单的解读：
@1 IPC层 ：无论是 C++层的BpBinder、BBinder，还是java层的BinderProxy、Binder类，最终调用的都是IPC层的IPCThreadState类，使用它的方法与驱动层进行交互，进而完成对应功能。同时IPCThreadState也是IPC层的核心方法，封装了对驱动的操作。
@2 RPC层：远程过程调用，在C++层我们需要自己来写，需要实现BpXXXService和BnXXXService，即封装数据和构造数据，以及实现Bp端的transact方法和Bn端的onTranscat方法。这个过程在实际书写中非常容易出错，调试时间长。而java层的RPC机制通过aidl的方式直接实现，这样就简化了RPC层的代码实现，因此使用起来显得非常方便。
@3 业务逻辑层：这个无论是C++层还是java层，都需要自己来实现。
总结下：
- Binder C++层 实现了IPC层机制，但RPC层代码和业务代码均需要自己动手来实现，难点在RPC部分。
- Binder Java层实现了IPC层机制，并且通过aidl方式实现了RPC层代码，因此使用起来相对简单很多。
2 分析 binder 代码心得总结
Binder的目的虽简单（即打开binder设备，然后读请求和 写回复），但架构繁琐（编写各种接口类和封装类等）。我们在研究源码时，一定要先搞清楚目的。实现只不过是达到该目的的一种手段和方式。也就是说 binder 只要驱动层的逻辑保持在那里，上面框架搭建的方式不止一种，android 上层框架的封装很好，同时也绝不意味着那是真理。可供参考学习与开拓视野。
最后这对binder代码的常识性知识也进行一个总结
3 Binder代码常识总结
@1 Bn与Bp是什么缩写？Binder Native与Binder Proxy
@2 Binder两个方面?
从应用程序的角度看Binder一共有两个方面：
Native 本地：例如Bn{ABC}，这是一个需要被继承和实现的类。
Proxy 代理：例如Bp{ABC}，这是一个在接口框架中被实现，但是在接口中没有体现的类。
客户端：例如客户端得到一个接口ABC，在调用的时候实际上被调用的是BpABC
@3 Binder的驱动程序在哪个目录？
kernel/include/linux/binder.h
kernel/drivers/android/binder.c
@4 Binder驱动是一个什么设备？主设备号是什么？Binder设备节点是什么？
是一个misc device，主设备号为10；节点为/dev/binder
@5 Binder驱动程序在proc文件系统建立的信息，包含什么信息？
proc目录：调用Binder各个进程的内容
state文件：使用函数binder_read_proc_state
stats文件：使用函数binder_read_proc_stats
transactions文件：使用函数binder_read_proc_transactions
transaction_log文件：使用函数binder_read_proc_transaction_log，其参数为binder_transaction_log (类型为struct binder_transaction_log)
failed_transaction_log文件：使用函数binder_read_proc_transaction_log 其参数为
binder_transaction_log_failed (类型为struct binder_transaction_log)
@6 Binder在proc文件夹位置：/proc/binder
@7 BR与BC的含义
BR_XXX等宏为BinderDriverReturnProtocol，表示Binder驱动返回协议。
BC_XXX等宏为BinderDriverCommandProtocol，表示Binder驱动命令协议。
@8 binder_thread数据结构是怎么样的？
struct binder_thread {
struct binder_proc *proc;
struct rb_node rb_node;
int pid;
int looper;
struct binder_transaction *transaction_stack;
struct list_head todo;
uint32_t return_error;
uint32_t return_error2;
wait_queue_head_t wait;
struct binder_stats stats;
};
@9 binder_write_read是怎么样的？
struct binder_write_read {
signed long write_size;
signed long write_consumed;
unsigned long write_buffer;
signed long read_size;
signed long read_consumed;
unsigned long read_buffer;
};
@A binder_thread 的各个成员信息是从哪里获得的？rb_node
@B Servicemanager的作用？可执行程序的路径？
servicemanager是一个守护进程，用该进程和/dev/binder进行通讯。
servicemanager可执行程序的路径：/system/bin/servicemanager
@C BnInterface和BpInterface是两个重要的模版，在哪个文件中定义的？是如何定义的？
在IInterface.h文件中
BnInterface模版的定义如下所示：
template class BnInterface : public INTERFACE, public BBinder
{
public:
virtual sp queryLocalInterface(const String16& _descriptor);
virtual String16 getInterfaceDescriptor() const;
protected:
virtual IBinder* onAsBinder();
};
BpInterface模版的定义如下所示：
template class BpInterface : public INTERFACE, public BpRefBase
{
public:
BpInterface(const sp& remote);
protected:
virtual IBinder* onAsBinder();
};
@D IsericeManager相关的两个文件是什么？什么时候启动？
ISericeManager.h
ISericeManager.cpp
ISericeManager是系统最先被启动的服务
@E IserviceManager知识要点：
ISericeManager本地功能并没有使现
它实际上由ServiceManager守护进程执行
用户程序通过调用BpServiceManager来获得其他的服务
@F 如何得到默认的或者缺省的ISericeManager
在ISericeManager.h中定义了一个接口，用于得到默认的ISericeManager：sp_defaultServiceManager();
此时得到的ISericeManager实际上是一个全局的ISericeManager。
至此 ，对android的binder系统就有一个全面的了解和认知了。
3