提示!应用程序的安装有两种情况,第一:首次启动系统时安装。第二:系统启动完毕后安装。

本篇博文基于第一种安装场景。在系统首次启动的场景中,系统会对/system/app、/system/priv-app、/data/app文件夹下的全部APK进行dex字节码到本地机器码的翻译,相同也会对/system/framework文件夹下的APK或者JAR文件,以及这些APK所引用的外部JAR。进行dex字节码到本地机器码的翻译。这样能够保证除了应用之外。系统中使用Java来开发的系统服务,也会统一地从dex字节码翻译成本地机器码。具体内容请移步老罗的博客Android
ART执行时无缝替换Dalvik虚拟机的过程分析


一、JVM、DVM、ART虚拟机了解
  • JVM虚拟机执行的是java字节码:
java->java bytecode(class)->java bytecode(jar)
注!

java虚拟机基于栈,基于栈的机器必须使用指令来加载和操作栈上的数据,所需指令相对来说比較多。


  • Dalvik虚拟机解释运行的dex字节码:
java->java bytecode(class)->dalvik bytecode(dex)
注:相对JVM,Dalvik基于寄存器,且经过优化并同意有限的内存中同一时候执行多个虚拟机实例。每一个Dalvik应用作为一个独立的Linxu进程执行。假设一个应用中有非常多类,编译后会对应生成非常多class文件。class文件之间也会有不少冗余信息,dex格式文件把全部classs文件内容整合到一个文件。这样能够降低总体文件占用,IO操作,同一时候也提高了类的查找速度。

此外。dex格式文件添加了新的操作码支持,文件结构也相对简洁,使用等长的指令来提高解析速度。

并且dex文件会尽量扩大仅仅读结构的大小,来提高进程间数据共享的速度。


  • ART虚拟机运行的本地机器码:
java->java bytecode(class)->dalvik bytecode(dex)->optimized android runtime machine code(oat)
注:ART所使用的AOT(Ahead-Of-Time)编译。在应用首次安装时,字节码预编译成机器码存储在本地,也就是说在程序执行前编译。而Dalvik是典型的JIT(Just_In_Time),此模式下,应用每次执行的时候,字节码都须要即时编译器转换为机器码再执行,也就是在程序执行时编译。因此在App执行时。ART模式相对于Dalvik省去了解释字节码的过程,占用内存也对应降低,进而提高App的执行效率。

二、Odex

    从上面一节中我们知道,在编译打包APK时,Java类会被编译成一个或者多个字节码文件(.class),通过dx工具CLASS文件转换成一个DEX(Dalvik Executable)文件。
    通常情况下,我们看到的Android应用程序实际上是一个以.apk为后缀名的压缩文件。我们能够通过压缩工具对apk进行解压,解压出来的内容中有一个名为classes.dex的文件。

那么我们首次开机的时候系统须要将其从apk中解压出来保存在data/app文件夹中。

    假设当前执行在Dalvik虚拟机下,Dalvik会对classes.dex进行一次“翻译”。“翻译”的过程也就是守护进程installd的函数dexopt来对dex字节码进行优化,实际上也就是由dex文件生成odex文件。终于odex文件被保存在手机的VM缓存文件夹data/dalvik-cache下(注意。这里所生成的odex文件依然是以dex为后缀名,格式如:system@priv-app@Settings@Settings.apk@classes.dex)。
    假设当前执行于Art模式下,    Art相同会在首次进入系统的时候调用/system/bin/dexopt工具来将dex字节码翻译成本地机器码,保存在data/dalvik-cache下。
    那么这里须要注意的是,不管是对dex字节码进行优化,还是将dex字节码翻译成本地机器码,终于得到的结果都是保存在同样名称的一个odex文件中面的,可是前者相应的是一个dey文件(表示这是一个优化过的dex),后者相应的是一个oat文件(实际上是一个自己定义的elf文件,里面包括的都是本地机器指令)。

简单来说不管是Art模式。还是DVM,优化的结果都是一个odex文件,仅仅是这两种odex文件有着本质的差别(一个是dey字节码,一个是oat机器码)。之所以这么设计。主要通过这样的方式,原来不论什么通过绝对路径引用了该odex文件的代码就都不须要改动了。能够理解为这是art与dalvik兼容的结果。

    因为在系统首次启动时会相应用进行安装。那么在预置APK比較多的情况下。将会大大添加系统首次启动的时间。从前面的描写叙述可知,既然不管是DVM还是ART,对DEX的优化结果都是保存在一个同样名称的odex文件,那么假设我们把这两个过程在ROM编译的时候预处理提取Odex文件将会大大优化系统首次启动的时间。

三、预编译提取Odex
在BoardConfig.mk中定义:WITH_DEXPREOPT := true。打开这个宏之后,不管是有源代码还是无源代码的预置apk预编译时都会提取odex文件。

    只是这里须要注意的是打开WITH_DEXPREOPT 宏之后,预编译时提取Odex会添加一定的空间。预置太多apk。会导致system.img 过大。而编译只是。遇到这样的情况能够通过删除apk中的dex文件、调大system.img的限制大小,或在预编译时跳过一些apk的odex提取。
    比如跳过helloworld应用提取的方法例如以下:

在文件夹\build\core\dex_preopt_odex_install.mk中加入红色标记的代码:

ifeq ($(LOCAL_MODULE),helloworld)

LOCAL_DEX_PREOPT:=

endif

build_odex:=

installed_odex:=

....

helloworld可替换为须要跳过提取odex的apk的LOCAL_MODULE名字,如Settings等。

最新文章

  1. .NET平台开源项目速览(13)机器学习组件Accord.NET框架功能介绍
  2. SDK接入(3)之iOS内支付(In-App Purchase)接入
  3. JS操作select下拉框动态变动(创建/删除/获取)
  4. IntelliJ IDEA使用(2)——IDEA配置Tomcat
  5. MySQL按照汉字的拼音排序,mysql汉字排序
  6. laravel增删改查
  7. Spring MVC 的汉字乱码问题
  8. Unity3D ShaderLab 布料着色器
  9. 几款超实用的 CSS 开发工具
  10. mysql-python模块编译问题解决
  11. 从jQuery的缓存到事件监听
  12. 济南学习 Day 2 T3 am
  13. Java API —— HashMap类 & LinkedHashMap类
  14. Android 开机自启动应用
  15. HTML5要点(二)
  16. C#JSON序列化与反序列化
  17. AIDL机制实现进程间的通讯实例
  18. 根据http协议下载文件保存到相应的文件下
  19. java 方法的重载
  20. 如何在同一台服务器上部署两个tomcat

热门文章

  1. Android 解决RecyclerView瀑布流效果结合Glide使用时图片变形的问题
  2. Burp Suite抓https数据包
  3. STM32的串口DMA收发以及双缓冲区的实现
  4. CAD设置系统变量(com接口VB语言)
  5. 12Oracle Database SQL程序
  6. jquery 五星评价(图片实现)
  7. java基础学习日志---File方法分析
  8. Python面向对象一些阶段性总结
  9. BZOJ 4094 USACO 2013 Dec. Optimal Milking
  10. Placing Lampposts