android bugly集成崩溃收集和热修复踩坑记录

前言

许久没写东西了，换了新工作，新环境，刚来就进行了坑人的拓展训练，继而迎来的是没人性的907作息（早晨九点，晚上12点，每周7天），之前的创业公司加班已经没有节操了，本以为从地狱里爬了上来，谁知道他妈的又下了一层～～～～

背景

言归正传，由于项目需要，产品中需要接入bugly的相关功能，来收集异常和热修复的功能添加，这里就一起说了

正题--下发补丁包

1、首先是在项目的build.gradle中的dependencies中添加依赖

Tips：这里有人会把1.0.8改成lastest.release,这有可能会跟app的build.gradle中的crashreport_upgrade:1.3.1版本冲突，故写死为1.0.8

classpath "com.tencent.bugly:tinker-support:1.0.8"

2、然后是在app的build.gradle中的dependencies中添加依赖

compile 'com.tencent.bugly:crashreport_upgrade:1.3.1'
compile 'com.tencent.bugly:nativecrashreport:latest.release'

3、在app目录下创建tinker-support.gradle文件

内容如下

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

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

/**
 * 此处填写每次构建生成的基准包目录
 */
def baseApkDir = "app-0705-21-37-36"

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

    // 开启tinker-support插件，默认值true
    enable = true
    // tinkerEnable功能开关
    tinkerEnable = true
    // 指定归档目录，默认值当前module的子目录tinker
    autoBackupApkDir = "${bakPath}"

    // 是否启用覆盖tinkerPatch配置功能，默认值false
    // 开启后tinkerPatch配置不生效，即无需添加tinkerPatch
    overrideTinkerPatchConfiguration = true

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

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

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

    // 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性
//    tinkerId = "base-2.3.0.152"
    tinkerId = "patch-2.3.0.152"
    // 构建多渠道补丁时使用
//     buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

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

    // 是否开启反射Application模式
    enableProxyApplication = 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的分配
    }
}

4、下面进行图文解析

这个文件中的其他东西没有需要的话可以不用再动了，文件的路径名称，按照自己的需要进行更改

下面就是要开始打基准包了

5、直接执行./gradlew clean assembleRelease 就可以看到在app中的build目录下会按照日期生成一个文件

里面有我们的R.txt,mapping.txt,和我们的基准包.apk文件如果没有mapping.txt,请确认你的混淆是不是开启了

6、下面就是修改代码，修改第4项第2张图中的路径，改成我们build目录下的那个文件夹目录

然后修改tinkerId 为补丁包patch的值

执行./gradlew clean buildTinkerPatchRelease 执行完毕后，生成如下图文件

其中patch_signed_7zip.apk就是我们所需要的补丁包

7、打开bugly官网

选择你的补丁包上传即可～～～～

正题--多渠道打包

bugly虽然是支持多渠道打包的,但是如果我们在productFlavors配置渠道，当我们执行

./gradlew clean buildTinkerPatchRelease 命令的时候

会造成对每个渠道都生成一个补丁包,这样我们要下发补丁包的时候就要下发很多个，这显然不是我们想要的效果。

这里我们就来推荐新一代打包神器walle

首先是配置在 app下的build.gradle中添加

// 多渠道使用walle示例（注：多渠道使用）
apply from: 'multiple-channel.gradle'

创建multiple-channel.gradle文件，内容如下

apply plugin: 'walle'
walle {
    // 指定渠道包的输出路径
    apkOutputFolder = new File("${project.buildDir}/outputs/apk");
    // 定制渠道包的APK的文件名称
    apkFileNameFormat = 'mkzhanReader_${channel}_V${versionName}_${versionCode}.apk';
    // 渠道配置文件
//    channelFile = new File("${project.getProjectDir()}/channel")
    channelFile = project.rootProject.file("storechannel")
}

在项目的build.gradle文件中dependencies中添加

classpath 'com.meituan.android.walle:plugin:1.1.6'

在工程目录下创建渠道文件我这里命名为storechannel

然后执行

./gradlew clean assembleReleaseChannel

就会在看到自己配置的输出路径下面产生的渠道包

这里我们还能添加一些统计分析，比如bugly收集异常上报的时候我们需要上报渠道

可通过下面方式添加

首先是在app的build.gradle中先引入walle的依赖

compile 'com.meituan.android.walle:library:1.1.6'

然后我们就可以通过代码获取到对映的渠道包了

 String channel = WalleChannelReader.getChannel(context);//获取渠道名称
 Bugly.setAppChannel(context, channel);//bugly设置渠道号

注意！注意！注意！当我们执行

assembleReleaseChannel

命令打渠道包的时候热更新插件在bakApk也会生成基线版本，我们只要对这个版本打补丁包，然后上传，下发就可以统一下发到各个渠道上，亲测可行

至此bugly热修复和多渠道打包都完成了，讲了那么多异常上报我们好像没说，其实很简单我们只要按照管方文档配置好项目，进行初始化，异常上报其实就可以用了，这里我们重点要讲的是热更新，所以异常上报就一笔带过啦....

码字不易！可怕的907，终于快要到12点了，收拾收拾下班！！！