应用性能优化之VerifyClass

发布日期:2022-08-07 21:46    点击次数:187

 

为了加速应用冷启动过程且不过度涉及业务改动,本文从虚拟机加载类的过程中找到优化项,且与业界的方案作了对比,并实现了半自动化的分析功能。类在使用或实例化之前需要被加载到虚拟机中并进行初始化。整个过程如下图所示:主要由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

来源:掘金

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



栏目分类



Powered by 南京苯邦自动化设备有限公司 @2013-2022 RSS地图 HTML地图