上一篇文章 Android Studio打包全攻略—從入門到精通限於篇幅Build Variants的作用分析得還不夠，這篇文章主要探討如何構建特別定製版App。
你肯定看到過這樣的App，類似於：打豆豆小米特別定製版、XXX魅族首發版。
這些App絕大部分介面樣式、功能實現和普通版本都差不多，不過只是多了一些墜飾，比如

1. 修改了App名稱，打豆豆變成了打豆豆小米定製版
2. 修改了App的圖示，加上了渠道商或者廠商的一些標識到啟動圖示上
3. 修改啟動頁面
4. 免廣告
   本文就主要圍繞著這幾個問題，就如何優雅的生成定製App來討論

為什麼要通過Build Variants構建

為什麼要使用這種方式來打包？
要是換做以前，拿到一個這種需求，我很可能的反應是去穩定版本上checkout

1. 程式碼維護麻煩
   checkout出來一份程式碼，相當於以後需要維護兩個App，兩份程式碼。兩個版本咱們可能還不覺得有啥，但是這才一個版本定製，要是以後我們的打豆豆App，不止是要定製小米還要定製360、定製魅族、定製三星。還要區分使用者群體，推出有廣告版本，無廣告版本。推出穩定版和功能升級的Pro版本—超級打豆豆。如果每個版本都拿一個分支來做，需要維護多少個分支？要是版本升級一次，是不是每個分支都要升級？哪得需要多大的工作量。

2. 測試負擔加重
   同樣，並不是基於一套程式碼實現的App，測試的時候不可避免的產生很多重複測試。
3. 配合產品運營效率低下
   因為，這種方式造成開發緩慢、維護麻煩、測試費時造成產品跟不上節拍，效率低下。

正題—怎麼建立

生成定製版App名稱

1. 首先，如果換作從前，不考慮Gradle我們修改App名稱是怎麼做的？
   找到AndroidManifest.xml檔案，application標籤裡面的android:label標籤儲存的是App名稱
   
   看到是通過@string/app_name 也就是values資料夾下面的strings.xml檔案裡面修改
   
   看到這裡，結合上一篇學到的知識，我們大概已經知道該怎麼做了。
   a. productFlavors裡面新建一個渠道號xiaomi {}
   
   
   b.然後在src目錄、也就是main目錄的同級目錄裡面新建一個叫xiaomi的目錄，然後把values/strings.xml拷貝到目錄下面，然後修改名稱為我們希望顯示的名稱。
   
   到這裡App名稱就改好了

生成定製版圖示

有了修改App名稱的經驗，修改圖示也就輕車熟路了，只是儲存圖示的資料夾，會有hdpi、xhdpi、xxhdpi等等好幾個目錄，需要一起拷貝過去，然後分別替換裡面的圖示為我們的圖示

修改啟動頁

和修改圖示一樣

這個圖片有點抽象 不要多想，畢竟是藝術

生成廣告版和免廣告版

使用：

大功告成，我們來試試效果，為了讓我們的定製App和原來的App同時安裝上手機，我們修改applicationId

  xiaomi { applicationId 'com.xiaomi.makeapp' }

對比著原版，看看效果

productFlavors（渠道），buildTypes（Debug&Release），原版優先順序

現在我們已經清楚了，如productFlavors（渠道）裡面的檔案會覆蓋原來App的檔案。
如果我現在新建一個叫debug的資料夾，對應

buildTypes {
        debug {
            minifyEnabled false
            debuggable true
        }

，如果對Debug裡面也新增一些啟動圖示、App名稱啥的看看會是什麼效果
，還是執行Build Variant的xiaomiDebug

變成了Debug裡面的設定的資訊
根據

productFlavors > main（預設）
buildTypes > productFlavors

我們可以得出規律，為了方便閱讀就表達為優先順序是：

Release&Debug > 渠道版本定製 > 預設設定

也就是說，高的會覆蓋低的設定

AB Test

什麼是AB Test

有這樣的場景：產品經理遇到困惑，對於一個頁面有兩個方案方案A和方案B，都覺得不錯，不知道應該選哪一個。
解決辦法：方案A和方案B都放到線上，統計使用者再每個方案的駐留時長，有效點選，訂單轉換等等有效資料，然後來計算兩個方案的效率，最後取效率高的。
當然，也可以不使用Build Variants，把兩個方案都寫到一個頁面，然後訪問伺服器，伺服器返指定採用那個方案的方式來實現。