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

vivo互联网技术
English

一、前言

疑问: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
阅读 1.3k

vivo 互联网技术
分享 vivo 互联网技术干货与沙龙活动,推荐最新行业动态与热门会议。
2.2k 声望
9.2k 粉丝
0 条评论
你知道吗?

2.2k 声望
9.2k 粉丝
宣传栏