疑问：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、odex2.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的配置，可以帮助解决很多问题。
以上就是详解dex优化对Arouter查找路径的影响的详细内容，更多关于dex优化 Arouter的资料请关注乐呵呵网其它相关文章！
