Bugly 热更新集成,以及问题解决

所有的线上app ,在用户使用中百分百不会发生崩溃是不可能的,不过一般来说对于那些不是非常严重的问题我们只要能控制崩溃率在1/1000以下就可以了,但是在某些情况下由于测试不充分,或是自己的原因,使得app崩溃的比例超过了阈值,我们只能修改问题后,重新测试,打包,审核,上线.这个流程是很耗时的 , 为了更快的解决线上问题,所以出现了热更新技术，因为之前使用了Bugly的异常收集，和版本更新功能，所以选择了腾讯的Bugly。

bugly的优缺点（因为bugly 采用的是微信Tinker的方案，所以可以看作是Tinker的优缺点）

• 优点

补丁包较小，消耗较小；
开发透明，文档丰富。

• 局限性

占用 ROM 较大；
需要重启才能生效

官方链接：腾讯bugly官方地址 ， 下面是我的集成步骤。

• 找到项目build.gradle添加

 classpath "com.tencent.bugly:tinker-support:latest.release" //bugly 热更新

• app build.gradle中天添加

// 依赖插件脚本
apply from: 'tinker-support.gradle'

• app build.gradle中添加bugly sdk依赖

    /*buggly*/
    api 'com.tencent.bugly:crashreport_upgrade:latest.release'
    api 'com.tencent.bugly:nativecrashreport:latest.release' //其中latest.release指代最新版本号，也可以指定 明确的版本号，例如2.2.0
    api "com.android.support:multidex:1.0.1" // 多dex配置
    // 指定tinker依赖版本（注：应用升级1.3.5版本起，不再内置tinker）
    api 'com.tencent.tinker:tinker-android-lib:1.9.9'

• 在app build.gradle 同级目录下创建tinker-support.gradle

tinker-support.gradle

内容直接复制

apply plugin: 'com.tencent.bugly.tinker-support'

def bakPath = file("${buildDir}/bakApk/")

/**
 * 此处填写每次构建生成的基准包目录
 */
def baseApkDir = "app-0208-15-10-00"

/**
 * 对于插件各参数的详细解析请参考
 */
tinkerSupport {

    // 开启tinker-support插件，默认值true
    enable = true

    // 指定归档目录，默认值当前module的子目录tinker
    autoBackupApkDir = "${bakPath}"

    // 是否启用覆盖tinkerPatch配置功能，默认值false

    // 开启后tinkerPatch配置不生效，即无需添加tinkerPatch
    overrideTinkerPatchConfiguration = true

    // 编译补丁包时，必需指定基线版本的apk，默认值为空
    // 如果为空，则表示不是进行补丁包的编译
    // @{link tinkerPatch.oldApk }
    baseApk = "${bakPath}/${baseApkDir}/app-release.apk"

    // 对应tinker插件applyMapping
    baseApkProguardMapping = "${bakPath}/${baseApkDir}/app-release-mapping.txt"

    // 对应tinker插件applyResourceMapping
    baseApkResourceMapping = "${bakPath}/${baseApkDir}/app-release-R.txt"

    // 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性
    tinkerId = "base-1.0.1"

    // 构建多渠道补丁时使用
    // buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

    // 是否启用加固模式，默认为false.(tinker-spport 1.0.7起支持）
    // isProtectedApp = true

    // 是否开启反射Application模式
    enableProxyApplication = false

    // 是否支持新增非export的Activity（注意：设置为true才能修改AndroidManifest文件）
    supportHotplugComponent = true

}

/**
 * 一般来说,我们无需对下面的参数做任何的修改
 * 对于各参数的详细介绍请参考:
 * https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
 */
tinkerPatch {
    //oldApk ="${bakPath}/${appName}/app-release.apk"
    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
        //tinkerId = "1.0.1-base"
        //applyMapping = "${bakPath}/${appName}/app-release-mapping.txt" //  可选，设置mapping文件，建议保持旧apk的proguard混淆方式
        //applyResourceMapping = "${bakPath}/${appName}/app-release-R.txt" // 可选，设置R.txt文件，通过旧apk文件保持ResId的分配
    }
}

其中几个重要配置

1. def baseApkDir = "app-0208-15-10-00" : 打补丁包依据的基准包的地址 ,打基准包时不用定义。
2. tinkerEnable = true : tinkerEnable功能开关(官方文档中没有添加,这个要将自己添加)
3. tinkerId ="base-1.0.1" : 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性
4. enableProxyApplication = true: 是否开启反射Application模式,设置为true 使用自己的appliocation. 反之使用bugly提供的

• 初始化sdk

public class MyApplication extends Application {

   @Override
   public void onCreate() {
       super.onCreate();
         // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
       // 调试时，将第三个参数改为true
       Bugly.init(this, "900029763", false);
       //autoCheckUpgrade设置成true，确保App启动时,自动检查更新
       Beta.autoCheckUpgrade = true ;

   @Override
   protected void attachBaseContext(Context base) {
       super.attachBaseContext(base);
       // you must install multiDex whatever tinker is installed!
       MultiDex.install(base);


       // 安装tinker
       Beta.installTinker();
   }

}
        

• AndroidManifest.xml配置

1. 权限配置

2. Activity配置

3. 配置FileProvider

如果你使用的第三方库也配置了同样的FileProvider, 可以通过继承FileProvider类来解决合并冲突的问题，示例如下：

这里要注意一下，FileProvider类是在support-v4包中的，检查你的工程是否引入该类库。在res目录新建xml文件夹，创建provider_paths.xml文件如下

• 打基准包

配置基准包的tinkerId

1556269891(1).png

执行assembleRelease编译生成基准包(编译生成基准包是要注意配置签名信息)：

1556272326(1).png

开始编译

1556269981(1).png

这个会在build/outputs/bakApk路径下生成每次编译的基准包、混淆配置文件、资源Id文件，如下图所示

1556270153(1).png

如果没有开启混淆 ,则不会有app-release-mapping.txt
基准包生成后需要联网上报, 在已联网的设备上运行刚生成的基准包即可,

• 查看基包时候打包成功,可以双击基包. 查看是否与设置tinker_id相同

1556271376(1).png

修改bug后,根据基线包生成补丁包

• 修改待修复apk路径、mapping文件路径、resId文件路径

1556271719(1).png

• 生成补丁包

生成补丁包

补丁包

• 上传补丁包

1556273194(1).png

上传补丁包后 等一会如果基包联网上报成功的话, 则可以解析出目标版本号, 然后点击立即下发,然后重启app 就可以看到更新结果了, 可能推送有5到10分钟的延迟,

• 页面会提示"未匹配到可应用补丁包的App版本 原因分析

当出现了"未匹配到可应用补丁包的App版本，请确认补丁包的基线版本是否已经发布"这样的提示时，可以确定，这个基准包的tinkerId等信息没有被上传到Bugly服务器，
此时可以检查App是否能够联网。
检查App ID是否正确。
是否xml 配置的了 bugly提供的Application 但是tinker-support.gradle中设置的是enableProxyApplication = true

• 注意

基包对以后制作补丁包来说是相当重要的，所以要注意保存;