都说AndroID最近行情不好,很多人都遇到瓶颈或放弃或转行。其实这种情况17年18年也是如此,相对比之下,个人认为今年比去年好多了,AndroID接下来将会走向复苏的春天。
自从Google开始推出AMP项目已经有一年了。除此之外,最近,Google宣布将有一个单独的移动web搜索索引。这革命性一步完全改变了移动app开发趋势,特别是从SEO和web app的角度。加速移动页面AMP改变web app 不正是说明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是否满足访问权限,目前权限控制很多时候是通过d出权限询问对话框,让用户选择是否运行。AndroID 6.0,也称为AndroID M,在6.0之前的系统是在App第一次安装时,会将整个App所涉及的所有权限一次询问,只要留意看会发现很多App根本用不上通信录和短信,但在这一次性权限权限时会包含进去,让用户拒绝不得,因为拒绝后App无法正常使用,而一旦授权后,应用便可以胡作非为。
针对这个问题,Google在AndroID M做了调整,不再是安装时一并询问所有权限,而是在App运行过程中,需要哪个权限再d框询问用户是否给相应的权限,对权限做了更细地控制,让用户有了更多的可控性,但**同时也带来了另一个用户诟病的地方,那也就是权限询问的d框的次数大幅度增多。**对于AndroID M平台上,有些App开发者可能会写出让手机异常频繁d框的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高级工程师的系统且全面的学习资料。涵盖了AndroID初级——AndroID高级架构师进阶必备的一些学习技能。
附上:我们之前因为秋招收集的二十套一二线互联网公司AndroID面试真题(含BAT、小米、华为、美团、滴滴)和我自己整理AndroID复习笔记(包含AndroID基础知识点、AndroID扩展知识点、AndroID源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。)
如果需要可以戳这里自行领取
如果需要可以戳这里自行领取
总结以上是内存溢出为你收集整理的看完老板就给加薪了!带你快速通过字节跳动面试,移动架构师成长路线全部内容,希望文章能够帮你解决看完老板就给加薪了!带你快速通过字节跳动面试,移动架构师成长路线所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)