Android的Context Manager（服务管理器）源码剖析-android学习之旅（99）

Context Manager介绍

Context Manager对应的进程是servicemanager进程，它先于Service Server和服务客户端运行，进入接收IPC数据的待机状态，处理来自Service Server的注册请求和服务客户端的查询请求。查看ini.rc脚本可以发现，Context Manager进程先于umediaserver和system_server进程运行。如下图所示：

关于服务进程更详细的介绍，见我之前的几篇文章

Android的启动过程分析(从进程和Framework的角度

Android系统服务详解

Android Binder IPC详解

每当service server注册服务时候，Context Manager都会把服务的名称和Binder节点编号注册到自身的目录中，该服务目录可以通过跟文件系统下面的/system/service程序查看。

service程序以IPC应答数据的形式接收Context Manager服务目录中的服务名称，并将收到的服务输入到画面中。具体操作是打开adb shell，输入service list，结果如下图：

Context Manager的运行

Context Manager的源码在/framework/base/cmds/servicemanager目录下的serveice_mamager.c文件中。它的main函数大致可以分为三个部分：binder_open(用来打开Binder Driver，并且创建IPC数据的接收buffer),binder_become_context_manager(注册特殊节点，既是0号binder节点),binder_loop(用来不断的接收IPC数据)

核心代码如下：

3部分的核心代码如下：

parse（）函数展开 ，代码如下：

parse（）又调用了svcmgr_handle()函数（） ，展开如下：

1.服务客户端在检索服务时候，执行这段代码，服务客户端首先通过RPC数据传递服务名称，从do_find_service()函数自身的服务列表获取服务编号，而后bio_put_ref（）函数生成binder_ object()结构体，该结构体将被包含到IPC数据的RPC数据中。而后调用binder_send_reply()函数，讲IPC应答数据传递到Binder Driver。

当service server注册服务时候使用这段代码。Context Manager调用do_add_service()函数将IPC数据的RPC数据包含的服务名称与Binder节点编号注册到自身的服务中目录中。而后调用binder_send_reply()函数，讲IPC应答数据传递到Binder Driver。

总结：Binder是由Service Server（android服务），Service Client（使用服务的客户）。Conetxt Manager（服务管理者），以及Binder Driver死大部分构成。