walle多渠道打包+Tinker(bugly)熱更新集成+360加固(樂固)

這三個東東是幹啥的相信你們都有所耳聞了，若是你沒有據說過，請出門左拐，百度一下你就知道。這裏不對這三個東東具體的集成方式作詳細的介紹，由於官方文檔已經寫的很詳細了，主要是對同時使用這三個東東時所須要注意的關鍵點進行填坑。

多渠道打包

項目本來使用的打包方式是傳統的方式，相信你們都知道的，就是經過build.gradle中定義好各個渠道：

productFlavors {
        yingyongbao {
            manifestPlaceholders = [UMENG_CHANNLE: "yingyongbao"]
        }
        baidu {
            manifestPlaceholders = [UMENG_CHANNLE: "baidu"]
        }
    }

而後在AndroidManifest.xml中定義：

<meta-data
            android:name="UMENG_CHANNEL"
            android:value="${UMENG_CHANNEL}" />

而後執行打包命令後就是漫長的打包等待....
差很少每次打包都要花費1，2個小時(咱們每次差很少打20個包🙈)...，而後就是對每一個包進行360加固，這個時間看網速，差很少也是1，2個小時...

然而最無奈的是想集成Tinker的時候，sorry，Tinker不支持這種打包方式....🌚
Tinker推薦了新一代的打包工具walle，walle是什麼？
傳送門：https://github.com/Meituan-Dianping/walle
walle怎麼集成官方文檔已經說的很清楚了，我在這裏就不在累述了。。

關鍵點是(敲黑板)：若是你集成了Umeng等第三方的數據統計SDK，能夠經過代碼設置，而再也不經過定義meta-data的方式。Umeng的方式以下：

String channel = WalleChannelReader.getChannel(mApplication,"Official");
MobclickAgent.startWithConfigure(new MobclickAgent.UMAnalyticsConfig(mApplication,
                "key id",
                channel));

walle集成好後打渠道包試一下，這速度簡直不是一個數量級的...

Tinker熱更新集成

爲了更新方便，我這裏使用的bugly，這樣不用本身搭建服務器管理補丁，同時bugly自帶了應用的升級功能，仍是比較方便的。bugly的集成相對來講稍微複雜一些，主要是要細心，特別是測試的時候，要反覆改一些東西，這裏我花了挺多時間。。。 官方文檔連接：
傳送門: https://bugly.qq.com/docs/user-guide/instruction-manual-android-hotfix/?v=20180521124306

關鍵點：主要是tinker-support.gradle中的配置，最重要的有幾點：

• 1. tinkerId的配置，通常是定義成版本號，基線版本通常是base-version，補丁通常是patch-version(其中version對應你本身的版本號)，在發版的時候必定要記得修改這個值，bugly會根據這個來匹配對應補丁的版本的。
     
• 1. baseApkDir的配置，這個參數是打補丁的時候纔用到，打基線版本的時候這個是沒用的，我就是這個參數沒理解，不知道幹啥用的，後來試了幾回後才知道。在打包的時候tinker會在module的build/bakApk/目錄下生成基線版本(文件夾名稱是應用名稱-打包時間)，還有R文件和mapping混淆文件(若是你的應用使用了混淆), 記得把這些文件進行保存，在打補丁包的時候會須要這些文件。
     在須要打補丁的時候，在module的build下新建bakApk文件夾，而後在bakApk文件夾下新建一個文件夾，好比v1.0.0，這個能夠自定義，而後將基線版本文件，包括R文件和mapping混淆文件拷貝到這個文件夾下，而後將baseApkDir參數改成你自定義的文件名，這個時候baseApkDir這個參數纔有用，記得要保證配置的baseApk，baseApkProguardMapping，baseApkResourceMapping與你拷貝進去的文件名路徑一致，不然編譯的時候會出錯，而後修改tinkerId爲patch-version，以後就能夠運行tinker-support的buildTinkerPatchRelease task。注意：是tinker-support下不是tinker下。
     
     運行完成後會在build/outputs/patch/release/下生成幾個文件，將patch_signed_7zip.apk文件上傳到bugly熱更新後臺，下發補丁便可。
     

到這裏tinker也算集成好了，而後就是打開APP測試一下，能夠經過logcat查看補丁是否合併成功。

360加固(騰訊的樂固也能夠的)

如今基本每一個上線的應用都不會裸奔了，都會選擇各類加固，具體的加固方法很簡單，只須要上傳apk包到後臺，而後加固好後從新下載過來簽名就能夠了。 這裏不作詳細的介紹了...

若是walle和tinker都已經集成好了，那麼恭喜你，還有另一個坑等着你....
當你使用walle打了渠道包後進行加固簽名，你會發現寫入的渠道信息丟失。。。 不要懷疑這不是你的姿式不對，加固從新簽名後渠道信息會丟失，同時加固簽名後tinker熱更新也無效了，logcat中會提示合併失敗了... WTF? 莫雞凍，解決辦法仍是有的，這裏要使用到一位大神的工具了：
傳送門 https://github.com/Jay-Goo/ProtectedApkResignerForWalle
這個工具是專門解決360加固後渠道丟失問題的。

下面開始解決問題：

• 1. 開啓tinker的加固支持，默認是關閉的。打開tinker-support.gradle，設置isProtectedApp = true(默認是被註釋了，取消註釋便可)。
     
• 1. 再也不使用walle的./gradlew clean assembleReleaseChannels生成各個渠道包，而是使用./gradlew clean assembleRelease生成基線版本包。
• 1. 生成的基線版本包就是在集成tinker提到的基線包，通常在build/bakApk/應用名-時間的文件夾下，將基線版本包上傳到360後臺進行加固，加固好後下載下來，不要進行簽名，要經過上面提到的工具進行簽名。
• 1. 將 https://github.com/Jay-Goo/ProtectedApkResignerForWalle 工具下載下來，將集成walle時候配置的channel文件拷貝到根目錄，將下載的加固後的apk也拷貝的根目錄下，按照官方文檔修改配置文件，配置祕鑰和文件路徑信息，注意配置的sdkBuildTool的路徑，這是你的Android Sdk的build tools的路徑，建議25.0以上。配置好後運行命令：
     python ApkResigner.py
     這個過程很快，只須要幾秒鐘，成功後會有提示，會在根目錄下生成channels文件夾，該文件夾下的就是生成好的各個渠道包了。 該渠道包已經完成了簽名和渠道寫入，同時能夠支持tinker熱更新了😊

OK了，到此整個過程就搞定了，能夠拿生成的渠道包分發到各個渠道了。

不多寫博客，寫的很差還請大路大神不吝賜教，還有不明白的給我留言討論吧...