前言

許久沒寫東西了，換了新工作，新環境，剛來就進行了坑人的拓展訓練，繼而迎來的是沒人性的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、下面進行圖文解析

這個檔案中的其他東西沒有需要的話可以不用再動了，檔案的路徑名稱，按照自己的需要進行更改

下面就是要開始打基準包了

5、直接執行./gradlew clean assembleRelease 就可以看到在app中的build目錄下會按照日期生成一個檔案

裡面有我們的R.txt,mapping.txt,和我們的基準包.apk檔案 如果沒有mapping.txt,請確認你的混淆是不是開啟了

6、下面就是修改程式碼，修改第4項第2張圖中的路徑，改成我們build目錄下的那個資料夾目錄

     然後修改tinkerId 為補丁包patch的值

     執行./gradlew clean buildTinkerPatchRelease  執行完畢後，生成如下圖檔案

其中patch_signed_7zip.apk就是我們所需要的補丁包

7、開啟bugly官網

選擇你的補丁包上傳即可～～～～

正題--多渠道打包

bugly雖然是支援多渠道打包的,但是如果我們在productFlavors配置渠道，當我們執行

./gradlew clean buildTinkerPatchRelease 命令的時候

會造成對每個渠道都生成一個補丁包,這樣我們要下發補丁包的時候就要下發很多個，這顯然不是我們想要的效果。

這裡我們就來推薦新一代打包神器walle

// 多渠道使用walle示例（注：多渠道使用）
apply from: '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'

然後執行

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