关于Tinkerpatch的初步研究

关于Tinkerpatch的初步研究

1 什么是Tinkerpatch

Thinkerpatch是基于开源库Tinker封装而来, 提供了补丁后台托管，版本管理，保证传输安全等功能

关于tinker的介绍可以上github上查看或者上Thinkerpatch官网查看

http://www.tinkerpatch.com/Docs/intro

2 如何使用Thinkerpatch

2.1添加 gradle 插件依赖

2.1.1 修改 project的build.gradle

buildscript {

   repositories {

       jcenter()

    }

   dependencies {

       // TinkerPatch 插件

       classpath"com.tinkerpatch.sdk:tinkerpatch-gradle-plugin:1.1.6"

    }

}

2.1.2修改 app的build.gradle

 

dependencies {

    // 若使用annotation需要单独引用,对于tinker的其他库都无需再引用

    provided("com.tinker.tinker:tinker-android-anno:1.7.9")

    compile("com.tinkerpatch.sdk:tinkerpatch-android-sdk:1.1.6")

}

apply from: 'tinkerpatch.gradle'

2.1.3 新建tinkerpatch.gradle（app  目录下）

apply plugin: 'tinkerpatch-support'

/**
 * TODO: 请按自己的需求修改为适应自己工程的参数
 */
def bakPath = file("${buildDir}/bakApk/")
def baseInfo = "app-0115-23-11-20"
def variantName = "release"//如果是debug包则是debug

tinkerpatchSupport {

    tinkerpatchSupport {

    /** 可以在debug的时候关闭 tinkerPatch **/

    tinkerEnable = true

    /** 是否使用一键接入功能  **/

    reflectApplication = true

    autoBackupApkPath = "${bakPath}"

    /** 在tinkerpatch.com得到的appKey **/

    appKey = "yourAppKey"

    /** 注意: 若发布新的全量包, appVersion一定要更新 **/

    appVersion = "1.0.0"

    def pathPrefix = "${bakPath}/${baseInfo}/${variantName}/"

    def name = "${project.name}-${variantName}"

    baseApkFile = "${pathPrefix}/${name}.apk"

    baseProguardMappingFile = "${pathPrefix}/${name}-mapping.txt"

    baseResourceRFile = "${pathPrefix}/${name}-R.txt"

}

//注：官网上的这些代码还不行，还需要添加如下代码才能编译通过

/**
 * 用于用户在代码中判断tinkerPatch是否被使能
 */
android {
    defaultConfig {
        buildConfigField "boolean", "TINKER_ENABLE", "${tinkerpatchSupport.tinkerEnable}"
    }
}

/**
 * 一般来说,我们无需对下面的参数做任何的修改
 * 对于各参数的详细介绍请参考:
 * https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
 */
tinkerPatch {
    ignoreWarning = false
    useSign = true
    dex {
        dexMode = "jar"
        pattern = ["classes*.dex"]
        loader = []
    }
    lib {
        pattern = ["lib/*/*.so"]
    }

    res {
        pattern = ["res/*", "r/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]
        ignoreChange = []
        largeModSize = 100
    }

    packageConfig {
    }
    sevenZip {
        zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
//        path = "/usr/local/bin/7za"
    }
    buildConfig {
        keepDexApply = false
    }
}

 

2.2 application中初始化SDK

分为reflectApplication true和false的情况

2.2.1 reflectApplication = true

public class SampleApplication extends Application {

    @Override

    public void onCreate() {

        super.onCreate();

        // 我们可以从这里获得Tinker加载过程的信息

        tinkerApplicationLike = TinkerPatchApplicationLike.getTinkerPatchApplicationLike();

        // 初始化TinkerPatch SDK, 更多配置可参照API章节中的,初始化SDK

        TinkerPatch.init(this)

            .reflectPatchLibrary()

            .setPatchRollbackOnScreenOff(true)

            .setPatchRestartOnSrceenOff(true)

            .setFetchPatchIntervalByHours(3);

        // 每隔3个小时(通过setFetchPatchIntervalByHours设置)去访问后台时候有更新,通过handler实现轮训的效果

        TinkerPatch.with().fetchPatchUpdateAndPollWithInterval();

    }

2.2.2 reflectApplication = false

将 Application 的逻辑移动到 ApplicationLike类中

@DefaultLifeCycle(application = "com.example.ygh.testhotfix.TestApplication",  

//这个TestApplication需要配置到mainxml中，如果找不到，rebuild即可
        flags = ShareConstants.TINKER_ENABLE_ALL,
        loadVerifyFlag = false)
public class TestApplicationLike extends DefaultApplicationLike {
    private static final String TAG = "Tinker.SampleAppLike";

    public TestApplicationLike(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();
        // 初始化TinkerPatch SDK, 更多配置可参照API章节中的,初始化 SDK
        TinkerPatch.init(this)
                .reflectPatchLibrary()
                .setPatchRollbackOnScreenOff(true)
                .setPatchRestartOnSrceenOff(true)
                .setFetchPatchIntervalByHours(3);

        // 每隔3个小时（通过setFetchPatchIntervalByHours设置）去访问后台时候有更新,通过handler实现轮训的效果
        TinkerPatch.with().fetchPatchUpdateAndPollWithInterval();
    }
}

2.3 生成基准包数据

2.3之前的配置都完成后，我们就可以开始生成基准包数据了，既然是打补丁，则需要先有基础的对照版本才能生成补丁，

比如我们的基础版本是1.0，命令到项目APP目录下运行gradle assembleRelease

如果BUILD SUCCESSFUL则表示成功，我们可以在APP--build--bakapp-app-版本-时间--release目录下看到基础包数据了（目录位置和命名可以自己在tinkerpatch.gradle中修改

目录中包含：apk文件、R.txt文件和mapping.txt文件 （注：mapping.txt是proguard的产物，如果你没有开启proguard则不会有这个文件）

2.4 生成补丁

生成基准数据后，比如patch版本是1.0。 已经上到外网供用户使用了一段时间，如果我们下版本需要增加类或者修改一个BUG，我们就可以生成补丁来完成升级

2.4.1 放入基准数据

根据tinkerpath.gradle配置中的baseInfo和variantName在build目录下新建文件夹bakApk/baseInfo/variantName  ，并把我们2.3步骤中生成的基准数据放进来

（如文件夹：bakApk/app-0115-23-11-20/release/）

2.4.2 修改appVersion

tinkerpatch.gradle中的appVersion为1.1（如果发布的是全量包，版本一定要更新）

2.4.3 命令行生成补丁文件

本地代码新增或者修改后，就可以运行gradle tinkerPatchRelease 来生成补丁，如果BUILD SUCCESSFUL则会在build目录下的outputs生成tinkerpatch文件夹，打开文件夹到最终目录会有很多文件，patch_signed_7zip.apk即是我们需要的补丁文件

2.5 发布补丁

我们进入tinkerpatch官网添加APP版本，上传补丁文件即可完成更新了

注：版本号需要填待修复的版本号1.0，而不最新的版本号1.1

发布完成后，我们可以观察更新状态：已下发(成功应用数/成功下载数)：1/1

3 tinkerpatch其他

  3.1 Tinker的已知问题

由于原理与系统限制，Tinker有以下已知问题：

1. Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件；
2. 由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；
3. 在Android N上，补丁对应用启动时间有轻微的影响；
4. 不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；
5. 对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。

3.2 补丁大小限制

  Tinkerpatch免费基础版有500K的补丁限制（标准版和定制版没有限制）。经测试Tinkerpatch对类中代码的会进行压缩，类的增加可以按字节码算。但是对于xml类资源文件占用比较大，500K应该可以支持几十个简单XML文件和300K左右图片资源。

因官网暂时没有数据给出，上面只是大概，具体应该和文件格式及Tinkerpatch的生成算法有关，所以需要生成补丁文件才能知道具体的大小

  3.3 加固厂商支持列表

暂时只支持某几个加固平台

以下数据来源官网（2017/5/10）

  支持列表:

加固厂商	测试
乐加固	Tested
爱加密	Tested
梆梆加固	Tested
360加固	Tested（需要使用2017.5.8之后的版本）
其他	请自行测试，只要满足下面规则的都可以支持

这里是否支持加固，需要加固厂商明确以下两点：

1.   不能提前导入类；

2.   在art平台若要编译oat文件，需要将内联取消。

3.4 日请求量超过购买的量级会怎样？

对于基础版用户，若量级超过日请求量1w，会无法下发新的补丁，但已下发的补丁会正常运行。

对于标准版用户，若是按月购买，用户增长到平均日请求量大于购买的量级，当月可以继续正常使用，下个月续费时再选用合适的量级。若是按年购买，我们会联系你商讨升级方案。

3.5 流量超出会怎样？

标准版每一档所配的流量一般已经可以满足需求。若补丁较大并下发得较频繁，当月流量超出时，会无法下发新的补丁，但已下发的补丁会正常运行，需要另外购买流量或升级套餐才能继续下发。

3.6如何回滚

可以简单删除当前appVersion控件来完成回滚，客户端会回滚到没有安装补丁的状态。后续可以重新建立同名appVersion。

3.7 补丁下发机制

每隔3个小时（可以通过setFetchPatchIntervalByHours设置）去访问后台时候有更新,通过handler实现轮训

3.8 安全性

通过HTTPS及签名校验等机制保障补丁下发的安全性（见tinker）