ART 运行时深层结构完全解析
——从 ArtMethod、ClassLinker 到 Invoke 全链路，兼谈 FART 在 Android 12–16 的失效与修复
如果你已经拿 FART 脱过壳、或者自己写过主动调用，那这篇应该能直接对上。
前面不废话， 背景尽量压短，后面把 Invoke 分流、Nterp、dump 点选择、高版本失效和现在怎么处理写细一点，代码也会多放一些。
先把认为最重要的东西放在这里 以下
ArtMethod 只是入口。真正决定主动调用能不能脱到东西的，是这四个问题同时成立：
FART 早期能打，是因为这四个问题当时相对好对齐。Android 12 之后开始大面积失效，不是单纯工具老了，而是执行路径、结构布局、存储限制、Profile/AOT、壳对抗一起变了。
ArtMethod 里真正关键的是三块：
身份：class、method index、access flag
代码位置：早期靠 dex_code_item_offset_，后面更多走 DexFile / CodeItemDataAccessor
执行入口：entry_point_from_quick_compiled_code_
调用时真正跳出去的，通常是最后一个。
所以会有这种误判：
ArtMethod 找到了，方法也调用了，CodeItem 却还是空的。
不一定是 dump 代码写错，更可能是你看的入口和壳恢复时用的不是同一条路。
ClassLinker 负责 load/link/init。很多抽取壳不是 loadClass 后立刻恢复，而是拖到第一次真正执行前。
DexCache 则让“文件镜像里的 Dex”和“运行时真正用到的解析结果”可能不一致。所以只 dump 整体 Dex 不够，还得单独拿 CodeItem。
执行后端现在也不单一：
还按“禁用 dex2oat 后全部长期解释”来设计方案，在高版本里前提已经不稳。
主动调用前，先看：
对应到代码里，大致就是：
这个指针可能是：
AOT/JIT 机器码
art_quick_to_interpreter_bridge
Nterp 入口
Generic JNI stub
Resolution trampoline
Instrumentation stub
它不是静态常量。ClassLinker::LinkCode、Instrumentation::InitializeMethodsCode、JIT 完成、deoptimize，都可能改它。
再叠加这些 flag：
只打印 ArtMethod*、不看 entry 和 flag，后面很容易盲排。
一个很具体的例子：
在 Android 14 Pixel 7 上，有个被加固的 onCreate，当时打印出来的 entry 是 0x70b1c8a000，反解后落到 art_quick_to_interpreter_bridge。按 FART 老路子主动调用，CodeItem 始终没恢复。
第一反应是 dump 时机不对，或者 self == nullptr 那个标记没进分支。后来开了 --force-interpreter 再调，entry 切到了 Nterp，以为这次稳了，结果 Execute 还是没进——Nterp 不走老 Execute。
最后把 dump 点从 Execute 往上提到 EnterInterpreterFromInvoke，才拿到完整 CodeItem。
排查时建议直接把关键信息打全：
实用判断：
entry 已是编译代码，主动调用大概率碰不到解释器恢复逻辑
entry 是 bridge，还有空间，但别默认后面一定进老 Execute
entry 变成 Nterp 后，老 Execute hook 可能直接失效
调用前后 CodeItem 完全不变，优先怀疑路径，不先改文件名和输出目录
结合 AOSP 常见实现，主干可以写成：
主要来说有三
FART 早期靠这个标记：
早期好用，是因为大多数被抽空方法最终还会掉进可观察的解释路径，Invoke 又足够靠前。
高版本继续只靠这个标记会越来越飘：调用表面上成功，实际执行已经从 quick entry 出去了。
进解释器后，更关键的一层其实是这里，不是老的 Execute 单点：
也就是说我们已经知道了
当前 ArtMethod*
方法是否静态
参数区
后续到底会进传统解释，还是被更快的解释后端接走
前面 Pixel 7 那个案子，真正转机不是又找了一个更花哨的 hook，而是 dump 点从 Execute 上移到了这一层。
一个可落的插法：
这比死钉 Execute 更能兜住“已经进解释体系，但不走老 Execute”的情况。
传统 FART 会盯 Execute，原因很多时候：
干扰 dex2oat 后，不少方法仍解释执行
<clinit> 相对稳定走解释
这里能同时碰到 ArtMethod 和当时的 CodeItem
老插法通常是：
整体 Dex dump 也可以放在这附近：
但 Nterp 把“解释执行 = 进旧 Execute”这个等式打断了。
Nterp 仍然解释字节码，入口却可以直接挂在 quick entry 上，调用约定更接近编译代码。
结果就是：
其实不一定是没恢复，更可能是你观察点没盖住这条路。
所以现在更稳的判断不是“有没有进 Execute”，而是：
Invoke 一旦认为有 quick code，就进：
对应关系可以粗写成：
但：
have_quick_code == true 不等于“已经是最终机器码”。
后面可能是 bridge，也可能是 nterp。看到 quick entry 就当 AOT，会直接排错方向。
主动调用如果只是“调了一下”，却没有把 CodeItem 正确摘出来，后面修复照样废。
简化版 dump 逻辑：
长度计算是脏活，也是修失败的高发区。思路大致是：
伪代码：
很多“bin 有了但修回去反编译仍坏”的问题，不是主动调用没触发，而是这里少算了 handler 段。
FART 强在三步闭环，不在单点 hook：
Java 侧主动调用链，常见是从 ClassLoader 枚举下去：
native 再转：
到了高版本，这套闭环还在，但“调用一定能把真实 CodeItem 暴露出来”不再自动成立。路径不对，后面全白做。
旧路径：
现在常见：
桥接和 Nterp 特别容易制造假象：
看到 art_quick_to_interpreter_bridge，以为稳了
force interpreter 后看到 Nterp，又以为稳了
两边都可能不进老 Execute
Pixel 7 上那个 onCreate 就是标准复现：
ArtMethod 大小、字段布局、pointer-sized fields 一直在变。
写死 Android 8/10 offset 的脚本，到 12 后读错是常态。
与其写死，不如运行时探：
CodeItem 获取也建议做成多版本后端，不要假设某一个固定位移永远能取到指令体。
/sdcard/fart/... 在 Scoped Storage 后经常直接写失败。
表现很误导：日志像跑完了，目录却是空的。
更稳的路径一般是：
写文件前先把返回值打出来：
现在更常见：
垃圾类一初始化就退
检测异常 ClassLoader 遍历 / 反射调用
破坏内存 Dex 头
恢复时机压到真实执行点
识别固定线程名、固定路径、固定 so
所以全量主动调用本身就可能成为触发器。
传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！
