首页 » Software Engineering » 正文

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

  刚刚结束的 Google I/O 大会上,Android下一代操作系统” L”带来不少惊喜。新系统运行更快、更省电。
  然而开发者对这个新系统也有颇多疑问,比如新的运行模式ART对开发者意味着什么?ART模式能否让应用的体验超越苹果?我认为在ART运行方式下”L”的性能提升在15%到80%之间。同时,ART优化了垃圾回收方式,执行效率比现行的Dalvik提高50%以上,减少了执行垃圾回收时对应用带来的卡顿,使应用运行更流畅。
  而在安全性方面,ART和Dalvik相比,安全模型和基本机制没有变化。但ART有一些细节改进,对安全有帮助。比如,安装时对dex文件做了更严格的验证。
  以下我汇集整理了开发者提问最多的6个问题,一并解答,希望可以帮助开发者更好滴认识这个全新的系统。

  问题1. 为什么ART能提高性能?
  答:主要来自两方面。
  1)预先(Ahead-of-time)编译。Android应用开发时,生成的Dex文件包含Java的Byte Code。在AndroidL以前,默认用Dalvik虚拟机。应用运行时,Dalvik对Java Byte Code进行解释执行,或进行Junt-In-Time的编译。在Android L里,应用安装时,用系统工具dex2oat将安装包中的Dex文件编译为ELF格式的执行文件(.oat文件)。应用运行时直接执行二进制指令。
  2)优化垃圾回收(garbagecollection)。垃圾回收主要有两种:(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系统碎片化的现状,当前大部分手机无法升级,只能购买新款手机。