一、前言
疑难：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