迎接 ART，第二部分（翻译自AndroidPolice）

EraserKing

原创简易自翻，有错请轻喷，顺便这不是某果粉站的二道贩子翻译。转载请注明出处。
原文地址：http://www.androidpolice.com/201 ... s-debuts-in-kitkat/

（前言略，大致就是什么过去很乱未来很美好之类）

ART，代表 Android Runtime，从根本上以与 Dalvik 不同的方法来处理应用的执行。当前的支持时依靠一个 Just-In-Time（JIT）编译器来解释字节码，即原始应用程序代码的一个版本。从某种意义上来说，应用只被开发人员部分编译，然后最终代码必须每次在运行时，通过每个用户设备上的编译器来执行。进程牵扯到一堆开支并且不是十分经济，但是这种机制使得应用能在不同的硬件和架构上运行。ART 则被设计为将应用在首次安装时通过预编译来把它们变为真正的原生应用，即将字节码转变为机器语言。这个过程叫做 Ahead-Of-Time（AOT）compilation —— 预先编译。通过降低设立新虚拟机或者运行解释代码的需求，启动时间可以被极大地削减并且同时执行也会更快。



目前，Google 将 ART 视作一种实验性的预览，一个对于开发者和硬件伙伴来说需要尝试的玩意。Google 自己对于 ART 的介绍明确地警告改变运行时可能导致损坏应用并且使得系统不稳定。ART 尚未完全来到全盛期，但是 Android 团队显然已经感觉到能够看到光芒。如果你有兴趣自己试试 ART，打开 设置 -> 开发者选项 -> 选择运行环境。激活它需要重启以从 libdvm.so 切换到 libart.so，但是请准备好初次重启时10分钟的等待，期间已安装的应用将会在新的运行时环境下准备。警告：现在切勿在 Paranoid Android（或者其它 AOSP）版本上尝试。它与现在的 gapps 包不兼容，会导致频繁崩溃，导致页面不可用。

它有多好？
目前来说，效率上潜在的增效很难以现在随 KitKat 一起来的 ART 版本来测量，所以它并不代表一旦深度优化后的可能性。迄今为止，估计和一些测评暗示新的运行时可以减半大部分应用的执行时间。这意味着长时间运行的、进程集中的任务可以更快地完成，使得系统可以空闲更多，持续更久。一般的应用可以享受到更平滑的动画和对于触摸及传感器数据更即时的反应。此外，既然典型的设备包括一颗四核（或者更多）的处理器，许多情况下需要激活更少的核心，并且可能会更好的利用 ARM 的 big.LITTLE 架构下的低功率核心。电池续航和性能上的改进会依使用场景和硬件上而有所差异，但是结果是本质的。

有何妥协？
使用 AOT 编译有一些缺点，但是相对于优点来说可以忽略不计。首先，完全编译的机器码相对于字节码通常会消耗更多的存储空间。这因为字节码里的每个符号代表机器码里的一些指令。当然，这个增长并不会显得非常巨大，一般不多于 10%~20%。这在 APK 很大时显得很多，但是在大多数应用里执行代码只占其中的一部分。比如，最近的带有新式视频编译的 Google+ APK 是 28.3 MB，但是代码只有 6.9 MB。另外一个显见的缺点是它会带来更长的应用安装时间——执行 AOT 编译的副作用。多长？这和应用有关；小程序上可能注意不到，但是像 Facebook 和 Google+ 这样复杂的应用将会带来等待。如果没多少应用的话可能不是什么烦恼，但是初次切换到 ART 时，转换 100 多个应用是一个耐心的严格测试。这倒不是很坏，需要允许 AOT 编译器更努力地寻找相对于 JIT 编译器来说有寻找的优化。总的来放，我很乐见这些牺牲的发生，如果它能带来更流畅的体验和增强的电池续航。

总而言之，ART 听上去像是一个惊艳的项目，一个我希望尽早成为 Android 常规组件的项目。这个改进让人惊讶同时缺点却不太明显。还有很多能在这个帖子里报导，包括工作的细节、评测和其它的很多东西。我将在接下来的几天更深入地潜进 ART，所以请保持关注！

全家

也就是说终于还是走上完全native的道路了吗

不过这样玩的话编译耗时怎么算 没编译完成就耗尽的手机的电量关机怎么办

还有源码暴露的问题……

ch_ch

全家 发表于 2013-11-8 10:16
也就是说终于还是走上完全native的道路了吗

不过这样玩的话编译耗时怎么算 没编译完成就耗尽的手机的电量 ...

dalvik bytecode编译成native？现在dalvik bytecode也是暴露的吧?
电池耗尽下次重新编译不就行了。实在不行直接下载native的包？

EraserKing

原文地址：http://www.androidpolice.com/201 ... ay-will-get-better/

现在你可能已经听说过 ART 了，并且了解了它将如何改善 Android 的性能和速度，但是现在它究竟表现如何？新的 Android 运行时承诺会大幅降低 Dalvik 带来的负担，这听上去很棒，但是它还远未成熟，也没有得到认真的优化。我用一系列测试来试试这个新运行时是否能够真正担当得起这些高期待。ART 绝对兑现了一些承诺，但是我必须提醒你，你可能并不会为今天在这里看到的结果而感动。

真实检查
坦诚地说，跑分应用表现得既不准确也不可靠，常常在完全相同的情景下给出大幅变化的结果。然而，它们是记录有意义的，并且是可测量的性能的唯一可用选择。更甚，因为绝大多数跑分都基于 NDK (Native Development Kit)，所以它们并不会因在 ART 下运行而得益。尽管有这些限制，仍然出现了一些有趣的、未曾预料到的结果。它们可以帮助我们更进一步地了解当前的性能状态。


跑分如何运行
每个跑分都至少在一台完全原生的 Nexus 5（甚至没有 ROOT）上运行至少4次，使用 Dalvik 和 ART。为了保证不受启动时任何应用的影响，启动后，在运行任何测试前，至少等待5分钟。在以下6个跑分应用之外，我还在 Chrome 里试了两个浏览器跑分 (SunSpider & BrowserMark)，但是并没有显示出明显的成绩上的差别。这里，我们来看结果。

Linpack for Android
能否得到好的测试结果的一个重要因素是保证工具测量到了正确的事。许多跑分应用基于 NDK，一些仍然基于 SDK。第一个也是最持久的一个是 Linpack for Android，它是一个在大量计算平台上的流行跑分应用的移植。我想在阅读描述后，它是一个明显的选择——“这个测试是一个 Android Dalvik 虚拟机状态的更真实反映，而不是底层处理器的浮点性能。”感谢 ART，相比 Dalvik，成绩高了 10%-14%。不是很渣。


Real Pi Benchmark
计算 Pi 的位数是另外一种给予处理器压力的方式，并且它是更有效的方法，因为它完全是整数运算并且完全避免了浮点运算。同 Linpack 一样，它覆盖了两种基础上的数学运算。顶部，Real Pi 使用了原生代码来演算 AGM+FFT 公式，但是使用了 Java for Machin 的公式。原生侧，ART 快了 3.5%，可能是因为接口上的优化还不是数学上的表现。更重要的是，Java 代码的测试快了 12%。

注解：值以秒计。数字越低越好。

Quadrant Standard
前一测试是更像是高规格的数学测验，因此现在是更需要测试系统。Linpack 和 Real Pi 展示了一些 ART 的正面改进，但是 Quadrant 展示了惊艳的边界——它可能表现得太棒了。ART 的 CPU 分数表现得超出想像，几乎是 Dalvik 的两倍。这大大地优于我们所听到的最乐观的估计…… I/O、2D 和 3D 渲染上的差距可以忽略，Dalvik 在内存测试中有一个诡异的 9% 的优势。



3D Mark
我对使用一个明显的基于 NDK 的跑分应用持怀疑态度，因为它理论上并不会受 ART 的什么影响。但是，运行测试时，一个有趣的现象发生了，Dalvik 运行时展现出了轻微的优势。很难找到一个合理的解释，但是欢迎任何理论。


AnTuTu Benchmark
突破性的改进走得更远，AnTuTu帮助展示了这一特征。显而易见的是 ART 在浮点操作上有着巨大的迈进，但是对于整数并没有明显的增幅。“RAM 操作”强烈显示了它更好地利用了缓存，而不是原始内存 I/O。高分数区域说明 Davlik 虚拟机的操作非常昂贵，导致了更多的开销。其它结果并不是特别有意义，除了存储 I/O，也许暗示了一系列特定的优化。一个显著的低分数出现在 UX Dalvik上，但是并不清楚 AnTuTu 测量了什么，所以这并没有什么关系。


CF-Bench
为了极限地产生数字，Chainfire 自己的测试工具基于 SDK 和 NDK 运行测试，取消了大量猜测性的工作。再一次，原生代码相对了 Dalvik 展示了一个很小的但是不寻常的优势。这里我们可以看到整数运算并不如意。大多数可以确认的特征显示，浮点操作展现出了极大的速度增益，这次是 23%-33%。


其它有趣的测量
测量切换运行时环境后的首次启动并不是一个典型测试，毫无疑问，但是花费的时间却很震惊。我想记录应用优化阶段然后直到抵达解锁屏幕的总时间。运行这个测试时，我安装了149个应用。


一些其它的事情
数字很有帮助，但是它们并不是故事的全部。跑分往往在几秒内让硬件工作得更加努力，然后切换到一个同样这样的新测试。遗憾的是，这些被忽略的细节并不容易被测量到。我并没有一个测量更智能的内存管理（特别是垃圾回收）或者是掌控多线程的好方法。我无法显示这些事情的数字，但是我能演示。传统的浏览器测试仅仅简单地尽快划动页面然后看着它试着继续（滑动）下去。使用 David 的巨型 HTC One 评测的移动版来压力测试 Chrome for Android 之后，Nexus 5 的超级 SoC 并不能在运行在 Dalvik 上的时候很好地保持……ART，在另一方面，未曾丢失一个像素。
自己看一看吧。
（视频在YTB上）
左：运行在 Dalvik上，右：运行在 ART 上
公平地说，切换到桌面版后，然后简单地一划将会轻易地将你送入白屏境地，但是很明显地，ART 相比于 Dalvik，渲染追上得更快。当有更多优化，也许我们在桌面版上也离无缝滚动也不远了。对于另一个演示，一个名为 spogbiper 的用户提交了它自己的边对边比较，使用两台 Nexus 7。运行 ART 的这一台似乎响应得更好。
（视频在YTB上）
总结与结论
数字与视频共同描绘了 ART 今日的地位。绝对有差距，但是它当前的境地还没有成熟到能够释放巨大的增益。浮点运算和基础响应显然受益于新运行时，但是那就是关于它的一切。整数运算、绝大多数常规代码执行，或者剩下的大多数东西来说，没多少改善，或者总体上来说没有。实际上，像是游戏玩家更值得使用 Dalvik，就目前来说。
为什么跑分还没有震撼我们？如果要我来猜的话，可能开发 ART 时候的第一目标是在投入大量优化前，保证它能工作并且稳定。如果是这种情况，很有可能有一些代码来检测错误和记录日志，以确保每件事都正常工作，并且这可能比 Dalvik 的开销更大。即使是在 ART 并未超出 Dalvik 的地方，这些数字也维持接近。对于山寨城随后带来的运行时，我们应该期望 ART 领先的性能鸿沟变得更宽。
现在轮到了真正的问题：现在值得立即切换到 ART 吗？Google 显然不把它推荐给常规用户，并且我也倾向于同意。即便 ART 似乎非常稳定，并且我感觉响应更好 - 可能仅仅是安慰剂效应 - 仍然有不稳定并导致应用崩溃的环境。如果哪怕仅有一个实例需要你切换回 Dalvik 来正常运行应用，带来的不便就远远超过你也许有的最小的性能增益。一旦我完成了这个系列，我可能还是使用 Dalvik 来使用 KitKat 的剩下部分，并且我能想像到大多数人将会做一样的事。

EraserKing

@jun4rui 这性能不能算极大的优化吧 反而在某些地方退步了

きらきしょう

以4.4为原始系统的新机器大概多久能面市？   看上去4.4是不是无法兼容部分老硬件……

EraserKing

jun4rui 发表于 2013-11-13 17:19
最后那段Chrome的快速卷动对比看了没？

ART下的快速超长页面卷动丝毫不卡，平滑得很。传统的Dalvik则明显 ...

如果应用都能正常用的话可以尝试
我上次试了，进系统之后直接FC，后来才知道是GAPPS包需要做DEODEX，再往后我就没试了