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、虚拟机等，看的一脸懵逼，我先哭一会儿。。等我把其他学了再来阅读这本书。
下面是阿里巴巴的微信订阅号，可以下载此书
