刚刚结束的 Google I/O 大会上，Android 下一代操作系统「L」带来不少惊喜。新系统运行更快、更省电。
然而开发者对这个新系统也有颇多疑问，比如新的运行模式 ART 对开发者意味着什么？ART 模式能否让应用的体验超越苹果？我认为在 ART 运行方式下「L」的性能提升在 15% 到 80% 之间。同时，ART 优化了垃圾回收方式，执行效率比现行的 Dalvik 提高 50% 以上，减少了执行垃圾回收时对应用带来的卡顿，使应用运行更流畅。
而在安全性方面，ART 和 Dalvik 相比，安全模型和基本机制没有变化。但 ART 有一些细节改进，对安全有帮助。比如，安装时对 dex 文件做了更严格的验证。
以下我汇集整理了 360 论坛上开发者提问最多的 6 个问题，一并解答，希望可以帮助开发者更好地认识这个全新的系统。
问题 1. 为什么 ART 能提高性能？
答：主要来自两方面。
预先（Ahead-of-time）编译。Android 应用开发时，生成的 Dex 文件包含 Java 的 Byte Code。在 Android L 以前，默认用 Dalvik 虚拟机。应用运行时，Dalvik 对 Java Byte Code 进行解释执行，或进行 Junt-In-Time 的编译。在 Android L 里，应用安装时，用系统工具 dex2oat 将安装包中的 Dex 文件编译为 ELF 格式的执行文件（.oat 文件）。应用运行时直接执行二进制指令。
优化垃圾回收（garbage collection）。垃圾回收主要有两种：（1）gcconcurrent。执行时，Dalvik 会在本次 gc 的开始和结束时会短时间暂停代码的执行。（2）gcforalloc。执行时，会较长时间中断 Java 代码的运行。在 ART 里，执行 gcconcurrent 时，只会暂停代码一次。执行 gcforalloc 时，中断 Java 代码运行的时间大大缩小了。总体上讲，ART 里垃圾回收占用的开销比 Dalvik 少 50% 以上。减少了垃圾回收时对应用带来的卡顿，使应用运行更流畅。
问题 2. 对应用开发者来说，需要做什么适配工作以支持 ART。比如重新编译、打包？
答：对绝大多数开发者来说，不需要。不论虚拟机是 Dalvik 还是 ART，安装包里所包含的仍然是 Dex 文件。由 Dex 文件编译为二进制文件的工作是在应用安装时，由装在设备上的系统工具 dex2oat 完成的。
问题 3. Android 的应用在 ART 里运行后，开发者还能在 Java 层面进行调试吗？
答：可以。事实上，应用安装后，编译生成的.oat 文件中，包含了原始的 Dex 文件。保留 Dex 文件有两个原因：
需要 Dex 里的关于类的信息，以支持 Java 反射等操作。
调试时，要用 Dex 里的调试信息。
正由于这个原因，编译生成的.oat 文件，大小是原始的 Dex 文件的两倍以上。
问题 4. 用 ART 后，性能最终能提高多少？
答：取决于具体的应用。在 Google I/O 上，Google 给的例子是提升两倍以上。
ART 我们实际测试下来，性能提升在 15% 到 80% 之间。对于大量使用 CPU 的应用，性能提升比较明显。但如果应用程序的时间主要花在调用系统 API，提升会小一些。因为很多系统 API 的代码主要在底层的.so 里面。
问题 5. ART 在安全性上有没有提升？
答：ART 和 Dalvik 相比，安全模型和基本机制没有变化。但 ART 有一些细节改进，对安全有帮助。比如：
安装时对 dex 文件做了更严格的验证。
纠正了 Dalvik 长期存在的一个对象模型的问题：一个类里的方法，如果没有加访问限制（即没有用 Public，Private，Protected 描述），Java 规定是 package-private 方法，不在同一 package 的子类不能访问和重载。而 Dalvik 一直允许子类重载 package-private 的方法。ART 里做了修改，行为与 Java 标准一致。
问题 6. Android L 使用 ART 后，有什么要引起注意的地方？
答：主要有这么几个：
因为安装时进行了预先编译。应用安装的时间变长，安装后生成的文件变大。
如果以 DexClassLoader 的形式加载代码，第一次执行时间也会变长。
对应用最好进行兼容性测试。大多数应用无需修改，但如果应用程序本身对 Dex 文件做了处理，比如进行了加壳，可能有兼容性问题。
总体来说，Android L 十分值得我们期待，今年秋天 Google 将推出正式版本，不过鉴于目前 Android 系统碎片化的现状，当前大部分手机无法升级，只能购买新款手机。
极客观察均为极客公园原创报道，转载请注明原文链接。