通过上一篇文章《》,我们已经对 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 不支持很多机型的原因,很大的可能,就是因为这些机型修改了底层的虚拟机结构。
【注:本文源自网络文章资源,由站长整理发布】