通过上一篇文章《》，我们已经对 Android 的热修复问题有了初步的认知。本文将重点探讨 Android 热修复升级实践中的兼容性问题的根源。
更多精彩内容请看 web 前端中文站
http://www.lisa33xiaoq.net 可按 Ctrl + D 进行收藏
目前市面上几乎所有的 native 替换方案，比如 Andfix 和另一种 Hook 框架 Legend，都是写死了 ArtMethod 结构体，这会带来巨大的兼容性问题。
从刚才的分析可以看到，虽然 Andfix 是把底层结构强转为了 art::mirror::ArtMethod，但这里的 art::mirror::ArtMethod 并非等同于 app 运行时所在设备虚拟机底层的 art::mirror::ArtMethod，而是 Andfix 自己构造的 art::mirror::ArtMethod。
我们再来回顾一下 Android 开源代码里面 art 虚拟机里的 ArtMethod:
可以看到，ArtMethod 结构里的各个成员的大小是和 AOSP 开源代码里完全一致的。这是由于 Android 源码是公开的，Andfix 里面的这个 ArtMethod 自然是遵照 android 虚拟机 art 源码里面的 ArtMethod 构建的。
但是，由于 Android 是开源的，各个手机厂商都可以对代码进行改造，而 Andfix 里 ArtMethod 的结构是根据公开的 Android 源码中的结构写死的。如果某个厂商对这个 ArtMethod 结构体进行了修改，就和原先开源代码里的结构不一致，那么在这个修改过了的设备上，替换机制就会出问题。
比如，在 Andfix 替换 declaring_class_ 的地方。
由于 declaring_class_ 是 andfix 里 ArtMethod 的第一个成员，因此它和以下这行代码等价：
如果手机厂商在 ArtMethod 结构体的 declaring_class_ 前面添加了一个字段 additional_，那么，additional_ 就成为了 ArtMethod 的第一个成员，所以 smeth + 0 这个位置在这台设备上实际就变成了 additional_，而不再是 declaring_class_ 字段。所以这行代码的真正含义就变成了：
这样就和原先替换 declaring_class_ 的逻辑不一致，从而无法正常执行热修复逻辑。
这也正是 Andfix 不支持很多机型的原因，很大的可能，就是因为这些机型修改了底层的虚拟机结构。
【注：本文源自网络文章资源，由站长整理发布】
