Android热修复Tinker原理分析

目录

1、tinker的class文件修复
2、tinker的资源文件修复
3、几种热修复方案对比

1、tinker的class文件修复

1.1、先说dex文件的加载和类的查找过程

1.1.1、dex文件的加载过程

Java层通过我们会通过创建一个DexClassLoader来加载我们的dex,下面就以此为切入点进行

dexClassLoader = new DexClassLoader(apkPath, getFilesDir().getAbsolutePath(), null, getClassLoader());

//查看DexClassLoader的构造方法。
public class DexClassLoader extends BaseDexClassLoader {
    // dexPath：是加载apk/dex/jar的路径
    // optimizedDirectory：是优化dex后得到的.odex文件的输出路径
    // libraryPath：是加载的时候需要用到的so库
    // parent：给DexClassLoader指定父加载器
    public DexClassLoader(String dexPath, String optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory), libraryPath, parent);
    }
}

//可以看到它调用的是父类的构造函数，所以直接来看BaseDexClassLoader的构造函数。
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
        String libraryPath, ClassLoader parent) {
    super(parent);
    this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
}

//创建了一个DexPathList实例，下面来看看DexPathList的构造函数。
private final Element[] dexElements;
public DexPathList(ClassLoader definingContext, String dexPath,
        String libraryPath, File optimizedDirectory) {
    ArrayList suppressedExceptions = new ArrayList();
    this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                                       suppressedExceptions);
}

//它调用的是makeDexElements方法来创建一个Element数组来存放Element对象，每个Element对象包含一个DexFile对象。
private static Element[] makeDexElements(ArrayList files, File optimizedDirectory,
                                         ArrayList suppressedExceptions) {
    ArrayList elements = new ArrayList();
    /*
     * Open all files and load the (direct or contained) dex files
     * up front.
     */
    for (File file : files) {
        File zip = null;
        DexFile dex = null;
        String name = file.getName();

        // 如果是一个dex文件
        if (name.endsWith(DEX_SUFFIX)) {
            // Raw dex file (not inside a zip/jar).
            try {
                dex = loadDexFile(file, optimizedDirectory);
            } catch (IOException ex) {
                System.logE("Unable to load dex file: " + file, ex);
            }
        // 如果是一个apk或者jar或者zip文件
        } else if (name.endsWith(APK_SUFFIX) || name.endsWith(JAR_SUFFIX)
                || name.endsWith(ZIP_SUFFIX)) {
            zip = file;

            try {
                // 1、调用loadDexFile加载dex文件，得到一个DexFile对象
                    loadDexFile通过c++层native方法去加载dex文件
                dex = loadDexFile(file, optimizedDirectory);
            } catch (IOException suppressed) {
               
                suppressedExceptions.add(suppressed);
            }
        } else if (file.isDirectory()) {
            elements.add(new Element(file, true, null, null));
        } else {
            System.logW("Unknown file type for: " + file);
        }
        
        // 2、把DexFile对象封装到Element对象中，然后将Element对象加入Element数组
        if ((zip != null) || (dex != null)) {
            elements.add(new Element(file, false, zip, dex));
        }
    }
    return elements.toArray(new Element[elements.size()]);
}

dex文件的加载流程：我们会使用DexClassLoader去加载dex文件，DexClassLoader会将这个任务委派给DexPathList中的makeDexElements方法，在makeDexElements中调用了native层的 c++方法去真正的加载dex文件，然后返回DexFile的对象，通过这个对象构建一个Element的对象，然后将这个Element添加到dexElements的数组中。

1.1.2、class文件的查找过程

//DexClassLoader间接调用父类findClass方法，findClass方法中调用DexPathList中的DexPathList方法
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(parent);
        this.originalPath = dexPath;
        this.pathList =
            new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }
    @Override
    protected Class findClass(String name) throws ClassNotFoundException {
        Class clazz = pathList.findClass(name);
        if (clazz == null) {
            throw new ClassNotFoundException(name);
        }
        return clazz;
    }

//看DexPathList中的findClass方法,可以看到它是遍历dexElements数组，到每个dex文件去寻找当前需要的类，找到之后直接返回不往下找了
    public Class findClass(String name) {
        for (Element element : dexElements) {
            DexFile dex = element.dexFile;
            if (dex != null) {
                Class clazz = dex.loadClassBinaryName(name, definingContext);
                if (clazz != null) {
                    return clazz;
                }
            }
        }
        return null;
    }

类的查找过程：DexClassLoader通过findClass去查找一个类，同样它也是委派给DexPathList的findClass去查找，在DexPathList的findClass中会去遍历我们上面创建的dexElements数组，然后在每个dex中去查找相应的类，找到之后就返回，不再向后查找。

1.2、Tinker中class修复过程

1.2.1、先看tinker-补丁包合成流程图

补丁包的合成流程：当tinker收到补丁包bug path后，它会开启一个service，和当前有问题的bug dex和成为一个新的fixed dex文件，然后置于tinker dex文件加载路径。

1.2.2、再看tinker-合成后的补丁包加载流程

补丁包的加载流程：获取到fixed dex文件后，通过反射DexPathList中的dexElements数组，将fixed dex插入到dexElements数组的最前面。classloader在寻找bug class的时候，找到的就是最前面的dex文件中我们已修复的fixed class。

2、tinker的资源文件修复

2.1、Context.getResources()

我们访问资源的时候通过Context.getResources()，获取Resources对象，然后通过Resources对象就可以访问各种资源了。
Context.getResources()流程
Context.getResources()获取的ContextImpl中的mResources对象。

mResources对象的获取过程

mResources是在activitythread初始化的时候获取的，具体是通过
ResourcesManager.getInstance().getResources(）去得到一个Resources。

这个方法的思想是这样的：在ResourcesManager中，所有的资源对象都被存储在ArrayMap中，首先根据当前的请求参数去查找资源，如果找到了就返回，否则就创建一个Resources对象返回，并且放到ArrayMap中。

为什么会有多个资源对象，因为不同分辨率、不同系统版本所对应的资源文件可以不同，比如折叠屏手机就有两个不同分辨率的屏幕对应，drawable-hdpi和drawable-xhdpi。

Resources对象的创建过程

public Resources(AssetManager assets, DisplayMetrics metrics, Configuration config)

 protected @Nullable AssetManager createAssetManager(@NonNull final ResourcesKey key) {
        AssetManager assets = new AssetManager();
        if (key.mResDir != null) {
            if (assets.addAssetPath(key.mResDir) == 0) {
                Log.e(TAG, "failed to add asset path " + key.mResDir);
                return null;
            }
        }

创建一个resource需要一个AssetManager， 然后通过AssetManager的addAssetPath去加载资源文件。
然后我们就可以通过resource访问各种资源文件了。

2.2、tinker的资源文件修复

 public static void monkeyPatchExistingResources(Context context, String externalResourceFile) throws Throwable {
   
final Field[] packagesFields;
        if (Build.VERSION.SDK_INT < 27) {
            packagesFields = new Field[]{packagesFiled, resourcePackagesFiled};
        } else {
            packagesFields = new Field[]{packagesFiled};
        }
//首先将activityThread中所有LoadApk中的resDir的值替换成新合成的资源文件路径
        for (Field field : packagesFields) {
            final Object value = field.get(currentActivityThread);

            for (Map.Entry> entry
                    : ((Map>) value).entrySet()) {
                final Object loadedApk = entry.getValue().get();
                if (loadedApk == null) {
                    continue;
                }
                final String resDirPath = (String) resDir.get(loadedApk);
                if (appInfo.sourceDir.equals(resDirPath)) {
                    resDir.set(loadedApk, externalResourceFile);
                }
            }
        }

// Create a new AssetManager instance 
 //创建一个新的AssetManager
        newAssetManager = (AssetManager) findConstructor(assets).newInstance();

// 并把资源补丁apk加载进新的 AssetManager 中
        if (((Integer) addAssetPathMethod.invoke(newAssetManager, externalResourceFile)) == 0) {
            throw new IllegalStateException("Could not create new AssetManager");
        }

//循环替换ResourcesManager中所有Resources对象的AssetManager。
        for (WeakReference wr : references) {
            final Resources resources = wr.get();
            if (resources == null) {
                continue;
            }
            try {
        // 把原来 resources 的 mAssets 属性替换成新的 AssetManager 对象
                assetsFiled.set(resources, newAssetManager);
            } catch (Throwable ignore) {
            }

            clearPreloadTypedArrayIssue(resources);
    // 最后调用 updateConfiguration 方法来确保资源更新了
            resources.updateConfiguration(resources.getConfiguration(), resources.getDisplayMetrics());
        }

1、首先将activityThread中所有LoadApk中的resDir的值替换成新合成的资源文件路径（获取Resources时，会以LoadApk中的resDir作为key去ResourcesManager中获取）
2、创建一个新的AssetManager，并把资源补丁apk加载进新的 AssetManager 中
3、将ResourcesManager中所有Resources对象中AssetManager替换成我们新建的AssetManager，那么所有的Resources对象获取到的都是新合成的资源文件。

3、几种热修复方案对比

Andfix、QQ控件热修复、Tinker。

3.1、Andfix

aandfix功能比较单一，只能修复方法，大致原理就是在运行时通过在native层去将bug方法替换成修复的方法。这样导致了两个问题：1、由于运行时，class已经加载，其field数值无法改变（要是能改变，通过这个class创建的对象就失效了），故其不能增加或者减少成员变量；2、因为是动态的，跳过了类的初始化，所以对于静态方法、静态成员变量、构造方法处理可能会有问题，另外增加类也是不可能的；3、由于其采用在native层去进行方法替换，不同厂商手机可能对native层代码做修改，故其兼容性可能较差。基于以上3个缺点，由于我们的app对兼容性要求较高，且可能对方法之外的地方做修改，所以Andfix是不满足我们的需求的。

andfix修复方法的前提是对bug方法修复之后使用注解进行标记（bug类名和bug方法名），然后将这个补丁文件记录在一个patch.mf的文件中。

3.2、QQ空间的热修复方案

QQ空间的热修复方案和Tinker方案较为类似，都是通过操作dexElements数组替换有问题的class来实现的，不同的是Tinker时将差分包和有问题的dex文件合成一个新的 fix dex插入到dexElements数组前面的，而QQ空间的热修复方案是直接将差分包，插入到dexElements的前面。会导致引用类和直接被引用类不在同一个dex的错误：

dex文件转化成odex文件期间会经历两个阶段：pre_verified和optimize，pre_verified会判断一个类的直接引用类是否和它在同一个dex文件，如果是，这个类就会被打上CLASS_ISPREVERIFIED，在optimize会根据这个标记去对这个类做指令优化。但是在类加载的时候，也会去判断这个类和其直接引用类是否在同一个dex，如果不在则报错。
如果一个直接被引用类是我们修复的方法，按照qq空间的修复方案，它和其引用类就会处于不同的dex文件，那么类加载的时候就会报错。

dex文件在dalvik执行之前会转化成odex文件，在这个过程中会对dex中每个类做一个检验：如果引用类（A）的直接引用的类（B）和这个类(A)在同一个dex，这个引用类（A）会被打上CLASS_ISPREVERIFIED标记，在类加载的时候，就会去判断类(A)和被引用类是否在一个dex，不在，则报错。
如果这个被引用类（B）是我们修复的方法，它就会和其引用类（A）处于不同的dex文件，那么类加载的时候就会报错。

QQ空间的热修复方案的解决方法是，使用aop在每个类的构造函数，引用了一个特殊的类（C），在编译的时候将这个类打进一个单独dex文件，这样所有的类在dex转化成odex的过程中都不会被打上标记，这样就避免了上述错误的发生。

但是这样有一个问题，如果在dex转化成odex期间，不做pre_verified和optimize两步，那么这这两步将推迟到类加载的阶段，会拖慢类加载的速度。
另外采用javassist进行字节码操作速度慢，会拖慢编译速度。
故淘汰了QQ空间的热修复方案。

3.3、Tinker3.4、tinker的其他优点

1、Tinker的覆盖比较全面，对class、资源文件、so文件都支持，
2、另外它比较容易扩展，在修复的各个阶段都提供了listener，我们可以重写这个listener，去监听修复的各个阶段。

3.4、Tinker的缺点

它的问题在于
1、由于Tinker采用的将fix dex 插入到dexElements最前面的方式去修复bug，所有它需要重启，不能即时生效。
2、Tinker在下发path的时候需要启动一个service去将path和有问题的dex文件合成一个新的dex文件，这个过程是对性能影响较大的，但是合成只需要一次，后续就不需要了，这样的性能损耗还是可以接受的；