Android多渠道打包詳細解析

1、多渠道打包概述

因爲國內存在着有衆多的應用市場，在不一樣的應用市場可能有不一樣的統計需求，爲此Android開發人員須要爲每一個應用市場發佈一個安裝包，這裏就引出了Android的多渠道打包。在安裝包中添加不一樣的標識，以此區分各個渠道，方便統計app在市場的各類效果。

所以，每當發新版本時，市場會提供一個渠道列表，Android RD會根據這些渠道相應地生成等量的渠道包。隨着渠道愈來愈多，爲了提升渠道打包的效率，所以催生了對多渠道打包的方式的研究。

本篇文章主要總結一下多渠道打包的相關知識以及美團的新舊兩種多渠道打包方案。

2、渠道包生成

Maven方式: 每打一個包都要執行一遍構建過程，效率過低;

apktool: 雖然不須要從新構建，但對每一個包都要從新簽名；

隨着渠道包的增多，每次打包動輒幾個小時，以上兩種方式的效率過低。

關於這兩種打包方式詳見：美團Android自動化之旅—生成渠道包

META-INF添加空文件

這是美團爲了提升打包效率而提出的一種新的多渠道打包方式，不須要從新構建，也不須要從新簽名。

介紹

經過解壓apk，根目錄下會有一個META-INF目錄，在該目錄下添加空文件，能夠不用從新簽名應用。所以，經過爲不一樣渠道的應用添加不一樣的空文件，能夠惟一標識一個渠道。

具體步驟

• 利用python代碼用來給apk添加空的渠道文件

• 在Java代碼中讀取空渠道文件名，識別渠道

具體代碼在上面美團生成多渠道包的連接中有詳細給出。

Walle

Walle（瓦力）：Android Signature V2 Scheme簽名下的新一代渠道包打包神器

瓦力經過在Apk中的APK Signature Block區塊添加自定義的渠道信息來生成渠道包，從而提升了渠道包生成效率，能夠做爲單機工具來使用，也能夠部署在HTTP服務器上來實時處理渠道包Apk的升級網絡請求。

原理介紹

Android 7.0（Nougat）引入一項新的應用簽名方案APK Signature Scheme v2，它是一個對全文件進行簽名的方案，能提供更快的應用安裝時間、對未受權APK文件的更改提供更多保護，在默認狀況下，Android Gradle 2.2.0插件會使用APK Signature Scheme v2和傳統簽名方案來簽署你的應用。

新應用簽名方案的簽名信息會被保存在區塊（APK Signing Block）中， 而區塊（Contents of ZIP entries）、區塊（ZIP Central Directory）、區塊（ZIP End of Central Directory）是受保護的，在簽名後任何對其的修改都逃不過新的應用簽名方案的檢查。

以前的渠道包生成方案是經過在META-INF目錄下添加空文件的打包方式在Signature Scheme v2的簽名方式下不可以使用了，由於META-INF已經被列入了保護區了，向META-INF添加空文件的方案會對上面受保護的三個區塊都有影響。

經過上面描述發現區塊（APK Signing Block）是不受簽名校驗規則保護的，所以Walle正是經過在該區塊作文章，寫入渠道信息。

具體步驟

• 對新的應用簽名方案生成的APK包中區塊（APK Signing Block）寫入渠道信息，並保存在APK中

• APK在安裝過程當中進行的簽名校驗，是忽略咱們添加的渠道信息的，這樣就能正常安裝了

• 在App運行階段，能夠經過ZIP的End of central directory、Central directory等結構中的信息找到咱們本身添加的渠道信息，從而實現獲取渠道信息的功能

最終，每打一個渠道包只需複製一個APK，而後在APK中添加一個渠道信息便可，這種打包方式速度很是快。

使用方式

• Gradle插件方式，方便快速集成

• 命令行方式，最大化知足各類自定義需求

關於Walle兩種使用方式的詳細步驟，參見：Android使用walle多渠道打包

3、渠道包適配

上述多渠道打包方式解決了打包慢的問題，可是隨着渠道愈來愈多，不一樣渠道對應用的要求也不盡相同。

例如，有的渠道要求app的應用名不一樣，有些渠道要求應用不能使用第三方統計工具，有些渠道要求應用不能自動更新。

以前的作法是爲每一個須要適配的渠道建立一個Git分支，發版時再切換到相應的分支，併合並主分支的代碼。適配的渠道比較少的話這種方式還能夠接受，隨着適配渠道的增多，這種方式就變得不可取。

幸虧Gradle flavor，能夠知足渠道適配的需求，只須要經過配置Gradle便可以實現多渠道的適配工做，省心省力。

Flavor

先來看build.gradle文件中的一段代碼：

android {
    ....

    productFlavors {
        flavor1 {
            minSdkVersion 14
        }
    }
}
複製代碼

上例定義了一個flavor：flavor1，並指定了應用的minSdkVersion爲14（固然還能夠配置更多的屬性，具體可參考相關文檔）。與此同時，Gradle還會爲該flavor關聯對應的sourceSet，默認位置爲src/<flavorName>目錄，對應到本例就是src/flavor1。

接下來，要作的就是根據具體的需求在build.gradle文件中配置flavor，並添加必要的代碼和資源文件。以flavor1爲例，運行gradle assembleFlavor1命令既可生成所需的適配包。經過適配不一樣的flavor便可以生成不一樣的渠道包，但該方式生成渠道包的方式須要重複編譯構建。

具體示例

使用不一樣的包名

productFlavors {
    qq {
        applicationId "com.hello.group.qq"
    }
}
複製代碼

面的代碼添加了一個名爲qq的flavor，並指定了應用的包名爲com.hello.group.qq，運行gradle assembleqq命令便可生成qq適配包。

使用不一樣的應用名

Gradle在構建應用時，會優先使用flavor所屬sourceSet中的同名資源。因此，解決思路就是在flavor的sourceSet中添加同名的字符串資源，以覆蓋默認的資源。

首先，在build.gradle配置文件中添加以下flavor：

android {
    productFlavors {
        wandoujia { 
        }
    }
}
複製代碼

上面的配置會默認src/wandoujia目錄爲wandoujia flavor的sourceSet。

接下來，在src目錄內建立wandoujia目錄，並添加以下應用名字符串資源（src/wandoujia/res/values/appname.xml）：

<resources>
    <string name="app_name">wandoujia_app</string>
</resources>
複製代碼

默認的應用名字符串資源以下（src/main/res/values/strings.xml）:

<resources>
    <string name="app_name">origin_app</string>
</resources>
複製代碼

最後，運行gradle assembleWandoujia命令便可生成應用名爲wandoujia_app的應用了。

wandoujia包下不使用strings.xml 名是由於會出現文件重複，默認的main 文件夾裏存在的文件在其餘適配目錄中不容許出現相同文件名的文件。

更多flavor適配示例，參見：美團Android自動化之旅—適配渠道包

以上就是最近了解關於多渠道打包的相關知識的總結。

想要實現更多自定義適配多渠道包的需求，還要更多的瞭解Gradle相關知識。