[Android]从一个简单的AIDL实现看binder原理（六）Android系统中Binder的运行

参考链接：

从一个简单的AIDL实现看binder原理（一）简单的AIDL实现
从一个简单的AIDL实现看binder原理（二）bindService的调用过程
从一个简单的AIDL实现看binder原理（三）bindService调用过程中Binder的传递
从一个简单的AIDL实现看binder原理（四）bindService调用过程中Binder的写入
从一个简单的AIDL实现看binder原理（五）bindService调用过程中Binder的转换

通过前面几篇博文的分析，我们可以得出一个结论：如果使用Binder进行IPC，那么需要客户端发送一个需要IPC的请求，通过某个媒介发送到服务端，服务端收到这个请求后，将服务端进程所在的Binder通过媒介转化为Binder的客户端代理(即BinderProxy) ,再发送给客户端，当客户端拿到BinderProxy后，就可以与服务端进行进程间通信了。

以我们在第一篇博文中的AIDL实现为例，当Activity所在进程要和RemoteService进程进行通信时，我们在Activity进程发起bindService操作，在经过AMS处理并成功启动RemoteService后，RemoteService进程将自己持有的Binder发送给AMS并且在经过IPC过程后转化成了BinderProxy，在AMS中寻找发起请求的Activity进程，并将这个BinderProxy通过ServiceConnection发送给客户端

那么这里就会有一个问题，我们在使用AMS的代理向AMS发送消息时，好像并没有出现上述过程，回顾一下在RemoteService进程发起publishService的场景：

private void handleBindService(BindServiceData data) {
        Service s = mServices.get(data.token);
        if (s != null) {
            try {
                data.intent.setExtrasClassLoader(s.getClassLoader());
                data.intent.prepareToEnterProcess();
                try {
                    if (!data.rebind) {
                        IBinder binder = s.onBind(data.intent);
                        ActivityManager.getService().publishService(
                                data.token, data.intent, binder);
                    } else {
                        s.onRebind(data.intent);
                        ActivityManager.getService().serviceDoneExecuting(
                                data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
                    }
                    ensureJitEnabled();
                } catch (RemoteException ex) {
                    throw ex.rethrowFromSystemServer();
                }
            } catch (Exception e) {
                if (!mInstrumentation.onException(s, e)) {
                    throw new RuntimeException(
                            "Unable to bind to service " + s
                            + " with " + data.intent + ": " + e.toString(), e);
                }
            }
        }
    }

在这里是直接调用了

ActivityManager.getService().publishService(
                                data.token, data.intent, binder);

ActivityManager.getService的实现：

 public static IActivityManager getService() {
        return IActivityManagerSingleton.get();
    }

    private static final Singleton IActivityManagerSingleton =
            new Singleton() {
                @Override
                protected IActivityManager create() {
                    final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
                    final IActivityManager am = IActivityManager.Stub.asInterface(b);
                    return am;
                }
            };

看代码的第10行，通过第一篇博文案例的分析，我们知道，这里拿到的其实就是AMS的BinderProxy
继续看获取的过程ServiceManager#getService：

    public static IBinder getService(String name) {
        try {
            IBinder service = sCache.get(name);
            if (service != null) {
                return service;
            } else {
                return Binder.allowBlocking(getIServiceManager().getService(name));
            }
        } catch (RemoteException e) {
            Log.e(TAG, "error in getService", e);
        }
        return null;
    }

这里就会有同学问，马老师发生甚么事了，怎么回事？这里怎么是直接从一个Map的实例sCache中获取的BinderProxy，但是为什么在RemoteService进程可以直接拿到AMS的BinderProxy呢？不应该通过某种媒介去请求AMS然后再发送回来么？

但是，如果所有的Binder的传递都需要一个媒介的话，就会陷入一种死循环：我需要一个媒介去和远端进行交互，启动媒介也需要一个媒介，这样就会陷入我永远需要一个媒介的状态。

当然，Android肯定不会傻到连这个问题都想不到的，那么Android系统如何解决这个问题的呢？接下来就引入一个重要的组件——ServiceManger

ServiceManger，顾名思义，它是系统各种Service的管理员，这里所说的ServiceManger并不是上文提到用来获取AMS本地代理的那个,而是指Native层的那个。

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

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

Android 系统第一个启动的 init 进程解析 init.rc 脚本时构建出系统的初始运行状态，Android 系统服务大多是在这个脚本中描述并被相继启动的，包括 zygote、mediaserver、surfaceflinger 以及 servicemanager 等

ServiceManager启动原理：

#init.rc
service servicemanager /system/bin/servicemanager
    class core
    user system
    group system
    critical
    onrestart restart healthd
    onrestart restart zygote
    onrestart restart media
    onrestart restart surfaceflinger
    onrestart restart drm

可以看到，当 ServiceManager 发生问题重启时，其他 healthd、zygote、media 等服务也会被重启。ServiceManager 服务启动后会执行 service_manager.c 的 main 函数，关键代码如下：

//frameworks/native/cmds/servicemanager/service_manager.c
int main(){
    bs = binder_open(128*1024);
    if (binder_become_context_manager(bs)) {
        ...
    }
    ...
    binder_loop(bs, svcmgr_handler);
    return 0;
}

其中三个函数对应了 ServiceManager 初始化的三个关键工作：

binder_open()：打开 binder 驱动并映射内存块大小为 128KB
binder_become_context_manager()：将自己设置为 Binder "DNS" 管理者
binder_loop()：进入循环，等待 binder 驱动发来消息
下面分别来分析这三个函数，首先来看 binder_open() 是怎么打开 binder 驱动并映射内存的：

struct binder_state *binder_open(size_t mapsize){
    struct binder_state *bs;
    struct binder_version vers;
    bs = malloc(sizeof(*bs));
    ...
    //打开 binder 驱动，最终调用 binder_open() 函数
    bs->fd = open("/dev/binder", O_RDWR | O_CLOEXEC);
    ...
    //获取 Binder 版本，最终调用 binder_ioctl() 函数
    ioctl(bs->fd, BINDER_VERSION, &vers)
    ...
    //将虚拟内存映射到 Binder，最终调用 binder_mmap() 函数
    bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
    ...
    return bs;
}

再来看 binder_become_context_manager() 是怎么将自己设置为 Binder "DNS 管理者的"：

int binder_become_context_manager(struct binder_state *bs){
    //发送 BINDER_SET_CONTEXT_MGR 命令，最终调用 binder_ioctl() 函数
    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

最后来看 binder_loop() 是怎么循环等待并处理 binder 驱动发来的消息：

void binder_loop(struct binder_state *bs, binder_handler func){
    int res;
    //执行 BINDER_WRITE_READ 命令所需的数据格式：
    struct binder_write_read bwr;
    uint32_t readbuf[32]; //每次读取数据的大小
    readbuf[0] = BC_ENTER_LOOPER; 
    //先将 binder 驱动的进入循环命令发送给 binder 驱动：
    binder_write(bs, readbuf, sizeof(uint32_t));
    for (;;) { //进入循环
        bwr.read_size = sizeof(readbuf);
        //读取到的消息数据存储在 readbuf
        bwr.read_buffer = (uintptr_t) readbuf; 
        //执行 BINDER_WRITE_READ 命令读取消息数据
        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, (uintptr_t) readbuf, bwr.read_consumed, func);
        ...
    }
}

BINDER_WRITE_READ 命令既可以用来读取数据也可以写入数据，具体是写入还是读取依赖 binder_write_read 结构体的 write_size 和 read_size 哪个大于 0，上面代码通过 bwr.read_size = sizeof(readbuf) 赋值，所以是读取消息。

binder_parse() 方法内部处理由 binder 驱动主动发出的、一系列 BR_ 开头的命令，包括上面提到过的 BR_TRANSACTION、BR_REPLY 等，简化后的代码如下：

int binder_parse(struct binder_state *bs, struct binder_io *bio,
                 uintptr_t ptr, size_t size, binder_handler func){
    switch(cmd) {
        case BR_TRANSACTION: {
            ...
            res = func(bs, txn, &msg, &reply); //处理消息
            //返回处理结果
            inder_send_reply(bs, &reply, txn->data.ptr.buffer, res); 
            ...
            break;
        }
        case BR_REPLY: {...}
        case BR_DEAD_BINDER: {...}
        ...
    }
}

对于 BR_TRANSACTION 命令主要做了两个工作，一是调用 func() 具体处理消息；二是调用 inder_send_reply() 将消息处理结果告知给 binder 驱动，注意这里的 func 是由 service_manager.c main 函数中传过来的方法指针，也就是 svcmgr_handler() 方法。

服务注册与查询
经过上面 ServiceManager 服务启动的过程分析，已经知道由 binder 驱动主动发过来的 BR_TRANSACTION 命令最终在 service_manager.c 的 svcmgr_handler() 方法中处理，那服务的注册与查询请求想必就是在这个方法中实现的了，确实如此，简化后的关键代码如下：

int svcmgr_handler(struct binder_state *bs,
                   struct binder_transaction_data *txn,
                   struct binder_io *msg,
                   struct binder_io *reply){
    switch(txn->code) {
         case SVC_MGR_GET_SERVICE:
         case SVC_MGR_CHECK_SERVICE:
              //查询服务，根据 name 查询 Server Handle
              handle = do_find_service(s, len, txn->sender_euid, txn->sender_pid);
              return 0;
         case SVC_MGR_ADD_SERVICE:
             //注册服务，记录服务的 name(下面的参数 s) 与 handle
             if (do_add_service(bs, s, len, handle, txn->sender_euid,
                 allow_isolated, txn->sender_pid))
                 return -1;
             break;
         case SVC_MGR_LIST_SERVICES: {
             //查询所有服务，返回存储所有服务的链表 svclist
             si = svclist;
             while ((n-- > 0) && si)
                 si = si->next;
             if (si) {
                 bio_put_string16(reply, si->name);
                 return 0;
             }
             return -1;
    }
    bio_put_uint32(reply, 0);
    return 0;
}

注册的服务都会存储在 svclist 链表上，do_add_service() 就是将服务插入到 svclist 链表上记录下来，do_find_service() 方法则遍历 svclist 查找对应的服务。

svcmgr_handler() 方法执行完后会进一步调用 inder_send_reply() 将执行结果回复给 binder 驱动，然后进入下一轮循环继续等待处理消息。

总结
ServiceManager 在 init.rc 中描述，由 init 进程启动，运行在一个单独的进程。

ServiceManager 启动后主要做了三件事：1. 打开 binder 驱动并映射内存；2. 将自己设置为 "服务大管家"；3. 循环等待 binder 驱动发来的消息。

ServiceManager 通过记录服务 Name 和 Handler 的关系，提供服务注册与查询功能。

对 Client 来说，ServiceManager 也是一个 Service，Client 可以直接获取到这个 Service，因为它的句柄值固定为 0。

APP进程获取ServiceManager

App进程获取ServiceManager，就是获取ServiceManager的代理，在binder驱动角度看，就是App对应的binder_proc获取对应的binder_ref，在App用户进程上看，App获取对应ServiceManager的BpBinder。

// framework/native/libs/binder/IServiceMnager.cpp
sp defaultServiceManager()
{
    if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
    {
        AutoMutex _l(gDefaultServiceManagerLock);
        while (gDefaultServiceManager == NULL) {
            gDefaultServiceManager = interface_cast(
                ProcessState::self()->getContextObject(NULL));
            if (gDefaultServiceManager == NULL)
                sleep(1);
        }
    }
    return gDefaultServiceManager;
}

从 ProcessState::self()->getContextObject(NULL) 获取ServiceManager，若为空，则说明ServiceManager进程还没起来，进入sleep，再次循环获取，直至非空。

ProcessState 是进程单例，每个进程只有一个实例

// frameworks/native/libs/binder/ProcessState.cpp
sp ProcessState::getContextObject(const sp& /*caller*/)
{
    // 获取句柄为0，即ServiceManager的BpBinder
    return getStrongProxyForHandle(0);
}

struct handle_entry {
      IBinder* binder; // 指向BBinder或者BpBinder
      RefBase::weakref_type* refs;
};

sp ProcessState::getStrongProxyForHandle(int32_t handle)
{
    sp result;
    AutoMutex _l(mLock);
    // 查找对应的BBinder或者BpBinder，在这里是取BpBinder
    handle_entry* e = lookupHandleLocked(handle);
    if (e != NULL) {
        IBinder* b = e->binder;
        if (b == NULL || !e->refs->attemptIncWeak(this)) {
            if (handle == 0) { // handle为0，即ServiceManager
                Parcel data;
                // 底层是binder_ioctl，查看对应的handle对应的binder是否已死
                status_t status = IPCThreadState::self()->transact(0, IBinder::PING_TRANSACTION, data, NULL, 0);
                if (status == DEAD_OBJECT)
                   return NULL;
            }
            // 创建BpBinder
            b = new BpBinder(handle); 
            e->binder = b;
            if (b) e->refs = b->getWeakRefs();
            result = b;
        } else {
            result.force_set(b);
            e->refs->decWeak(this);
        }
    }
    return result;
}

利用 ProcessState::self()->getContextObject(NULL)) App进程获取到了ServiceManager的BpBinder，其中BpBinder的handle是0

向ServiceManager中注册服务

在系统启动ServiceManager后，接着会启动zygote进程，zygote进程会启动SystemServer进程，在SystemServer中会继续启动系统所需的各种服务，如AMS,WMS,PMS等，在这些系统服务启动完成后，会想ServiceManager中进行注册操作

注册的操作跟我们在前面博文中分析的RemoteService进程向Activity进程发送Binder实例类似，是将系统服务的Binder发送到ServiceManager中，而发送的媒介就是ServiceManager的Proxy,在发送完成后，这些系统服务的Binder实例也转换为BinderProxy，ServiceManager会将这些BinderProxy保存

Android系统的运行结构大概如下图：

image.png

简单画了一下一个APP进程想要使用AMS的过程：

image.png

如果从系统启动开始，那么的过程大致如下：
1.init进程启动ServiceManager、zygote、SystemServer进程
2.SystemServer进程启动各种系统服务，如AMS
3.AMS启动后通过addService向ServiceManager注册
4.ServiceManger收到消息后保存AMS的BinderProxy及对应字符串
5.APP进程获取到ServiceManger的BinderProxy并发起获取AMS的请求
6.ServiceManager收到请求并根据字符串找到AMS的BinderProxy返回给App进程
7.App进程拿到AMS的BinderProxy与AMS远端进行通信

经历过这一切，才到达我们这系列文章的起点，即Context#bindeService的执行，而在Activity中发起bindService又经历了什么呢？大概如下图：

image.png

从APP进程发起，通过AMS，经过四次IPC过程，RemoteService的binder才会发送到APP进程，在拿到Service的BinderProxy后，App进程即可与RemoteService进程通信

通过上面的分析，我们基本缕清了Binder作为IPC工具究竟在Android系统中占了怎样的地位，可以说，没有Binder就没有Android系统