# 一、前言

疑问：dex文件是什么？dex文件优化又是什么？

dex文件优化会给项目带来什么问题，怎么解决这些问题？

## 1.1 APK的编译和打包流程

1、通过aapt打包资源文件res，对应生成R.java、resources.arsc和res文件（二进制&非二进制保持原来的代码）

2、处理aidl文件，生成java接口文件（没有aidl 则忽略）

3、通过java compile编译R.java、 java接口文件，生成对应.class文件（java compiler）

4、运用dex命令，将.class文件和第三方sdk库中的.class文件转换成classes.dex文件

5、通过apkbuilder将aapt生成的CompiledResources和其他资源文件以及classes.dex文件打包生成apk

6、同样的，可以使用Jarsigner工具，对上面的apk进行debug或者release签名

apk的编译和打包流程图如下：

![图片](https://img-blog.csdnimg.cn/img_convert/c2fe4f1b5a060d5ec52f0ef8c2cdcd94.png)

实际项目开发中，5、6两个步骤，可以借助jenkins平台直接生成release包即可满足需求。

## 1.2 dex文件的应用场景

再来看看dex文件常用的场景，比较流行的有：APK 的瘦身、热修复、插件化、应用加固、Android 逆向工程、64 K 方法数限制。

拿方法数限制举例，在上面的第4步，将class文件转换成dex文件，默认只会生成一个dex文件，单个dex文件中的方法数不能超过65536，不然编译会报错，但是我们在开发App时肯定会集成一堆库，方法数一般都是超过65536的，解决这个问题的办法就是：一个dex装不下，用多个dex来装，gradle增加一行配置：multiDexEnabled true。

dex文件的应用场景网上介绍的很多，本文不做介绍。而是对项目中实际遇到的问题进行剖析，从而对dex优化有进一步的理解。

# 二、dex到vdex、odex

## 2.1 ART预优化

ART（Android runtime）是什么，它是虚拟机，运营java代码、APP用的。参考Android发展史，Android 5.0把ART作为默认的虚拟机，而不是Android4.4及之前使用的DVM（Dalvik VM）了。

回顾一下DVM和ART和Android的关系，我们先来了解运行Java的几种虚拟机的工作机制：（1）JVM：JVM虚拟机运行的是java字节码。Java文件到JVM的过程是：**java -> java bytecode(class) -> java bytecode(jar)**

> **DVM**：DVM虚拟机解析执行的dex字节码。Java文件到DVM的过程是：java -> java bytecode(class) -> dalvik bytecode(dex)

> **ART**：ART虚拟机执行本地机器码。Java文件到ART的过程是：java -> java bytecode(class) -> dalvik bytecode(dex) -> optimized android runtime machine code(oat)

可以看到，DVM到ART的演变，实际上是java文件到虚拟机的执行代码的过渡，相对而言，ART多了oat的过程，ART使用AOT（Ahead-Of-Time）编译，在应用第一次安装的时候，字节码预编译成机器码存在本地，DVM是使用JIT（Just-In-Time）编译，在应用每次运行的时候，字节码都需要通过编译器即时转换为机器码才能继续执行。ART相对于DVM，省去了每次解析字节码的过程，所以运行时占用的内存会减少，提升应用的运行效率。

## 2.2 ART的运行方式

ART在Android5.0时代，号称使用AOT即可让系统运行在512M的机器上。从 Android 7.0（简称 N）开始，ART结合 AOT、即时 (JIT) 编译和配置文件引导型编译。

这几种模式可以组合配置，以谷歌的Pixel 设备举例，配置了以下编译流程：

> 1）最初安装应用时不进行任何 AOT 编译。应用前几次运行时，系统会对其进行解译，并对经常执行的方法进行 JIT 编译。

> 2）当设备闲置和充电时，编译守护进程会运行，以便根据在应用前几次运行期间生成的配置文件对常用代码进行 AOT 编译。

下一次重新启动应用时将会使用配置文件引导型代码，并避免在运行时对已经编译过的方法进行 JIT 编译。在应用后续运行期间进行了 JIT 编译的方法将会被添加到配置文件中，然后编译守护进程将会对这些方法进行 AOT 编译。

ART 包括一个编译器（dex2oat 工具）和一个为启动 Zygote 而加载的运行时 (libart.so)。dex2oat 工具接受一个 APK 文件，并生成一个或多个编译文件，然后运行时将会加载这些文件。文件的个数、扩展名和名称会因版本而异，但在 Android O 版本中，将会生成以下文件：

> vdex：其中包含 APK 的未压缩 DEX 代码，另外还有一些旨在加快验证速度的元数据。

> odex：其中包含 APK 中经过 AOT 编译的方法代码。

> art (optional)：其中包含 APK 中列出的某些字符串和类的 ART 内部表示，用于加快应用启动速度。

## 2.3 vdex、odex的作用

解压一个APK（以厂商的系统应用包举例）的包，可以看到下面的结构，不含有任何dex文件

![图片](https://img-blog.csdnimg.cn/img_convert/f9d737b6fdab98ea181af5188340d6e5.png)

再看下这个应用在手机中的目录结构，vdex、odex文件包含apk的所有代码，正常也会包含classes.dex文件。由于vdex、odex是机器码，没办法直接转成可以查看的二级制码查看（也可能是我使用的工具不对）。

## 2.4 vdex、odex与classes.dex关系

可能是系统编译的bug，也可能是生成了ART文件之后，对odex、vdex文件做了二次处理，现象是这样的，尝试获取odex中的dex文件，提示不含有dex文件。

![图片](https://img-blog.csdnimg.cn/img_convert/8f299566f829229ba5bd5b4bf309b5d9.png)

为了再次确认odex里面是否真的含有dex文件，使用010Editor再次确认，可以看到recent Files下面仍然是没有dex文件的。

![图片](https://img-blog.csdnimg.cn/img_convert/38bf70b33187cccab459a0aa7e4f49ff.png)

尝试获取vdex中的dex文件，也是无法获取的。

![图片](https://img-blog.csdnimg.cn/img_convert/4e770a7665009901813d641052bd3e41.png)

所以说，odex(或者vdex)中含有classes.dex的说法是不正确的。

# 三、Arouter是什么

阿里的一个路由组件，功能很多，我这边的实际使用场景是进行页面跳转。具体功能可以参考阿里峰会上对[arouter的介绍](https://blog.csdn.net/cpcpcp123/article/details/107891817)。

借鉴峰会中提到的一点作为铺垫，也是我们下面将要讲述的一点。“最后想分享的就是ARouter的未来开发计划。未来ARouter会支持插件化并且支持生成映射关系文档，因为插件化是现在很多大型APP中会使用的技术方案，很多的Dex和功能是动态地下发到APP中的，而在这种情况下，是无法找到所有的Dex文件的，也就是对于没有加载过的Dex而言，里面的映射关系是跳转不过去的，所以一旦Dex文件位置发生变动，常规的方案是无法找到Dex的，也不能实现映射文件初始化，这一部分会在后面的版本中进行支持”。

阿里可以识别的arouter路径如下：

![图片](https://img-blog.csdnimg.cn/img_convert/11acd826fe864b4bf18e576470c36b6b.png)

换句话说，arouter可能因为dex文件的位置变化或者路径变化，而无法找到。

# 四、踩坑

## 4.1 现象

2.4中提到了odex文件中不含有dex，而arouter查找路径遵循分组按需加载的规则，归结到底，实际上就是对class文件的查找，如下图：

![图片](https://img-blog.csdnimg.cn/img_convert/603503ca3a0f19a314f36a0a208ddd5c.png)

而class文件的信息记录在dex文件中，所以出现了异常，使用arouter进行页面跳转的时候，出现classNotFound exception。

## 4.2 解决方案

想要找到解决方案，就要知道怎么样让odex对arouter路径不产生影响，这方面，可能在没有相关经验的时候，很难找到解决方案，只能一点点查找。通过搜索ART的工作原理，找到文章[《配置ART》](https://source.android.google.cn/devices/tech/dalvik/configure?hl=zh-cn)，其中文章提到：

![图片](https://img-blog.csdnimg.cn/img_convert/bf0c3d6fb24519094c4b75fbcfd2a332.png)

也就是说通过配置LOCAL\_DEX\_PREOPT的属性，可以防止odex优化，于是找到[Android.mk](https://wallpapers.com/android)中设置该属性的地方进行设置LOCAL\_DEX\_PREOPT := nostripping。

![图片](https://img-blog.csdnimg.cn/img_convert/75c912d798336f4978498a4af144e4e3.png)

既在编译的时候做dex优化（生成odex文件），又不从apk里剥离dex。于是有了下面的apk生成之后的路径对比，再看下dex不被剥离的路径，下面含有了classes.dex文件。

![图片](https://img-blog.csdnimg.cn/img_convert/9e8fecd82166453e8ffdb8e622f9b03c.png)

使用jadx打开这个classes.dex文件，发现arouter的路径文件就在这里，所以arouter的跳转正常了，异常不再出现。

![图片](https://img-blog.csdnimg.cn/img_convert/3f08d86b1a798fddbed6989347dcd875.png)

# 五、总结

odex优化这种系统做的事情，往往会出现一些意想不到的结果，如果你负责厂商的应用，经常需要内置项目，这时候要注意了，当你的应用中含有第三方框架的时候，要注意路径、资源的引用都是没问题的，虽然正常情况下，odex文件不会对你的路径产生干扰，但是也难免odex出现失误，因为对于odex来说，里面的资源无需保存，生成art文件能够运行即可。合理使用art的配置，可以帮助解决很多问题。

> 作者：vivo互联网客户端团队-Xu jie

ITPub博客

dex优化对Arouter查找路径的影响

最新文章