一切等到Google I/O 2014就会明了，第二天会有一个Sesson专门介绍ART，可惜Google不打算录像。无论如何keynote应该会提到它。
https://www.google.com/events/io/schedule/session/b750c8da-aebe-e311-b297-00155d5066d7

  • 到4.4(Kitkat)为止，Dalvik依然必须是默认的执行环境
  • AOSP的主分支已经删掉了Dalvik

我的猜测是，下星期的Google I/O 2014只会纸面发布Android 5.0，正式的发布可能会到秋天(否则4.4.3/4.4.4的更新显得不合时宜)。而Android 5.0将会和目前的AOSP master一样仅包含ART。

还有一种可能性，Google或许会像苹果那样面向第三方开发者公开Nexus/GPE/Android Silver设备的预览版Android 5.0。注意现在已经有快速更新的预览版Nexus设备私有驱动:https://developers.google.com/android/nexus/blobs-preview

Introducing ART

1，ART的性能比Dalvik好
2，ART对dex的检验比Dalvik严格，某些经过后处理(如混淆)的dex文件即便能在Dalvik环境正常运行，但也可能无法通过ART的检查。用于代码混淆/加密的软件可能需要针对ART做出变动。
3，改进了垃圾回收
4，更好的debug工具(如不影响程序执行速度的性能分析，更细致的内容监控，报错/违例有更多提示)

对于非预装软件，ART的编译是在手机端现场进行，这远比dalvik环境下制作optimized dex慢。带有大量java代码的应用(比如淘宝，比如微信，比如QQ)会受到很大影响，它们安装时间可达数十秒乃至超出一分钟。

连同更严格的SELinux策略(Chainfire提到su的实现需要更复杂)，折腾Android会变得更困难：

可能无法像目前一样导出Gapps以及别的预装代码，因为.odex化的预装软件不包含可供还原成dex格式的代码。

Xposed的作者有提到，换用原生代码后，一方面Xposed需要重新实现插入自定义函数的做法(Xposed是rovo86的业余作品)，在ART里执行自定义的am/pm命令容易招致重启，而重启之后设备又会重新编译所有应用程序/框架(耗时10~30分钟，主要受安装的应用数量以及CPU性能影响)。

其它，考虑到AppOps依然在获得新补丁，它最后可能会以设备管理器形式的应用出现。Android确实太需要这样的角色出场了。

附：
java–>java bytecode(jar)–>dalvik bytecode(dex)的基本顺序没有改变
对于Dalvik

java–>java bytecode(.jar)–>dalvik bytecode(.dex)–>optimized dalvik bytecode(.odex)
这里的.odex如同其名，本质依然是dalvik字节码

对于Android RunTime

java–>java bytecode(.jar)–>dalvik bytecode(.dex)–>optimized android runtime machine code(.odex)

ART的编译器(LLVM)会把dalvik字节码编译成oat格式的机器码，并封装为elf文件。
使用.odex扩展名应是为了保持libart与libdvm互相替换时的一致性，对应两者的可执行代码使用同一个文件名。

有人用quicksort算法做了测试，通过JNI执行的原生代码最快，ART慢一半，dalvik只有JNI三分之一的速度。
Tech Things

— 完 —

本文作者：知乎用户（登录查看详情）

【知乎日报】
你都看到这啦，快来点我嘛 Σ(▼□▼メ)

此问题还有 7 个回答，查看全部。
延伸阅读：
如何评价腾讯的 Android ROM「tita 」？和其他 ROM 相比，tita 有什么优势？
如何分析 iOS、Android 和 Windows Phone 的 UI 设计？

分享到