我們經(jīng)常會遇到對于一個工程，想要針對不同的渠道而展示不一樣的效果，這種情況下，以前的做法可能會重開一個分支，針對特殊需求在新的分支上修改，但是這種情況比較繁瑣，而且如果渠道很多，這種辦法是效率極差的。

Android Studio中的Gradle插件中的productFlavor為我們提供了很多便利，那其具體可以為我們省去多少工作，又可以達(dá)到什么樣的效果呢？
productFlavor

實質(zhì)上就是我們打包時使用到的渠道配置，其配置的位置，就在我們項目中主module中的build.gradle中，如下：

android {
    productFlavors {
         a{
             ...
         }
         b {
             ...
         }
    }

}

上述，分別建了兩個flavor a、b，經(jīng)過上述配置之后，可以看到build變量也增加如下：
這里寫圖片描述
這樣我們就可以通過切換build變量后運(yùn)行，看到不同flavor下的app。
我們可以做些什么？
配置不同的包名

productFlavors {
    // 不設(shè)置，繼承defaultConfig中的配置
    a {
    }
    b {
       applicationId "com.example.android.myapplication.b"
    }
}

上述如果不進(jìn)行配置，則會使用我們默認(rèn)的配置

通過以上的配置，兩個flavor已對應(yīng)不同的包名，這樣可以將不同包名的應(yīng)用同時安裝到同一個終端上，同時查看兩個app的效果。
修改資源

最明顯的就是應(yīng)用名、應(yīng)用圖標(biāo)等，在我們原本的工程，這部分資源是存放于main/res/下，那我們?nèi)绻胍鼡Q這些資源很應(yīng)該怎么做呢？

有了product flavor后非常簡單，只需要在與main同級下創(chuàng)建與想要配置的flavor名相同的文件夾，并在其中放置想修改的資源文件即可。

如我們想要更改應(yīng)用名，則做如下操作
這里寫圖片描述
即在src下與main同級，創(chuàng)建b文件夾，添加values文件夾，并添加了strings.xml文件，并在其中添加內(nèi)容：

<resources>
    <string name="app_name">b</string>
</resources>

然后此時選擇build變量為a，運(yùn)行，切換為b，再運(yùn)行，即可看到模擬器上存在兩個app，一個是我們a，應(yīng)用名為My Application，另一個為b，應(yīng)用名為b
這里寫圖片描述
以上基本就實現(xiàn)了應(yīng)用名的替換。

當(dāng)然res下的文件基本是可以替換的，包括布局，圖片等，但是要記住其對應(yīng)的文件目錄、文件名要和main/res/下的保持一致。
AndroidManifest.xml

android應(yīng)用的很多東西都是在該配置文件中配置的，我們切換app，其中的一些配置也需要修改，那這些修改怎么配置呢？

同理，我們也需要將該文件，放置于我們新建的flavor文件夾下，在build時，這里的配置會與原來的配置進(jìn)行合并，但是需要注意一些東西：
1、新建的文件中application部分是不能省略的
2、如果我們更換其中的一些配置值，如在meta-data的值，則需要對該部分配置，加上replace標(biāo)志，如下：

<meta-data
    android:name="key"
    android:value="value"
    tools:node="replace"/>

如果不加replace標(biāo)志，則會發(fā)現(xiàn)報錯，有重復(fù)的key存在。

3、有一些值像scheme，親試，以上述方式是無法正確更換的，像這種情況應(yīng)該怎么辦呢？

我們可以從build.gradle文件中falvor的配置上著手，增加manifestPlaceholders，配置一些key-value值：

productFlavors {
   // 不設(shè)置，繼承defaultConfig中的配置
   a {
      manifestPlaceholders=[scheme:"a"]
   }
   b {
      applicationId "com.example.android.myapplication.b"
      manifestPlaceholders=[scheme:"b"]
   }
}

<activity android:name=".MainActivity">
   <intent-filter>
       <action android:name="android.intent.action.MAIN" />
       <category android:name="android.intent.category.LAUNCHER" />
       <data android:scheme="${scheme}"/>
   </intent-filter>
</activity>

如上，為兩個flavor加入了scheme，在配置文件中使用時，直接使用${scheme}即可。通過這樣的方式，配置文件中的內(nèi)容即根據(jù)不同的flavor而使用不同的值。
修改邏輯

有些情況，我們無法通過像上述的一些方式去直接改變這些值，那怎么能在代碼中對flavor進(jìn)行區(qū)分呢？

從上述可以看到，如果配置了多個flavor，則會與buildType（release、debug）進(jìn)行搭配產(chǎn)生新的build變量，buildType可以從BuildConfig中獲取到，那么flavor同樣也可以，我們可以看一下BuildConfig文件的內(nèi)容：

package com.example.android.myapplication;

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String APPLICATION_ID = "com.example.android.myapplication.b";
  public static final String BUILD_TYPE = "debug";
  public static final String FLAVOR = "b";
  public static final int VERSION_CODE = 1;
  public static final String VERSION_NAME = "1.0";
}

從上述可以看到其中有一個常量FLAVOR，其值就是我們配置的flavor。那么在代碼中就可以使用BuildCoonfig.FLAVOR來進(jìn)行判斷，進(jìn)而進(jìn)行不同的操作。
分flavor打包要怎么打呢？

打指定flavor包：gradlew assemble(flavor)(Debug|Release)
如我們的例子中

根據(jù)我們配置的flavor，有以下的組合：

gradlew assembleA(Debug|Release) 
gradlew assembleB(Debug|Release) 

總結(jié)

productFlavor還是為我們的分渠道提供了很多便利的，我們只需要將不一致的地方代替即可，在build過程中會進(jìn)行合并，最終達(dá)到我們想要的效果。
————————————————
原文鏈接：https://blog.csdn.net/cherish1260/article/details/78498304