通过上一篇文章《》，我们已经对 Android 的热修复问题有了初步的认知。本文将重点探讨Android热修复升级实践中的兼容性问题的根源。

更多精彩内容请看 web前端中文站
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不支持很多机型的原因，很大的可能，就是因为这些机型修改了底层的虚拟机结构。

【注：本文源自网络文章资源，由站长整理发布】