本文主要是介绍《深入探索Android热修复技术原理》读后感以及插件化思考，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
最近编辑于2019/02/17
主要介绍了阿里Sophix方案。
热修复的概念：
AndroidManifest出现BUG是无法修复的，想增加四大组件，可通过预先在安装包的AndroidManifest里面埋入代理的组件，在每次新增组件时，通过预埋的代理组件实现与系统进程间的通信。
热修复需要在补丁包中包含一个新逻辑的dex文件。
资源的修复，主要通过修改资源包的内容。
so库修复是通过在加载时优先加载补丁包的so库。
热替换代码修复：
Andfix底层替换的局限性：Andfix是根据公开的Android源码对ArtMethod结构体里面的字段进行的修改。如果手机厂商修改了ArtMethod的结构体（其实是在结构体前面增加字段，编译为AOT机器码后发生替换错位），就会导致机型不支持。
而Sophix采用了整体替换ArtMethod的方案，就避免了手机厂商修改结构体的问题。但也带来需要计算ArtMethod大小的问题，后来发现ArtMethod Array的地址是紧密排列的，通过相邻两个ArtMethod的起始地址的差值计算出ArtMethod的大小。优点只要以后ArtMethod数组仍是以线性结构排列，该方案仍能适用。
访问权限的问题：通常是因为类是由不同的Classloader加载导致的，可以通过反射或者采用冷启动的方式来解决。
热替换的局限：因为热替换需要原有的类实例的结构不变。因此使用Sophix进行热修复，想让用户体验到热替换，只能在原有类的方法里修改或者新增一个原包不存在的新类（PS这样会使代码变乱，在上升级包前应该重新整理代码）。还有其他一些局限：比如尽量不要增加非静态内部类、需要混淆配置加上-dontoptimize防止方法裁剪与内联、防止因泛型类型擦除与多态矛盾而产生的桥接方法、基本不支持Lambda表达式、补丁类不能引用非public类。
冷启动代码修复：
QQ空间和Tinker的冷启动方案与前面的热部署模式不兼容，Sophix寻求一种既能无侵入打包又能做热部署的补充解决方案。QQ空间使用的插桩（需要增加一个含有无关帮助类的dex，原dex中所有类的构造函数都引用这个类）会影响类加载效率。Tinker采用了把原有dex和补丁包里的dex重新合并的方案，Sophix则采用去除基线包中的补丁类再加上补丁。Tinker对Application的处理是需要开发者将自己的Application替换成TinkerApplication，而Sophix直接再JNI层去除Application类的pre-verified标志（需要Application用到的所有非系统类都和Application位于同一个dex里，因为Android官方multi-dex机制会自动将Application用到的类都打包到主dex中，所以只要把热修复初始化放在attachBaseContext的最前面就行），同时Sophix提供了指定AndroidManifest的Application为SophixStubApplication的方案（会解决一些入口类的问题，同时也不影响用户通过设置SophixEntry自定义Application）。
Android APP的启动顺序：Application.attachBaseContext——>ContentProvider.onCreate——>Application.onCreate——>Activity.onCreate。
资源热修复技术：
普遍的做法是参考Instant Run，把资源热修复分为两步：
1、构造一个新的AssetManager，并通过反射调用addAssetPath，把这个完整的新资源包加入到AssetManager中。这样就得到了一个含有所有新资源的AssetManager。
2、找到所有之前引用到原有AssetManager的地方，通过反射，把引用处替换为新的AssetManager。
Sophix采用了另辟蹊径的方案，主要是使补丁包的pacakage id为0x66，使其不与已经加载的资源冲突（修改资源时，还需在代码引用处做出相应修改，因为原先的资源还是存在的）。
so库热修复技术：
由于so库热部署的种种限制，Sophix采用了反射注入重启生效的冷启动方案。
编辑于2019/02/18
插件化思考
插件化技术类似于热修复技术，插件化更注重于多个插件的版本控制，也更注重于插件的即插即用（无需冷启动更新），但也由于不涉及原类的修改使得即插即用成为可能。
插件化也分为so库的加载、资源的加载、代码的加载。
so库的加载使用了System.load或者System.loadLibrary的方案，如同上面那本书中所讲，实际是存在一定限制的。
资源的加载也是从参照Instant Run的方案（我的一个无侵入支持应用内以及插件式的安卓应用换肤框架就是采用的这种方案）到修改资源id的技术衍变。
由于无需修改原类，使得代码的即插即用成为可能。这是插件化着重研究的方面。简单一点的如同上面热修复技术提到的预先在安装包的AndroidManifest里面埋入代理的组件，在每次新增组件时，通过预埋的代理组件实现与系统进程间的通信。复杂一点主要是运用静态代理进行Hook，或者动态代理进行Hook（Shawn_Dut 讲解了Android 动态代理以及利用动态代理实现 ServiceHook，GitHub上的源码，只不过插件化需要Hook的对象很多以及一些其他细节问题需要考虑）。
这篇关于《深入探索Android热修复技术原理》读后感以及插件化思考的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
