基于Android 6.0的源码剖析， 本文详细地讲解了ServiceManager启动流程

一. 概述

ServiceManager是Binder IPC通信过程中的守护进程，本身也是一个Binder服务，但并没有采用libbinder中的多线程模型来与Binder驱动通信，而是自行编写了binder.c直接和Binder驱动来通信，并且只有一个循环binder_loop来进行读取和处理事务，这样的好处是简单而高效。

ServiceManager本身工作相对简单，其功能：查询和注册服务。 对于Binder IPC通信过程中，其实更多的情形是BpBinder和BBinder之间的通信，比如ActivityManagerProxy和ActivityManagerService之间的通信等。

1.1 流程图

启动过程主要以下几个阶段：

打开binder驱动：binder_open；

注册成为binder服务的大管家：binder_become_context_manager；

进入无限循环，处理client端发来的请求：binder_loop；

二. 启动过程

ServiceManager是由init进程通过解析init.rc文件而创建的，其所对应的可执行程序/system/bin/servicemanager，所对应的源文件是service_manager.c，进程名为/system/bin/servicemanager。

启动Service Manager的入口函数是service_manager.c中的main()方法，代码如下：

2.1 main

[ -> service_manager.c]

2.2 binder_open

[-> servicemanager/binder.c]

打开binder驱动相关操作:

先调用open()打开binder设备，open()方法经过系统调用，进入Binder驱动，然后调用方法binder_open()，该方法会在Binder驱动层创建一个binder_proc对象，再将binder_proc对象赋值给fd->private_data，同时放入全局链表binder_procs。再通过ioctl()检验当前binder版本与Binder驱动层的版本是否一致。

调用mmap()进行内存映射，同理mmap()方法经过系统调用，对应于Binder驱动层的binder_mmap()方法，该方法会在Binder驱动层创建Binder_buffer对象，并放入当前binder_proc的proc->buffers链表。

2.2.1 binder_state

[-> servicemanager/binder.c]

2.3 binder_become_context_manager

[-> servicemanager/binder.c]

成为上下文的管理者，整个系统中只有一个这样的管理者。 通过ioctl()方法经过系统调用，对应于Binder驱动层的binder_ioctl()方法.

2.3.1 binder_ioctl

[-> kernel/drivers/android/binder.c]

根据参数BINDER_SET_CONTEXT_MGR，最终调用binder_ioctl_set_ctx_mgr()方法，这个过程会持有binder_main_lock。

2.3.2 binder_ioctl_set_ctx_mgr

[-> kernel/drivers/android/binder.c]

进入binder驱动，在Binder驱动中定义的静态变量

创建了全局的binder_node对象binder_context_mgr_node，并将binder_context_mgr_node的强弱引用各加1.

2.3.3 binder_new_node

[-> kernel/drivers/android/binder.c]

在Binder驱动层创建binder_node结构体对象，并将当前binder_proc加入到binder_node的node->proc。并创建binder_node的async_todo和binder_work两个队列。

2.4 binder_loop

[-> servicemanager/binder.c]

进入循环读写操作，由main()方法传递过来的参数func指向svcmgr_handler。

binder_write通过ioctl()将BC_ENTER_LOOPER命令发送给binder驱动，此时bwr只有write_buffer有数据，进入binder_thread_write()方法。 接下来进入for循环，执行ioctl()，此时bwr只有read_buffer有数据，那么进入binder_thread_read()方法。

2.4.1 binder_write

[-> servicemanager/binder.c]

根据传递进来的参数，初始化bwr，其中write_size大小为4，write_buffer指向缓冲区的起始地址，其内容为BC_ENTER_LOOPER请求协议号。通过ioctl将bwr数据发送给binder驱动，则调用其binder_ioctl方法，如下：

2.4.2 binder_ioctl

[-> kernel/drivers/android/binder.c]

2.4.3 binder_ioctl_write_read

[-> kernel/drivers/android/binder.c]

此处将用户空间的binder_write_read结构体 拷贝到内核空间.

2.4.4 binder_thread_write

[-> kernel/drivers/android/binder.c]

从bwr.write_buffer拿出cmd数据,此处为BC_ENTER_LOOPER. 可见上层本次调用binder_write()方法，主要是完成设置当前线程的looper状态为BINDER_LOOPER_STATE_ENTERED。

2.5 binder_parse

[-> servicemanager/binder.c]

解析binder信息，此处参数ptr指向BC_ENTER_LOOPER，func指向svcmgr_handler。故有请求到来，则调用svcmgr_handler。

2.5.1 bio_init

[-> servicemanager/binder.c]

其中

2.5.2 bio_init_from_txn

[-> servicemanager/binder.c]

将readbuf的数据赋给bio对象的data

2.6 svcmgr_handler

[-> service_manager.c]

......

该方法的功能：查询服务，注册服务，以及列举所有服务

2.6.1 svcinfo

每一个服务用svcinfo结构体来表示，该handle值是在注册服务的过程中，由服务所在进程那一端所确定的。

三. 核心工作

servicemanager的核心工作就是注册服务和查询服务。

3.1 do_find_service

[-> service_manager.c]

uint32_tdo_find_service(structbinder_state *bs,

查询到目标服务，并返回该服务所对应的handle

3.1.1 find_svc

从svclist服务列表中，根据服务名遍历查找是否已经注册。当服务已存在svclist，则返回相应的服务名，否则返回NULL。

当找到服务的handle, 则调用bio_put_ref(reply, handle)，将handle封装到reply.

3.1.2 bio_put_ref

3.1.3 bio_alloc_obj

3.1.4 bio_alloc

3.2 do_add_service

[-> service_manager.c]

注册服务的分以下3部分工作：

svc_can_register：检查权限，检查selinux权限是否满足；

find_svc：服务检索，根据服务名来查询匹配的服务；

svcinfo_death：释放服务，当查询到已存在同名的服务，则先清理该服务信息，再将当前的服务加入到服务列表svclist；

3.2.1 svc_can_register

[-> service_manager.c]

3.2.2 svcinfo_death

[-> service_manager.c]

3.2.3 bio_get_ref

[-> servicemanager/binder.c]

3.3 binder_link_to_death

[-> servicemanager/binder.c]

binder_write经过跟小节2.4.1一样的方式, 进入Binder driver后,直接调用后进入binder_thread_write, 处理BC_REQUEST_DEATH_NOTIFICATION命令

3.3.1 binder_ioctl_write_read

[-> kernel/drivers/android/binder.c]

3.3.2 binder_thread_write

[-> kernel/drivers/android/binder.c]

.....

此方法中的proc, thread都是指当前servicemanager进程的信息. 此时TODO队列有数据,则进入binder_thread_read.

那么哪些场景会向队列增加BINDER_WORK_DEAD_BINDER事务呢? 那就是当binder所在进程死亡后,会调用binder_release方法, 然后调用binder_node_release.这个过程便会发出死亡通知的回调.

3.3.3 binder_thread_read

将命令BR_DEAD_BINDER写到用户空间, 此处的cookie是前面传递的svcinfo_death. 当binder_loop下一次 执行binder_parse的过程便会处理该消息。

3.3.4 binder_parse

[-> servicemanager/binder.c]

由小节3.2的 si->death.func = (void*) svcinfo_death; 可知此处 death->func便是执行svcinfo_death()方法.

3.3.5 svcinfo_death

[-> service_manager.c]

3.3.6 binder_release

[-> service_manager.c]

向Binder Driver写入BC_RELEASE命令, 最终进入Binder Driver后执行binder_dec_ref(ref, 1)来减少binder node的引用.

3.4 binder_send_reply

[-> servicemanager/binder.c]

当小节2.5执行binder_parse方法，先调用svcmgr_handler()，再然后执行binder_send_reply过程。该方法会调用 [小节2.4.1] binder_write进入binder驱动后，将BC_FREE_BUFFER和BC_REPLY命令协议发送给Binder驱动，向client端发送reply. 其中data的数据区中保存的是TYPE为HANDLE.

四. 总结

ServiceManger集中管理系统内的所有服务，通过权限控制进程是否有权注册服务,通过字符串名称来查找对应的Service; 由于ServiceManger进程建立跟所有向其注册服务的死亡通知, 那么当服务所在进程死亡后, 会只需告知ServiceManager. 每个Client通过查询ServiceManager可获取Server进程的情况，降低所有Client进程直接检测会导致负载过重。

ServiceManager启动流程：

打开binder驱动，并调用mmap()方法分配128k的内存映射空间：binder_open();

通知binder驱动使其成为守护进程：binder_become_context_manager()；

验证selinux权限，判断进程是否有权注册或查看指定服务；

进入循环状态，等待Client端的请求：binder_loop()。

注册服务的过程，根据服务名称，但同一个服务已注册，重新注册前会先移除之前的注册信息；

死亡通知: 当binder所在进程死亡后,会调用binder_release方法,然后调用binder_node_release.这个过程便会发出死亡通知的回调.

ServiceManager最核心的两个功能为查询和注册服务：

注册服务：记录服务名和handle信息，保存到svclist列表；

查询服务：根据服务名查询相应的的handle信息。