洞悉 MySQL 底层架构:一举拿下腾讯美团滴滴 offer,持续更新中
前言
2021 全年从开头到结尾似乎就没多少好消息。这里我说的是整个互联网行业,并没有单单挑出某个公司或者某个细分领域。而对于广大 Android 开发者来说,找工作似乎也变得越来越难了。
2021 年 1 月,我在 51job 搜索了一下北京地区的 Android 岗位,只有 2100 多个,而几年前的时候,大概是 2018 年中期吧,我记得那时候 Android 岗位是过万的(我应该没有记错),现在的形势对 Android developer 如何可谓一目了然……
当然,经济大环境如此,行业过冬,找工作难肯定不只是 Android 独有的,其他技术同行们肯定日子也难过,冬天嘛,要的就是一个抱团取暖喽。今天写下这篇文章,争取给同行们带去那么一点点温暖吧。PS:本文仅针对 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 开发者以及手机厂商共同努力,共同打造安全与体验俱佳的 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 系统上层进程间通信的不二选择。
最后相关架构及资料领取方式:
点击我的GitHub免费领取获取往期 Android 高级架构资料、源码、笔记、视频。高级 UI、性能优化、架构师课程、NDK、混合式开发(ReactNative+Weex)微信小程序、Flutter 全方面的 Android 进阶实践技术,群内还有技术大牛一起讨论交流解决问题。
评论