浅谈Binder通讯原理与机制

Binder是Android提供的一种进程间通讯（IPC，Inter-Process Communication）机制。

Android是基于Linux的操做系统，Linux自带多种进程通讯方式，为何还要引入Binder。因此在讲解Binder以前，先来分析Linux自带的七种通讯方式。

1、Linux系统的进程间通讯

进程是一个独立的资源分配单元，不一样进程（一般指用户进程）之间的资源是独立的，一个进程不能直接访问另外一个进程的资源，可是，进程不是孤立的，不一样的进程须要进行信息的交互和状态的传递等，所以须要进程间通讯。

进程间通讯的目的：

• 数据传输：一个进程须要将它的数据发送给另外一个进程。
• 通知事件：一个进程须要向另外一个或一组进程发送消息，通知它（它们）发生了某种事件（如进程终止时要通知父进程）。
• 资源共享：多个进程之间共享一样的资源。为了作到这一点，须要内核提供互斥和同步机制。
• 进程控制：有些进程但愿彻底控制另外一个进程的执行（如 Debug 进程），此时控制进程但愿可以拦截另外一个进程的全部陷入和异常，并可以及时知道它的状态改变。

Linux只要支持的七种进程间通讯方式以下：

（1）管道(pipe)

管道是由内核管理的一个缓冲区，至关于咱们放入内存中的一个纸条。管道的一端链接一个进程的输出，这个进程会向管道中放入信息。管道的另外一端链接一个进程的输入，这个进程取出被放入管道的信息。一个缓冲区不须要很大，它被设计成 环形的数据结构，以即可循环利用。当管道中没有信息的话，从管道中读取的进程会等待，直到另外一端的进程放入信息。当管道被放满信息的时候，尝试放入信息的进程会等待，直到另外一端的进程取出信息。当两个进程都终结的时候，管道也自动消失。

管道容许一个进程和另外一个与它有共同祖先的进程之间进行通讯。

（2）命名管道（FIFO）

相似于管道，可是它能够用于任何两个进程之间的通讯，命名管道在文件系统中有对应的文件名。命名管道经过命令mkfifo或系统调用mkfifo来建立。

缺点（管道和命名管道）：在建立时分配一个管道时，缓存区大小比较有限，数据以无格式字节流传输；并不适合Android大量的进程通讯。

（3）消息队列(message queue)

消息队列提供了一种从一个进程向另外一个进程发送一个数据块的方法。 每一个数据块都被认为含有一个类型，接收进程能够独立地接收含有不一样类型的数据结构。咱们能够经过发送消息来避免命名管道的同步和阻塞问题。可是消息队列与命名管道同样，每一个数据块都有一个最大长度的限制。

缺点: 信息复制两次，额外的CPU消耗；不合适频繁或信息量大的通讯；

（4）共享内存(shared memory)

共享内存就是容许两个不相关的进程访问同一个逻辑内存，是最快的可用IPC形式。不一样进程之间共享的内存一般安排为同一段物理内存，进程能够将同一段共享内存链接到它们本身的地址空间中，全部进程均可以访问共享内存中的地址。同时，为了安全性考虑，它每每与其余通讯机制，如信号量结合使用，以达到进程间的同步及互斥。无须复制，共享缓冲区直接付附加到进程虚拟地址空间，速度快。

缺点: 通讯须要设计复杂的机制保证各进程通信有效性。进程间的同步问题操做系统没法实现，必须各进程利用同步工具解决； 安全问题比较突出，若是Android采用Binder 无异于将每一个App放在一个内存中，这样是很是不安全的。

（5）套接字(Socket)

套接字做为更通用的接口，传输效率低，主要用于不通机器或跨网络的通讯。

（6）信号量(semaphore)

常做为一种锁机制，防止某进程正在访问共享资源时，其余进程也访问该资源。所以，主要做为进程间以及同一进程内不一样线程之间的同步手段。

（7）信号(signal)

不适用于信息交换，更适用于进程中断控制，好比非法内存访问，杀死某个进程等；

2、为何Android引入Binder通讯？

下面咱们从5个角度来展开对Binder的分析：

(1) 从性能的角度 数据拷贝次数：Binder数据拷贝只须要一次，而管道、消息队列、Socket都须要2次，但共享内存方式一次内存拷贝都不须要；从性能角度看，Binder性能仅次于共享内存。

(2) 从稳定性的角度 Binder是基于C/S架构的，简单解释下C/S架构，是指客户端(Client)和服务端(Server)组成的架构，Client端有什么需求，直接发送给Server端去完成，架构清晰明朗，Server端与Client端相对独立，稳定性较好；而共享内存实现方式复杂，没有客户与服务端之别， 须要充分考虑到访问临界资源的并发同步问题，不然可能会出现死锁等问题；从这稳定性角度看，Binder架构优越于共享内存。

仅仅从以上两点，各有优劣，还不足以支撑google去采用binder的IPC机制，那么更重要的缘由是：

(3) 从安全的角度 传统Linux IPC的接收方没法得到对方进程可靠的UID/PID，从而没法鉴别对方身份；而Android做为一个开放的开源体系，拥有很是多的开发平台，App来源甚广，所以手机的安全显得额外重要；对于普通用户，毫不但愿从App商店下载偷窥隐射数据、后台形成手机耗电等等问题，传统Linux IPC无任何保护措施，彻底由上层协议来确保。

Android为每一个安装好的应用程序分配了本身的UID，故进程的UID是鉴别进程身份的重要标志，前面提到C/S架构，Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否知足访问权限，目前权限控制不少时候是经过弹出权限询问对话框，让用户选择是否运行。Android 6.0，也称为Android M，在6.0以前的系统是在App第一次安装时，会将整个App所涉及的全部权限一次询问，只要留意看会发现不少App根本用不上通讯录和短信，但在这一次性权限权限时会包含进去，让用户拒毫不得，由于拒绝后App没法正常使用，而一旦受权后，应用即可以胡做非为。

针对这个问题，google在Android M作了调整，再也不是安装时一并询问全部权限，而是在App运行过程当中，须要哪一个权限再弹框询问用户是否给相应的权限，对权限作了更细地控制，让用户有了更多的可控性，但**同时也带来了另外一个用户诟病的地方，那也就是权限询问的弹框的次数大幅度增多。**对于Android M平台上，有些App开发者可能会写出让手机异常频繁弹框的App，企图直到用户受权为止，这对用户来讲是不能忍的，用户最后吐槽的可不光是App，还有Android系统以及手机厂商，有些用户可能就跳果粉了，这还须要广大Android开发者以及手机厂商共同努力，共同打造安全与体验俱佳的Android手机。

传统IPC只能由用户在数据包里填入UID/PID；另外，可靠的身份标记只有由IPC机制自己在内核中添加。其次传统IPC访问接入点是开放的，没法创建私有通道。从安全角度，Binder的安全性更高。

说到这，可能有人要反驳，Android就算用了Binder架构，而现现在Android手机的各类流氓软件，不就是干着这种偷窥隐射，后台偷偷跑流量的事吗？没错，确实存在，但这不能说Binder的安全性很差，由于Android系统仍然是掌握主控权，能够控制这类App的流氓行为，只是对于该采用何种策略来控制，在这方面android的确存在不少有待进步的空间，这也是google以及各大手机厂商一直努力改善的地方之一。在Android 6.0，google对于app的权限问题做为较多的努力，大大收紧的应用权限；另外，在Google举办的Android Bootcamp 2016大会中，google也表示在Android 7.0 （也叫Android N）的权限隐私方面会进一步增强加固，好比SELinux，Memory safe language(还在research中)等等，在今年的5月18日至5月20日，google将推出Android N。

话题扯远了，继续说Binder。

(4）从语言层面的角度 你们多知道Linux是基于C语言(面向过程的语言)，而Android是基于Java语言(面向对象的语句)，而对于Binder偏偏也符合面向对象的思想，将进程间通讯转化为经过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个能够跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍及于系统的各个进程之中。能够从一个进程传给其它进程，让你们都能访问同一Server，就像将一个对象或引用赋值给另外一个引用同样。Binder模糊了进程边界，淡化了进程间通讯过程，整个系统仿佛运行于同一个面向对象的程序之中。从语言层面，Binder更适合基于面向对象语言的Android系统，对于Linux系统可能会有点“水土不服”。

另外，Binder是为Android这类系统而生，而并不是Linux社区没有想到Binder IPC机制的存在，对于Linux社区的广大开发人员，我仍是表示深深佩服，让世界有了如此精湛而美妙的开源系统。也并不是Linux现有的IPC机制不够好，相反地，通过这么多优秀工程师的不断打磨，依然很是优秀，每种Linux的IPC机制都有存在的价值，同时在Android系统中也依然采用了大量Linux现有的IPC机制，根据每类IPC的原理特性，因时制宜，不一样场景特性每每会采用其下最适宜的。好比在Android OS中的Zygote进程的IPC采用的是Socket（套接字）机制，Android中的Kill Process采用的signal（信号）机制等等。而Binder更多则用在system_server进程与上层App层的IPC交互。

(5) 从公司战略的角度

总所周知，Linux内核是开源的系统，所开放源代码许可协议GPL保护，该协议具备“病毒式感染”的能力，怎么理解这句话呢？受GPL保护的Linux Kernel是运行在内核空间，对于上层的任何类库、服务、应用等运行在用户空间，一旦进行SysCall（系统调用），调用到底层Kernel，那么也必须遵循GPL协议。

而Android 之父 Andy Rubin对于GPL显然是不能接受的，为此，Google巧妙地将GPL协议控制在内核空间，将用户空间的协议采用Apache-2.0协议（容许基于Android的开发商不向社区反馈源码），同时在GPL协议与Apache-2.0之间的Lib库中采用BSD证受权方法，有效隔断了GPL的传染性，仍有较大争议，但至少目前缓解Android，让GPL止步于内核空间，这是Google在GPL Linux下 开源与商业化共存的一个成功典范。

综合上述5点，可知Binder是Android系统上层进程间通讯的不二选择。

3、Binder通讯原理与机制

 Linux将空间分为内核空间和用户空间，Linux 操做系统和驱动程序运行在内核空间，用户运用程序（用户进程）运行在用户空间。两个不一样的用户进程之间不能够直接访问，而用户空间能够经过System calls（系统回调）与内核空间通讯的，若是在内核空间中有一个模块，可以完成数据的转发，那么两个进程就能够通讯了。Binder是基于C/S架构的，即指客户端(Client)和服务端(Server)组成的架构，Client端有什么需求，直接发送给Server端去完成，以下图所示：

Binder的通讯模型有4个角色：Binder Client、Binder Server、Binder Driver（Binder驱动）、ServiceManager。

Binder Client是请求服务的进程；Binder Server是提供服务的进程；Binder驱动承载进程间通讯的数据转发；ServiceManager维护映射关系表，都有哪些服务，每一个都是什么、有什么方法可调用。ServiceManager、Binder Client、Binder Server处于不一样的进程，他们三个都在用户空间，而Binder驱动在内核空间。

下面咱们以一个案例来大体说明Binder的通讯过程，案例：Client A进程调用Server B进程的computer对象的add方法。

1，Server进程向ServiceManager注册，告诉ServiceManager我是谁，我有什么，我能作什么。就比如Server B进程有一个computer对象，这个computer对象有个add方法，这时映射关系表就生成了。

2，Client A进程向ServiceManager查询，我要调用Server B进程的computer对象的add方法，因为Binder Client和ServiceManager处于不一样的进程，因此这个过程也要通过Binder驱动，这时候Binder驱动就开始发挥他的做用了。当向ServiceManager查询完毕，Binder驱动将computer对象转换成了computerProxy对象，并转发给了Client A进程，所以，Client A进程拿到的并非真实的computer对象，而是一个代理对象，即computerProxy对象。

3，当Client A进程调用add方法，这个消息发送给Binder驱动，这时驱动发现，原来是computerProxy，那么Client A进程应该是须要调用computer对象的add方法的，这时驱动通知Server B进程，调用你的computer对象的add方法，将结果给我。而后Server B进程就将计算结果发送给驱动，驱动再转发给Client A进程，这时Client进程还蒙在了鼓里，他觉得本身调用的是真实的computer对象的add方法，其实他只是调用了代理而已，不过Client最终仍是拿到了计算结果。这里能够发现，Binder驱动起到了中转的做用。

Binder的架构图以下图所示：

 

 

参考连接：

http://blog.csdn.net/lianghe_work/article/details/47707667

https://blog.csdn.net/zhu2695/article/details/51148249

https://github.com/interviewandroid/AndroidInterView