你期待已久的热修复—Tinker热修复集成总结

前言介绍

Tinker热修复集成总结

xingstarx的博客地址：

http://www.jianshu.com/p/194c9d89b227

正文 

集成tinker

对于原有app集成tinker，还是比较简单的，根据tinker上的wiki的指示操作即可。 具体步骤如下：

1. 在项目的build.gradle中添加 tinker-patch-gradle-plugin 的依赖

buildscript { 
    dependencies {     
        classpath 'com.tencent.tinker:tinker-patch-gradle-plugin:1.7.9'
     }
}

1. 然后在app的gradle文件app/build.gradle，我们需要添加tinker的库依赖以及apply tinker的gradle插件.

dependencies { //可选，用于生成application类 provided 'com.tencent.tinker:tinker-android-anno:1.7.9' //tinker的核心库 compile 'com.tencent.tinker:tinker-android-lib:1.7.9'} ... ...//apply tinker插件apply plugin: 'com.tencent.tinker.patch'

1. 还需要配置

dexOptions {     
    jumboMode = true
 }

tinker的最佳实践，防止由于字符串增多导致force-jumbol，导致更多的变更

1. 最后可以把tinker相关的代码挪动到tinkerpatch.gradle中

2. 改造SampleApplication，通过SampleApplicationLike代理SampleApplication的行为。具体可以看wiki和SampleApplication相关的改动可以参考 TinkerDemo

加固支持 

从1.7.8开始，tinker又支持加固了，只需要修改tinkerpatch.gradle中的这部分

buildConfig {            
        applyMapping = getApplyMappingPath()
            applyResourceMapping = getApplyResourceMappingPath()
            tinkerId = getTinkerIdValue()
            keepDexApply = false

            isProtectedApp = true //开启加固
        }

集成patchsdk

patchsdk 使用的是 https://github.com/baidao/tinker-manager/tree/master/patchsdk步骤如下

1. 需要在app/build.gradle中添加

repositories { jcenter() }dependencies { ... compile 'com.dx168.patchsdk:patchsdk:1.1.3'}

1. 使用ApplicationLike代理原来的Application

@SuppressWarnings("unused")
@DefaultLifeCycle(application = "com.dx168.patchsdk.sample.MyApplication",flags = ShareConstants.TINKER_ENABLE_ALL,loadVerifyFlag = false)
public class MyApplicationLike extends TinkerApplicationLike { 
    
 public MyApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) {     
        super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
 } 

@Override
 public void onCreate() {     
     super.onCreate();
     String appId = "20170112162040035-6936";
     String appSecret = "d978d00c0c1344959afa9d0a39d7dab3";
     PatchManager.getInstance().init(getApplication(), "http://xxx.xxx.xxx/hotfix-apis/", appId, appSecret, new ActualPatchManager() {         @Override
         public void cleanPatch(Context context) {
             TinkerInstaller.cleanPatch(context);
         }         
         
         @Override
         public void patch(Context context, String patchPath) {
             TinkerInstaller.onReceiveUpgradePatch(context, patchPath);
         }
     });
     PatchManager.getInstance().register(new Listener() {
         ...
     });
     PatchManager.getInstance().setTag("your tag");
     PatchManager.getInstance().setChannel("");
     PatchManager.getInstance().queryAndPatch();
  }
}

1. 搭建补丁后台管理系统 参考Readme 搭建补丁后台，不过这个后台没有push下发补丁的功能，只有后台下发后，客户端pull拉取补丁，进行补丁修复操作 如果你的app用的是bugly来作为异常上报和运营统计，那么可以直接使用bugly提供的后台，具体操作请参考这里， 小巫同学录制了一系列相关的视频，参考视频教程即可学会,地址在这里 ，bugly支持push下发，比自己搭建后台更加有优势，同样，也可以使用TinkerPatch补丁管理后台，不过是收费的。

生成渠道包

对于渠道包，如果不是需要使用热修复，那么怎么生成渠道包都可以的。 对于flavor编译渠道包，会导致不同的渠道包由于BuildConfig变化导致classes.dex差异，这种方案是不可取的。

 将渠道信息写在apk文件的zip comment中，是非常推荐的，例如可以使用项目packer-ng-plugin或者可使用V2 Scheme的walle, 也包括最新出来的多渠道打包神器ApkChannelPackage，说一下区别，如果要使用热修复的话，对于不需要加固的app，那么生成渠道包，这三种方案都可以采用；对于要加固的app，只能采用ApkChannelPackage这种方案中的根据已有APK生成渠道包(如果有其他的方案，请记得告诉我)。这篇文章对多渠道打包工具对比做了详细的区分。目前采用的也是ApkChannelPackage方案。

生成补丁

以TinkerDemo为例

1. 执行./gradlew assembleRelease 生成apk

2. 使用梆梆加固工具加固apk，并签名，得到加固并且重签名的app_protected_signed.apk

3. 使用./gradlew reBuildChannel 生成渠道包

4. 修改TinkerDemo中的若干代码

5. ./gradlew tinkerPatchRelease 生成patch补丁apk(需要保证补丁包tinkerId跟基线版本tinkerId一致)(也就是说，打补丁的时候不要commit代码，tinkerId是根据git commit生成的)

6. 如果搭建了补丁管理后台的话，使用后台上传补丁包，进行修复，根据log，可以观察到结果

7. 如果没有搭建补丁管理后台的话，使用adb push app/build/outputs/tinkerPatch/release/patch_signed_7zip.apk /storage/sdcard0/（参考tinker的sample工程，以及tinker接入文档）

测试补丁包

根据生成补丁的若干步骤，来测试补丁包是否有效，在第三步生成渠道包后，安装其中的一个渠道apk到手机上，然后呢，我这边是通过补丁管理后台上传的补丁，然后客户端pull补丁，根据log，可以清晰的看到补丁是否下载完成，是否有效。下载完补丁后，会进行dex合成。然后在后台或者屏幕关闭后app会被杀死，重启后补丁才会生效，这个时候我们才真正修复了问题。

踩过的坑

1. gradle打release包需要开启签名(./gradlew assembleRelease),不然的话，打patch包的时候，提示出错(./gradlew tinkerPatchRelease)

2. 打补丁包的时候，得保证基线版本是上一次发版本的apk，而且如果用的是tinker的默认形式的话,tinkerId得跟上一次发版本的apk的tinkerId一致，也就是基于上一次发版本的tag开bugfix分支，但是记得不要commit代码，这样就保证了tinkerId一致(可以考虑是用app的版本号VERSION_NAME来作为tinkerId，每一次的发版，肯定是会修改版本号的)，如果是bugly集成的tinker，请参考bugly官方文档

3. 加固包跟渠道包如何相容的问题，一开始不太懂，如果有加固的需求如何做?。 我们需要搞明白的是，加固包不是基线版本，使用tinker打补丁包，用的是基线版本，得到基线版本后，我们会选择梆梆加固，乐固，爱加密这样的平台对基线版本进行加固，得到加固包后，还需要注意的是，不能够用普通的渠道包生成方案来打渠道包。举例来说吧，我司的app，采用的是梆梆加固，加固后，工具自动帮你做了生成渠道包的操作，但是这种生成的渠道包实际上是有问题的，会导致无法打补丁，无法修复，tinker热修复不生效。这种生成的渠道包，不同渠道对应的dex的CRC都不一样，我们得保证打出来的渠道包的dex都是一样的，通过apksigner可以知道梆梆加固的签名工具采用的是v1签名方案，那么我们可以考虑在APK文件的注释字段，添加渠道信息。这样就能保证不同渠道的dex是一致的。

4. ApkChannelPackage 存在一点小问题，还需要作者修复，v1签名的判断逻辑有问题，加固后的apk，会改变META-INF/XXX.SF的名称,这块需要修改，不然./gradle reBuildChannel执行后，无法生成渠道包，对于开发者而言可以自己搭建本地localMaven，来测试修改这个repo 作者已经修复若干问题

博客地址:

http://www.jianshu.com/p/194c9d89b227

终端研发部提倡： 没有做不到的，只有想不到的。

在这里获得的不仅仅是技术！ 

让心，在阳光下学会舞蹈

让灵魂，在痛苦中学会微笑

—终端研发部—

如果你觉得此文对您有所帮助，欢迎入群 QQ交流群 ：232203809   

微信公众号：终端研发部

            

这里学到的不仅仅