背景

热修复早已不是什么新鲜技术了，各个大厂基本都有自己的热修复方案。
关于各个热修方案的对比就不赘述了，网上一搜一大堆。直接看Tinker官方文档 就行。

这里说下为什么选择Tinker吧
先说优点

1. 开源免费，讲道理，要不是免费肯定用集成起来更简单的Sophix了
2. 目前仍处于维护状态
3. 腾讯背书，官方说微信也在用，那我们自然没什么好顾虑的了

说完优点再吐槽下缺点

1. 文档基本没怎么更新了，项目稍微新一点的集成起来需要踩坑
2. demo比较老，agp版本很低
3. 集成使用比较麻烦，代码量相较于常规的其它三方sdk多很多
4. 处于open状态的issues数量比较多，开源项目遇到奇奇怪怪的问题只能尽量自己解决，肯定不会像商业sdk有技术快速支持的。
5. 补丁的版本管理和维护需要自己搭建

集成步骤

这里我说下我自己比较推荐的集成步骤

1. 先把源码下载下来，跑通，能够在demo上实现热修的功能
2. 新建一个干净的空项目，从0开始集成tinker，同样要实现热修的功能
3. 最后再往自己的项目中集成

集成步骤官方文档写的也比较清楚了，只是demo的agp版本比较老，一些配置的增加也没有在文档中更新。因此，在高版本的AGP项目中集成起来还是要踩一些坑的。

这里我把我集成tinker时踩的坑记录一下，有些坑也花了点时间去解决，希望能帮到需要的同学。
先说下我的AGP版本，这个可能会影响到Tinker

1. AGP版本是7.0.4
2. gradle版本是7.3.3
3. tinker用的就是最新的版本（目前是：v1.9.14.25.3）

AGP7.x 配置Tinker

我们都知道AGP7开始，之前的classpath配置有所变更，如果你是AGP7以上的版本，需要在settings.gradle添加tinker的配置

pluginManagement {
    
    repositories {
    
        google()
        mavenCentral()
        gradlePluginPortal()
    }

    resolutionStrategy {
    
        /*配置tinker*/
        eachPlugin {
    
            if (requested.id.id == "com.tencent.tinker.patch") {
    
                useModule("com.tencent.tinker:tinker-patch-gradle-plugin:1.9.14.25.3")
            }
        }
    }
}

随后就正常在App模块里的build.gradle添加tinker所需依赖即可
示例：

plugins {
    
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
    id 'com.tencent.tinker.patch'//tinker插件
    id 'kotlin-kapt'
}

生成补丁包时提示 Could not resolve all files for configuration ‘:app:sevenZipToolsLocator’.

我是在M1的电脑上生成补丁包，过程中提示找不到7zip。
根据报错的信息 Could not find SevenZip-1.1.10-osx-aarch_64.exe (com.tencent.mm:SevenZip:1.1.10). 中的.exe 也能猜出来是平台相关的问题。

这里我们可以按照以下步骤做解决这个问题

1. brew install p7zip 本地安装下7zip
2. 获取本地安装的7zip路径 which 7za
3. 更改下配置，把zipArtifact配置注释掉，path更改为本机安装的7za路径

        sevenZip {
    
            /**
             * optional，default '7za'
             * the 7zip artifact path, it will use the right 7za with your platform
             */
//            zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
            /**
             * optional，default '7za'
             * you can specify the 7za path yourself, it will overwrite the zipArtifact value
             */
            /*这里改成本地安装的7za路径*/
            path = "/opt/homebrew/bin/7za"
        }

然后再次执行生成补丁任务即可。
这个问题我看其他人也遇到了，也回答了一下，参照这个也可以：https://github.com/Tencent/tinker/issues/1718

Tinker配置

官方文档和demo中的配置不是很全，毕竟文档很久没更新了，而且demo的配置比较复杂，我这里实际上用不到这么复杂的配置，下面是精简后的配置，仅供参考

/*我这里直接就用版本号来作为tinkerid了*/
def versionName = android.defaultConfig.versionName
print("versionName:" + versionName)

/*存放要生成补丁的文件夹*/
def tinkerPath = "${projectDir}/tinker/"

/**
 * 生成补丁包的配置
 * 参考官方文档：https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
 */
tinkerPatch {
    
    tinkerEnable = true
    /*旧包*/
//    oldApk = "${buildDir.path}/outputs/apk/xxx.apk"
    oldApk = "${tinkerPath}/app-release.apk"
    // 补丁输出路径 选填：默认在app/build/outputs/tinkerPatch下
    outputFolder = "${tinkerPath}/patch/"
    ignoreWarning = true // 是否忽略警告
    allowLoaderInAnyDex = true // 是否支持在任意dex中加载类
    removeLoaderForAllDex = true
    useSign = true // 在运行过程中需要验证基准apk包与补丁包的签名是否一致,release包肯定是需要签名的，默认值是true
    buildConfig {
    
        /*指定旧APK的mapping文件 可减少补丁包大小*/
        applyMapping = "${tinkerPath}/mapping.txt"
        /*旧APK的resource_mapping文件 可减少补丁包大小*/
        applyResourceMapping = "${tinkerPath}/R.txt"
        /*生成tinkerid 补丁包在合并时会验证布丁包的id和基准包的id是否一致 简单点可以用versionName*/
        tinkerId = versionName
        /*是否使用加固模式，只在加固包的情况下设置为true*/
        isProtectedApp = false
        /*是否支持新增非export的activity 测试设置为true也不知道新增页面，会报错*/
        supportHotplugComponent = false
        /*如果keepDexApply为true，则dex所在的类引用旧的apk。打开这个可以减少dex-diff文件的大小。*/
        keepDexApply = false
    }

    // dex相关的配置项
    dex {
    
        /**
         * 只能是'raw'或者'jar'。 对于'raw'模式，我们将会保持输入dex的格式。对于'jar'模式，我们将会把输入dex重新压缩封装到jar。
         * 如果你的minSdkVersion小于14，你必须选择‘jar’模式，而且它更省存储空间，但是验证md5时比'raw'模式耗时。默认我们并不会去校验md5,一般情况下选择jar模式即可。
         */
        dexMode = "jar"
        /**
         * 需要处理dex路径，支持*、?通配符，必须使用'/'分割。路径是相对安装包的，例如assets/...
         * */
        pattern = ["classes*.dex", "assets/secondary-dex-?.jar"]
        // 需要处理dex路径，支持*、?通配符，必须使用'/'分割。路径是相对安装包的，例如assets/...
        /**
         * 这一项非常重要，它定义了哪些类在加载补丁包的时候会用到。这些类是通过Tinker无法修改的类，也是一定要放在main dex的类。
         * 这里需要定义的类有：
         * 1. 你自己定义的Application类；
         * 2. Tinker库中用于加载补丁包的部分类，即com.tencent.tinker.loader.*；
         * 3. 如果你自定义了TinkerLoader，需要将它以及它引用的所有类也加入loader中；
         * 4. 其他一些你不希望被更改的类，例如Sample中的BaseBuildInfo类。这里需要注意的是，这些类的直接引用类也需要加入到loader中。或者你需要将这个类变成非preverify。
         * 5. 使用1.7.6版本之后的gradle版本，参数1、2会自动填写。若使用newApk或者命令行版本编译，1、2依然需要手动填写
         * */
        loader = [
             "com.yzq.hotfix.App"//这里写你自己的Application类
        ]
    }
    //  lib相关的配置项
    lib {
    
        /**
         * 需要处理lib路径，支持*、?通配符，必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的，例如assets/...
         * 一般来讲我们的so文件都放在下面两个路径下面
         */
        pattern = ["lib/*/*.so", "src/main/jniLibs/*/*.so"]
    }
    // res相关的配置项
    res {
    
        /**
         * 需要处理res路径，支持*、?通配符，必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的，例如assets/...，务必注意的是，只有满足pattern的资源才会放到合成后的资源包。
         */
        pattern = ["res/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]
        /**
         * 支持*、?通配符，必须使用'/'分割。若满足ignoreChange的pattern，在编译时会忽略该文件的新增、删除与修改。 最极端的情况，ignoreChange与上面的pattern一致，即会完全忽略所有资源的修改。
         */
        ignoreChange = [
                "assets/sample_meta.txt"
        ]
        largeModSize = 100
        // 对于修改的资源，如果大于largeModSize，我们将使用bsdiff算法。这可以降低补丁包的大小，但是会增加合成时的复杂度。默认大小为100kb
    }
    // 7zip路径配置项，执行前提是useSign为true
    sevenZip {
    
//        zipArtifact = "com.tencent.mm:SevenZip:1.2.17"
        /**
         * 系统中的7za路径，例如"/usr/local/bin/7za"。path设置会覆盖zipArtifact，若都不设置，将直接使用7za去尝试。
         * 这里改成本地安装的7za路径
         * */
        path = "/opt/homebrew/bin/7za"
//        path = "/Users/yuzhiqiang/.gradle/caches/modules-2/files-2.1/com.tencent.mm/SevenZip/1.2.17"
    }
}

这里说一下applyMapping和applyResourceMapping的文件从哪里来。
一般我们通过assembleRelease打完包后，可以在build文件夹中找到apk文件和mapping文件

R文件则是在intermediates文件夹内

tinker-patch-cli jar包如何获取

如果你的补丁需要通过命令行来生成，那么你就需要用到tinker-patch-cli的jar包。那这个jar包如何获取呢？
也比较简单，首先，把tinker源码拉下来，找到buildTinkerSdk这个task，执行一下

随后在build目录中就能获取到jar包了。

至于如何使用看遵循官方文档即可。
不想编译的直接下载这个 Tinker Cli Jar文件 就行，已经生成好了。

Tinker加固包的补丁如何生成

加固包的补丁生成步骤如下

1. isProtectedApp 配置要设置为true
2. 编译出加固前的基准包，保存好，后面生成补丁要用。
3. 加固前的基准包进行加固，正常上应用商店，用户使用的是加固后的基准包
4. 发现bug，进行修复。编译出加固前的新包
5. 使用加固前的基准包和加固前的新包产生补丁
6. 测试补丁是否正常，通过测试后发布补丁

也就是说，产生补丁都是加固前的包。使用补丁是在加固后的包上使用。不要搞错了。

补丁管理规则

这里我们需要跟服务端一起制定规则，给个参考如下：

1. 版本和补丁之间的关系是通过配置的tinkerId关联的，补丁和App的tinkerid必须一致才能正常加载，否则校验是不通过的。
2. App一旦发布就是基准包，此时一定要保存好这个基准包(未加固前的包)以及mapping.txt和R.txt文件，后续改版本补丁的生成都是基于该基准包生成
3. App在一个版本内可以包含多个补丁，新补丁必须要包含旧补丁已修复的代码。
4. 补丁生效前一定要先通过测试才能下发。
5. 服务端给补丁时一定是当前App版本所对应的最新版本的补丁。

看官方文档也能看出来，Tinker的集成以及使用还是比较繁琐的，代码量也不小，具体的代码还需要根据自己的App来做更改。

好了，本篇文章就是这样，希望能帮到你。

---

如果你觉得本文对你有帮助，麻烦动动手指顶一下，可以帮助到更多的开发者，如果文中有什么错误的地方，还望指正，转载请注明转自喻志强的博客 ，谢谢！