Binder系列5—注册服务(addService)

Binder系列5—注册服务(addService)_第1张图片

一.概述

1.1 media服务注册

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


Binder系列5—注册服务(addService)_第2张图片

过程说明:

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

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

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

1.2 类图

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


Binder系列5—注册服务(addService)_第3张图片

图解:

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

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

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

1.3 时序图

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


Binder系列5—注册服务(addService)_第4张图片


二. ProcessState

2.1 ProcessState::self

[-> ProcessState.cpp]


Binder系列5—注册服务(addService)_第5张图片

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

2.2 ProcessState初始化

[-> ProcessState.cpp]


Binder系列5—注册服务(addService)_第6张图片

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]


Binder系列5—注册服务(addService)_第7张图片

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系列5—注册服务(addService)_第8张图片

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

对于Binder实体,则cookie记录Binder实体的指针;

对于Binder代理,则用handle记录Binder代理的句柄;

关于localBinder,代码见Binder.cpp。


Binder系列5—注册服务(addService)_第9张图片

3.2.3 finish_flatten_binder

3.2.3 finish_flatten_binder


将flat_binder_object写入out。

3.3 BpBinder::transact

[-> BpBinder.cpp]


Binder系列5—注册服务(addService)_第10张图片

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

3.3.1 IPCThreadState::self

[-> IPCThreadState.cpp]


Binder系列5—注册服务(addService)_第11张图片

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

3.3.2 IPCThreadState初始化

[-> IPCThreadState.cpp]


Binder系列5—注册服务(addService)_第12张图片

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

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

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

3.4 IPC::transact

[-> IPCThreadState.cpp]


Binder系列5—注册服务(addService)_第13张图片

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

errorCheck() //数据错误检查

writeTransactionData() // 传输数据

waitForResponse() //f等待响应

3.5 IPC.writeTransactionData

[-> IPCThreadState.cpp]


Binder系列5—注册服务(addService)_第14张图片

其中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]


Binder系列5—注册服务(addService)_第15张图片

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

3.7 IPC.talkWithDriver

[-> IPCThreadState.cpp]


Binder系列5—注册服务(addService)_第16张图片

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]


Binder系列5—注册服务(addService)_第17张图片

4.2 binder_thread_write


Binder系列5—注册服务(addService)_第18张图片

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系列5—注册服务(addService)_第19张图片

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

4.3.2 binder_new_node


Binder系列5—注册服务(addService)_第20张图片

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]


Binder系列5—注册服务(addService)_第21张图片

\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进程),通信流程图如下所示:


Binder系列5—注册服务(addService)_第22张图片

过程分析:

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是一个完整的事务过程。 到此,其他进行便可以获取该服务,使用服务提供的方法,下一篇文章将会讲述如何获取服务。

你可能感兴趣的:(Binder系列5—注册服务(addService))