一、背景

App热更新

目前市面上成熟的商业热更新方案不少，有腾讯Bugly的Tinker封装，有阿里云的Sophix，也有游戏垂直行业的卓盟乐变。这些成熟方案，都有一个适用范围，即对App、对游戏整包进行热更新。前两者是和包名绑定在一起的，所以只适用于App热更新；而卓盟乐变则专注于游戏行业，可支持多渠道包热更新。其实最好的还是Sophix，可惜没有开源，虽有公开原理，但是公开资料里也透露了探索与开发周期长达9个月。

在社区，比较流行的热更新有Tinker、QZone、AndFix(HotFix)、Sophix、Robust、Dexposed、Nuwa、Amigo，同商业热更新方案一样，也是适用于App整包热更新。在这些方案里，影响力最大的是微信的Tinker方案，13048个Star，拥有完善的文档，整个框架注重高可用性，最重要的是官方持续维护，在2018年12月，merge7次。相比之下，其他有在Github上开源的框架，star数都是7000以下，上次更新时间都在1年前，甚至2年前。

SDK热更新

SDK热更新，这是一个极少被关注的问题，Google、百度上相关的文章一篇都没有。我们首先进行思考，SDK热更新同App热更新有什么不同？，SDK热更新要做什么？

SDK热更新同App热更新有什么不同？

App热更新，输入的是一个基准包和一个新版包，输出的是差分包（或补丁），将这个差分包（或补丁）下载到客户端，客户端加载后生效。
SDK热更新，输入的是一个基准SDK和一个新版SDK，输出的也是差分包（或补丁），不同的是，SDK会被集成到不同的游戏包中，这个游戏包也会被分成各式各样的渠道包，我们要将这个差分包（或补丁）下载到所有游戏、所有渠道包，并加载生效。

SDK热更新要做什么？

1. 对SDK的代码、资源进行标识，我们要进行热更新的对象，就是这些代码、资源。

比如，我们可以进行这样标识：所有在com.divin.包名之下的java类，所有assets/divin/文件夹之下的Assets文件，所有以divin_开头的Res文件，所有/res/values/文件，所有以divin_开头的so文件。

2. 在热更新的整个流程，对上述代码、资源进行特别操作。

包括build(计算差分)、patch(合并差分)、load(加载差分)。

十分感谢微信Tinker的开源，对外开放了完整的热更新过程，站在伟人肩上，下面的SDK热更新，都是基于Tinker开源库进行的修改。

热更新重点

1. dex热更新，即Java代码热更新。

阿里系(AndFix,Hotfix)走的底层替换方案，好处在于实时生效，腾讯系(Tinker)走的是类加载方案，好处在于高兼容性。阿里百川系（Sophix）就有点机智了，两种方案都有使用，还进行了一定的升级，优先走底层替换方案，底层替换方案走不下去了就走类加载方案。

AndFix(HotFix)的底层替换方案已过时，Sophix的无视底层具体结构的底层替换方案较新。感兴趣的同学可以深入了解下，追寻极致的代码热替换。

Tinker的类加载方案，需要重启应用后让Classloader去加载新类。因为Android上无法对一个类进行卸载，不重启，则无法加载新类。

2. 资源文件热更新。

这里也是有两个流派，一个流派是参考Instant Run通过addAssetPath加载新的资源包到AssetsManager，然后再替换Resource中的AssetsManager；一个流派是构造新的R文件资源地址以0x66开头的资源包，再通过addAssetPath加载新的资源包到AssetsManager，因为新的R文件资源地址以0x66开头，新的Java代码里，也引用0x66开头的资源，这样就可以新旧资源不干扰且都能生效。

Tinker属于第一个流派，Sophix属于第二个流派。

非常遗憾的是，在我们基于Tinker实现SDK资源更新（即指定资源更新）时，只知道第一个流派，并不知道第二个流派（那篇文章没细读，印象不深）。所以后文中所提到的SDK资源更新（指定资源更新），其实是自己摸索出来的，可以理解成流派二的拼多多版，实现了资源新增、更改，但暂未支持R文件直接引用。

3. so文件热更新。

说到这里，是真感谢这世界上有数组这玩意。so文件的热更新，也是把补丁so库的路径插入到nativeLibraryDirectories数组的最前面。

二、Tinker

开源

Tinker已开源，Tencent/tinker，同时有详细的使用Wiki，Tinker使用Wiki。

热更新过程

Tinker的整个热更新过程，可以理解成四个步骤。

1. Tinker集成

集成Tinker分两大块，一块是Application改造，一块是定制化功能。第一块较为简单，使用Annotation Processor在编译时生成新Application；第二块非常复杂。

2. build(计算差分)

build有两种模式，一种是供Android Studio开发使用的Gradle模式，一种是使用Java实现的命令行模式。二者最底层，其实都是使用的tinker-patch-lib，一个用Java实现的核心库。

3. patch(合并差分)

4. load(加载差分)

源码结构

Tinker的源码分为这么几大块：

1. tinker-sample-android

顾名思义，这是一个demo，庞大！庞大！庞大！从未见过一个第三方SDK，暴露了如此多的api，可以定制如此多的功能！难怪Sophix在其官方文档中对热更新方案做横向对比时，把自己描述为“傻瓜式接入”，把Amigo描述为“一般”，却把Tinker描述为“复杂”。其实微信官方也有描述，Tinker为了实现“高可用”的目标，在接入成本上做了妥协。热补丁并不简单，在使用之前请务必先仔细阅读XXXX。总的来说，感谢腾讯baba。

demo里，示例了：

①如何控制热更新的请求过滤、合并过程、加载过程、合并后的后续处理、升级热更新模块本身的代码。

②如何改造Application。

③Gradle集成模式的42个参考配置。 42个参考配置！42个参考配置！42个参考配置！

这里让大家放心的是，复杂的是Tinker的定制化开发，而不是给到cp的SDK。我们可以对外隐藏这些定制化开发的细节。

2. tinker-build

这是热更新过程中build步骤的源码，有三个子模块，tinker-patch-lilb是核心代码，tinker-patch-cli是命令行模式的源码，tinker-patch-gradle-plugin是Gradle模式的源码。

3. tinker-android

这是热更新过程中patch和load步骤的源码，随Apk、游戏运行在客户端。也有Application改造时用到的Annotation Processor库的源码。

4. tinker-commons

tinker-build所用到的基础库。

5. third-party

tinker-build所用到的第三方库。

三、SDK热更新实现

1. 指定代码热更新。

我们回顾热更新的4个步骤，第二个步骤是build(计算差分)，输入的是一个基准包和一个新版包，输出的是差分包（或补丁）。如果在这个核心算法的里，增加一项功能，只比对SDK的代码，不比对游戏的代码，是不是就可行了呢？

这种思路，有一点点站在业务层反推实现方案的嫌疑。但最后实践检验，还真可以这样。

我们回顾demo中的一项功能，升级热更新模块本身的代码，那Tinker如何去实现这一个功能的呢？Tinker通过一个配置表来配置热更新模块本身的代码。

这里的配置是支持Pattern的。

把游戏的代码也当热更新模块本身的代码配置，是否OK？

结果是不OK。能够build，但是不能patch、load。

网上所有的博客，其实都有提到Tinker自研了一套dex diff、patch的算法，可以高效地比对出差分包，并在客户端patch出目标dex包。难道是Tinker这一套算法不支持这样地添加非热更新模块代码？

这时候我们回过头理解这一套dex diff、patch算法，也许你都还用不上深入理解，看到上面的几行字，说不定就能发现玄妙。有兴趣可以把视野停在此处思考一下。

Tinker的dex diff、patch算法，说到底，就是一个可逆的过程，先计算两个包的区别特征，再通过一个包以及区别特征，来推出另一个包。这套算法是从dex的方法和指令维度进行全量合成。

用简单的公式来表示：

服务端diff: New.dex - base.dex = patch.file

客户端patch: base.dex + patch.file = New.dex

在上面的尝试中，客户端patch所用到的base.dex，已经不是服务端diff所用到的base.dex了。前者是游戏包的dex，后者是SDK的dex。

摆在我们面前的选择只有两个，一个是理解并修改这套算法，另一个是，另辟蹊径。但前者，显然不是3、5天调研时间能完成的。

柳暗花明又一村~

调试源码时，发现了这玩意：

@Override
public void onAllPatchesEnd() throws Exception {
    if (!hasDexChanged) {
        Logger.d("No dexes were changed, nothing needs to be done next.");
        return;
    }
    if (config.mIsProtectedApp) {
        generateChangedClassesDexFile();
    } else {
        generatePatchInfoFile();
    }

    addTestDex();
}

超想用抖音的BGM描述一下内心的心情，“这是什么造型，挺别致哦~”

在开发者配置isProtectedApp的true或false时，其实Tinker走了两套不一样的差分算法。false时，走Tinker自研的差分算法；true时，走常规的差分算法。

这套差分算法是基于Class类的，可以被客户端patch、load的。

接着，就是对配置表loader配置的复刻了，这里思路比较清晰，增加一个isSDKMode配置，如果为true则走SDK模式，不去读loader配置，而去读loader配置的复刻字段sdkPackage，用来填写需要更新的SDK代码。我们SDK是com.divin.*。

搞定！

2. 指定资源文件热更新。

我们先说一下不同资源，在Apk包中的目录结构。

解压缩Apk包后，根目录下有assets和res文件夹。如果你用这个Apk包的目录结构和Android工程源码的目录结构做对比，assets中的内容是一一对应的，Apk包的res文件夹也能Android工程源码的res中资源一一对应起来，但是会少了Android工程源码的res/values文件夹下的文件。

这些res/values文件去哪儿了呢？

resources.arsc

所以，指定资源文件热更新要分两大块，一块是不能一一对应上的res/values文件，一块是能一一对应上的assets文件和res文件。

不能一一对应上的res/values文件

重述一下，Android工程源码中，不能一一对应上的res/values文件，到Apk文件目录的resources.arsc文件中去了。

我们回顾Tinker更新步骤，第2步build，通过diff算法生成差分包，第3步patch，通过patch算法生成新的res资源包，第4步load，加载新的res资源包。

用SDK的resources.arsc生成差分包，再用游戏的旧resources.arsc计算新的resources.arsc？

这样，又面临我们做指定代码热更新时面临的问题。摆在我们面前的选择只有两个，一个是理解并修改这套算法，另一个是，另辟蹊径。

What?? 逼我们上梁山？？

这里面临两个问题：

我们无法计算出新的resources.arsc文件。
就算计算出来了也没用，因为resources.arsc不仅有SDK的资源，还有游戏的资源。使用SDK的resources.arsc文件，必然会让游戏因找不到资源而崩溃！

车到山前必有路，逐个击破！

第一个问题。 其实Res资源也是有两种算法，一种是Tinker自研的diff、patch算法，一种是不计算差分，完整下载，完整加载。具体到每一个资源，到底走哪种算法，其实是根据资源的大小做的判断，默认是100kb以下的完整下载、完整加载，100kb以上的走自研的diff、patch算法。

那我们就强行走第二种算法，这里要做的事情有二件：

控制差分的判断逻辑，强行走第二种算法。
修改patch时的CSC、md5完整性判断逻辑。（TODO：预研时，我是直接去掉了，实际业务中，需要增加新的完整性判断逻辑）

第二个问题。我们细读Tinker的资源load流程，它生效的原理是Instant Run那一套流派一。

流派一原理简述如下：

先获取默认的AssetManager，通过反射获取其构造方法
通过AssertManager的addAssetPath函数，加入外部的资源路径
将Resources的mAssets的字段设为前面的AssertManager

这一套，所实现的效果，就是用addAssetPath用新的Res资源包替换原来的Res资源包。慢着，add，Asset，Path，添加资源目录，能不能添加多个呢？

看Android源码找找希望吧。

    /**
     * @deprecated Use {@link #setApkAssets(ApkAssets[], boolean)}
     * @hide
     */
    @Deprecated
    @UnsupportedAppUsage
    public int addAssetPath(String path) {
        return addAssetPathInternal(path, false /*overlay*/, false /*appAsLib*/);
    }


    private int addAssetPathInternal(String path, boolean overlay, boolean appAsLib) {
        Preconditions.checkNotNull(path, "path");
        synchronized (this) {
            ensureOpenLocked();
            final int count = mApkAssets.length;

            // See if we already have it loaded.
            for (int i = 0; i < count; i++) {
                if (mApkAssets[i].getAssetPath().equals(path)) {
                    return i + 1;
                }
            }

            final ApkAssets assets;
            try {
                if (overlay) {
                    // TODO(b/70343104): This hardcoded path will be removed once
                    // addAssetPathInternal is deleted.
                    final String idmapPath = "/data/resource-cache/"
                            + path.substring(1).replace('/', '@')
                            + "@idmap";
                    assets = ApkAssets.loadOverlayFromPath(idmapPath, false /*system*/);
                } else {
                    assets = ApkAssets.loadFromPath(path, false /*system*/, appAsLib);
                }
            } catch (IOException e) {
                return 0;
            }

            mApkAssets = Arrays.copyOf(mApkAssets, count + 1);
            mApkAssets[count] = assets;
            nativeSetApkAssets(mObject, mApkAssets, true);
            invalidateCachesLocked(-1);
            return count + 1;
        }
    }

BGM再来一次，“这是什么造型，挺别致哦~”

mApkAssets，伟大的数组！

获取新的AssetsManager，先添加热更新的新Res资源，再添加游戏原本的旧Res资源。这样，会先去第一个Res中找资源，第一个Res中找不到再去第二个Res中找。

所以，这里是能实现对SDK资源的新增、修改，但是不能删去资源，同时也不支持R文件直接引用，因为R文件的地址是常量，在Apk编译时，这些常量会跟着引用R文件的业务Class走。如果想保持R文件的地址不变，可以修改APT编译器，也能通过Apktool来做，当然还有上面提到的资源热更新流派二。

能一一对应上的assets文件和res文件。

这里实现起来，其实和代码热更新有些相似。Tinker默认有这样的配置表：

增加一个isSDKMode配置，如果为true则走SDK模式，不去读ignoreChange配置，而去读ignoreChange配置的复刻字段sdkResPath，

至于差分算法，倒是没有什么问题。不论是Tinker自研的diff、patch算法，还是完整下载、完整加载，都可行，毕竟要更新的文件都是SDK独有的，游戏并没有共用。当然啦，使用Tinker自研的diff、patch算法肯定是最好的，毕竟可以减小差分包大小。

3. 指定so文件热更新。

略。

四、效果

SDK热更新范围

代码: 所有在com.divin.包名之下的java类
assets: 所有assets/divin/文件夹之下的文件
普通Res: 所有以divin_开头的文件
/res/values/: 所有文件, 但是只能实现增加/更改values,不能实现删除values.
so库: 以divin_开头的so文件

SDK热更新限制

无法更新AndroidManifest
在部分三星android-21的机型上无法生效
资源替换不支持远程View, 如应用icon.
不支持SDK直接R文件引用资源

集成配置

1. app.gradle

dependencies {
    // tinker-android-lib(本地module) 为必须依赖
    // anno为可选依赖，用于使用AnnotationProcessor生成Application
    //implementation("com.tencent.tinker:tinker-android-lib:${TINKER_VERSION}") { changing = true }
    implementation project(':tinker-android::tinker-android-lib')
    annotationProcessor("com.tencent.tinker:tinker-android-anno:${TINKER_VERSION}") { changing = true }
    compileOnly("com.tencent.tinker:tinker-android-anno:${TINKER_VERSION}") { changing = true }
}

2. 修改Application

参考SampleApplicationLike.java改造Application.

3. 更新

TinkerLogic.patch(Context context)

写博客嘛，交个朋友！

↓来来来，点一点小爱心。爱心是动力~

基于Tinker的SDK全局热更新方案（全网唯一）