热修复

ゞ浴缸里的玫瑰 2023-08-17 15:15 146阅读 0赞

## 一、前言 ##

任何程序都无法保证上线后不会出现紧急bug，选择的修复方式不同，其代价也大不相同。所谓热修复，是相对于正常的版本迭代修复而言的，它可以及时在应用内下载补丁更新程序逻辑，修复bug；而不需要等到下一个版本发布。举个简单的例子，假如有一行代码的逻辑写错了，并且已经编译出APK，安装到了用户的手机上，此时有两种处理方式：

1.  等待下一个版本发布，其中修复了错误代码，即迭代修复
2.  给用户推送补丁，及时修复错误代码，即热修复

下图对比两者区别：

![600079-20190822164837155-217724649.png][]

从上图可以看出热修复相对于迭代修复有很大优势：

1.  成本优势——避免了重新向渠道更新APK版本
2.  时间优势——几乎是即时修复，不必等待版本覆盖时间
3.  体验优势——避免重新安装版本，用户无感修复

热修复技术可以为应用增加一份安全保障，也为程序更新提供了一种新的可能途径。

--------------------

## 二、热修复技术原理 ##

从技术角度来说，我们的目的是非常明确的：把错误的代码替换成正确的代码。注意这里的替换，并不是直接擦写dx文件，而是提供一份新的正确代码，让应用运行时绕过错误代码，执行新的正确代码。

![热修复][600079-20190823101939615-2044655051.png]

想法简单直接，但实现起来并不容易。目前主要有三类技术方案：

*  native底层替换方案
 *  类加载方案
 *  Instant Run方案

### （１）native底层替换方案 ###

Android/Java代码的最小组织方式是方法（Method，实际上，每一个dex文件最多可以包含65536（0xffff）个方法），每个方法在ART虚拟机中都有一个ArtMethod结构体指针与之对应，ArtMethod结构体中包含了Java方法的所有信息，包括执行入口、访问权限、所属类和代码执行地址等等。换句话说，虚拟机就是通过ArtMethod结构体来操纵Java方法的。ArtMethod结构如下：

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

class ArtMethod FINAL {
    ...
    protected:
      GcRoot<mirror::Class> declaring_class_;
    
      std::atomic<std::uint32_t> access_flags_;
    
      // Offset to the CodeItem.
      uint32_t dex_code_item_offset_;
    
      // Index into method_ids of the dex file associated with this method.
      uint32_t dex_method_index_;
    
      uint16_t method_index_;
    
      uint16_t hotness_count_;
    
      struct PtrSizedFields {
        // Depending on the method type, the data is
        //   - native method: pointer to the JNI function registered to this method
        //                    or a function to resolve the JNI function,
        //   - conflict method: ImtConflictTable,
        //   - abstract/interface method: the single-implementation if any,
        //   - proxy method: the original interface method or constructor,
        //   - other methods: the profiling data.
        void* data_;
    
        // Method dispatch from quick compiled code invokes this pointer which may cause bridging into
        // the interpreter.
        void* entry_point_from_quick_compiled_code_;
      } ptr_sized_fields_;
    ...
    ｝

其中有一个关键指针，它是方法的执行入口：

entry_point_from_quick_compiled_code_

也就是说，这个指针指向方法体编译后对应的汇编指令。那么，如果我们能hook这个指针，由原来指向有bug的方法，变成指向正确的方法，就达到了修复的目的。这就是native层替换方案的核心原理。具体实现方案可以是改变指针指向（AndFix），也可以直接替换整个结构体（Sophix）。

需要注意的是，底层替换方案虽然是即使生效的，但是因为不会加载新类，而是直接修改原类，所以修改的代码不能增加新的方法，否则会造成索引数与方法数不匹配，无法通过索引找到正确方法，字段同理。

### （２）类加载方案 ###

native底层替换方案hook的是method指针，类加载方案则将目标定在类上。我们写的.java代码，最终是由ClassLoader加载的。

![600079-20190826104015429-942455156.png][]

上面提到过每一个dex文件最多可以包含65536（0xffff）个方法，超过了就需要用到分包方案，也就是说，每个APK中可能包含多个dex文件。而每个dex文件，最终对应DexPathList中的一个Element实例：

static class Element {
            private final File path;
            private final DexFile dexFile;
            private ClassPathURLStreamHandler urlHandler;
            private boolean initialized;
    
            public Element(DexFile dexFile, File dexZipPath) {
                this.dexFile = dexFile;
                this.path = dexZipPath;
            }
    
            ......
    }

如果加载一个类，会调用DexPathList中的findClass函数：

public Class<?> findClass(String name, List<Throwable> suppressed) {
            DexPathList.Element[] var3 = this.dexElements; //多个dex文件对应Element数组
            int var4 = var3.length;
    
            for(int var5 = 0; var5 < var4; ++var5) {
                DexPathList.Element element = var3[var5];
                Class<?> clazz = element.findClass(name, this.definingContext, suppressed);  //以此从dex文件中查找目标Class
                if (clazz != null) {
                    return clazz;
                }
            }
    
            if (this.dexElementsSuppressedExceptions != null) {
                suppressed.addAll(Arrays.asList(this.dexElementsSuppressedExceptions));
            }
    
            return null;
        }

如上代码，当需要加载一个类时，会依次从dex文件检索，直至找到目标类后停止：

![600079-20190826110419942-1897892974.png][]

实际上，类替换方案的核心思想就是：将修改后的patch（包含bug类文件）打包成dex文件，然后hook ClassLoader加载流程，将这个dex文件插入到Element数组的第一个元素。因为加载类是依次进行的，所以虚拟机从第一个Element找到类后，就不会再加载bug类了。

类加载方案也有缺点，因为类加载后无法卸载，所以类加载方案必须重启App，让bug类重新加载后才能生效。

### （3）Instant Run方案 ###

Instant Run 方案的核心思想是——插桩，在编译时通过插桩在每一个方法中插入代码，修改代码逻辑，在需要时绕过错误方法，调用patch类的正确方法。

首先，在编译时Instant Run为每个类插入IncrementalChange变量：

IncrementalChange  $change;

为每一个方法添加类似如下代码：

public void onCreate(Bundle savedInstanceState) {
            IncrementalChange var2 = $change;
            //$change不为null，表示该类有修改，需要重定向
            if(var2 != 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 = (TextView)this.findViewById(2131492944);
            }
        }

如上代码，当一个类被修改后，Instant Run会为这个类新建一个类，命名为xxx&override，且实现IncrementalChange接口，并且赋值给原类的$change变量。

public class MainActivity$override implements IncrementalChange {
    ｝

此时，在运行时原类中每个方法的var2 != null，通过access$dispatch（参数是方法名和原参数）定位到patch类MainActivity$override中修改后的方法。

Instant Run是google在AS2.0时用来实现“热部署”的，同时也为“热修复”提供了一个绝佳的思路。美团的Robust就是基于此。

### 总结： ###

以上是三种方案的基本原理，每种方案又有不同的实现方案，导致目前热修复出现百家争鸣的现象。无论哪种热修复方案，都不是一蹴而就的，需要在长期的实战中不断完善。

众方案各有所长，且基于自家业务不断更新迭代。统计如下：

<table> 
 <tbody> 
  <tr> 
   <th align="center">特性</th> 
   <th align="center">Dexposed</th> 
   <th align="center">AndFix</th> 
   <th align="center">Tinker/Amigo</th> 
   <th align="center">QQ Zone</th> 
   <th align="center">Robust/Aceso</th> 
   <th align="center">Sophix</th> 
  </tr> 
  <tr> 
   <td align="center">技术原理</td> 
   <td colspan="2" align="center">native底层替换</td> 
   <td colspan="2" align="center">类加载</td> 
   <td align="center">Instant Run</td> 
   <td align="center">混合</td> 
  </tr> 
  <tr> 
   <td align="center">所属</td> 
   <td colspan="2" align="center">阿里</td> 
   <td align="center">微信/饿了么</td> 
   <td align="center">QQ空间</td> 
   <td align="center">美团/蘑菇街</td> 
   <td align="center">阿里</td> 
  </tr> 
  <tr> 
   <td align="center">即时生效</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">&nbsp;YES</td> 
   <td align="center">&nbsp;NO</td> 
   <td align="center">NO</td> 
   <td align="center">&nbsp;YES</td> 
   <td align="center">混合</td> 
  </tr> 
  <tr> 
   <td align="center">方法替换</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">&nbsp;YES</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">&nbsp; YES&nbsp;</td> 
   <td align="center">YES</td> 
  </tr> 
  <tr> 
   <td align="center">类替换</td> 
   <td align="center">NO</td> 
   <td align="center">&nbsp;NO</td> 
   <td align="center">YES</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">&nbsp; YES&nbsp;</td> 
   <td align="center">&nbsp;YES&nbsp;</td> 
  </tr> 
  <tr> 
   <td align="center">类结构修改</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">&nbsp;NO</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">&nbsp;NO</td> 
   <td align="center">YES&nbsp;</td> 
  </tr> 
  <tr> 
   <td align="center">资源替换</td> 
   <td align="center">NO</td> 
   <td align="center">&nbsp;NO</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
  </tr> 
  <tr> 
   <td align="center">so替换</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
  </tr> 
  <tr> 
   <td align="center">支持gradle</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES</td> 
   <td align="center">YES&nbsp;</td> 
  </tr> 
  <tr> 
   <td align="center">支持ART</td> 
   <td align="center">NO&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
   <td align="center">YES&nbsp;</td> 
  </tr> 
 </tbody> 
</table>

可以看出，阿里系多采用native底层方案，腾讯系多采用类加载机制。其中，Sophix是商业化方案；Tinker/Amigo支持特性较多，同时也更复杂，如果需要修复资源和so，可以选择；如果仅需要方法替换，且需要即时生效，Robust是不错的选择。

--------------------

## 三、自定义热修复方案 ##

以类加载机制为例，自定义一个简单的热修复demo，核心代码如下（尚未验证通过，待研究插件化技术之后补齐）：

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

public class Hotfix {
    
        public static void patch(Context context, String patchDexFile, String patchClassName)
                throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
            //获取系统PathClassLoader的"dexElements"属性值
            PathClassLoader pathClassLoader = (PathClassLoader) context.getClassLoader();
            Object origDexElements = getDexElements(pathClassLoader);
    
            //新建DexClassLoader并获取“dexElements”属性值
            String otpDir = context.getDir("dex", 0).getAbsolutePath();
            Log.i("hotfix", "otpdir=" + otpDir);
            DexClassLoader nDexClassLoader = new DexClassLoader(patchDexFile, otpDir, patchDexFile, context.getClassLoader());
            Object patchDexElements = getDexElements(nDexClassLoader);
    
            //将patchDexElements插入原origDexElements前面
            Object allDexElements = combineArray(origDexElements, patchDexElements);
    
            //将新的allDexElements重新设置回pathClassLoader
            setDexElements(pathClassLoader, allDexElements);
    
            //重新加载类
            pathClassLoader.loadClass(patchClassName);
        }
    
        private static Object getDexElements(ClassLoader classLoader) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {
            //首先获取ClassLoader的“pathList”实例
            Field pathListField = Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");
            pathListField.setAccessible(true);//设置为可访问
            Object pathList = pathListField.get(classLoader);
    
            //然后获取“pathList”实例的“dexElements”属性
            Field dexElementField = pathList.getClass().getDeclaredField("dexElements");
            dexElementField.setAccessible(true);
    
            //读取"dexElements"的值
            Object elements = dexElementField.get(pathList);
            return elements;
        }
    
        //合拼dexElements
        private static Object combineArray(Object obj, Object obj2) {
            Class componentType = obj2.getClass().getComponentType();
            //读取obj长度
            int length = Array.getLength(obj);
            //读取obj2长度
            int length2 = Array.getLength(obj2);
            Log.i("hotfix", "length=" + length + ",length2=" + length2);
            //创建一个新Array实例，长度为ojb和obj2之和
            Object newInstance = Array.newInstance(componentType, length + length2);
            for (int i = 0; i < length + length2; i++) {
                //把obj2元素插入前面
                if (i < length2) {
                    Array.set(newInstance, i, Array.get(obj2, i));
                } else {
                    //把obj元素依次放在后面
                    Array.set(newInstance, i, Array.get(obj, i - length2));
                }
            }
            //返回新的Array实例
            return newInstance;
        }
    
        private static void setDexElements(ClassLoader classLoader, Object dexElements) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {
            //首先获取ClassLoader的“pathList”实例
            Field pathListField = Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");
            pathListField.setAccessible(true);//设置为可访问
            Object pathList = pathListField.get(classLoader);
    
            //然后获取“pathList”实例的“dexElements”属性
            Field declaredField = pathList.getClass().getDeclaredField("dexElements");
            declaredField.setAccessible(true);
    
            //设置"dexElements"的值
            declaredField.set(pathList, dexElements);
        }
    }

--------------------

## 四、Robust方案对接 ##

Robust是美团团队基于Instant Run 技术开发的开源（dian zan）热修复框架，Github地址：[https://github.com/Meituan-Dianping/Robust][https_github.com_Meituan-Dianping_Robust]

下面以Robust 4.9版本为例，详细介绍一下其对接流程，主要步骤如下：

1.  添加robust插件
2.  配置插件特性——robust.xml
3.  配置补丁加载方法——自定义PatchManipulate和RobustCallback子类
4.  编译基础版本（生成mapping.txt，methodMap.robust）
5.  修复代码
6.  生成补丁——patch.jar
7.  补丁下载/推送
8.  调用修复命令

### （１）添加robust插件 ###

共有两处需要添加，在项目外层build.gradle添加：

dependencies {
            classpath 'com.meituan.robust:gradle-plugin:0.4.90'
            classpath 'com.meituan.robust:auto-patch-plugin:0.4.90'
        }

在app module的build.gradle添加：

apply plugin: 'com.android.application'
    //此两项紧跟com.android.application，生成补丁时打开auto-patch-plugin插件
    //apply plugin: 'auto-patch-plugin'
    apply plugin: 'robust'

### （２）配置插件特性——robust.xml ###

将robust.xml配置文件拷贝到app根目录下，并按需求配置插件特性:

<?xml version="1.0" encoding="utf-8"?>
    <resources>
    
        <switch>
            
            
            <turnOnRobust>true</turnOnRobust>
            
    
            
            
            
            <manual>false</manual>
    
            
            
            
            <forceInsert>false</forceInsert>
    
            
            <catchReflectException>true</catchReflectException>
            
    
            
            
            <patchLog>false</patchLog>
    
            
            <proguard>true</proguard>
            
    
            
            <useAsm>true</useAsm>
            
        </switch>
    
        
        
        <packname name="hotfixPackage">
            <name>com.xibeixue.hotfix</name>
            
            
        </packname>
    
        
        <exceptPackname name="exceptPackage">
            <name>com.meituan.robust</name>
            <name>com.meituan.sample.extension</name>
        </exceptPackname>
    
        
        <patchPackname name="patchPackname">
            <name>com.xibeixue.hotfix</name>
        </patchPackname>
    
        
        <noNeedReflectClass name="classes no need to reflect">
    
        </noNeedReflectClass>
    </resources>

注意：如果是调试，请打开forceInsert，关闭proguard。一般packname和patchPackname需要自行配置，其他选项保持默认即可。

### （３）配置补丁加载方法 ###

第（２）步配置的是插件的工作方式，为了生成补丁patch.jar；程序还需要知道如何加载补丁，比如补丁在哪里，要解压到哪里等。这就需要自定义PatchManipulate子类：

public class PatchManipulateImp extends com.meituan.robust.PatchManipulate {
        @Override
        protected List<Patch> fetchPatchList(Context context) {
            //将app自己的robustApkHash上报给服务端，服务端根据robustApkHash来区分每一次apk build来给app下发补丁
            //apkhash is the unique identifier for  apk,so you cannnot patch wrong apk.
            //String robustApkHash = RobustApkHashUtils.readRobustApkHash(context);
            Patch patch = new Patch();
            patch.setName("123");
            //we recommend LocalPath store the origin patch.jar which may be encrypted,while TempPath is the true runnable jar
            patch.setLocalPath(Environment.getExternalStorageDirectory().getAbsolutePath() + File.separator + "patch");
            /*上面的路径看似设置的是目录,其实不是,在get方法中默认追加了.jar;temp默认则追加_temp.jar.可以理解为设置补丁的文件名.建议放在程序内部目录,提高安全性*/
            /*com.xibeixue.hotfix.PatchesInfoImpl要和robut.xml中patchPackname节点里面的包名保持一致*/
            patch.setPatchesInfoImplClassFullName("com.xibeixue.hotfix.PatchesInfoImpl");
            List patches = new ArrayList<Patch>();
            patches.add(patch);
            return patches;
        }
    
        @Override
    
        protected boolean verifyPatch(Context context, Patch patch) {
            patch.setTempPath(context.getCacheDir() + File.separator + "robust" + File.separator + "patch");
            //in the sample we just copy the file
            try {
                copy(patch.getLocalPath(), patch.getTempPath());
            } catch (Exception e) {
                e.printStackTrace();
                throw new RuntimeException("copy source patch to local patch error, no patch execute in path " + patch.getTempPath());
            }
    
    
            return true;
        }
    
        @Override
        protected boolean ensurePatchExist(Patch patch) {
            return true;
        }
    
        public void copy(String srcPath, String dstPath) throws IOException {
            Log.i("hotfix","srcPath=" + srcPath);
            File src = new File(srcPath);
            if (!src.exists()) {
                throw new RuntimeException("source patch does not exist ");
            }
            File dst = new File(dstPath);
            if (!dst.getParentFile().exists()) {
                dst.getParentFile().mkdirs();
            }
            InputStream in = new FileInputStream(src);
            try {
                OutputStream out = new FileOutputStream(dst);
                try {
                    // Transfer bytes from in to out
                    byte[] buf = new byte[1024];
                    int len;
                    while ((len = in.read(buf)) > 0) {
                        out.write(buf, 0, len);
                    }
                } finally {
                    out.close();
                }
            } finally {
                in.close();
            }
        }
        
    }

注意：setPatchesInfoImplClassFullName时需要和robust.xml中的patchPackname包名保持一致。

如果要对补丁加载过程监听，需要自定义RobustCallback子类：

public class RobustCallBackSample implements com.meituan.robust.RobustCallBack {
        @Override
        public void onPatchListFetched(boolean result, boolean isNet, List<Patch> patches) {
            Log.d("RobustCallBack", "onPatchListFetched result: " + result);
            Log.d("RobustCallBack", "onPatchListFetched isNet: " + isNet);
            for (Patch patch : patches) {
                Log.d("RobustCallBack", "onPatchListFetched patch: " + patch.getName());
            }
        }
    
        @Override
        public void onPatchFetched(boolean result, boolean isNet, Patch patch) {
            Log.d("RobustCallBack", "onPatchFetched result: " + result);
            Log.d("RobustCallBack", "onPatchFetched isNet: " + isNet);
            Log.d("RobustCallBack", "onPatchFetched patch: " + patch.getName());
        }
    
        @Override
        public void onPatchApplied(boolean result, Patch patch) {
            Log.d("RobustCallBack", "onPatchApplied result: " + result);
            Log.d("RobustCallBack", "onPatchApplied patch: " + patch.getName());
    
        }
    
        @Override
        public void logNotify(String log, String where) {
            Log.d("RobustCallBack", "logNotify log: " + log);
            Log.d("RobustCallBack", "logNotify where: " + where);
        }
    
        @Override
        public void exceptionNotify(Throwable throwable, String where) {
            Log.e("RobustCallBack", "exceptionNotify where: " + where, throwable);
        }
    }

### （４）编译基础版本 ###

到目前为止，就可以编译基础版本了，这时插件会生成两个文件

//方法记录文件，该文件在打补丁的时候用来区别到底哪些方法需要被修复
    build/outputs/robust/methodsMap.robust
    //该文件列出了原始的类、方法和字段名与混淆后代码间的映射，需要开启proguard配置项后才会出现
    build/outputs/mapping/mapping.txt

将这两个文件拷贝到app根目录下的robust文件夹下（没有就自行创建），后面生成补丁时会用到。

### （５）修复代码 ###

//修复代码，需要添加Modify注释或者调用RobustModify.modify()方法，作为修复标记
        @Modify
        public void run() {
    //        Log.i("hotfix", "我有一个严重Bug需要修复！");
            Log.i("hotfix", "我的Bug已经被修复！");
        }
    
        //添加代码需要添加Add注释，作为标记
        @Add
        public void run2(){
            Log.i("hotfix", "我是一个新添加的方法！");
        }

### （６）生成补丁 ###

生成补丁，只需要打开auto-patch-plugin补丁插件，重新编译即可：

//打开补丁插件
    apply plugin: 'auto-patch-plugin'
    apply plugin: 'robust'

此时，会在app根目录下的robust文件夹下生成patch.jar补丁文件。

### （７）补丁下载、推送 ###

Robust热修复框架并没有补丁下载模块，需要自行和后台服务协商下载或推送方案。但是patch.jar必须下载到PatchManipulateImp指定的localPath。另外，如果下载到sd卡，一定要申请sd卡读写权限！

### （８）调用修复命令 ###

在合适的时机，调用修复命令，一般下载后尽早调用：

new PatchExecutor(getApplicationContext(), new PatchManipulateImp(), new RobustCallBackSample()).start();

调用修复命令后，不用重启进程，再次调用被修复方法时，发现已经开始执行修复逻辑了！

Demo源码：[https://github.com/JiaxtHome/hotfix][https_github.com_JiaxtHome_hotfix]

--------------------

## 五、总结 ##

尽管热修复（或热更新）相对于迭代更新有诸多优势，市面上也有很多开源方案可供选择，但目前热修复依然无法替代迭代更新模式。有如下原因：

*  热修复框架多多少少会增加性能开销，或增加APK大小
 *  热修复技术本身存在局限，比如有些方案无法替换so或资源文件
 *  热修复方案的兼容性，有些方案无法同时兼顾Dalvik和ART，有些深度定制系统也无法正常工作
 *  监管风险，比如苹果系统严格限制热修复

所以，对于功能迭代和常规bug修复，版本迭代更新依然是主流。一般的代码修复，使用Robust可以解决，如果还需要修复资源或so库，可以考虑Tinker。

转载于:https://www.cnblogs.com/not2/p/11392733.html

[600079-20190822164837155-217724649.png]: /images/20230810/d1135e0fee2b46f586d91254b8c96a02.png
[600079-20190823101939615-2044655051.png]: /images/20230810/d85d846d0d074a80a124eabb0a15d52b.png
[ContractedBlock.gif]: https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif
[ExpandedBlockStart.gif]: /images/20230810/ff6d902d0c52459bb99238048142f8d2.png
[600079-20190826104015429-942455156.png]: /images/20230810/4952cdb3e7e64736acfa2737827a3a3a.png
[600079-20190826110419942-1897892974.png]: /images/20230810/9c918d8e504345fc99813f126ec40e00.png
[https_github.com_Meituan-Dianping_Robust]: https://github.com/Meituan-Dianping/Robust
[https_github.com_JiaxtHome_hotfix]: https://github.com/JiaxtHome/hotfix