我們在 app 正式釋出的時候一定會使用正式簽名的方式來打包，這種方式只能生成唯一的一個包，但是如今的應用商店非常多，如：小米、OPPO、360、百度、豌豆莢、應用寶等等。而我們只有一個 apk 檔案要投入到這麼多的應用商店中去，如果你的公司不需要統計每個應用商店的實際下載使用量的話，那倒是不會有這樣的問題。

但是，如果你的公司就是需要統計每個商店的實際下載使用情況，那麼你將如何去識別當前使用者是從哪一個商店下載來的呢？出現問題原因是：我們使用的 apk 安裝包當前僅有一個。

假設，我們可以向 apk 內植入一個字串，比如我給釋出到小米商店的 apk 中植入“xiaomi” ，然後拷貝一份 apk 安裝包釋出到小米商店中，給百度植入“baidu”，然後也拷貝一份釋出到百度商店中，然後通過 JAVA 程式碼在使用者從某一個商店中下載並使用時，我獲取這個字串，然後返回給後臺，這不就可以知道使用者從哪個商店下載了嗎！

多渠道就是指我們的應用程式可以從不同的商店下載，不同的應用商店就是不同的渠道。那你可能會有疑惑，我們為什麼要知道使用者從哪個渠道下載的呢？

這個問題其實與利益息息相關，你這樣想。假如你寫一個 app 釋出到不同的商店上，你肯定會關注究竟哪一個商店的使用者使用量比較多、下載量比較大的問題，你可能手頭沒有那麼多經濟去每一個商店平臺都推廣你的 app ，所以你要記錄哪個商店使用者量最大，然後著重推廣。

友盟打包

說了這麼多，相信你已經明白多渠道打包的重要性了。既然我們可以向每一個 apk 中植入一個標誌這商店名稱的字串，那麼如果一個一個的來的話，顯然是一個龐大的工作，沒有多大實際意義，而且 apk 檔案是無法直接向裡面新增一個外部檔案的，你需要其他的手段來實現，那麼我們先來看友盟多渠道打包的方式。

友盟的實現方式是通過 xxx.keystore 檔案來進行一個一個的壓包，通過程式碼的方式來分別生成一個你指定的應用商店的對應 apk 檔案。這種方式會比較慢，如果你的需求是要投入到幾百上千個商店的話，顯然生成檔案的速度會非常慢。但如果你的需求量在幾十上百，我建議你可以使用友盟來打包，公司也通常使用這種方式。

那麼我們看看如何實現吧！

一、引入友盟支援

在工程列表（AndroidManifest.xml）檔案中加入友盟提供的支援，這個與 Activity 並列層級。

<!-- 新增友盟支援 -->
<meta-data android:value="${UMENG_CHANNEL_VALUE}" android:name="UMENG_CHANNEL"/>

二、新增閉包

然後在 app 的 build.gradle 中新增以下程式碼，目的是為了生成對應的應用商店的 apk ，新增位置在 android 閉包下，以下程式碼不難理解。

注意：在 gradle 中是無法使用數字開頭的名字，所以你應該懂得變更一下。

 //友盟閉包
 productFlavors {
 wandoujia {}
 xiaomi {}
 baidu {}
 yingyongbao {}
 //注意 360：gradle 中不能以數字開頭
 _360{}
 }
 productFlavors.all { flavor ->
 flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
 }

這裡注意一下，也許你會報這個錯誤：

ERROR: All flavors must now belong to a named flavor dimension.

解決方法就是在上面的 defalutConfig 閉包中新增內容：

flavorDimensions "versionCode"

然後再同步一下就沒有問題了。

三、簽名打包

接下來就是打包的過程了，很簡單，我們只需要選中如下圖中的各個應用商店的版本即可，然後它就會在你設定的目錄下生成對應的 apk 檔案了。

如果對簽名打包不懂的可以看這篇文章：Android App正式簽名打包流程

這就是我的專案生成的對應的 apk 檔案所在的資料夾，點進去就會看到安裝包啦。

四、新增版本號

當然了，你可能希望加入當前 app 的開發版本號，這樣就對每個版本升級時所用的 apk 包就一目瞭然了。這是你需要把當前 app build.gradle 中的 deflautConfig閉包下的 versionName 給設定到打包生成的 apk 名中。那程式碼是這樣的：

 //為多渠道包新增 app 版本號
 applicationVariants.all { variant ->
 variant.outputs.all { output ->
  def outputFile = output.outputFile
  if (outputFile != null && outputFile.name.endsWith(".apk")) {
  def fileName = outputFile.name.replace(".apk","-${ defaultConfig.versionName }.apk")
  outputFileName = fileName;
  }
 }
 }

這是一段 groovy 語言，通常在 jvm 中使用，可以很好的和 java 程式碼配合。你只需要將它新增到剛剛寫的友盟閉包後面就可以了，如這樣：

然後你再一次打包一下，就可以在目錄中看到 apk 檔案了，一個是剛剛沒有新增的預設版本，一個是擁有版本號。

注意：這裡會有一個警告資訊，內容是這樣：

WARNING: API 'variantOutput.getPackageApplication()' is obsolete and has been replaced with 'variant.getPackageApplicationProvider()'.It will be removed at the end of 2019.

它是說這個 API 在 2019 年末將要被替換成後面的一個，不過別擔心，只要你在升級 gradle 的時候注意一下就好了，在未來它要被替換的時候，你也要做出相應的更改！

五、獲取渠道資訊

到目前為止，我們還沒真正的看到這樣打包有什麼用處。不著急，我們需要將每個 apk 檔案釋出到對應的商店以後才需要獲取這個字串，這樣才能夠真正的識別使用者在哪個商店中下載來的，然後在使用者使用量最大的商店中去大力推廣。那麼如何獲取這個字串呢？

我就簡單一點，在 MainActivity 中直接獲取這個字串了，在實際開發中，顯然是要把這個資訊傳給後臺進行統計的，不然沒有任何意義。我們的獲取程式碼如下：

還記得我們在 meta-data 中定義了 UMENG_CHANNEL 屬性的名字嗎，現在我們就可以利用它來獲取 字串 了。

import android.content.Context;
import android.content.pm.ApplicationInfo;
import android.content.pm.PackageManager;
 
public class ChannelUtil {
 public static String getChannel(Context context) {
 PackageManager pm = context.getPackageManager();
 ApplicationInfo appInfo = null;
 try {
  appInfo = pm.getApplicationInfo(context.getPackageName(),PackageManager.GET_META_DATA);
  return appInfo.metaData.getString("UMENG_CHANNEL");
 } catch (PackageManager.NameNotFoundException e) {
  e.printStackTrace();
 }
 return "";
 }
}

然後我在啟動 app 的時候使用 toast 驗證一下是否如我們想象的一樣：

獲取渠道資訊

結果沒錯，相信大家已經明白了多渠道打包的作用了，它的本質就是在簽名打包的時候嵌入一個字串，通過不同的 apk 包對應不同的商店名，然後上傳到相應的商店，最後獲取這個字串值返回給後臺。那麼，本篇關於多渠道打包的內容就這樣講完了。

以上這篇Android 多渠道(友盟)打包教程分享就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支援我們。