为什么 -Android- 要采用 -Binder- 作为 -IPC- 机制？，android 输入法开发源码

接下来正面回答这个问题，从 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 开发者以及手机厂商共同努力，共同打造安全与体验俱佳的 A

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

ndroid 手机。

Android 中权限控制策略有 SELinux 等多方面手段，下面列举从 Binder 的一个角度的权限控制： Android源码的Binder权限是如何控制？ -Gityuan的回答

传统 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 下 开源与商业化共存的一个成功典范。

有了这些铺垫，我们再说说 Binder 的今世前缘

Binder 是基于开源的 <u>OpenBinder</u>实现的，OpenBinder 是一个开源的系统 IPC 机制,最初是由 <u>Be Inc.</u>?开发，接着由<u>Palm, Inc.</u>公司负责开发，现在 OpenBinder 的作者在 Google 工作，既然作者在 Google 公司，在用户空间采用 Binder 作为核心的 IPC 机制，再用 Apache-2.0 协议保护，自然而然是没什么问题，减少法律风险，以及对开发成本也大有裨益的，那么从公司战略角度，Binder 也是不错的选择。

另外，再说一点关于 OpenBinder，在 2015 年 OpenBinder 以及合入到 Linux Kernel 主线 3.19 版本，这也算是 Google 对 Linux 的一点回馈吧。

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

------------------------------------------------------------------------------------------------------------------------------------------ 接着，回答上述提到的 D-Bus

也采用 C/S 架构的 IPC 机制，<u>D-Bus</u>是在用户空间实现的方法，效率低，消息拷贝次数和上下文切换次数都明显多过于 Binder。针对 D-Bus 这些缺陷，于是就产生了 kdbus，这是 D-Bus 在内核实现版，效率得到提升，与 Binder 一样在内核作为字符设计，通过 open()打开设备，mmap()映射内存。

（1）kdbus 在进程间通信过程，Client 端将消息在内存的消息队列，可以存储大量的消息，Server 端不断从消息队里中取消息，大小只受限内存； （2）Binder 的机制是每次通信，会通信的进程或线程中的 todo 队里中增加 binder 事务，并且每个进程所允许 Binder 线程数，google 提供的默认最大线程数为 16 个，受限于 CPU，由于线程数太多，增加系统负载，并且每个进程默认分配的（1M-8K）大小的内存。

而 kdbus 对于内存消耗较大，同时也适合传输大量数据和大量消息的系统。Binder 对 CPU 和内存的需求比较低，效率比较高，从而进一步说明 Binder 适合于移动系统 Android，但是，也有一定缺点，就是不同利用 Binder 输出大数据，比如利用 Binder 传输几 M 大小的图片，便会出现异常，虽然有厂商会增加 Binder 内存，但是也不可能比系统默认内存大很多，否则整个系统的可用内存大幅度降低。

最后，简单讲讲 Android Binder 架构

Binder 在 Android 系统中江湖地位非常之高。在 Zygote 孵化出 system_server 进程后，在 system_server 进程中出初始化支持整个 Android framework 的各种各样的 Service，而这些 Service 从大的方向来划分，分为 Java 层 Framework 和 Native Framework 层(C++)的 Service，几乎都是基于 BInder IPC 机制。

1.?**Java framework：作为 Server 端继承(或间接继承)于 Binder 类，Client 端继承(或间接继承)于 BinderProxy 类。**例如 ActivityManagerService(用于控制 Activity、Service、进程等) 这个服务作为 Server 端，间接继承 Binder 类，而相应的 ActivityManager 作为 Client 端，间接继承于 BinderProxy 类。 当然还有 PackageManagerService、WindowManagerService 等等很多系统服务都是采用 C/S 架构；

2.?**Native Framework 层：这是 C++层，作为 Server 端继承(或间接继承)于 BBinder 类，Client 端继承(或间接继承)于 BpBinder。**例如 MediaPlayService(用于多媒体相关)作为 Server 端，继承于 BBinder 类，而相应的 MediaPlay 作为 Client 端，间接继承于 BpBinder 类。

总之，一句话"无 Binder 不 Android"。

文末

最后，我再重复一次，如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。