最近產品經理提了一個需求，讓我在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。
- 使用超簡單
- 都是企鵝自己的
- 打包速度超快
傳送門：
加固
加固就沒什么說的，很簡單。
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 集成成功并且上線，熱修復也沒問題。
終于可以開開心心回家了。
