Android 热修复+加固+多渠道打包+统计 技术总结
最近产品经理提了一个需求，让我在App中集成上面四个技术，以前每个技术都单独弄过，但是如果把这四个技术融合到一起，相互兼容还是第一次。
技术最终选型
使用流程
代码中集成统计功能 ——> 用热修复生成 Release App ——> 将 App 进行加固 ——> 将加固的 App 多渠道打包
具体详情
热修复
现在大部分热修复使用的都是微信开源的 Tinker，如果直接拿过来使用，配置什么的有点麻烦，wiki 上的文档看的也有点头晕。
由于时间原因，我们现在最重要的是先快速集成测试，高级用法和原理来日方长。
推荐2个快速集成：
最开始集成的时候，我两个都用过，集成方式都非常简单，最后我选用了 Bugly，主要有几点：
- 项目中集成了Bugly异常上报，很好用。
- Bugly 不收费，TinkerPatch 要收费。
- Bugly 官方对加固工具进行了兼容测试。
Q：热修复和加固其实是有冲突的
如果用 Android Studio 自带的多渠道打包工具，打出来的每个包都是有差异的，不能对每个包都进行一一加固，我们是程序猿，肯定要偷懒。并且一个热修复不能通用所有的包。
如果你使用了微信的Tinker热补丁方案，那么就需要为不同的渠道包打不同的补丁，这完全是不可以接受的。（因为Tinker是通过对比基础包APK和新包APK生成差分补丁，然后再把补丁和基础包APK一起合成新包APK。这就要求用于生成差分补丁的基础包DEX和用于合成新包的基础包DEX是完全一致的，即：每一个基础渠道包的DEX文件是完全一致的，不然就会合成失败）
《android新一代多渠道打包神器》
最后在网上找了很久，看了美团的 Walle 和其他的多渠道打包，最后选择了 bugly 的哥们开发的 ApkChannelPackage。
- 使用超简单
- 都是企鹅自己的
- 打包速度超快
多渠道打包工具对比.png
传送门：
加固
加固就没什么说的，很简单。
Bugly 的加固支持：
腾讯乐固
爱加密
梆梆加固
360加固（SDK 1.3.1之后版本支持）
ApkChannelPackage
使用这个多渠道打包速度好快，我打10个包1分钟左右。
最开始集成这个时，遇到一些坑，记录一下。
以下都是在 app/build.gradle 配置：
- 直接生成多渠道包：
channel {
//多渠道包的输出目录，默认为new File(project.buildDir,"channel")
baseOutputDir = new File(project.buildDir, "channel")
//多渠道包的命名规则，默认为：${appName}-${versionName}-${versionCode}-${flavorName}-${buildType}
apkNameFormat = '${appName}-${versionName}-${versionCode}-${flavorName}-${buildType}'
}
- 根据已有的 App 生成多渠道包，适合集成了热修复的
rebuildChannel {
//已有APK的名字必须包含base字符串，这样插件生成多渠道包时，会用当前的渠道替换base字符串，形成新的渠道包
baseReleaseApk = new File(project.projectDir, "base-app-release.apk")
releaseOutputDir = new File(project.projectDir, "channelApk/")
}
生成的目录在 app/channelApk 文件夹中。
- 获取多渠道号
String channel = ChannelReaderUtil.getChannel(getApplicationContext());
Logger.i("多渠道版本是：" + channel);
- MTA 上传版本号
StatConfig.setInstallChannel(channel);
MTA 统计
MTA 开发文档中有这样一个字段：MTA_CHANNEL
manifestPlaceholders = [
MTA_APPKEY : "XXXXXXX",
MTA_CHANNEL : "Test",
]
后面才发现这个字段是在 Gradle 编译时配置的渠道号，如果没有多渠道统计，那所有的渠道都是设置的值“Test”。但是如果进行了MTA 上报版本号，会以最后上报的为准。
最终 App 集成成功并且上线，热修复也没问题。
终于可以开开心心回家了。
