热修复到现在2022年已经不是一个新名词&＃xff0c;但是作为Android开发核心技术栈的一部分&＃xff0c;我这里还得来一次冷饭热炒。
随着移动端业务复杂程度的增加&＃xff0c;传统的版本更新流程显然无法满足业务和开发者的需求&＃xff0c; 热修复技术的推出在很大程度上改善了这一局面。国内大部分成熟的主流 App都拥有自己的热更新技术&＃xff0c;像手淘、支付宝、微信、QQ、饿了么、美团等。
可以说&＃xff0c;一个好的热修复技术&＃xff0c;将为你的 App助力百倍。对于每一个想在 Android 开发领域有所造诣的开发者&＃xff0c;掌握热修复技术更是必备的素质。
热修复是 Android 大厂面试中高频面试知识点&＃xff0c;也是我们必须要掌握的知识点。热修复技术&＃xff0c;可以看作 Android平台发展成熟至一定阶段的必然产物。 Android热修复了解吗&＃xff1f;修复哪些东西&＃xff1f; 常见热修复框架对比以及各原理分析&＃xff1f;
热修复说白了就是不再使用传统的应用商店更新或者自更新方式&＃xff0c;使用补丁包推送的方式在用户无感知的情况下&＃xff0c;修复应用bug或者推送新的需求
传统更新和热更新过程对比如下&＃xff1a;
热修复优缺点:
首先我们得知道热修复修复哪些东西&＃xff1f;
从技术角度来说&＃xff0c;我们的目的是非常明确的&＃xff1a;把错误的代码替换成正确的代码。 注意这里的替换&＃xff0c;并不是直接擦写dx文件&＃xff0c;而是提供一份新的正确代码&＃xff0c;让应用运行时绕过错误代码&＃xff0c;执行新的正确代码。
想法简单直接&＃xff0c;但实现起来并不容易。目前主要有三类技术方案&＃xff1a;
之前分析类加载机制有说过: 加载流程先是遵循双亲委派原则&＃xff0c;如果委派原则没有找到此前加载过此类&＃xff0c; 则会调用CLassLoader的findClass方法&＃xff0c;再去BaseDexClassLoader下面的dexElements数组中查找&＃xff0c;如果没有找到&＃xff0c;最终调用defineClassNative方法加载
代码修复就是基于这点&＃xff1a; 将新的做了修复的dex文件&＃xff0c;通过反射注入到BaseDexClassLoader的dexElements数组的第一个位置上dexElements[0]&＃xff0c;下次重新启动应用加载类的时候&＃xff0c;会优先加载做了修复的dex文件&＃xff0c;这样就达到了修复代码的目的。原理很简单
代码如下&＃xff1a;
public class Hotfix {public static void patch(Context context, String patchDexFile, String patchClassName)throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {//获取系统PathClassLoader的"dexElements"属性值PathClassLoader pathClassLoader &＃61; (PathClassLoader) context.getClassLoader();Object origDexElements &＃61; getDexElements(pathClassLoader);//新建DexClassLoader并获取“dexElements”属性值String otpDir &＃61; context.getDir("dex", 0).getAbsolutePath();Log.i("hotfix", "otpdir&＃61;" &＃43; otpDir);DexClassLoader nDexClassLoader &＃61; new DexClassLoader(patchDexFile, otpDir, patchDexFile, context.getClassLoader());Object patchDexElements &＃61; getDexElements(nDexClassLoader);//将patchDexElements插入原origDexElements前面Object allDexElements &＃61; combineArray(origDexElements, patchDexElements);//将新的allDexElements重新设置回pathClassLoadersetDexElements(pathClassLoader, allDexElements);//重新加载类pathClassLoader.loadClass(patchClassName);
}
private static Object getDexElements(ClassLoader classLoader) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {//首先获取ClassLoader的“pathList”实例Field pathListField &＃61; Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");pathListField.setAccessible(true);//设置为可访问Object pathList &＃61; pathListField.get(classLoader);//然后获取“pathList”实例的“dexElements”属性Field dexElementField &＃61; pathList.getClass().getDeclaredField("dexElements");dexElementField.setAccessible(true);//读取"dexElements"的值Object elements &＃61; dexElementField.get(pathList);return elements;}//合拼dexElementsprivate static Object combineArray(Object obj, Object obj2) {Class componentType &＃61; obj2.getClass().getComponentType();//读取obj长度int length &＃61; Array.getLength(obj);//读取obj2长度int length2 &＃61; Array.getLength(obj2);Log.i("hotfix", "length&＃61;" &＃43; length &＃43; ",length2&＃61;" &＃43; length2);//创建一个新Array实例&＃xff0c;长度为ojb和obj2之和Object newInstance &＃61; Array.newInstance(componentType, length &＃43; length2);for (int i &＃61; 0; i
类加载过程如下&＃xff1a;
微信Tinker&＃xff0c;QQ 空间的超级补丁、手 QQ 的QFix 、饿了 么的 Amigo 和 Nuwa 等都是使用这个方式
缺点&＃xff1a;因为类加载后无法卸载&＃xff0c;所以类加载方案必须重启App&＃xff0c;让bug类重新加载后才能生效。
底层替换方案不会再次加载新类&＃xff0c;而是直接在 Native 层 修改原有类&＃xff0c; 这里我们需要提到Art虚拟机中ArtMethod&＃xff1a; 每一个Java方法在Art虚拟机中都对应着一个 ArtMethod&＃xff0c;ArtMethod记录了这个Java方法的所有信息&＃xff0c;包括所属类、访问权限、代码执行地址等。
结构如下&＃xff1a;
// art/runtime/art_method.h
class ArtMethod FINAL {
...protected:GcRoot
}
在 ArtMethod结构体中&＃xff0c;最重要的就是 注释1和注释2标注的内容&＃xff0c;从名字可以看出来&＃xff0c;他们就是方法的执行入口。 我们知道&＃xff0c;Java代码在Android中会被编译为 Dex Code。
Art虚拟机中可以采用解释模式或者 AOT机器码模式执行 Dex Code
那是不是只需要替换这个几个 entry_point_* 入口地址就能够实现方法替换了呢&＃xff1f; 并没有那么简单&＃xff0c;因为不论是解释模式还是AOT模式&＃xff0c;在运行期间还会需要调用ArtMethod中的其他成员字段
AndFix采用的是改变指针指向&＃xff1a;
// AndFix/jni/art/art_method_replace_6_0.cpp
void replace_6_0(JNIEnv* env, jobject src, jobject dest) {art::mirror::ArtMethod* smeth &＃61;(art::mirror::ArtMethod*) env->FromReflectedMethod(src); // 1art::mirror::ArtMethod* dmeth &＃61;(art::mirror::ArtMethod*) env->FromReflectedMethod(dest); // 2...// 3smeth->declaring_class_ &＃61; dmeth->declaring_class_;smeth->dex_cache_resolved_methods_ &＃61; dmeth->dex_cache_resolved_methods_;smeth->dex_cache_resolved_types_ &＃61; dmeth->dex_cache_resolved_types_;smeth->access_flags_ &＃61; dmeth->access_flags_ | 0x0001;smeth->dex_code_item_offset_ &＃61; dmeth->dex_code_item_offset_;smeth->dex_method_index_ &＃61; dmeth->dex_method_index_;smeth->method_index_ &＃61; dmeth->method_index_;smeth->ptr_sized_fields_.entry_point_from_interpreter_ &＃61;dmeth->ptr_sized_fields_.entry_point_from_interpreter_;smeth->ptr_sized_fields_.entry_point_from_jni_ &＃61;dmeth->ptr_sized_fields_.entry_point_from_jni_;smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_ &＃61;dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_;LOGD("replace_6_0: %d , %d",smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_,dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_);
}
缺点&＃xff1a;存在一些兼容性问题&＃xff0c;由于ArtMethod结构体是Android开源的一部分&＃xff0c;所以每个手机厂商都可能会去更改这部分的内容&＃xff0c;这就可能导致ArtMethod替换方案在某些机型上面出现未知错误。
Sophix为了规避上面的AndFix的风险&＃xff0c;采用直接替换整个结构体。这样不管手机厂商如何更改系统&＃xff0c;我们都可以正确定位到方法地址
install run方案Instant Run 方案的核心思想是——插桩&＃xff0c;在编译时通过插桩在每一个方法中插入代码&＃xff0c;修改代码逻辑&＃xff0c;在需要时绕过错误方法&＃xff0c;调用patch类的正确方法。
首先&＃xff0c;在编译时Instant Run为每个类插入IncrementalChange变量
IncrementalChange $change;
为每一个方法添加类似如下代码&＃xff1a;
public void onCreate(Bundle savedInstanceState) {IncrementalChange var2 &＃61; $change;//$change不为null&＃xff0c;表示该类有修改&＃xff0c;需要重定向if(var2 !&＃61; null) {//通过access$dispatch方法跳转到patch类的正确方法var2.access$dispatch("onCreate.(Landroid/os/Bundle;)V", new Object[]{this, savedInstanceState});} else {super.onCreate(savedInstanceState);this.setContentView(2130968601);this.tv &＃61; (TextView)this.findViewById(2131492944);}
}
如上代码&＃xff0c;当一个类被修改后&＃xff0c;Instant Run会为这个类新建一个类&＃xff0c;命名为xxx&override&＃xff0c;且实现IncrementalChange接口&＃xff0c;并且赋值给原类的$change变量。
public class MainActivity$override implements IncrementalChange {
&＃xff5d;
此时&＃xff0c;在运行时原类中每个方法的var2 !&＃61; null&＃xff0c;通过accessdispatch&＃xff08;参数是方法名和原参数&＃xff09;定位到patch类MainActivitydispatch&＃xff08;参数是方法名和原参数&＃xff09;定位到patch类MainActivityoverride中修改后的方法。
Instant Run是google在AS2.0时用来实现“热部署”的&＃xff0c;同时也为“热修复”提供了一个绝佳的思路。美团的Robust就是基于此。
这里我们来看看install run的原理即可&＃xff0c;市面上的常见修复方案大部分都是基于此方法。
public static void monkeyPatchExistingResources(Context context,String externalResourceFile, Collection
// 创建一个新的AssetManagerAssetManager newAssetManager &＃61; (AssetManager) AssetManager.class.getConstructor(new Class[0]).newInstance(new Object[0]); // ... 1Method mAddAssetPath &＃61; AssetManager.class.getDeclaredMethod("addAssetPath", new Class[] { String.class }); // ... 2mAddAssetPath.setAccessible(true);
// 通过反射调用addAssetPath方法加载外部的资源&＃xff08;SD卡资源&＃xff09;if (((Integer) mAddAssetPath.invoke(newAssetManager,new Object[] { externalResourceFile })).intValue() &＃61;&＃61; 0) { // ... 3throw new IllegalStateException("Could not create new AssetManager");}Method mEnsureStringBlocks &＃61; AssetManager.class.getDeclaredMethod("ensureStringBlocks", new Class[0]);mEnsureStringBlocks.setAccessible(true);mEnsureStringBlocks.invoke(newAssetManager, new Object[0]);if (activities !&＃61; null) {for (Activity activity : activities) {Resources resources &＃61; activity.getResources(); // ... 4try {
// 反射得到Resources的AssetManager类型的mAssets字段Field mAssets &＃61; Resources.class.getDeclaredField("mAssets"); // ... 5mAssets.setAccessible(true);
// 将mAssets字段的引用替换为新创建的newAssetManagermAssets.set(resources, newAssetManager); // ... 6} catch (Throwable ignore) {...}// 得到Activity的Resources.ThemeResources.Theme theme &＃61; activity.getTheme();try {try {
// 反射得到Resources.Theme的mAssets字段Field ma &＃61; Resources.Theme.class.getDeclaredField("mAssets");ma.setAccessible(true);
// 将Resources.Theme的mAssets字段的引用替换为新创建的newAssetManagerma.set(theme, newAssetManager); // ... 7} catch (NoSuchFieldException ignore) {...}...} catch (Throwable e) {Log.e("InstantRun","Failed to update existing theme for activity "&＃43; activity, e);}pruneResourceCaches(resources);}}
/**
* 根据SDK版本的不同&＃xff0c;用不同的方式得到Resources 的弱引用集合
*/ Collection
//遍历并得到弱引用集合中的 Resources &＃xff0c;将 Resources mAssets 字段引用替换成新的 AssetManagerfor (WeakReference
}
采用同样的方式&＃xff0c;
资源修复原理&＃xff1a;
- 1.创建新的AssetManager&＃xff0c;通过反射调用addAssetPath方法&＃xff0c;加载外部资源&＃xff0c;这样新创建的AssetManager就含有了外部资源
- 2.将AssetManager类型的mAsset字段全部用新创建的AssetManager对象替换。这样下次加载资源文件的时候就可以找到包含外部资源文件的AssetManager。
sdk提供接口替换System默认加载so库接口
SOPatchManager.loadLibrary(String libName) -> System.loadLibrary(String libName)
SOPatchManager.loadLibrary接口加载 so库的时候优先尝试去加载sdk 指定目录下的补丁so&＃xff0c;
加载策略如下&＃xff1a;
如果存在则加载补丁 so库而不会去加载安装apk安装目录下的so库 如果不存在补丁so&＃xff0c;那么调用System.loadLibrary去加载安装apk目录下的 so库。
我们可以很清楚的看到这个方案的优缺点: 优点&＃xff1a;不需要对不同 sdk 版本进行兼容&＃xff0c;因为所有的 sdk 版本都有 System.loadLibrary 这个接口。 缺点&＃xff1a;调用方需要替换掉 System 默认加载 so 库接口为 sdk提供的接口&＃xff0c; 如果是已经编译混淆好的三方库的so 库需要 patch&＃xff0c;那么是很难做到接口的替换
虽然这种方案实现简单&＃xff0c;同时不需要对不同 sdk版本区分处理&＃xff0c;但是有一定的局限性没法修复三方包的so库同时需要强制侵入接入方接口调用&＃xff0c;接着我们来看下反射注入方案。
前面介绍过 System. loadLibrary ( “native-lib”); 加载 so库的原理&＃xff0c;其实native-lib 这个 so 库最终传给 native 方法执行的参数是 so库在磁盘中的完整路径&＃xff0c;比如&＃xff1a;/data/app-lib/com.taobao.jni-2/libnative-lib.so, so库会在 DexPathList.nativeLibraryDirectories/nativeLibraryPathElements 变量所表示的目录下去遍历搜索
sdk<23 DexPathList.findLibrary 实现如下
可以发现会遍历 nativeLibraryDirectories数组&＃xff0c;如果找到了 loUtils.canOpenReadOnly (path)返回为 true, 那么就直接返回该 path, loUtils.canOpenReadOnly (path)返回为 true 的前提肯定是需要 path 表示的 so文件存 在的。那么我们可以采取类似类修复反射注入方式&＃xff0c;只要把我们的补丁so库的路径插入到nativeLibraryDirectories数组的最前面就能够达到加载so库的时候是补丁 库而不是原来so库的目录&＃xff0c;从而达到修复的目的。
sdk>&＃61;23 DexPathList.findLibrary 实现如下
sdk23 以上 findLibrary 实现已经发生了变化&＃xff0c;如上所示&＃xff0c;那么我们只需要把补丁so库的完整路径作为参数构建一个Element对象&＃xff0c;然后再插入到nativeLibraryPathElements 数组的最前面就好了。
对于 so库的修复方案目前更多采取的是接口调用替换方式&＃xff0c;需要强制侵入用户 接口调用。 目前我们的so文件修复方案采取的是反射注入的方案&＃xff0c;重启生效。具有更好的普遍性。 如果有so文件修复实时生效的需求&＃xff0c;也是可以做到的&＃xff0c;只是有些限制情况。
可以看出&＃xff0c;阿里系多采用native底层方案&＃xff0c;腾讯系多采用类加载机制。其中&＃xff0c;Sophix是商业化方案&＃xff1b;Tinker/Amigo支持特性较多&＃xff0c;同时也更复杂&＃xff0c;如果需要修复资源和so&＃xff0c;可以选择&＃xff1b;如果仅需要方法替换&＃xff0c;且需要即时生效&＃xff0c;Robust是不错的选择。
尽管热修复&＃xff08;或热更新&＃xff09;相对于迭代更新有诸多优势&＃xff0c;市面上也有很多开源方案可供选择&＃xff0c;但目前热修复依然无法替代迭代更新模式。有如下原因&＃xff1a; 热修复框架多多少少会增加性能开销&＃xff0c;或增加APK大小 热修复技术本身存在局限&＃xff0c;比如有些方案无法替换so或资源文件 热修复方案的兼容性&＃xff0c;有些方案无法同时兼顾Dalvik和ART&＃xff0c;有些深度定制系统也无法正常工作 监管风险&＃xff0c;比如苹果系统严格限制热修复
所以&＃xff0c;对于功能迭代和常规bug修复&＃xff0c;版本迭代更新依然是主流。一般的代码修复&＃xff0c;使用Robust可以解决&＃xff0c;如果还需要修复资源或so库&＃xff0c;可以考虑Tinker。
最后分享一份我自己收录整理的Android学习PDF&＃43;架构视频&＃43;面试文档&＃43;核心笔记&＃xff0c;高级架构技术进阶脑图、Android开发面试专题文档&＃xff0c;高级进阶架构文档。这些都是我现在闲暇还会反复翻阅的精品学习文档。里面对近几年的大厂面试高频问题都有详细的讲解&＃xff0c;也是对我这次面试通过有很大的帮助。相信可以有效的帮助大家掌握知识、理解原理。
当然你也可以拿去查漏补缺&＃xff0c;提升自身的竞争力。↓↓↓
有需要的可以复制下方链接&＃xff0c;传送直达&＃xff01;&＃xff01;&＃xff01;
https://qr21.cn/CaZQLo?BIZ&＃61;ECOMMERCE
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
