Android 热更新热升级访问权限和即时生效问题

公告：“业余草”微信公众号提供免费CSDN下载服务(只下Java资源)，关注业余草微信公众号，添加作者微信：xttblog2，发送下载链接帮助你免费下载！
本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序

腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云

前段时间 IOS 取消了相关框架的热更，在 CSDN 社区专家群引起了大量的讨论。大家纷纷发表自己的看法和技术解决方案。本文不是 IOS 相关的问题的解决方案，主要围绕 Android 的热更新进行学习！

综合前面的几篇文章《Android热修复升级原理和实践》、《Android热修复升级、兼容性问题的根源》、《详解 Android 热更新升级如何突破底层结构差异？》。

看了前面的几篇文章，你可能会有疑惑：我们只是替换了ArtMethod的内容，但新替换的方法的所属类，和原先方法的所属类，是不同的类，被替换的方法有权限访问这个类的其他private方法吗？

以这段简单的代码为例

public class Demo{
	Demo{
		func();
	}
	private void func(){}
}

Demo构造函数调用私有函数func所对应的Dex Code和Native Code为

这个调用逻辑和之前Activity的例子大同小异，需要注意的地方是，在构造函数调用同一个类下的私有方法func时，没有做任何权限检查。也就是说，这时即使我把func方法的偷梁换柱，也能直接跳过去正常执行而不会报错。

可以推测，在dex2oat生成AOT机器码时是有做一些检查和优化的，由于在dex2oat编译机器码时确认了两个方法同属一个类，所以机器码中就不存在权限检查的相关代码。

同包名下的权限问题

但是，并非所有方法都可以这么顺利地进行访问的。我们发现补丁中的类在访问同包名下的类时，会报出访问权限异常：

虽然com.patch.demo.BaseBug和com.patch.demo.MyClass是同一个包com.patch.demo下面的，但是由于我们替换了com.patch.demo.BaseBug.test，而这个替换了的BaseBug.test是从补丁包的Classloader加载的，与原先的base包就不是同一个Classloader了，这样就导致两个类无法被判别为同包名。具体的校验逻辑是在虚拟机代码的Class::IsInSamePackage中：

关键点在于，Class loaders must match这行注释。

知道了原因就好解决了，我们只要设置新类的Classloader为原来类就可以了。而这一步同样不需要在JNI层构造底层的结构，只需要通过反射进行设置。这样仍旧能够保证良好的兼容性。

实现代码如下：

这样就解决了同包名下的访问权限问题。

反射调用非静态方法产生的问题

当一个非静态方法被热替换后，在反射调用这个方法时，会抛出异常。

比如下面这个例子：

//BaseBug.test方法已经被热替换了。
... ...
BaseBug bb = new BaseBug();
Method testMeth = BaseBug.class.getDeclaredMethod("test");
testMeth.invoke(bb);

invoke的时候就会报：

这里面，expected receiver的BaseBug，和got到的BaseBug，虽然都叫com.patch.demo.BaseBug，但却是不同的类。

前者是被热替换的方法所属的类，由于我们把它的ArtMethod的declaring_class_替换了，因此就是新的补丁类。而后者作为被调用的实例对象bb的所属类，是原有的BaseBug。两者是不同的。

在反射invoke这个方法时，在底层会调用到InvokeMethod：

这里面会调用VerifyObjectIsClass函数做验证。

o表示Method.invoke传入的第一个参数，也就是作用的对象。
c表示ArtMethod所属的Class。

因此，只有o是c的一个实例才能够通过验证，才能继续执行后面的反射调用流程。

由此可知，这种热替换方式所替换的非静态方法，在进行反射调用时，由于VerifyObjectIsClass时旧类和新类不匹配，就会导致校验不通过，从而抛出上面那个异常。

那为什么方法是非静态才有这个问题呢？因为如果是静态方法，是在类的级别直接进行调用的，就不需要接收对象实例作为参数。所以就没有这方面的检查了。

对于这种反射调用非静态方法的问题，我们会采用另一种冷启动机制对付，本文在最后会说明如何解决。

即时生效所带来的限制

除了反射的问题，像本方案以及Andfix这样直接在运行期修改底层结构的热修复，都存在着一个限制，那就是只能支持方法的替换。而对于补丁类里面存在方法增加和减少，以及成员字段的增加和减少的情况，都是不适用的。

原因是这样的，一旦补丁类中出现了方法的增加和减少，就会导致这个类以及整个Dex的方法数的变化。方法数的变化伴随着方法索引的变化，这样在访问方法时就无法正常地索引到正确的方法了。

而如果字段发生了增加和减少，和方法变化的情况一样，所有字段的索引都会发生变化。并且更严重的问题是，如果在程序运行中间某个类突然增加了一个字段，那么对于原先已经产生的这个类的实例，它们还是原来的结构，这是无法改变的。而新方法使用到这些老的实例对象时，访问新增字段就会产生不可预期的结果。

不过新增一个完整的、原先包里面不存在的新类是可以的，这个不受限制。

总之，只有两种情况是不适用的：

1. 引起原有了类中发生结构变化的修改
2. 修复了的非静态方法会被反射调用，而对于其他情况，这种方式的热修复都可以任意使用。

总结

虽然有着一些使用限制，但一旦满足使用条件，这种热修复方式是十分出众的，它补丁小，加载迅速，能够实时生效无需重新启动app，并且具有着完美的设备兼容性。对于较小程度的修复再适合不过了。

本修复方案将最先在阿里Hotfix最新版本(Sophix)上应用，由手机淘宝技术团队与阿里云联合发布。

Sophix提供了一套更加完美的客户端服务端一体的热更新方案。针对小修改可以采用本文这种即时生效的热修复，并且可以结合资源修复，做到资源和代码的即时生效。

而如果触及了本文提到的热替换使用限制，对于比较大的代码改动以及被修复方法反射调用情况，Sophix也提供了另一种完整代码修复机制，不过是需要app重新冷启动，来发挥其更加完善的修复及更新功能。从而可以做到无感知的应用更新。

并且Sophix做到了图形界面一键打包、加密传输、签名校验和服务端控制发布与灰度功能，让你用最少的时间实现最强大可靠的全方位热更新。

一张表格来说明一下各个版本热修复的差别：

说明：

1. 部分情况指的是构造方法、参数数目大于8或者参数包括long,double,float基本类型的方法。
2. 冷启动方式，指的是需要重启app在下次启动时才能生效。
3. 对于Andfix及Hotfix 1.X能够支持的代码变动情况，都能做到即时生效。而对于Andfix及Hotfix 1.X不支持的代码变动情况，会走冷启动方式，此时就无法做到即时生效。
4. Hotfix 1.X已经支持绝大部分主流手机，只是在X86设备以及修改了虚拟机底层结构的ROM上不支持。
5. 由于支持了资源和库，如果有这些方面的更新，就会导致的补丁变大一些，这个是很正常的。并且由于只包含差异的部分，所以补丁已经是最大程度的小了。
6. 提供服务端的补丁发布和停发、版本控制和灰度功能，存储开发者上传的补丁包。

最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！

本文原文出处：业余草： » Android 热更新热升级访问权限和即时生效问题