图解Android中的binder机制

前言

Binder作为Android中核心机制，对于理解Android系统是必不可少的，关于binder的文章也有不少，可是每次看总感受看的不是很懂，到底什么才是binder机制？为何要使用binder机制？binder机制又是怎样运行的呢？这些问题只是了解binder机制是不够的，须要从Android的总体系统出发来分析，在我找了不少资料后，真正的弄懂了binder机制，相信看完这篇文章你们也能够弄懂binder机制。

一、Binder是什么？

要理解binder，先要知道IPC，Inter-process communication ,也就是进程中相互通讯，Binder是Android提供的一套进程间相互通讯框架。用来多进程间发送消息，同步和共享内存。已有的进程间通讯方式有一下几种：

一、Files 文件系统（包括内存映射） 二、Sockets 三、Pipes 管道 四、共享内存 五、Intents, ContentProviders, Messenger 六、Binder

Android系统中的Binder框架图以下：

拿Activity举例从上图能够看出来：Activity是由ActivityManager来控制的，而ActivityManager实际上是经过Binder获取ActivityManagerService服务来控制Activity的，而且ActivityManager是Android系统FrameWork层的，和应用中的activity不是同一个进程。

重点：

一、Binder是Android提供的一套进程间通讯框架。

二、系统服务ActivityManagerService,LocationManagerService，等都是在单独进程中的，使用binder和应用进行通讯。

二、Android系统框架

如上图，Android系统分红三层。最上层是application应用层，第二层是Framework层，第三层是native层。 由下图可知几点：

一、Android中的应用层和系统服务层不在同一个进程，系统服务在单独的进程中。

二、Android中不一样应用属于不一样的进程中。

Android应用和系统services运行在不一样进程中是为了安全，稳定，以及内存管理的缘由，可是应用和系统服务须要通讯和分享数据。

优势

安全性：每一个进程都单独运行的，能够保证应用层对系统层的隔离。

稳定性：若是某个进程崩溃了不会致使其余进程崩溃。

内存分配：若是某个进程以及不须要了能够从内存中移除，而且回收相应的内存。

三、Binder通讯

client请求service服务，好比说Activity请求Activity ManagerService服务，因为Activity和ActivityManagerService是在两个不一样的进程中的，那么下图是一个很直观的请求过程。

可是注意，一个进程是不能直接直接操做另外一个进程的，好比说读取另外一个进程的数据，或者往另外一个进程的内存空间写数据，进程之间的通讯要经过内核进程才能够，所以这里就要使用到进程通讯工具Binder了以下图：

Binder driver经过/dev/binder /dev/binder 提供了 open, release release, poll poll, mmap mmap, flush flush, and ioctl等操做的接口api。这样进程A和进程B就能够经过内核进程进行通讯了。进程中大部分的通讯都是经过ioctl（binderFd, BINDER_WRITE_READ, &bwd）来进行的。bwd 的定义以下：

struct binder_write_read {  
  signed long write_size;/* bytes to write */ 
  signed long write_consumed; /* bytes consumed by driver */  
  unsigned long write_buffer; 
  signed long read_size;  /* bytes to read */ 
  signed long read_consumed;  /* bytes consumed by driver */  
  unsigned long read_buffer;
   };
复制代码

可是上面还有个问题就是client和service要直接和binder driver打交道，可是实际上client和service并不想知道binder相关协议，因此进一步client经过添加proxy代理，service经过添加stub来进一步处理与binder的交互。

这样的好处是client和service均可以不用直接去和binder打交道。上面的图好像已经很完善了，可是Android系统更进一步封装，不让client知道Binder的存在，Android系统提供了Manager来管理client。以下图：

这样client只须要交给manager来管理就行了，根本就不用关心进程通讯相关的事，关于manager实际上是很熟悉的，好比说activity的就是由ActivityManager来控制的，ActivityManager是经过Binder获取ActivityManagerService来控制activity的。这样就不用咱们本身来使用Binder来ActivityManagerService通讯了。

更进一步，client是如何具体获取到哪一个service的呢？以下图所示：

在service和binder之间还有一个contextManager，也就是serviceManager，每个service要先往serviceManager里面进行注册，注册完成以后由serviceManager统一管理。 在Android studio中能够经过adb指定打印出当前已经注册过serviceManager的service。

$ adb shell service list 
Found 71 services: 0 sip: 
[android.net.sip.ISipService] 1 phone: [com.android.internal.telephony.ITelephony] … 20  location: [android.location.ILocationManager] …
 55  activity: [android.app.IActivityManager] 
 56  package: [android.content.pm.IPackageManager] … 
 67  SurfaceFlinger: [android.ui.ISurfaceComposer] 
 68  media.camera: [android.hardware.ICameraService] 
 69  media.player: [android.media.IMediaPlayerService]
  70  media.audio_flinger: [android.media.IAudioFlinger]
复制代码

下图是一次更加完整的client和service的通讯流程：

四、Binder框架

在看Binder框架以前，先来看一下，从client发出请求service的完整的流程。

获取服务过程：

第一步：client要请求服务，好比说在activity中调用context.getSystemService()方法，这个时候serviceManager就会使用getService（name），而后就会调用到native层中的ServiceManagerNative类中的getService(name)方法。

第二步：ServiceManagerNative会经过Binder发送一条SVG_MGR_GET_SERVICE的指令，而后经过svcmgr_handler()调用do_find_service（）方法去svc_list中查找到相关的service。

第三步：查找到相应的服务后就会经过Binder将服务传给ServiceManagerNative，而后传给serviceManager，最后client就可使用了。

注意： 服务实在svclist中保存的，svclist是一个链表，所以客户端调用的服务必需要先注册到svclist中。

注册服务过程：

第一步： service经过调用serviceManager中的addService方法，而后调用ServiceManagerNative类中的addservice(name)方法。

第二步： ServiceManagerNative会经过Binder发送一条SVG_MGR_ADD_SERVICE的指令，而后经过svcmgr_handler()调用do_add_service（）方法往svc_list中添加相应的service。

重点：全部的服务都要先注册到svc_list中才能被client调用到。svc_list以linkedlist的形式保存这些服务。

Binder结构设计 要了解binder的结构设计，就要了解Android的体系结构，Android是分红application层，framework层native层，以及内核层，Binder设计在每一层上都有不一样的抽象。以下图：

由上图可知Binder的总体设计总共有四层：

一、Java层AIDL。

二、Framework层， Android.os.Binder 。

framework层中最重要的数据结构是transaction，有一下几个默认的：

三、Native 层: libBinder.cpp

在native层主要是libBinder

四、内核层 内核层的通讯都是经过ioctl来进行的，client打开一个ioctl,进入到轮询队列，一直阻塞直到时间到或者有消息。

五、Binder中使用的设计模式

一、代理模式（Proxy Pattern ） 在Android中client不是直接去和binder打交道，client直接和Manager交互，而manager和managerProxy交互，也就是说client是经过managerProxy去和binder进行交互的。同时service也不是直接和binder交互，而是经过stub去和binder交互。以下图。

二、Bridge Pattern 以下图，应用层也就是Java层要使用MediaPlayer,就要调用native层中的MediaPlayer.cpp，可是MediaPlay.java不是直接去跟JNI打交道，而是经过与MediaPlayerSevice通讯，从而通过Binder返回的。

六、Binder与内存映射mmap

Binder IPC 是基于内存映射（mmap）来实现的，可是 mmap() 一般是用在有物理介质的文件系统上的。

好比进程中的用户区域是不能直接和物理设备打交道的，若是想要把磁盘上的数据读取到进程的用户区域，须要两次拷贝（磁盘-->内核空间-->用户空间）；一般在这种场景下 mmap() 就能发挥做用，经过在物理介质和用户空间之间创建映射，减小数据的拷贝次数，用内存读写取代I/O读写，提升文件读取效率。

而 Binder 并不存在物理介质，所以 Binder 驱动使用 mmap() 并非为了在物理介质和用户空间之间创建映射，而是用来在内核空间建立数据接收的缓存空间。

一次完整的 Binder IPC 通讯过程一般是这样：

首先 Binder 驱动在内核空间建立一个数据接收缓存区； 接着在内核空间开辟一块内核缓存区，创建内核缓存区和内核中数据接收缓存区之间的映射关系，以及内核中数据接收缓存区和接收进程用户空间地址的映射关系； 发送方进程经过系统调用 copyfromuser() 将数据 copy 到内核中的内核缓存区，因为内核缓存区和接收进程的用户空间存在内存映射，所以也就至关于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通讯。 以下图：

参考文献

一、rts.lab.asu.edu/web_438/pro…

二、rts.lab.asu.edu/web_438/pro…