Android下一代操作系统“L”更快更安全

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

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

Android L 运行界面

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

以下汇集整理了360论坛上开发者提问最多的6个问题，360***技术专家任寰做了解答，希望可以帮助开发者更好地认识这个全新的系统。

问题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文件有两个原因：一，需要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系统碎片化的现状，当前大部分手机无法升级，只能购买新款手机。