- ServiceManager(SM)本身也是一个Binder Server，为其它BinderServer提供获取地址服务。Binder驱动提供了专门为SM提供服务的命令，由native代码实现。
- 为保证在使用binder机制前就处于正常工作状态，SM在init程序进行解析时启动，并且如需要重启则其它系统服务也会被重新加载。
- SM通过Binder驱动构建的过程
- 打开Binder设备并初始化，包括被映射到进程中的内存起始位置、映射区块大小、映射区只读等
- 将自己设置为context_manager，使整个系统只允许一个SM存在，其它BinderServer尝试设置会失败。由于SM启动的早，所以保证了是系统中第一个向Binder驱动注册的程序
- 进入主循环处理消息
- 首先告知Binder驱动将要进入循环
- 从Binder驱动读取消息
- 处理消息，如消息时退出则结束循环；为空则继续读取或等待；其它则进行处理。
- Java层进程使用SM
- 由于BinderClient可能是Android 应用程序，所以SM需要提供Java层接口，使得许多对象在Java层与C/C++层具有双重身份。
- 每个进程只允许打开一次Binder设备，只做一次内存映射，由所有需要使用Binder驱动的线程共享。从而防止进程每次使用BinderServer或SM服务都需要打开Binder驱动并进行内存映射消耗过多的系统资源。
- BinderClient与SM工作都是基于Binder驱动完成的
- BinderClient访问SM过程：
- 打开Binder设备
- 执行mmap映射
- 通过Binder驱动向SM发送请求
- 得到结果
- BinderServer启动时将自己的名称与对应句柄值保存在SM（句柄为0）中，调用者只知道BinderServer名称，需要先向SM查询对应句柄值
- Android系统为进程使用Binder机制而封装了两个实现类：ProcessState（进程相关，负责打开binder启动设备，进行mmap工作等）、IPCThreadState（线程相关，负责与Binder启动设备进行具体的命令通信）
- SM具体工作流程：
- SM在Android设备启动后运行，并注册、完成初始化。无服务请求时处于睡眠状态
- Binder Client向Binder驱动发起请求后进入睡眠，等待返回结果
- SM接收到Binder驱动的请求，被唤醒，读取具体请求，填写信息并向Binder驱动返回结果
- Binder Client接收到结果被唤醒，读取结果，并填充到Parcel中，进过层层操作传递给调用者
网友评论