大纲
-
Binder通信机制介绍
- Android与Linux通信机制的比较
-
Binder在Service服务中的作用
-
Binder通信机制流程
- Android与Linux通信机制的比较
-
数据结构分析
-
驱动分析
-
Binder的流程分析
-
Service Manager成为守护进程
-
Server和Client获得ServiceManager的远程接口
-
Server向SM注册服务
-
Client从SM获得服务
-
-
基于framework层的实现
-
初始化framework层Binder框架
-
C/S获得ServiceManager的Java远程接口过程
-
XXXService的接口定义和启动过程,添加自己到SM中
-
Client获得XXXService的Java远程接口过程
-
Client通过Java远端接口使用XXXService提供的服务
-
-
实际应用
-
PMService例子
-
碰到的问题及解决办法
-
1. Binder通信机制介绍
1.1 Android与Linux通信机制的比较
虽然Android继承使用Linux的内核,但Linux与Android的通信机制不同。
在Linux中使用的IPC通信机制如下:
- 传统IPC:无名pipe, signal, trace, 有名管道
- AT&T Unix 系统V:共享内存,信号灯,消息队列
- BSD Unix:Socket
而在Android中,并没有使用这些,取而代之的是Binder机制。Binder机制是采用OpenBinder演化而来,在Android中使用它的原因如下:
- 采用C/S的通信模式。而在linux通信机制中,目前只有socket支持C/S的通信模式,但socket有其劣势,具体参看第二条。
- 有更好的传输性能。对比于Linux的通信机制,socket:是一个通用接口,导致其传输效率低,开销大;管道和消息队列:因为采用存储转发方式,所以至少需要拷贝2次数据,效率低;共享内存:虽然在传输时没有拷贝数据,但其控制机制复杂(比如跨进程通信时,需获取对方进程的pid,得多种机制协同操作)。
- 安全性更高。Linux的IPC机制在本身的实现中,并没有安全措施,得依赖上层协议来进行安全控制。而Binder机制的UID/PID是由Binder机制本身在内核空间添加身份标识,安全性高;并且Binder可以建立私有通道,这是linux的通信机制所无法实现的(Linux访问的接入点是开放的)。
综上所述,Android采用Binder机制是有道理的。既然Binder机制这么多优点,那么我们接下来看看它的实现思路是怎样的。
1.2 Binder在Service服务中的作用
在android中,有很多Service都是通过binder来通信的,比如MediaServer旗下包含了众多service:
- AudioFlinger 音频核心服务
- AudioPolicyService:音频策略相关的重要服务
- MediaPlayerService:多媒体系统中的重要服务
- CameraService:有关摄像/照相的重要服务
- Server注册服务。Server作为众多Service的拥有者,当它想向Client提供服务时,得先去Service Manager(SM)那儿注册自己的服务。Server可以向SM注册一个或多个服务。
- Client申请服务。Client作为Service的使用者,当它想使用服务时,得向SM申请自己所需要的服务。Client可以申请一个或多个服务。
- 当Client申请服务成功后,Client就可以使用服务了。
注意:SM一方面管理Server所提供的服务,同时又响应Client的请求并为之分配相应的服务。扮演的角色相当于月老,两边牵线。这种通信方式的好处是:一方面,service和Client请求便于管理,另一方面在应用程序开发时,只需为Client建立到Server的连接,就可花很少时间和精力去实现Server相应功能。那么,Binder与这个通信模式有什么关系呢?!其实,3者的通信用的就是Binder机制。
Client向SM申请一个或多个服务。SM的作用相当于月老,管理Server所提供的服务,同时又响应Client的请求并为之分配相应的服务。
2. Client根据得到的服务信息与服务所在的Server进程建立通信的通路,然后可以直接与Server交互了;好处:
Client,Server与SM的通信:
3者的通信机制是基于Binder的。