Bugly熱修復使用及多渠道打包
頭
不知道你是否遇到過這個情況，項目上線後或者開始給別人使用的時候，冷不丁的冒出個Bug，這時候首先要幹嘛？
先看崩潰日誌啊
看完崩潰日誌你知道了造成崩潰的原因，然後幹嘛？
開始甩鍋啊
當查明瞭是誰造成的這個崩潰後，你發現不是你的問題，於是你心中一樂，長舒一口氣，仰天大笑：碼海沉浮又幾載，我輩豈是蓬蒿人；笑完便準備躺牀上睡覺去——秋豆麻袋，是不是忘了什麼東西？
是的，即使你發現了問題，並且找到了問題的來源，這時候還差一步：解決問題的辦法！如何解決？
發佈新版本？
這樣不覺得很麻煩嗎？特別是如果一個項目處於初期階段，Bug是想甩都甩不掉的，如果每發現一次崩潰，都需要靠發佈一個新版本去解決的話，那未免就太麻煩了。不光是開發者麻煩，使用者也會因爲頻繁的升級而不耐煩（just like me），那問題又回來了，如何解決？
熱修復啊
通過線上修復Bug，讓用戶在神不知鬼不覺的情況下就進行了一次應用更新，麻麻再也不用擔心App崩潰啦！（不存在的）
熱修復還有個隱藏的好處，那就是在測試人員不夠（開發兼測試），測試機型不夠的情況下可以顯著改善App的崩潰率。好吧，準備開始使用吧。
身
一、爲什麼要用Bugly
市面上關於熱修復和崩潰日誌監測的相關技術和SDK種類各不相同，爲什麼偏偏要用Bugly呢？
- 可以獲取到App崩潰日誌
- 可以集成Think熱修復
- 界面好看，方便管理版本
- 免費
- （湊巧就用了這一款，其他的都沒有用過）
基於以上原因，最後就使用了Bugly去解決上面提到過的問題；
二、Bugly熱更新接入流程
其實關於Bugly熱更新的詳細接入流程，官方的文檔介紹的非常詳細，對新手比較友好，我第一次使用也是直接參照的文檔，下面是官方文檔的地址：
雖然官方有例子，這裏還是寫了一個簡化版，也方便以後哪天自己忘記了依舊能快速使用：
第一步：添加依賴插件
在你的項目更目錄下的“build.gradle”中添加：
buildscript {
repositories {
jcenter()
}
dependencies {
// tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明確版本號，例如1.0.4
classpath "com.tencent.bugly:tinker-support:1.1.2"
}
}
在寫這篇文章的時候，最新的版本就是1.1.2
第二步：添加依賴插件
gradle配置
在app module的“build.gradle”文件中添加（示例配置）：
...
// 依賴插件腳本
apply from: 'tinker-support.gradle'
android {
defaultConfig {
ndk {
//設置支持的SO庫架構
abiFilters 'armeabi' //, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'
}
}
}
dependencies {
implementation 'com.android.support:multidex:1.0.1'
// 多dex配置
//註釋掉原有bugly的倉庫
//compile 'com.tencent.bugly:crashreport:latest.release'//其中latest.release指代最新版本號，也可以指定明確的版本號，例如1.3.4
implementation 'com.tencent.bugly:crashreport_upgrade:1.3.5'
// 指定tinker依賴版本（注：應用升級1.3.5版本起，不再內置tinker）
implementation 'com.tencent.tinker:tinker-android-lib:1.9.6'
implementation 'com.tencent.bugly:nativecrashreport:latest.release'
//其中latest.release指代最新版本號，也可以指定明確的版本號，例如2.2.0
}
在這個版本的SDK裏面，已經集成了崩潰日誌上傳的功能哦！
tinker-support.gradle的配置
接下來，你要在app module目錄下創建另外一個gradle文件，命名爲“tinker-support.gradle”，然後對它進行配置：
apply plugin: 'com.tencent.bugly.tinker-support'
def bakPath = file("${buildDir}/bakApk/")
/**
* 此處填寫每次構建生成的基準包目錄
*/
def baseApkDir = "app-0921-14-52-06"
/**
* 對於插件各參數的詳細解析請參考
*/
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 = "1.0.1-patch" //tinkerId = "1.0.1-patch" tinkerId = "1.0.1-base"
// 構建多渠道補丁時使用
// 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的分配
}
}
這裏面的配置比較多，一開始看還是有點兒眼花繚亂的，所以得慢慢來；
這裏對其中的幾點進行說明：
- baseApkDir ： 這裏填寫每次構建生成的基準包目錄，每次打包的時候，都會有新的目錄和新的基準包生成，但是隻有你打算髮布的那一個的目錄纔是有效的。
- tinkerId ： 構建基準包和補丁包都要指定不同的tinkerId，並且必須保證唯一性。比如你的第一個基準包打包的時候可以把這個id設置爲“1.0.0-base”，當你想打包熱修復補丁包的時候，需要把這個id換成1.0.0-patch。
更詳細的配置項參考：tinker-support配置說明
第三步：初始化SDK
上面的“tinker-support.gradle”中的enableProxyApplication屬性設置的是false，是Tinker推薦的接入方式。
自定義Application，當enableProxyApplication爲false的情況
public class SampleApplication extends TinkerApplication {
public SampleApplication() {
super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike",
"com.tencent.tinker.loader.TinkerLoader", false);
}
}
SampleApplicationLike需要是自定義的繼承DefaultApplicationLike的類，不要忘了在AndroidManifest.xml中聲名上面的這個Application哦。
public class SampleApplicationLike extends DefaultApplicationLike {
public static final String TAG = "Tinker.SampleApplicationLike";
public SampleApplicationLike(Application application, int tinkerFlags,
boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime,
long applicationStartMillisTime, Intent tinkerResultIntent) {
super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
}
@Override
public void onCreate() {
super.onCreate();
// 這裏實現SDK初始化，appId替換成你的在Bugly平臺申請的appId
// 調試時，將第三個參數改爲true
Bugly.init(getApplication(), "900029763", false);
}
@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
@Override
public void onBaseContextAttached(Context base) {
super.onBaseContextAttached(base);
// you must install multiDex whatever tinker is installed!
MultiDex.install(base);
// 安裝tinker
// TinkerManager.installTinker(this); 替換成下面Bugly提供的方法
Beta.installTinker(this);
}
@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
public void registerActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks) {
getApplication().registerActivityLifecycleCallbacks(callbacks);
}
}
上面需要注意的是在“onCreate()”方法中進行初始化的時候，填入的appId是你在Bugly創建的項目的Appid，其他地方基本上不用改了
自定義Application，當enableProxyApplication爲true的情況
這種的接入方式要簡單許多，無須你改造Application
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
// 這裏實現SDK初始化，appId替換成你的在Bugly平臺申請的appId
// 調試時，將第三個參數改爲true
Bugly.init(this, "900029763", false);
}
@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.權限配置：
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.READ_LOGS" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
2.Activity配置：
<activity
android:name="com.tencent.bugly.beta.ui.BetaActivity"
android:configChanges="keyboardHidden|orientation|screenSize|locale"
android:theme="@android:style/Theme.Translucent" />
3.配置FileProvider
注意：如果您想兼容Android N或者以上的設備，必須要在AndroidManifest.xml文件中配置FileProvider來訪問共享路徑的文件。
<!--熱更新需要的Provider-->
<provider
android:name="android.support.v4.content.FileProvider"
android:authorities="${applicationId}.fileProvider"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/provider_paths"/>
</provider>
在res目錄新建xml文件夾，創建provider_paths.xml文件如下：
<?xml version="1.0" encoding="utf-8"?>
<paths xmlns:android="http://schemas.android.com/apk/res/android">
<!-- /storage/emulated/0/Download/${applicationId}/.beta/apk-->
<external-path name="beta_external_path" path="Download/"/>
<!--/storage/emulated/0/Android/data/${applicationId}/files/apk/-->
<external-path name="beta_external_files_path" path="Android/data/"/>
</paths>
第五步：混淆配置
爲了避免混淆SDK，在Proguard混淆文件中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
# tinker混淆規則
-dontwarn com.tencent.tinker.**
-keep class com.tencent.tinker.** { *; }
三、打包
當上面的環境配置都沒有問題之後，就可以進行打包了。
打包之前，你還得配置一下編譯正式版apk所需要的keystore.jks文件，這個文件怎麼創建的就不介紹了，這裏主要介紹一下如何配置：
在app moudle目錄下的“build.gradle”中配置：
android {
signingConfigs {
release {
keyAlias 'xxxxxxxx'
keyPassword 'xxxxxxxx'
storeFile file('../keystore.jks')
storePassword 'xxxxxxxx'
}
}
...
}
其中的各項參數就不必做說明了
然後就是打包過程
打包過程中需要注意之前提到過的tinkerId的配置，以及目錄的配置，很重要哦！
生成的基準包會在這個目錄
生成的補丁包會在這個目錄
然後就準備開始使用吧
四、使用
找到你創建的產品，然後進入到下面的界面
接着，發佈新補丁吧，看一看效果
具體的效果可以自行嘗試一下，不過有時候你會遇到上傳不成功的情況，一般下發後要過5到10分鐘纔會生效（可能是我的網絡問題），如果太久沒效果，應該是哪裏出問題了
尾
前面的所有操作都嘗試過後，接下來你可能就會面臨新的需求了。比如說，多渠道打包的實現，比較舊的辦法是通過productFlavors去實現分別打包，不過這樣會有一個弊端，即有多少渠道打包流程就執行多少次，這樣效率顯然是不夠的；
於是乎，新的打包方案出來了：
使用Walle進行多渠道打包
下面是Walle的github地址：
Walle（瓦力）：Android Signature V2 Scheme簽名下的新一代渠道包打包神器
它的接入文檔寫的也十分友好，接下來實際操作一遍：
Walle的Gradle接入
在項目根目錄的 build.gradle 中添加依賴：
buildscript {
dependencies {
classpath 'com.meituan.android.walle:plugin:1.1.6'
}
}
然後在app module中的 build.gradle 添加：
apply plugin: 'walle'
dependencies {
compile 'com.meituan.android.walle:library:1.1.6'
}
並進行插件配置
walle {
// 指定渠道包的輸出路徑
apkOutputFolder = new File("${project.buildDir}/outputs/channels");
// 定製渠道包的APK的文件名稱
apkFileNameFormat = '${appName}-${packageName}-${channel}-${buildType}-v${versionName}-${versionCode}-${buildTime}.apk';
// 渠道配置文件
channelFile = new File("${project.getProjectDir()}/channel")
}
接着在app module目錄下創建一個文件，和上面配置中要保持一致，就叫 channel
360
yingyongbao
baidu
wandoujia
xiaomi
oppo
lenovo
huawei
default_channel
# 打包命令 gradlew clean assembleReleaseChannels 或者 gradlew assembleReleaseChannels
最後，在你的Application中的onCreate方法裏添加：
String channel = WalleChannelReader.getChannel(getApplication());
Bugly.setAppChannel(getApplication(), channel);
如果你實現的是SampleApplicationLike，也是在它的onCreate方法裏添加即可。
接下來通過運行上面的打包命令或者通過圖中的手動操作，都是可以打包的
末
至此，基本上整個配置流程就到此結束!!!
不過有一個問題我一直不知道如何解決，就是打包基準包的命名，在 tinker-support.gradle 進行配置是不起效果的，試了好久都沒效果，看來還得交給其他小夥伴們解決了
那麼
