一、背景
之前在搞Android产物字节码分析时发现的一个问题，这和一个老生常谈的定论：“Java访问常量不会触发类加载”有密切关系，估计大家会感兴趣，因此写下来给大家分享下。
二、结论先行
在Android上，访问一个常量（符号引用）也会触发类加载
这和Android具体的代码场景有关系，感兴趣可以接着往下看～
三、问题分析
3.1 工具利器
推荐工具 010 Editor，它内置了很多种二进制文件的结构模版，可以帮助我们快速查看一些二进制文件的内容，例如二进制xml、dex、arsc文件等。
~/.config/SweetScape/010 Editor.ini，如果010editor过了30天试用期，可以删除这个文件来清除记录，即可接着使用。
推荐工具 python struct，直接import struct就行。可以帮助我们按照字节快速解析数据，例如：
struct.unpack('<HHI', f.read(8))
含义：读取后8个字节的数据，<代表按照小端序读取，unpack的结果是一个数组，HHI代表前两个元素为short，第三个元素为int，分别对应2、2、4个字节的数据。
3.2 知识储备
3.2.1 dex的部分格式
dex最上层结构还是比较清晰的：
[图片上传失败...(image-529efb-1683790977467)]
我们需要关注其中的：
-
dex_string_ids dex字符串常量池
-
dex_type_ids dex中所有的类名描述
-
dex_field_ids dex中所有的字段描述，举个例子
[图片上传失败...(image-f9cc98-1683790977467)]
class_idx指的是它所在的类名索引（从dex_type_ids中查找），type_idx指的是类型名称（从dex_type_ids中查找），name_idx指的是字段名索引（从dex_string_ids中查找）
- dex_class_defs dex中所有类的描述，举个例子：
[图片上传失败...(image-6717c5-1683790977467)]
class_data指的是类里面的所有信息，其中中包含了数据static_fields，指的是类中所有的static字段的数据：
[图片上传失败...(image-bc1ec0-1683790977467)]
其中 field_idx_diff指的是这个字段在字段表里面的索引，access_flags指的是字段的修饰符，包括private、public、static等等
底部的static_values指的是static final常量的值，它和上面的class_data.static_fields中前面几位static final常量是一一对应（按照顺序对应）的：
[图片上传失败...(image-5b6239-1683790977467)]
因为static变量是在类的<clinit>方法中进行赋值的，所以只有常量在static_values里面有值
由上可知：在dex中，static和static final字段储存位置是一样的，仅修饰符不一样
3.2.2 访问static字段的指令
这个拿实际的例子比较好说明：
// 访问一个static 变量/常量
R.string.dialog_loading_title
它对应的字节码指令：
[图片上传失败...(image-fe40c7-1683790977467)]
0160 03f3
忽略01，关键是 60 03f3：
60 代表指令 sget，含义是获取一个static字段
03f3 代表字段的索引，十进制为1011，在对应的字段表中为：
[图片上传失败...(image-165a40-1683790977467)]
通过03f3能从字段表中读取该字段，能获取到class_idx类索引，可以拿到类的名称。也就是通过 60 03f字节码只能查询到R.string.dialog_loading_title符号引用，但无法查询到对应的值。
结合3.2.1的信息，其实已经能猜出来，访问常量同样会触发类加载。因为访问static字段的指令都是sget，访问static变量肯定会触发类加载，那访问常量也是同样的道理。
3.2.3 指令解析的部分源码
这里直接贴出sget指令解析的源码地址
经过一系列的源码追踪，能找到最终解析 sget 后面的字段的地方：
[图片上传失败...(image-3dcca1-1683790977467)]
该函数中调用了ResolveType ，参数传入了class_idx，这和3.2.1节的内容呼应。接着追踪：
[图片上传失败...(image-30c3ed-1683790977467)]
其实到这一步已有有答案了，FindClass接着就会去加载一个class 。
不过相信大家还是对哪里使用的static_values感兴趣，接着看：
在一个class初始化的时候：
[图片上传失败...(image-b0249d-1683790977467)]
这里也是和3.2.1节内容呼应，初始化一个class时会去获取它在dex中的定义 ClassDef
截图是在初始化class的static字段，而对static final的赋值请见EncodedStaticFieldValueIterator
[图片上传失败...(image-15eb1b-1683790977467)]
[图片上传失败...(image-10ad5e-1683790977466)]
这里的static_value_off_和3.2.1中的static_values对应，代表着常量的值
3.2.4 javac的内联优化
在访问一个常量时，javac总是会帮我们把常量的符号引用变成对值的直接引用，所以从这个角度说，访问一个常量确实不会触发类加载。例子：
class A {
public static final NAME = "abc";
}
// 编译前
String localName = A.NAME;
// 编译后
String localName = “abc”
但凡事都有意外，什么情况下常量不会被优化呢？拿个实际的场景举例子：
在Android的一个普通模块中定义了新的资源，例如R.string.name这种的，这个模块在编译之后会产生R.jar，例如截图：（class反编译之后的）
[图片上传失败...(image-91d617-1683790977466)]
这里的属性全是static变量，而javac对不会对static变量做内联优化。也就是说仍然存在着R.xxx.xxx的各种符号引用，比如这种的：（class的图形化展示 R.attr.submodule_a）
[图片上传失败...(image-bc3e89-1683790977466)]
这个模块的class文件会参与到App的编译，但无需再走javac。App编译时会对R.xx.xx赋值（注意上面截图中属性值都还是0）并将修饰符改为常量，例如产物：(App的最终产物dex中的R$string)
[图片上传失败...(image-900c49-1683790977466)]
所以，在最终的代码中就存在“对一个常量的符号引用”的情况
上述仅发生在debug包中，打release包时还会对常量的符号引用进行内联
3.3 本地验证
上面从理论上说通了访问一个常量是可能造成类加载的。现在来进行本地验证：
我这里就拿3.2.4中的普通模块的R场景进行测试了，测试关键代码如下：
[图片上传失败...(image-cf32e1-1683790977466)]
[图片上传失败...(image-a3ab02-1683790977466)]
日志结果：
[图片上传失败...(image-d4efcf-1683790977466)]
符合预期，访问常量（符号引用）确实造成了类加载！
注意：实验只能在自定义ClassLoader（插件化）的情况下测试，因为对于宿主源码的ClassLoader是PathClassLoader。PathClassLoader在调用findLoadedClass时就会“偷摸”着把class加载了，会导致rIsLoaded方法第一次访问时就直接返回true了。
网友评论