阿里电子书《深入探索Android热修复技术原理》整理的笔记

1.热修复技术介绍

代码修复两大主要方案
- 底层替换方案:限制较多,但时效性好,立即见效
- 类加载方案时效性差,需要重新冷启动才能见效,但限制少
代码修复底层替换方案
- 底层替换方案是在已经加载了的类中直接替换掉原有方法.
- 不能对原有类进行方法和字段的增减,因为这样将破坏原有类的结构.
- 方法增减将导致这个类及整个Dex方法数的变化,伴随着方法索引的变化,这样访问方法时就无法正常的索引到正确的方法;
- 字段增加或减少,所有字段的索引都会发生变化;
- 传统底层替换方案,都是直接依赖修改虚拟机方法实体中的具体字段.依据的是Android开源版本.如果厂商修改了虚拟机方法实体,替换机制就可能出问题;
代码修复类加载方案
- 类加载方案的原理是在app重新启动后让Classloader去加载新的类.
- 在app运行到一半的时候,所有需要发生变更的类都已经被加载过,Android无法对一个类进行卸载.如果不重启,原来的类还在虚拟机中,就无法加载新类.
- 只有在下次重启时候,在还没有走到业务逻辑前抢先加载补丁中的新类,后续访问才是新的类.
- dex比较的最佳粒度,应该是在类的粒度
- Sophix采用的也是全量合成dex的技术.可以看做是dex文件级别的类插装方案.Sophix对旧包与补丁包中classes.dex的顺序进行了打破与重组,使得系统可以自然地识别到这个顺序,以实现类覆盖的目的
资源修复
- 市面上很多资源热修复方案都采用了Instant Run的实现
- Instant Run中资源修复步骤:
  1. 构造一个新的AssetManager,通过反射调用addAssetPath,把这个完整的新资源包加到AssetManager中.这样就得到一个含有所有新资源的AssetManager.
  2. 找到所有之前引用到AssetManager的地方,通过反射,将引用出替换为AssetManager.
- Sophix资源热修复没有采用Instant Run的技术,而是构造了一个package id 为 0x66 的资源包,这个包里只包含改变了的资源项,然后直接在原有AssetManager中addAssetPath这个包即可.无需变更AssetManager对象的引用.
  1. Sophix构造的补丁包的 package id 为0x66,不与已经加载的 0x7f冲突,所以直接加入到已有的AssetManager中可以直接使用.
  2. Sophix资源补丁包中,只包含新增资源,以及原有内容发生了改变的资源.
SO库修复:本质上是对native方法的修复和替换

Sophix采用的是类似类修复反射注入方式,把补丁so库的路径插入到nativeLibraryDirectories数组的最前面, 这样加载so库的时候就是补丁so库而不是原来的so库

2.代码热修复技术

3.资源热修复技术

Android资源的热修复,就是在app不重新安装的情况下,利用下发的补丁包直接更新app中的资源 Sophix的资源热修复方案

1:构造一个 package id 为0x66的资源包,这个包里只含有变更的资源,以及新增资源;
2:然后直接在原有AssetManager上调用addAssetPath加入这个资源包即可;

因为我们补丁包的id和已经加载的0x7f冲突,所以直接加入原有AssetManager即可直接使用

4.SO库热修复技术

无