9102年了，还不知道Android为什么卡？
|
字节码可以通过不同的编译模版被编译为机器码，而编译模版的不同将直接导致编译完后的机器码性能大相径庭。
在安卓中，ART有一套规定的，统一的编译模版，暂且称为VM模版，这套模版虽算不上差劲，但也算不上优秀。 因为它是谷歌爸爸搞出来的，肯定算不上差劲，但由于没有针对每一个APP进行特定的优化，所以也算不上优秀。 ②. vm模版存在的问题 问题就存在于没有针对每一个APP进行优化。 在上文谷歌对于Android2.2的虚拟机优化中已经讲到过，那时候谷歌使用JIT将用户常用的功能记下来(热点代码)，当用户打开APP的时候立马将这些内容编译出来，即优先编译热点代码。 但是到了Android7.0的混合编译时代，由于AOT的存在，这个功能被弱化了，这时JIT记录下的热点代码并非是持久化的。AOT的编译优先级遵循于vm模版，AOT根据模板的内容将一些字节码优先编译为机器码。 那么这个时候就产生了一个问题。 先举个例子，一家中餐馆的招牌菜是番茄炒蛋，那么番茄炒蛋的备菜肯定很足，但是顾客A特立独行，他偏偏不要吃番茄炒蛋，他每次都点一个冷门的牛排套餐，那这时候只能让顾客等着老板将牛排套餐做完。 如果一个APP的热点代码(如首页)，刚好游离于VM模板之外，那么AOT就其实形同虚设了。(比如vm模版优先编译名称不大于15个字符的类和方法，但是首页的类名刚好高于15个字符。此处仅为举例并没有实际论证过) 下面用首页和设置页来举例：由于遵循vm模版，AOT因为某个原因没有优先编译首页部分代码，而转而去编译了不太重要的设置页代码：
上图的流程说明了在特殊情况下，AOT编译实则不起作用，完全是靠解释器和JIT在进行实时编译，整个编译方案退步到了Android2.2时期。 ③. 聪明的ART 虽然这个问题存在，但并不是特别严重。因为ART并没有我说的那么笨。在之后应用使用过程中，ART会记录并学习用户的使用习惯(保存热点代码)，然后更新针对当前APP的定制化vm模版，不断的补充热点代码，补充定制化模版。 这是不是听起来很熟悉?在手机发布大会上的宣传语“基于用户操作习惯进行学习，APP打开速度不断提高”的部分原理就是这个。 ④. 最终大招，一劳永逸 其实要一劳永逸的解决这个问题思路也不难：我们只需要在吃饭前跟老板提前预定想吃啥就行，让老板先准备起来，这样等我们到了就不用等餐了。 在最新的Android9.0版本中，谷歌推出了这个类似提前预定的功能：编译系统支持在具有蓝图编译规则的原生 Android 模块上使用 Clang 的配置文件引导优化 (PGO)。 说人话：谷歌允许你在开发阶段添加一个配置文件，这个配置文件内可指定“热点代码”，当应用安装完后，ART在后台悄悄编译APP时，会优先编译配置文件中指定的“热点代码”。 虽然谷歌支持，但是这块技术对于APP开发人员而言国内资料过于缺乏，普及面不广。笔者先贴上官方链接，以及这篇博客，其中介绍的还是挺详细的。(隔壁Xcode针对PGO都有UI界面了) 三、解决思路 解决思路总结为四个字就是：华为方舟。 方舟的解决思路：
总结一下：方舟支持在打包编译阶段针对不同APP进行不同的编译优化，然后直接打包成机器码.apk(很可能已经不叫apk了)，然后直接运行。 这样看起来方舟确实解决掉了三大问题，但是，代价呢? 如果按照这个思路，方舟就肯定不止是一个编译器了，它应该还有一套自己的runtime。当然这些都是后话了。 关于方舟的实现只是大概讲了思路，但没有深入，因为一来方舟没开源，二来方舟发布会PPT营销层面更多，技术细节缺少，现在奇思妙想完全是纸上谈兵，一切还是静待开源吧。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
