• 热修复之原理2


    1.热修复框架的对比?

    热修复框架的种类繁多,按照公司团队划分主要有以下几种:

    阿里系 AndFix、Dexposed、阿里百川、Sophix
    腾讯系 微信的Tinker、QQ空间的超级补丁、手机QQ的QFix
    知名公司 美团的Robust、饿了么的Amigo、美丽说蘑菇街的Aceso
    其他 RocooFix、Nuwa、AnoleFix

    虽然热修复框架很多,但热修复框架的核心技术主要有三类,分别是代码修复、资源修复和动态链接库修复。

    虽然很多热修复框架采用了类加载方案,但具体的实现细节和步骤还是有一些区别的,

    比如QQ空间的超级补丁和Nuwa是按照上面说得,将补丁包 放在Element数组的第一个元素得到优先加载。

    微信Tinker将新旧apk做了diff,得到patch.dex,然后将patch.dex与手机中apk的classes.dex做合并,生成新的classes.dex,然后在运行时通过反射将classes.dex放在Element数组的第一个元素。

    饿了么的Amigo则是将补丁包中每个dex 对应的Element取出来,之后组成新的Element数组,在运行时通过反射用新的Element数组替换掉现有的Element 数组。

    采用类加载方案的主要是以腾讯系为主,包括微信的Tinker、QQ空间的超级补丁、手机QQ的QFix、饿了么的Amigo和Nuwa等等。
    ————————————————

    2.1 底层替换方案
    与类加载方案不同的是,底层替换方案不会再次加载新类,而是直接在Native层修改原有类,由于是在原有类进行修改限制会比较多,不能够增减原有类的方法和字段,如果我们增加了方法数,那么方法索引数也会增加,这样访问方法时会无法通过索引找到正确的方法,同样的字段也是类似的情况。

    底层替换方案和反射的原理有些关联,就拿方法替换来说,方法反射我们可以调用java.lang.Class.getDeclaredMethod,

    假设我们要反射Key的show方法,会调用如下所示。

    Key.class.getDeclaredMethod("show").invoke(Key.class.newInstance());
    Android 8.0的invoke方法。
    libcore/ojluni/src/main/java/java/lang/reflect/Method.java

    @FastNative
    public native Object invoke(Object obj, Object... args)
    throws IllegalAccessException, IllegalArgumentException, InvocationTargetException;

     
    invoke方法是个native方法,对应Jni层的代码为:
    art/runtime/native/java_lang_reflect_Method.cc

    static jobject Method_invoke(JNIEnv* env, jobject javaMethod, jobject javaReceiver,
    jobject javaArgs) {
    ScopedFastNativeObjectAccess soa(env);
    return InvokeMethod(soa, javaMethod, javaReceiver, javaArgs);
     
    Method_invoke函数中又调用了InvokeMethod函数:
    art/runtime/reflection.cc

    jobject InvokeMethod(const ScopedObjectAccessAlreadyRunnable& soa, jobject javaMethod,
    jobject javaReceiver, jobject javaArgs, size_t num_frames) {

    ...
    ObjPtr<mirror::Executable> executable = soa.Decode<mirror::Executable>(javaMethod);
    const bool accessible = executable->IsAccessible();
    ArtMethod* m = executable->GetArtMethod();//1
    ...
    }
     
    注释1处获取传入的javaMethod(Key的show方法) 在ART虚拟机中对应的一个ArtMethod指针,

    ArtMethod结构体中包含了Java方法的所有信息,包括执行入口、访问权限、所属类和代码执行地址等等,ArtMethod结构如下所示。

    art/runtime/art_method.h

    class ArtMethod FINAL {
    ...
    protected:
    GcRoot<mirror::Class> declaring_class_;
    std::atomic<std::uint32_t> access_flags_;
    uint32_t dex_code_item_offset_;
    uint32_t dex_method_index_;
    uint16_t method_index_;
    uint16_t hotness_count_;
    struct PtrSizedFields {
    ArtMethod** dex_cache_resolved_methods_;//1
    void* data_;
    void* entry_point_from_quick_compiled_code_;//2
    } ptr_sized_fields_;
    }
     

    注释1处获取传入的javaMethod(Key的show方法) 在ART虚拟机中对应的一个ArtMethod指针,

    ArtMethod结构体中包含了Java方法的所有信息,包括执行入口、访问权限、所属类和代码执行地址等等,ArtMethod结构如下所示。


    ArtMethod结构中比较重要的字段是注释1处的dex_cache_resolved_methods_和注释2处的entry_point_from_quick_compiled_code_,它们是方法的执行入口,

    当我们调用某一个方法时(比如Key的show方法),就会取得show方法的执行入口,通过执行入口就可以跳过去执行show方法。
    替换ArtMethod结构体中的字段或 者替换整个ArtMethod结构体,这就是底层替换方案。

    AndFix采用的是替换ArtMethod结构体中的字段,这样会有兼容问题,因为厂商可能会修改ArtMethod结构体,导致方法替换失败。

    Sophix采用的是替换整个ArtMethod结构体,这样不会存在兼容问题。
    底层替换方案直接替换了方法,可以立即生效不需要重启。采用底层替换方案主要是阿里系为主,包括AndFix、Dexposed、阿里百川、Sophix。

    3.3 Instant Run方案
    除了资源修复,代码修复同样也可以借鉴Instant Run的原理, 可以说Instant Run的出现推动了热修复框架的发展。
    Instant Run在第一次构建apk时,使用ASM在每一个方法中注入了类似如下的代码:

    IncrementalChange localIncrementalChange = $change;//1
    if (localIncrementalChange != null) {//2
    localIncrementalChange.access$dispatch(
    "onCreate.(Landroid/os/Bundle;)V", new Object[] { this,
    paramBundle });
    return;
    }
     
    其中注释1处是一个成员变量localIncrementalChange ,它的值为$change,$change实现了IncrementalChange这个抽象接口。

    当我们点击InstantRun时,如果方法没有变化则$change为null,就调用return,不做任何处理。如果方法有变化,就生成替换类,这里我们假设MainActivity的onCreate方法做了修改,就会生成替换类MainActivity$override,这个类实现了IncrementalChange接口,同时也会生成一个AppPatchesLoaderImpl类,这个类的getPatchedClasses方法会返回被修改的类的列表(里面包含了MainActivity),根据列表会将MainActivity的$change设置为MainActivity$override,因此满足了注释2的条件,会执行MainActivity$override的access$dispatch方法,accessdispatch方法中会根据参数&quot;onCreate.(Landroid/os/Bundle;)V&quot;执行‘MainActivitydispatch方法中会根据参数&quot;onCreate.(Landroid/os/Bundle;)V&quot;执行`MainActivitydispatch方法中会根据参数"onCreate.(Landroid/os/Bundle;)V"执行‘MainActivityoverride`的onCreate方法,从而实现了onCreate方法的修改。
    借鉴Instant Run的原理的热修复框架有Robust和Aceso。
     

    ————————————————

    代码修复
    代码修复主要有三个方案,分别是底层替换方案、类加载方案和Instant Run方案。

    3.1 类加载方案
    类加载方案基于Dex分包方案,什么是Dex分包方案呢?这个得先从65536限制和LinearAlloc限制说起。
    65536限制
    随着应用功能越来越复杂,代码量不断地增大,引入的库也越来越多,可能会在编译时提示如下异常:

    com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536
    1
    这说明应用中引用的方法数超过了最大数65536个。产生这一问题的原因就是系统的65536限制,65536限制的主要原因是DVM Bytecode的限制,

    DVM指令集的方法调用指令invoke-kind索引为16bits,最多能引用 65535个方法。
    LinearAlloc限制
    在安装时可能会提示INSTALL_FAILED_DEXOPT。产生的原因就是LinearAlloc限制,DVM中的LinearAlloc是一个固定的缓存区,当方法数过多超出了缓存区的大小时会报错。

    为了解决65536限制和LinearAlloc限制,从而产生了Dex分包方案。

    Dex分包方案主要做的是在打包时将应用代码分成多个Dex,将应用启动时必须用到的类和这些类的直接引用类放到主Dex中,其他代码放到次Dex中。

    当应用启动时先加载主Dex,等到应用启动后再动态的加载次Dex,从而缓解了主Dex的65536限制和LinearAlloc限制。

    Dex分包方案主要有两种,分别是Google官方方案、Dex自动拆包和动态加载方案。因为Dex分包方案不是本章的重点,这里就不再过多的介绍,我们接着来学习类加载方案。

    ————————————————
     在Android解析ClassLoader(二)Android中的ClassLoader中讲到了ClassLoader的加载过程,其中一个环节就是调用DexPathList的findClass的方法,如下所示。

    Element内部封装了DexFile,DexFile用于加载dex文件,因此每个dex文件对应一个Element。
    多个Element组成了有序的Element数组dexElements。当要查找类时,会在注释1处遍历Element数组dexElements(相当于遍历dex文件数组),注释2处调用Element的findClass方法,其方法内部会调用DexFile的loadClassBinaryName方法查找类。如果在Element中(dex文件)找到了该类就返回,如果没有找到就接着在下一个Element中进行查找。
    根据上面的查找流程,我们将有bug的类Key.class进行修改,再将Key.class打包成包含dex的补丁包Patch.jar,放在Element数组dexElements的第一个元素,这样会首先找到Patch.dex中的Key.class去替换之前存在bug的Key.class,排在数组后面的dex文件中的存在bug的Key.class根据ClassLoader的双亲委托模式就不会被加载,这就是类加载方案,如下图所示。


    类加载方案需要重启App后让ClassLoader重新加载新的类,为什么需要重启呢?这是因为类是无法被卸载的,因此要想重新加载新的类就需要重启App,因此采用类加载方案的热修复框架是不能即时生效的。
    ————————————————  

    三、阿里百川HotFix
    阿里百川推出的热修复HotFix服务,相对于QQ空间超级补丁技术和微信Tinker来说,定位于紧急BUG修复的场景下,能够最及时的修复BUG,下拉补丁立即生效无需等待。
    图片描述
    1、AndFix实现原理
    AndFix不同于QQ空间超级补丁技术和微信Tinker通过增加或替换整个DEX的方案,提供了一种运行时在Native修改Filed指针的方式,实现方法的替换,达到即时生效无需重启,对应用无性能消耗的目的。
    原理图如下:
    图片描述
    2、AndFix实现过程

    对于实现方法的替换,需要在Native层操作,经过三个步骤:
    图片描述
    接下来以Dalvik设备为例,来分析具体的实现过程:

    AndFix对ART设备同样支持,具体的过程与Dalvik相似,这里不再赘述。

    从技术原理,不难看出阿里百川HotFix的几个特点:

    优势:

      1. BUG修复的即时性

      2. 补丁包同样采用差量技术,生成的PATCH体积小

      3. 对应用无侵入,几乎无性能损耗
        不足:

      4. 不支持新增字段,以及修改<init>方法,也不支持对资源的替换。

      5. 由于厂商的自定义ROM,对少数机型暂不支持。

    二、微信Tinker
    微信针对QQ空间超级补丁技术的不足提出了一个提供DEX差量包,整体替换DEX的方案。主要的原理是与QQ空间超级补丁技术基本相同,

    区别在于不再将patch.dex增加到elements数组中,而是差量的方式给出patch.dex,然后将patch.dex与应用的classes.dex合并,

    然后整体替换掉旧的class.dex文件,以达到修复的目的。
    图片描述
    我们来逆向微信的APK看一下具体的实现:

    从代码中可以看到, 通过反射 操作得到PathClassLoader的DexPatchList, 反射调用patchlist的makeDexElements()方法,

    把本地的dex文件直接替换到Element[]数组中去,达到修复的目的。

    对于如何进行patch.dex与classes.dex的合并操作,这里微信开启了一个新的进程,开启新进程的服务TinkerPatchService 进行合并。
    图片描述
    整体的流程如下:
    图片描述
    从流程图来看,同样可以很明显的找到这种方式的特点:
           优势:

      1. 合成整包,不用在构造函数插入代码,防止verify,verify和opt在编译期间就已经完成,不会在运行期间进行。

      2. 性能提高。兼容性和稳定性比较高。

      3. 开发者透明,不需要对包进行额外处理。

             不足:

      1. 与超级补丁技术一样,不支持即时生效,必须通过重启应用的方式才能生效。

      2. 需要给应用开启新的进程才能进行合并,并且很容易因为内存消耗等原因合并失败。

      3. 合并时占用额外磁盘空间,对于多DEX的应用来说,如果修改了多个DEX文件,就需要下发多个patch.dex与对应的classes.dex进行合并操作时这种情况会更严重,因此合并过程的失败率也会更高。

    一、QQ空间超级补丁技术
    超级补丁技术基于DEX分包方案,使用了多DEX加载的原理,大致的过程就是:把BUG方法修复以后,放到一个单独的DEX里,插入到dexElements数组的最前面,让虚拟机去加载修复完后的方法。
    图片描述
    当patch.dex中包含Test.class时就会优先加载,在后续的DEX中遇到Test.class的话就会直接返回而不去加载,这样就达到了修复的目的。

    但是有一个问题是,当两个调用关系的类不在同一个DEX时,就会产生异常报错。我们知道,在APK安装时,虚拟机需要将classes.dex优化成odex文件,然后才会执行。在这个过程中,会进行类的verify操作,如果调用关系的类都在同一个DEX中的话就会被打上CLASS_ISPREVERIFIED的标志,然后才会写入odex文件。

    所以,为了可以正常地进行打补丁修复,必须避免类被打上CLASS_ISPREVERIFIED标志,具体的做法就是单独放一个类在另外DEX中,让其他类调用。

    修复的步骤为:

    1. 可以看出是通过获取到当前应用的Classloader,即为BaseDexClassloader

    2. 通过反射获取到他的DexPathList属性对象pathList

    3. 通过反射调用pathList的dexElements方法把patch.dex转化为Element[]

    4. 两个Element[]进行合并,把patch.dex放到最前面去

    5. 加载Element[],达到修复目的

    整体的流程图如下:
    图片描述
    从流程图来看,可以很明显的找到这种方式的特点:
    优势:

    1. 没有合成整包(和微信Tinker比起来),产物比较小,比较灵活

    2. 可以实现类替换,兼容性高。(某些三星手机不起作用)
      不足:

    3. 不支持即时生效,必须通过重启才能生效。

    4. 为了实现修复这个过程,必须在应用中加入两个dex!dalvikhack.dex中只有一个类,对性能影响不大,但是对于patch.dex来说,修复的类到了一定数量,就需要花不少的时间加载。对手淘这种航母级应用来说,启动耗时增加2s以上是不能够接受的事。

    5. 在ART模式下,如果类修改了结构,就会出现内存错乱的问题。为了解决这个问题,就必须把所有相关的调用类、父类子类等等全部加载到patch.dex中,导致补丁包异常的大,进一步增加应用启动加载的时候,耗时更加严重。

  • 相关阅读:
    Kubelet 会做些什么
    k8s apiserver 源码阅读笔记
    robotframework环境安装
    Hper-V卸载
    Hyper-V安装虚拟机
    git下载/上传文件提示:git did not exit cleanly
    jmeter使用csv传参进行并发测试验证
    jenkins启动
    win7系统中 python2、python3安装后再安装插件时遇到的问题
    Base.py最基层的一些方法的封装--自己整理的一些小内容
  • 原文地址:https://www.cnblogs.com/awkflf11/p/12555754.html
Copyright © 2020-2023  润新知