《深入探索Androdi热修复技术原理（阿里巴巴）》--读书笔记

No1：

Hybrid就是原生和Html5混合开发app

No2：

插件化方法Altas或者DroidPlugin

No3：

热修复技术可以把更新补丁上传到云端，此时APP就可以直接从云端下拉补丁直接应用生效

优势：

1）无需重新发版，实时高效热修复

2）用户无感知修复，无需下载新的应用，代价小

3）修复成功率高，把损失降到最低

No4：

热修复框架Sophix：包括代码修复、资源修复、so修复

No5：

代码修复油两大主要方案，一种是阿里系的底层替换方案，另一种是腾讯系的类加载方案

这两种方案各有优劣

* 底层替换方案限制颇多，但时效性最好，加载轻快，立即见效

* 类加载方案时效性差，需要重新冷启动才能见效，但修复范围广，限制少

底层替换方案是在已经加载了的类中直接替换掉原有方法，是在原来类的基础上进行修改的。因而无法实现对与原有类进行方法和字段的增减，因为这样将破坏原有类的结构。

类加载方案的原理是在app重新启动后让Classloader去加载新的类

Sophix的代码修复体系同时涵盖了底层替换方案和类加载方案。

No6：

Instant Run资源热修复分为两步

1）构造一个新的AssetManager，并通过反射调用addAssetPath，把这个完整的新资源包加入到AssetManager中。这样就得到了一个含有所有新资源的AssetManager

2）找到所有之前引用到原有AssetManager的地方，通过反射，把引用处替换为AssetManager

No7：

SO库修复本质上是对native方法的修复和替换

阿里采用的是类似类修复反射注入方式。把补丁so库的路径插入到nativeLibraryDirctories数组的最前面，就能够达到加载so库的时候是补丁so库，而不是原来so库的目录，从而达到修复的目的。

No8：

Sophix的核心设计理念，就是非侵入性

No9：

Sophix资源替换方案优势在于：

1）不修改AssetManager的引用处，替换更快更完全（对比Instant Run以及所有copycat的实现）

2）不必下发完整包，补丁包中只包含有变动的资源（对比Instant Run、Amigo等方式的实现）

3）不需要再运行时合成完整包。不占用运行时计算和内存资源（对比Tinker的实现）

No10：

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

No11：

内部类在编译期会被编译为跟外部类一样的顶级类

No12：

静态内部类和非静态内部类的区别：

非静态内部类持有外部类的引用，静态内部类不持有外部类的引用

No13：

android虚拟机首先通过javac把源代码编译成.class，然后再通过dx工具优化成适合移动设备的dex字节码文件

No14：

打补丁是通过反编译为smali然后新apk跟基线apk进行差异对比，得到最后的补丁包。

No15：

冷启动实现方案

No16：

Dalvik下采用我们自行研发的全量DEX方案

Art下本质上虚拟机已经支持多dex的加载，我们要做的仅仅是把补丁dex作为主dex（classes.dex）加载而已

No17：

Instant Run中的资源热修复分为两步

1）构造一个新的AssetManager，并通过反射调用addAssetPath，把这个完整的新资源包加入到AssetManager中。这样就得到了一个含有所有新资源的AssetManager

2）找到所有之前引用到原有AssetManager的地方，通过反射，把引用处替换为AssetManager

No18：

资源修复方案：构造了一个package id为0x66的资源包，这个包里只包含改变了的资源项，然后直接在原有AssetManager中addAssetPath这个包

No19：

Sophix资源修复的优势

1）不侵入打包，直接对比新旧资源即可产生补丁资源包（对比修改aapt方式的实现）

2）不必下发完整包，补丁包中只包含有变动的资源（对比Instant Run、Amigo等方式的实现）

3）不需要再运行时合成完整包。不占用运行时计算和内存资源（对比Tinker的实现）

No20：

Java Api提供以下两个接口加载一个so库

1）System.loadLibrary(String libName):传进去的参数：so库名称，表示的so库文件，位于apk压缩文件中的libs目录，最后复制到apk安装目录下

2）System.load(String pathName):传进去的参数：so库在磁盘中的完整路径。加载一个自定义外部so库文件

总结下：

1）动态注册的native方法映射通过加载so库过程中调用JNI_OnLoad方法调用完成

2）静态注册的native方法映射是在该native方法第一次执行的时候才完成映射，当然前提是该so库已经load过

No21：

so库的实时生效必须满足以下几点：

1）so库为了兼容Dalvik虚拟机下动态注册native方法的实时生效，必须对so文件进行改名

2）针对so库静态注册native方法的实时生效，首先需要解注册静态注册的native方法，这个也是难点，因为我们很难知道so库中哪几个静态注册的native方法发生了变更。假设就算我们知道如果静态注册的native方法需要解注册，重新load补丁so库也有可能被修复也有可能不被修复

3）上面对补丁so进行了第二次加载，那么肯定是多消耗了一次本地内存，如果补丁so库够大，补丁so够多，那么JNI层的OOM也不是没可能

4）另外一方面补丁so如果新增了一个动态注册的方法而dex中没有响应方法，直接去加载这个补丁so文件会报NoSuchMethodError异常，具体逻辑在dvmRegisterJNIMethod中。我们知道如果dex如果新增了一个native方法，那么走不了热部署只能冷启动重启生效，所以此时补丁so就不能第二次load了。这种情况下so库的修复严重依赖于dex的媳妇方案

No22：

so库的修复方案目前更多采取的是接口调用替换方案，需要强制侵入用户接口调用。目前我们的so文件修复方案采取的是fanshe注入的方案，重启生效。具有更好的普遍性

No23：

Sophix方案纵向比较

飞速看完这本书，心里是崩溃的，涉及C、C++、Smali、Lambda、虚拟机等，看的一脸懵逼，我先哭一会儿。。等我把其他学了再来阅读这本书。

下面是阿里巴巴的微信订阅号，可以下载此书