Binder 驱动是 解析init.rc过程中，启动 ueventd 时，在 ueventd 的启动中，会解析 ueventd.rc 文件，此时就其注册 Binder 驱动，Ashmem 驱动等。
- ProcessState对于一个进程是单例
- 一个进程是在ProcessState.cpp 初始化的时候进行 open("/dev/binder"),mmap() 等操作，两者会在 kernal层 binder 驱动处执行 binder_open() 和 binder_mmap( )
- ProcessState 在 open_drive()中打开 binder 驱动，随后通过 binder_ioctl( )与 Binder 驱动进行通信，查询并校验BinderVersion,设置 Binder 线程最大数量
- binder_open( )会将打开驱动的进程信息构造为 binder_proc 结构体，并且挂载到 binder 驱动进行管理
- binder_mmap( )会让 binder 驱动与打开驱动的驱动的虚拟地址共同映射到同一块物理内存。
- service_manager.cpp 作为 service 的管理者，在 Binder 驱动中的编号为 0；
- service_manager由解析init.rc后启动初始化
- service_manager 使用同空间下的 binder.c，而不直接使用 kernal 中的 binder.c
- service_manager在其 main()方法中，使用同空间下的 binder.c 打开 Binder 驱动，使用 binder_open( ),调用open("/dev/open")打开 binder 驱动，随后通过 ioctl 与 binder 驱动通信校验 Binder 版本号，然后通过 mmap()进行内存映射。
- 随后通过 binder_become_context_manager( )想 binder 驱动申请成为上下文管理者。
- 随后通过 binder_loop( )进入循环，通过 svcmgr_hander 进行处理请求
- 网上将 Android Binder通信的架构类化成计算机网络，service_manager 视为DNS 等。
- 在与 Binder 进行的通讯过程，可以认为是协议的层层包装和层层解包装。在每一层都会打包一个控制,在转交后通过解析控制命令，转到对应函数处理。
- 像 service_manager 申请成为上下文管理者，在 iotcl( )中的 cmd 是 BINDER_SET_CONTEXT_MGR，在 binder_ioctl( )中case 匹配到，直接执行对应的方法。而大部分利用 Binder 是进行进程间通信的，其使用的 cmd 是BINDER_WRITE_READ。
- defaultServiceManager()@IServiceManager.cpp
- 对于 service_manager 的使用，分为 Java 层和 c++层。先来看 Java 层。
- Java 层的 ServiceManager.getIServiceManager( )返回ServiceManagerProxy( )对象。link
- 于是 Java 层中 service_manager 的代理表现为 ServiceManagerProxy.java(mRemote=BinderProxy.java(mObject=BpBinder.cpp(handle = 0)))
- 于是 native 层的service_manager 的代理表现为BpManagerService.cpp(mRemote = BpBinder.cpp(handle = 0))
- 于是可以知道，无论是 native 层还是 Java 层，都是对于 BpBinder.cpp(handle = 0 )的包装。所有对于 service_manager 通讯发出的请求最终都会由 BpBinder.cpp(handle = 0)来发出
- Parcel 详解
- 以添加服务为例子看整个 Binder 通讯过程
网友评论