天天看點
傳回

Bugly熱修複使用及多管道打包

Bugly熱修複使用及多管道打包

    • 頭
    • 身
      • 一、為什麼要用Bugly
      • 二、Bugly熱更新接入流程
        • 第一步：添加依賴插件
        • 第二步：添加依賴插件
          • gradle配置
          • tinker-support.gradle的配置
        • 第三步：初始化SDK
          • 自定義Application，當enableProxyApplication為false的情況
          • 自定義Application，當enableProxyApplication為true的情況
        • 第四步：AndroidManifest.xml配置
          • 1.權限配置：
          • 2.Activity配置：
          • 3.配置FileProvider
        • 第五步：混淆配置
      • 三、打包
      • 四、使用
    • 尾
      • 使用Walle進行多管道打包
        • Walle的Gradle接入
    • 末

頭

不知道你是否遇到過這個情況，項目上線後或者開始給别人使用的時候，冷不丁的冒出個Bug，這時候首先要幹嘛？

先看崩潰日志啊

看完崩潰日志你知道了造成崩潰的原因，然後幹嘛？

開始甩鍋啊

當查明了是誰造成的這個崩潰後，你發現不是你的問題，于是你心中一樂，長舒一口氣，仰天大笑：碼海沉浮又幾載，我輩豈是蓬蒿人；笑完便準備躺床上睡覺去——秋豆麻袋，是不是忘了什麼東西？

是的，即使你發現了問題，并且找到了問題的來源，這時候還差一步：解決問題的辦法！如何解決？

釋出新版本？

這樣不覺得很麻煩嗎？特别是如果一個項目處于初期階段，Bug是想甩都甩不掉的，如果每發現一次崩潰，都需要靠釋出一個新版本去解決的話，那未免就太麻煩了。不光是開發者麻煩，使用者也會因為頻繁的更新而不耐煩（just like me），那問題又回來了，如何解決？

熱修複啊

通過線上修複Bug，讓使用者在神不知鬼不覺的情況下就進行了一次應用更新，麻麻再也不用擔心App崩潰啦！（不存在的）

熱修複還有個隐藏的好處，那就是在測試人員不夠（開發兼測試），測試機型不夠的情況下可以顯著改善App的崩潰率。好吧，準備開始使用吧。

身

一、為什麼要用Bugly

市面上關于熱修複和崩潰日志監測的相關技術和SDK種類各不相同，為什麼偏偏要用Bugly呢？

  • 可以擷取到App崩潰日志
  • 可以內建Think熱修複
  • 界面好看，友善管理版本
  • 免費
  • （湊巧就用了這一款，其他的都沒有用過）

基于以上原因，最後就使用了Bugly去解決上面提到過的問題；

二、Bugly熱更新接入流程

其實關于Bugly熱更新的詳細接入流程，官方的文檔介紹的非常詳細，對新手比較友好，我第一次使用也是直接參照的文檔，下面是官方文檔的位址：

【Bugly Android熱更新使用指南】

雖然官方有例子，這裡還是寫了一個簡化版，也友善以後哪天自己忘記了依舊能快速使用：

第一步：添加依賴插件

在你的項目更目錄下的“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'
        }
    }
    ...
}

其中的各項參數就不必做說明了

然後就是打包過程

Bugly熱修複使用及多管道打包

打包過程中需要注意之前提到過的tinkerId的配置，以及目錄的配置，很重要哦！

生成的基準包會在這個目錄

Bugly熱修複使用及多管道打包

生成的更新檔包會在這個目錄

Bugly熱修複使用及多管道打包

然後就準備開始使用吧

四、使用

找到你建立的産品，然後進入到下面的界面

Bugly熱修複使用及多管道打包

接着，釋出新更新檔吧，看一看效果

Bugly熱修複使用及多管道打包

具體的效果可以自行嘗試一下，不過有時候你會遇到上傳不成功的情況，一般下發後要過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方法裡添加即可。

接下來通過運作上面的打包指令或者通過圖中的手動操作，都是可以打包的

Bugly熱修複使用及多管道打包

末

至此，基本上整個配置流程就到此結束!!!

不過有一個問題我一直不知道如何解決，就是打包基準包的命名，在 tinker-support.gradle 進行配置是不起效果的，試了好久都沒效果，看來還得交給其他小夥伴們解決了

那麼

Bugly熱修複使用及多管道打包
bugly android 熱修複 crash 熱更新
上一篇: VC++ 導出Excel表格執行個體
下一篇: Android 騰訊 Bugly 熱修複

繼續閱讀