一.概述

1.1 media服务注册

media入口函数是main_mediaserver.cpp中的main()方法，代码如下：

过程说明:

获取ServiceManager: 讲解了defaultServiceManager()返回的是BpServiceManager对象， 用于跟servicemanager进程通信;

理解Binder线程池的管理, 讲解了startThreadPool和joinThreadPool过程.

本文的重点就是讲解Native层服务注册的过程.

1.2 类图

在Native层的服务以media服务为例，来说一说服务注册过程，先来看看media的整个的类关系图

图解：

蓝色代表的是注册MediaPlayerService服务所涉及的类

绿色代表的是Binder架构中与Binder驱动通信过程中的最为核心的两个类；

紫色代表的是注册服务和获取服务的公共接口/父类；

1.3 时序图

先通过一幅图来说说，media服务启动过程是如何向servicemanager注册服务的。

二. ProcessState

2.1 ProcessState::self

[-> ProcessState.cpp]

获得ProcessState对象: 这也是单例模式，从而保证每一个进程只有一个ProcessState对象。其中gProcess和gProcessMutex是保存在Static.cpp类的全局变量。

2.2 ProcessState初始化

[-> ProcessState.cpp]

ProcessState的单例模式的惟一性，因此一个进程只打开binder设备一次,其中ProcessState的成员变量mDriverFD记录binder驱动的fd，用于访问binder设备。

BINDER_VM_SIZE = (1*1024*1024) - (4096 *2), binder分配的默认内存大小为1M-8k。

DEFAULT_MAX_BINDER_THREADS = 15，binder默认的最大可并发访问的线程数为16。

2.3 open_driver

[-> ProcessState.cpp]

open_driver作用是打开/dev/binder设备，设定binder支持的最大线程数。关于binder驱动的相应方法，见文章Binder Driver初探。

ProcessState采用单例模式，保证每一个进程都只打开一次Binder Driver。

2.4 mmap

参数说明：

addr: 代表映射到进程地址空间的起始地址，当值等于0则由内核选择合适地址，此处为0；

size: 代表需要映射的内存地址空间的大小，此处为1M-8K；

prot: 代表内存映射区的读写等属性值，此处为PROT_READ(可读取);

flags: 标志位，此处为MAP_PRIVATE(私有映射，多进程间不共享内容的改变)和 MAP_NORESERVE(不保留交换空间)

fd: 代表mmap所关联的文件描述符，此处为mDriverFD；

offset：偏移量，此处为0。

mmap()经过系统调用，执行binder_mmap过程。

三. 服务注册

3.1 instantiate

[-> MediaPlayerService.cpp]

注册服务MediaPlayerService：由defaultServiceManager()返回的是BpServiceManager，同时会创建ProcessState对象和BpBinder对象。 故此处等价于调用BpServiceManager->addService。其中MediaPlayerService位于libmediaplayerservice库.

3.2 BpSM.addService

[-> IServiceManager.cpp ::BpServiceManager]

服务注册过程：向ServiceManager注册服务MediaPlayerService，服务名为”media.player”；

3.2.1 writeStrongBinder

[-> parcel.cpp]

3.2.2 flatten_binder

[-> parcel.cpp]

将Binder对象扁平化，转换成flat_binder_object对象。

对于Binder实体，则cookie记录Binder实体的指针；

对于Binder代理，则用handle记录Binder代理的句柄；

关于localBinder，代码见Binder.cpp。

3.2.3 finish_flatten_binder

3.2.3 finish_flatten_binder

将flat_binder_object写入out。

3.3 BpBinder::transact

[-> BpBinder.cpp]

Binder代理类调用transact()方法，真正工作还是交给IPCThreadState来进行transact工作。先来 看看IPCThreadState::self的过程。

3.3.1 IPCThreadState::self

[-> IPCThreadState.cpp]

\TLS是指Thread local storage(线程本地储存空间)，每个线程都拥有自己的TLS，并且是私有空间，线程之间不会共享。通过pthread_getspecific/pthread_setspecific函数可以获取/设置这些空间中的内容。从线程本地存储空间中获得保存在其中的IPCThreadState对象。

3.3.2 IPCThreadState初始化

[-> IPCThreadState.cpp]

每个线程都有一个IPCThreadState，每个IPCThreadState中都有一个mIn、一个mOut。成员变量mProcess保存了ProcessState变量(每个进程只有一个)。

mIn 用来接收来自Binder设备的数据，默认大小为256字节；

mOut用来存储发往Binder设备的数据，默认大小为256字节。

3.4 IPC::transact

[-> IPCThreadState.cpp]

IPCThreadState进行transact事务处理分3部分：

errorCheck() //数据错误检查

writeTransactionData() // 传输数据

waitForResponse() //f等待响应

3.5 IPC.writeTransactionData

[-> IPCThreadState.cpp]

其中handle的值用来标识目的端，注册服务过程的目的端为service manager，此处handle=0所对应的是binder_context_mgr_node对象，正是service manager所对应的binder实体对象。binder_transaction_data结构体是binder驱动通信的数据结构，该过程最终是把Binder请求码BC_TRANSACTION和binder_transaction_data结构体写入到mOut。

transact过程，先写完binder_transaction_data数据，其中Parcel data的重要成员变量：

mDataSize:保存再data_size，binder_transaction的数据大小；

mData: 保存在ptr.buffer, binder_transaction的数据的起始地址；

mObjectsSize:保存在ptr.offsets_size，记录着flat_binder_object结构体的个数；

mObjects: 保存在offsets, 记录着flat_binder_object结构体在数据偏移量；

接下来执行waitForResponse()方法。

3.6 IPC.waitForResponse

[-> IPCThreadState.cpp]

在waitForResponse过程, 首先执行BR_TRANSACTION_COMPLETE；另外，目标进程收到事务后，处理BR_TRANSACTION事务。 然后发送给当前进程，再执行BR_REPLY命令。

3.7 IPC.talkWithDriver

[-> IPCThreadState.cpp]

binder_write_read结构体用来与Binder设备交换数据的结构, 通过ioctl与mDriverFD通信，是真正与Binder驱动进行数据读写交互的过程。 主要是操作mOut和mIn变量。

ioctl()经过系统调用后进入Binder Driver.

四. Binder Driver

ioctl -> binder_ioctl -> binder_ioctl_write_read

4.1 binder_ioctl_write_read

[-> binder.c]

4.2 binder_thread_write

4.3 binder_transaction

注册服务的过程，传递的是BBinder对象，故[小节3.2.1]的writeStrongBinder()过程中localBinder不为空， 从而flat_binder_object.type等于BINDER_TYPE_BINDER。

服务注册过程是在服务所在进程创建binder_node，在servicemanager进程创建binder_ref。 对于同一个binder_node，每个进程只会创建一个binder_ref对象。

向servicemanager的binder_proc->todo添加BINDER_WORK_TRANSACTION事务，接下来进入ServiceManager进程。

4.3.1 binder_get_node

从binder_proc来根据binder指针ptr值，查询相应的binder_node。

4.3.2 binder_new_node

4.3.3 binder_get_ref_for_node

handle值计算方法规律：

每个进程binder_proc所记录的binder_ref的handle值是从1开始递增的；

所有进程binder_proc所记录的handle=0的binder_ref都指向service manager；

同一个服务的binder_node在不同进程的binder_ref的handle值可以不同；

五. ServiceManager

由Binder系列3—启动ServiceManager已介绍其原理，循环在binder_loop()过程， 会调用binder_parse()方法。

5.1 binder_parse

[-> servicemanager/binder.c]

5.2 svcmgr_handler

[-> service_manager.c]

5.3 do_add_service

[-> service_manager.c]

\svcinfo记录着服务名和handle信息，保存到svclist列表。

5.4 binder_send_reply

[-> servicemanager/binder.c]

binder_write进入binder驱动后，将BC_FREE_BUFFER和BC_REPLY命令协议发送给Binder驱动， 向client端发送reply.

六. 总结

服务注册过程(addService)核心功能：在服务所在进程创建binder_node，在servicemanager进程创建binder_ref。 其中binder_ref的desc再同一个进程内是唯一的：

每个进程binder_proc所记录的binder_ref的handle值是从1开始递增的；

所有进程binder_proc所记录的handle=0的binder_ref都指向service manager；

同一个服务的binder_node在不同进程的binder_ref的handle值可以不同；

Media服务注册的过程涉及到MediaPlayerService(作为Client进程)和Service Manager(作为Service进程)，通信流程图如下所示：

过程分析：

MediaPlayerService进程调用ioctl()向Binder驱动发送IPC数据，该过程可以理解成一个事务binder_transaction(记为T1)，执行当前操作的线程binder_thread(记为thread1)，则T1->from_parent=NULL，T1->from = thread1，thread1->transaction_stack=T1。其中IPC数据内容包含：

Binder协议为BC_TRANSACTION；

Handle等于0；

RPC代码为ADD_SERVICE；

RPC数据为”media.player”。

Binder驱动收到该Binder请求，生成BR_TRANSACTION命令，选择目标处理该请求的线程，即ServiceManager的binder线程(记为thread2)，则 T1->to_parent = NULL，T1->to_thread = thread2。并将整个binder_transaction数据(记为T2)插入到目标线程的todo队列；

Service Manager的线程thread2收到T2后，调用服务注册函数将服务”media.player”注册到服务目录中。当服务注册完成后，生成IPC应答数据(BC_REPLY)，T2->form_parent = T1，T2->from = thread2, thread2->transaction_stack = T2。

Binder驱动收到该Binder应答请求，生成BR_REPLY命令，T2->to_parent = T1，T2->to_thread = thread1, thread1->transaction_stack = T2。 在MediaPlayerService收到该命令后，知道服务注册完成便可以正常使用。

整个过程中，BC_TRANSACTION和BR_TRANSACTION过程是一个完整的事务过程；BC_REPLY和BR_REPLY是一个完整的事务过程。 到此，其他进行便可以获取该服务，使用服务提供的方法，下一篇文章将会讲述如何获取服务。