安卓 rxjava 使用，4 面字节跳动拿到 Offer，面试必问

前言

其实对于很多人来说，都和我原来有同样一个疑虑：**到底去大厂还是创业型公司？**去大公司一个萝卜一个坑，要往上走需要运气+实力足够好才能脱颖而出，创业型公司，可能更容易实现自己的想法和舞台，能把能力表现的淋漓尽致，可是会碰到更多的问题，公司经营不下去了怎么办？薪资待遇不如大厂？

接下来正面回答这个问题，从 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 手机。

Android 中权限控制策略有 SELinux 等多方面手段，下面列举从 Binder 的一个角度的权限控制：

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

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

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

如果你进阶的路上缺乏方向，可以点击我的【腾讯文档】加入我们的圈子和安卓开发者们一起学习交流！以下全部内容都可以在腾讯文档中获取！

• Android 进阶学习全套手册

• 
  
  

• Android 对标阿里 P7 学习视频

• 
  
  

• BATJ 大厂 Android 高频面试题

• 
  
  

最后，借用我最喜欢的乔布斯语录，作为本文的结尾：

人这一辈子没法做太多的事情，所以每一件都要做得精彩绝伦。你的时间有限，所以不要为别人而活。不要被教条所限，不要活在别人的观念里。不要让别人的意见左右自己内心的声音。最重要的是，勇敢的去追随自己的心灵和直觉，只有自己的心灵和直觉才知道你自己的真实想法，其他一切都是次要。