Binder通信过程
1.首先，一个进程使用 BINDER_SET_CONTEXT_MGR 命令通过 Binder 驱动将自己注册成为 ServiceManager
2.Server 通过驱动向 ServiceManager 中注册 Binder（Server 中的 Binder 实体），表明可以对外提供服务。驱动为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager，ServiceManger 将其填入查找表。
3.Client 通过名字，在 Binder 驱动的帮助下从 ServiceManager 中获取到对 Binder 实体的引用，通过这个引用就能实现和 Server 进程的通信。
Binder通信的代理模式
当 A 进程想要获取 B 进程中的 object 时，驱动并不会真的把 object 返回给 A，而是返回了一个跟 object 看起来一模一样的代理对象 objectProxy，这个 objectProxy 具有和 object 一摸一样的方法，但是这些方法并没有 B 进程中 object 对象那些方法的能力，这些方法只需要把把请求参数交给驱动即可。对于 A 进程来说和直接调用 object 中的方法是一样的。
当 Binder 驱动接收到 A 进程的消息后，发现这是个 objectProxy 就去查询自己维护的表单，一查发现这是 B 进程 object 的代理对象。于是就会去通知 B 进程调用 object 的方法，并要求 B 进程把返回结果发给自己。当驱动拿到 B 进程的返回结果后就会转发给 A 进程，一次通信就完成了。
ServiceManager进程启动
1.==ServiceManager成为Binder管理者==
首先在android系统开始启动时通过init.rc启动了servicemanager(Native进程)可执行文件进程，系统真正的ServieManager管理最终通过Native进程servicemanager来完成。接下来分析在main函数中做了那些事情：
1.binder_open(128*1024)通过打开/dev/binder设备节点返回fd文件描述符，通过mmap最终实现对binder驱动128K大小的内存映射
2.binder_become_context_manager(bs)通过ioctl往设备节点发送BINDER_SET_CONTEXT_MGR命令通知Binder驱动为servicemanager创建特殊不变的0句柄实体binder_node:binder_context_mgr_node
3.Binder_loop(bs,svcmgr_handler)通过iotcl发送BINDER_WRITE_READ命令并携带BC_ENTER_LOOPER请求命令告知Binder驱动创建了binder主线程并使binder驱动创建与之对应的binder_thread结构体存储到binder_proc中，并通过for循环进入循环读取binder驱动返回信息的循环流程
ServiceManager（native进程）最终通过获取binder驱动设备节点fd地址，与binder驱动内存映射（虚拟内存与物理内存映射），开启binder主体线程循环读取binder驱动返回的消息而成为服务端；
成为服务端后能够不断接收来自客户端（服务端 与客户端在此统称为客户端）的binder请求通信，ServiceManager（native进程）完成其他服务的注册并保存binder驱动创建的binder句柄值与服务名称字符串，保证客户端通过字符串获取其他服务引用句柄；因而ServiceManager（native进程）为binder管理者（服务注册与获取的桥梁）。
2.==客户端通过ServiceManager获取服务==
用户进程需要和ServiceManager（native进程）进程通信，ServiceManager进程接收到请求后去响应
1.用户进程第一步先实例化ServiceManager Binder Proxy代理
通过BinderInternal.getContextObject()调用获取到句柄值为0的BpBinder native对象，最终通过javaObjectForIbinder()函数的jni转换为BinderProxy类对象其实就是填充了这个类的mObject对象也就是ServiceManager Binder对象的引用封装对象，所以SMN才能通过asInterface完成代理Proxy的实例化
