本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
前段时间，Android 平台上涌现了一系列热修复方案，如阿里的 Andfix、微信的Tinker、QQ空间的Nuva、手Q的QFix等等。
其中，Andfix 的即时生效令人印象深刻，它稍显另类，并不需要重新启动，而是在加载补丁后直接对方法进行替换就可以完成修复，然而它的使用限制也遭遇到更多的质疑。
我们也对代码的 native 替换原理重新进行了深入思考，从克服其限制和兼容性入手，以一种更加优雅的替换思路，实现了即时生效的代码热修复。
Andfix 回顾
我们先来看一下，为何唯独Andfix能够做到即时生效呢？
原因是这样的，在app运行到一半的时候，所有需要发生变更的Class已经被加载过了，在Android上是无法对一个Class进行卸载的。而腾讯系的方案，都是让Classloader去加载新的类。如果不重启，原来的类还在虚拟机中，就无法加载新类。因此，只有在下次重启的时候，在还没走到业务逻辑之前抢先加载补丁中的新类，这样后续访问这个类时，就会Resolve为新的类。从而达到热修复的目的。
Andfix采用的方法是，在已经加载了的类中直接在native层替换掉原有方法，是在原来类的基础上进行修改的。我们这就来看一下Andfix的具体实现。
其核心在于replaceMethod函数
这是一个native方法，它的参数是在Java层通过反射机制得到的Method对象所对应的jobject。src对应的是需要被替换的原有方法。而dest对应的就是新方法，新方法存在于补丁包的新类中，也就是补丁方法。
Android的java运行环境，在4.4以下用的是dalvik虚拟机，而在4.4以上用的是art虚拟机。
我们以art为例，对于不同Android版本的art，底层Java对象的数据结构是不同的，因而会进一步区分不同的替换函数，这里我们以Android 6.0为例，对应的就是replace_6_0。
每一个Java方法在art中都对应着一个ArtMethod，ArtMethod记录了这个Java方法的所有信息，包括所属类、访问权限、代码执行地址等等。
通过env->FromReflectedMethod，可以由Method对象得到这个方法对应的ArtMethod的真正起始地址。然后就可以把它强转为ArtMethod指针，从而对其所有成员进行修改。
这样全部替换完之后就完成了热修复逻辑。以后调用这个方法时就会直接走到新方法的实现中了。
虚拟机调用方法的原理
为什么这样替换完就可以实现热修复呢？这需要从虚拟机调用方法的原理说起。
在Android 6.0，art虚拟机中ArtMethod的结构是这个样子的：
这其中最重要的字段就是entry_point_from_interprete_和entry_point_from_quick_compiled_code_了，从名字可以看出来，他们就是方法的执行入口。我们知道，Java代码在Android中会被编译为Dex Code。
art中可以采用解释模式或者AOT机器码模式执行。
解释模式，就是取出Dex Code，逐条解释执行就行了。如果方法的调用者是以解释模式运行的，在调用这个方法时，就会取得这个方法的entry_point_from_interpreter_，然后跳转过去执行。
而如果是AOT的方式，就会先预编译好Dex Code对应的机器码，然后运行期直接执行机器码就行了，不需要一条条地解释执行Dex Code。如果方法的调用者是以AOT机器码方式执行的，在调用这个方法时，就是跳转到entry_point_from_quick_compiled_code_执行。
那我们是不是只需要替换这几个entry_point_*入口地址就能够实现方法替换了呢？
并没有这么简单。因为不论是解释模式或是AOT机器码模式，在运行期间还会需要用到ArtMethod里面的其他成员字段。
就以AOT机器码模式为例，虽然Dex Code被编译成了机器码。但是机器码并不是可以脱离虚拟机而单独运行的，以这段简单的代码为例：
编译为AOT机器码后，是这样的：
这里面我去掉了一些校验之类的无关代码，可以很清楚看到，在调用一个方法时，取得了ArtMethod中的dex_cache_resolved_methods_，这是一个存放ArtMethod*的指针数组，通过它就可以访问到这个Method所在Dex中所有的Method所对应的ArtMethod*。
Activity.onCreate的方法索引是70，由于是64位系统，因此每个指针的大小为8字节，又由于ArtMethod*元素是从这个数组的第0x2个位置开始存放的，因此偏移(70 + 2) * 8 = 576的位置正是Activity.onCreate的ArtMethod指针。
这是一个比较简单的例子，而在实际代码中，有许多更为复杂的调用情况。很多情况下还需要用到dex_code_item_offset_等字段。由此可以看出，AOT机器码的执行过程，还是会有对于虚拟机以及ArtMethod其他成员字段的依赖。
因此，当把一个旧方法的所有成员字段换成都新方法后，执行时所有数据就可以保持和新方法的一致。这样在所有执行到旧方法的地方，会取得新方法的执行入口、所属class、方法索引号以及所属dex信息，然后像调用旧方法一样顺滑地执行到新方法的逻辑。
限于篇幅，本文就到这里。下一章我们将继续解剖Android 热修复升级的 兼容性问题的根源。附上剩余的3篇文章地址：
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Android热修复升级原理和实践