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、下面进行图文解析

1530802559980.jpg 1530803367125.jpg

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

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

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

1530803084040.jpg

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

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

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

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

1530803633866.jpg

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

7、打开bugly官网

1530803776460.jpg 1530803839720.jpg

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

正题--多渠道打包

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

1530804638628.jpg

然后执行

./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点了，收拾收拾下班！！！