Android L对开发者意味着什么？

本文作者/360首席技术专家 任寰

 
在结束不久的 Google I/O 大会上，Android下一代操作系统“Android  L”带来不少惊喜——新系统号称运行更快、更省电。

然而开发者对这个新系统也有颇多疑问，比如新的运行模式ART对开发者意味着什么？ART模式能否让应用的体验超越苹果？我认为在ART运行方式下“L”的性能提升在15%到80%之间。同时，ART优化了垃圾回收方式，执行效率比现行的Dalvik提高50%以上，减少了执行垃圾回收时对应用带来的卡顿，使应用运行更流畅。

而在安全性方面，ART和Dalvik相比，安全模型和基本机制没有变化。但ART有一些细节改进，对安全有帮助。比如，安装时对dex文件做了更严格的验证。

图：Android L 运行界面

以下我汇集整理了论坛上开发者提问最多的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）gc_concurrent。执行时，Dalvik会在本次gc的开始和结束时会短时间暂停代码的执行。

（2）gc_for_alloc。执行时，会较长时间中断Java代码的运行。在ART里，执行gc_concurrent时，只会暂停代码一次。执行gc_for_alloc时，中断Java代码运行的时间大大缩小了。总体上讲，ART里垃圾回收占用的开销比Dalvik少50%以上。减少了垃圾回收时对应用带来的卡顿，使应用运行更流畅。

问题2. 对应用开发者来说，需要做什么适配工作以支持ART。比如重新编译，打包？

答：对绝大多数开发者来说，不需要。不论虚拟机是Dalvik还是ART，安装包里所包含的仍然是Dex文件。由Dex文件编译为二进制文件的工作是在应用安装时，由装在设备上的系统工具dex2oat完成的。

问题3. Android的应用在ART里运行后，开发者还能在Java层面进行调试吗？

答：可以。事实上，应用安装后，编译生成的.oat文件中，包含了原始的Dex文件。保留Dex文件有两个原因：

1. 需要Dex里的关于类的信息，以支持Java反射等操作。
2. 调试时，要用Dex里的调试信息。

正由于这个原因，编译生成的.oat文件，大小是原始的Dex文件的两倍以上。

问题4. 用ART后，性能最终能提高多少？

答：取决于具体的应用。在Google I/O上，Google给的例子是提升两倍以上。

ART我们实际测试下来，性能提升在15%到80%之间。对于大量使用CPU的应用，性能提升比较明显。但如果应用程序的时间主要花在调用系统API，提升会小一些。因为很多系统API的代码主要在底层的.so里面。

问题5. ART在安全性上有没有提升？

答：ART和Dalvik相比，安全模型和基本机制没有变化。但ART有一些细节改进，对安全有帮助。比如：

1. 安装时对dex文件做了更严格的验证。
2. 纠正了Dalvik长期存在的一个对象模型的问题：一个类里的方法，如果没有加访问限制（即没有用Public，Private，Protected描述），Java规定是package-private方法，不在同一package的子类不能访问和重载。而Dalvik一直允许子类重载package-private的方法。ART里做了修改，行为与Java标准一致。

问题6. Android L使用ART后，有什么要引起注意的地方？

答：主要有这么几个：

1. 因为安装时进行了预先编译。应用安装的时间变长，安装后生成的文件变大。
2. 如果以DexClassLoader的形式加载代码，第一次执行时间也会变长。
3. 对应用最好进行兼容性测试。大多数应用无需修改，但如果应用程序本身对Dex文件做了处理，比如进行了加壳，可能有兼容性问题。

 

总体来说，Android L十分值得我们期待，今年秋天Google将推出正式版本，不过鉴于目前Android系统碎片化的现状，当前大部分手机无法升级，只能购买新款手机。

 

雷峰网原创文章，未经授权禁止转载。详情见转载须知。