序

为了加速应用冷启动过程且不过度涉及业务改动，本文从虚拟机加载类的过程中找到优化项，且与业界的方案作了对比，并实现了半自动化的分析功能。类在使用或实例化之前需要被加载到虚拟机中并进行初始化。整个过程如下图所示：主要由LoadingClass和InitializingClass两部分组合。

LoadingClass旨在把Class从Dex加载到虚拟机中，但不涉及类的使用或执行流程。InitializingClass旨在保证使用类前已经经过了初始化流程，此流程嵌入类的使用或执行过程中。

加载类

DefineClass主要通过SetupClass、InsertClass以及LoadClass将一个类加载到虚拟机中，最后返回mirror:Class对象指针。

SetupClass：设置类的访问标志以及ClassLoader。 InsertClass：将类插入到对应ClassLoader的ClassTable中，以便查找。 LoadClass：将类的属性及方法加载到类中。 类初始化

类的属性或方法在使用前必须经过类的初始化。

InitializeClass：核验类、初始化父类、接口方法以及静态属性。 VerifyClass：核验类的合法性，在下一节详细分析。 核验类

VerifyClass使用VerifyClassUsingOatFile或PerformClassVerification方法之一去核查Class。其中PerformClassVerification就包含了Systrace中耗时VerifyClass的Tag，如下图所示：

VerifyClassUsingOatFile：通过Oat文件中的Class状态位去核验Class，当状态位等于kStatusVerified时，核查流程到此为止，直接快速返回。否则需要进入耗时的PerformClassVerification流程。 PerformClassVerification：主要核验类中的直接方法和虚方法。 ComputeWidthsAndCountOps：判断PC值与dalvik指令数是否相等。 ScanTryCatchBlocks：检查Try语句开始地址、结束地址以及try开始操作符的合法性。检查catch中handler语句开始操作符的合法性。 VerifyInstructions：检查各种dalvik指令，同时将GC检查点插入到括号、switch、throw指令中。 VerifyCodeFlow：检查每条dalvik指令的寄存器以及参数的合法性。 提前发现

从上面的分析可以看出，应该尽可能让核查走VerifyClassUsingOatFile流程，即通过Oat文件状态位核查成功。Oat文件中类的状态位是什么以及为什么状态位不等于kStatusVerified是问题的突破点。

通过oatdump命令去dump相应的odex文件，可以查看类的状态位，操作方式如下：

VLOG默认是不会被打印的，需要动态开启，开启的方式可以通过：art::gLogVerbosity.class_linker = true而打开，因为本项目需要看到dex2oat和其他进程的打印情况，本人是在系统源码中进行编译生成的so，然后，通过ptrace注入so到Zygote的，此方法需要root设备，如果只需要查看本进程， yahoo邮箱应不需要这么麻烦，具体方法还未探索，但思路应该是一致的。举例如下，本人碰到的问题是AppCompat包中的类不能被核验通过。

解决方案

将Runtime对象中的verify_设置成verifier::VerifyMode::kNone。

需要通过Runtime对象首地址遍历查找verify_属性，魔改厂商可能带来兼容性问题。 缺少VerifyClass过程，可能会后置发现非法指令问题。 对zygote中值verify_进行修改将造成cow内存消耗。 将多出EnsureSkipAccessChecksMethods一步处理逻辑，将类中每个函数flag进行修改，此处逻辑没有对单个类进行处理，所以，每个类的每个函数的flag都将被无谓修改，如下图所示：

直面问题本身，通过VLOG的输出信息，去修正源码，具体到本案例，是由于AppCompat库中使用了系统不支持的语句，如下图所示：

本App运行环境是在8.1(API27)上，TextView没有方法setFirstBaselineToTopHeight，所以，因为指令非法导致类核验失败。(注意Build.VERSION.SDK_INT是不会被编译优化的，它本身是final类型，但它的取值是等于SystemProperties.getInt("ro.build.version.sdk"， 0)，所以，必须运行时，才能确定)。本人尝试了如下方法： 将系统源码sdk中的Build.VERSION.SDK_INT值设置成27进行编译出新的sdk，然后，将此sdk覆盖源生的android.jar，希望编译时将appcompat中的Build.VERSION.SDK_INT >= 28判断逻辑优化掉，但实际aar不会参与sdk的编译，此项只能优化项目自身的逻辑。 将appcompat源码下载下来，去掉非法指令，重新编译成aar使用。 直接在android8.1源码中编译support v7包使用。 以上两种方法，能定制自己所需的aar，甚至能裁剪资源，但碰到了致命的问题：新生成的aar不能发布到maven了，这样的话，需要推动业务修改包名，另一个问题是，如果是项目中的第三方aar依赖了appcompat的话，问题又会出现。所以，最终通过制作ASM插件，将Build.VERSION.SDK_INT值设置成固定27，问题解决了，且使得本项目中apk size减少了22K。 如果是应用需要兼容多个不同版本的ROM，也可以按照ROM版本的不同，使用App Bundle下发“最合适”的App。 平台化

为了降低方案实施难度，现已将方案平台化，只要将apk拖入网页中即可看到类核验不通过的原因。

作者：大力智能技术

链接：https://juejin.cn/post/6951225539990388750

来源：掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。