在上一篇（Android系统源码分析-从init进程开始 ）中，我们已经看到，servicemanager是init进程通过init.rc的service指令来启动的守护进程。用linux的ps命令也可以看到servicemanager进程是init进程的子进程。那么，这个进程的作用是什么？他的初始化过程又是怎样被执行的？本节我们一起来分析一下。
Binder源码分析系列文章：
Android系统源码分析-进程间通信机制binder(一)：守护进程servicemanager
Android系统源码分析-进程间通信机制binder(二)：binder内存映射
Android系统源码分析-进程间通信机制binder(三)：从framework层到Native层
Android系统源码分析-进程间通信机制binder(四)：从Native层到Driver层
Android系统是基于Linux系统的，从进程的角度来说，Android继承了Linux的进程间通信机制，例如共享内存，信号量，管道，socket等，除此之外，Android系统的最大特点之一就是提供了独有的进程间通信机制，即binder机制。而servicemanager进程正是支持binder机制的基石。
在应用开发时，经常通过mContext.getSystemService（xxx）来获取一个系统服务，其实，在Android系统底层（kernel之上），就是通过servicemanager进程来获取的这个服务。例如，
获取输入法服务的代码如下：
(InputMethodManager) mContext.getSystemService(Context.INPUT_METHOD_SERVICE);
servicemanager进程的作用：
servicemanger提供了注册服务，查询服务等功能。
在代码分析过程中，主要从一下几个角度去看待：
初始化流程
注册一个service的流程
binder的底层数据存储结构
servicemanager进程的代码位置：
servicemanager进程是一个守护进程，核心代码都是用c语言编写的，代码目录是：
frameworks/base/cmds/servicemanager
代码：
service_manager.c文件的main韩式是整个进程的入口函数。代码如下：
int main(int argc, char **argv)
{
struct binder_state *bs;
void *svcmgr = BINDER_SERVICE_MANAGER;
bs = binder_open(128*1024);
if (binder_become_context_manager(bs)) {
ALOGE("cannot become context manager (%s)\n", strerror(errno));
return -1;
}
svcmgr_handle = svcmgr;
binder_loop(bs, svcmgr_handler);
return 0;
}可以看到，仅仅十几行代码，看起来也非常精美。
代码分析：
1. BINDER_SERVICE_MANAGER的值的定义（在binder.h）如下：
#define BINDER_SERVICE_MANAGER ((void*) 0) 这个值有什么意义呢？
每一个service都需要注册到servicemanager中，都对应有一个handler，这些service就是通过这个handler来区分的。而servicemanager本省也是一个service，它的handler是0，即BINDER_SERVICE_MANAGER。要查找一个service，都是从servicemanager开始进行查询。
2. binder_open(128*1024)
非常重要的一个函数。这个函数主要功能就是初始化binder。即打开binder驱动并且映射到一块128*1024大小的内存中。
binder_open的代码如下：
在binder.c中：
struct binder_state *binder_open(unsigned mapsize)
{
struct binder_state *bs;
bs = malloc(sizeof(*bs));
if (!bs) {
errno = ENOMEM;
return 0;
}
bs->fd = open("/dev/binder", O_RDWR);
if (bs->fd < 0) {
fprintf(stderr,"binder: cannot open device (%s)\n",
strerror(errno));
goto fail_open;
}
bs->mapsize = mapsize;
bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
if (bs->mapped == MAP_FAILED) {
fprintf(stderr,"binder: cannot map device (%s)\n",
strerror(errno));
goto fail_map;
}
/* TODO: check version */
return bs;
fail_map:
close(bs->fd);
fail_open:
free(bs);
return 0;
}分析：
1）. bs->fd = open("/dev/binder", O_RDWR);
打开 了驱动/dev/binder。可以看出，原理binder最底层是有一个/dev/binder存在的。
2）. mmap：通过mmap系统调用把/dev/binder映射在一块内存中，大小就是128*1024byters。
3）.返回的是 struct binder_state 类型的一个指针，这个结构体中保存了binder驱动的文件句柄，内存映射大小，以及这块内存区域的地址等。
struct binder_state的定义：
struct binder_state
{
int fd;
void *mapped;
unsigned mapsize;
};另外一个非常重要的数据结构是：struct svcinfo
struct svcinfo
{
struct svcinfo *next;
void *ptr;
struct binder_death death;
int allow_isolated;
unsigned len;
uint16_t name[0];
};这是一个列表，存放的就是所有注册的service。
通过这个列表就能遍历到所有的service。
3. binder_become_context_manager函数：
int binder_become_context_manager(struct binder_state *bs)
{
return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}分析：
通过ioctl servicemanaer就成为了service的服务管理者。
4.binder_loop函数：
void binder_loop(struct binder_state *bs, binder_handler func)
{
int res;
struct binder_write_read bwr;
unsigned readbuf[32];
bwr.write_size = 0;
bwr.write_consumed = 0;
bwr.write_buffer = 0;
readbuf[0] = BC_ENTER_LOOPER;
binder_write(bs, readbuf, sizeof(unsigned));
for (;;) {
bwr.read_size = sizeof(readbuf);
bwr.read_consumed = 0;
bwr.read_buffer = (unsigned) readbuf;
res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
if (res < 0) {
ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
break;
}
res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);
if (res == 0) {
ALOGE("binder_loop: unexpected reply?!\n");
break;
}
if (res < 0) {
ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));
break;
}
}
}
分析：
在loop中，不停地通过ioctl对/dev/binder驱动进行访问，
readbuf用于存储读取到的消息数据；
BINDER_WRITE_READ用于读取消息数据。
然后，再进行解析，即
res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);
再看binder_parse是如何工作的：
int binder_parse(struct binder_state *bs, struct binder_io *bio,
uint32_t *ptr, uint32_t size, binder_handler func)
{
int r = 1;
uint32_t *end = ptr + (size / 4);
while (ptr < end) {
uint32_t cmd = *ptr++;
#if TRACE
fprintf(stderr,"%s:\n", cmd_name(cmd));
#endif
switch(cmd) {
case BR_NOOP:
break;
case BR_TRANSACTION_COMPLETE:
break;
case BR_INCREFS:
case BR_ACQUIRE:
case BR_RELEASE:
case BR_DECREFS:
#if TRACE
fprintf(stderr," %08x %08x\n", ptr[0], ptr[1]);
#endif
ptr += 2;
break;
case BR_TRANSACTION: {
struct binder_txn *txn = (void *) ptr;
if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_txn)) {
ALOGE("parse: txn too small!\n");
return -1;
}
binder_dump_txn(txn);
if (func) {
unsigned rdata[256/4];
struct binder_io msg;
struct binder_io reply;
int res;
bio_init(&reply, rdata, sizeof(rdata), 4);
bio_init_from_txn(&msg, txn);
res = func(bs, txn, &msg, &reply);
binder_send_reply(bs, &reply, txn->data, res);
}
ptr += sizeof(*txn) / sizeof(uint32_t);
break;
}
case BR_REPLY: {
struct binder_txn *txn = (void*) ptr;
if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_txn)) {
ALOGE("parse: reply too small!\n");
return -1;
}
binder_dump_txn(txn);
if (bio) {
bio_init_from_txn(bio, txn);
bio = 0;
} else {
/* todo FREE BUFFER */
}
ptr += (sizeof(*txn) / sizeof(uint32_t));
r = 0;
break;
}
case BR_DEAD_BINDER: {
struct binder_death *death = (void*) *ptr++;
death->func(bs, death->ptr);
break;
}
case BR_FAILED_REPLY:
r = -1;
break;
case BR_DEAD_REPLY:
r = -1;
break;
default:
ALOGE("parse: OOPS %d\n", cmd);
return -1;
}
}
return r;
}分析：
1）. 解析以BR开头的这些命令；
2）. 以case BR_TRANSACTION为例子：
case BR_TRANSACTION: {
...
res = func(bs, txn, &msg, &reply); //处理消息
//返回处理结果
inder_send_reply(bs, &reply, txn->data.ptr.buffer, res);
...
break;
}res = func(bs, txn, &msg, &reply);
作用：用于处理消息；func就是在前面已经注册的service的handler，可以认为是具体的service。通过func，就回调到了具体的service中的对应函数中。
inder_send_reply(bs, &reply, txn->data.ptr.buffer, res); ：
作用：返回处理结果。
在binder_loop中的第二个参数，即svcmgr_handler，
这个就是service的注册函数，具体代码如下：
int svcmgr_handler(struct binder_state *bs,
struct binder_txn *txn,
struct binder_io *msg,
struct binder_io *reply)
{
struct svcinfo *si;
uint16_t *s;
unsigned len;
void *ptr;
uint32_t strict_policy;
int allow_isolated;
// ALOGI("target=%p code=%d pid=%d uid=%d\n",
// txn->target, txn->code, txn->sender_pid, txn->sender_euid);
if (txn->target != svcmgr_handle)
return -1;
// Equivalent to Parcel::enforceInterface(), reading the RPC
// header with the strict mode policy mask and the interface name.
// Note that we ignore the strict_policy and don't propagate it
// further (since we do no outbound RPCs anyway).
strict_policy = bio_get_uint32(msg);
s = bio_get_string16(msg, &len);
if ((len != (sizeof(svcmgr_id) / 2)) ||
memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
fprintf(stderr,"invalid id %s\n", str8(s));
return -1;
}
switch(txn->code) {
case SVC_MGR_GET_SERVICE:
case SVC_MGR_CHECK_SERVICE:
s = bio_get_string16(msg, &len);
ptr = do_find_service(bs, s, len, txn->sender_euid);
if (!ptr)
break;
bio_put_ref(reply, ptr);
return 0;
case SVC_MGR_ADD_SERVICE:
s = bio_get_string16(msg, &len);
ptr = bio_get_ref(msg);
allow_isolated = bio_get_uint32(msg) ? 1 : 0;
if (do_add_service(bs, s, len, ptr, txn->sender_euid, allow_isolated))
return -1;
break;
case SVC_MGR_LIST_SERVICES: {
unsigned n = bio_get_uint32(msg);
si = svclist;
while ((n-- > 0) && si)
si = si->next;
if (si) {
bio_put_string16(reply, si->name);
return 0;
}
return -1;
}
default:
ALOGE("unknown code %d\n", txn->code);
return -1;
}
bio_put_uint32(reply, 0);
return 0;
}分析：
1）case SVC_MGR_ADD_SERVICE:的执行就是service的注册；
2）case SVC_MGR_CHECK_SERVICE:的执行就是service的查询；
3）case SVC_MGR_LIST_SERVICES:的执行就是列出所有service。
do_add_service函数：
如果已经注册了对应的service，就不再注册。否则，将新的节点添加到svclist中。
这样，整个servicemangar进程就初始化完成了。再总结一下：
打开binder驱动->注册servicemanager（handler为0）->binder loop。
Android进程间通信之binder，必须掌握的底层代码。