一、前言
疑问：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的编译和打包流程图如下：
实际项目开发中，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文件
再看下这个应用在手机中的目录结构，vdex、odex文件包含apk的所有代码，正常也会包含classes.dex文件。由于vdex、odex是机器码，没办法直接转成可以查看的二级制码查看（也可能是我使用的工具不对）。
2.4 vdex、odex与classes.dex关系
可能是系统编译的bug，也可能是生成了ART文件之后，对odex、vdex文件做了二次处理，现象是这样的，尝试获取odex中的dex文件，提示不含有dex文件。
为了再次确认odex里面是否真的含有dex文件，使用010Editor再次确认，可以看到recent Files下面仍然是没有dex文件的。
尝试获取vdex中的dex文件，也是无法获取的。
所以说，odex(或者vdex)中含有classes.dex的说法是不正确的。
三、Arouter是什么
阿里的一个路由组件，功能很多，我这边的实际使用场景是进行页面跳转。具体功能可以参考阿里峰会上对arouter的介绍。
借鉴峰会中提到的一点作为铺垫，也是我们下面将要讲述的一点。“最后想分享的就是ARouter的未来开发计划。未来ARouter会支持插件化并且支持生成映射关系文档，因为插件化是现在很多大型APP中会使用的技术方案，很多的Dex和功能是动态地下发到APP中的，而在这种情况下，是无法找到所有的Dex文件的，也就是对于没有加载过的Dex而言，里面的映射关系是跳转不过去的，所以一旦Dex文件位置发生变动，常规的方案是无法找到Dex的，也不能实现映射文件初始化，这一部分会在后面的版本中进行支持”。
阿里可以识别的arouter路径如下：
换句话说，arouter可能因为dex文件的位置变化或者路径变化，而无法找到。
四、踩坑
4.1 现象
2.4中提到了odex文件中不含有dex，而arouter查找路径遵循分组按需加载的规则，归结到底，实际上就是对class文件的查找，如下图：
而class文件的信息记录在dex文件中，所以出现了异常，使用arouter进行页面跳转的时候，出现classNotFound exception。
4.2 解决方案
想要找到解决方案，就要知道怎么样让odex对arouter路径不产生影响，这方面，可能在没有相关经验的时候，很难找到解决方案，只能一点点查找。通过搜索ART的工作原理，找到文章《配置ART》，其中文章提到：
也就是说通过配置LOCAL_DEX_PREOPT的属性，可以防止odex优化，于是找到Android.mk中设置该属性的地方进行设置LOCAL_DEX_PREOPT := nostripping。
既在编译的时候做dex优化（生成odex文件），又不从apk里剥离dex。于是有了下面的apk生成之后的路径对比，再看下dex不被剥离的路径，下面含有了classes.dex文件。
使用jadx打开这个classes.dex文件，发现arouter的路径文件就在这里，所以arouter的跳转正常了，异常不再出现。
五、总结
odex优化这种系统做的事情，往往会出现一些意想不到的结果，如果你负责厂商的应用，经常需要内置项目，这时候要注意了，当你的应用中含有第三方框架的时候，要注意路径、资源的引用都是没问题的，虽然正常情况下，odex文件不会对你的路径产生干扰，但是也难免odex出现失误，因为对于odex来说，里面的资源无需保存，生成art文件能够运行即可。合理使用art的配置，可以帮助解决很多问题。
作者：vivo互联网客户端团队-Xu jie
