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

集成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'
   }
   }复制代码

2. 而后在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'复制代码

3. 还须要配置

   dexOptions {
     jumboMode = true
   }复制代码

   tinker的最佳实践，防止因为字符串增多致使force-jumbol，致使更多的变动

4. 最后能够把tinker相关的代码挪动到tinkerpatch.gradle中

5. 改造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 使用的是 github.com/baidao/tink…步骤以下

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

   repositories {
   jcenter()
   }
   dependencies {
   ...
   compile 'com.dx168.patchsdk:patchsdk:1.1.3'
   }复制代码

2. 使用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();
   }
   }复制代码

3. 搭建补丁后台管理系统
   参考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 做者已经修复若干问题
5. 还有一些其余的坑已经记不得了。。。

博客地址:

www.jianshu.com/p/194c9d89b…

相信本身，没有作不到的，只有想不到的

若是你以为此文对您有所帮助，欢迎入群 QQ交流群 ：232203809
微信公众号：终端研发部

技术+职场