Android : 代碼多維度管理(產品風味) - flavorDimensions & productFlavors

一、關於配置產品風味

　　Android studio 升級到3.0之后，gradle增加了多維度管理配置，便於同一個項目中創建應用的不同版本，分別管理依賴項並簽署配置。創建產品風味與創建構建類型類似：只需將它們添加到 productFlavors {} 代碼塊並配置您想要的設置。產品風味支持與 defaultConfig 相同的屬性，這是因為 defaultConfig 實際上屬於 ProductFlavor 類。這意味着，您可以在 defaultConfig {} 代碼塊中提供所有風味的基本配置，每種風味均可更改任何這些默認值，例如 applicationId。當您創建新模塊時，Android Studio 會自動為您創建調試和發布這兩種構建類型。盡管調試構建類型不會出現在構建配置文件中，Android Studio 會為其配置 debuggable true。這樣，您可以在安全的 Android 設備上調試應用並使用通用調試密鑰庫配置 APK 簽署。官網示例：

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list each dimension determines its priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig {} block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property above--the first dimension has a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion '24'
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level. To learn more about assigning version codes to
      // support app updates and uploading to Google Play, read Multiple APK Support
      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion '23'
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion '21'
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

 通過以上配置，就可以編譯出多維度apk，以上示例可根據 "api" + "mode" 2個維度分別配置多個產品：

　　① minApi21 的 demo 、②minApi21 的 full 、③minApi23 的 demo 、④minApi23 的 full 、⑤minApi24 的 demo  、⑥minApi24 的 full

 

二、小試牛刀

　　從以上官網介紹可知產品多維度，即是在同一個工程上配置編譯出各風味的apk版本，比如：演示用的簡化版的和完整功能release版、兩個平台UI的差異、多個項目之間功能增減...等等，通過多維度配置就不用一個版本維護一份工程，也不會因判斷邏輯太多，導致代碼臃腫。下面簡單使用一下多版本管理的工具–priductFlavors：

　　（1）在 build.gradle 中添加自定義的風味維度：

    // Specifies a flavor dimension.
    flavorDimensions "mode", 'platform'

    // 多渠道定義
    productFlavors {
        orginal {
            // Assigns this product flavor to the 'mode' flavor dimension.
            // This step is optional if you are using only one dimension.
            dimension "mode"
        }

        phone {
            dimension "platform"
            versionNameSuffix "-slide"
        }

        tv {
            dimension "platform"
            versionNameSuffix "-button"
        }
    }

　　（2）同步、配置：

　　　　  在build.gradle添加自定義維度同步后，可在 build/generated/source/buildConfig目錄下找到對應的產品型號目錄（默認是生成當前Build Variant配置的），也分別有debug和release的版本：

 

　　　　添加自定義維度后也可通過Gradle或者在Terminal中使用命令‘gradlew :app:assembleRelease’直接構建打包，生成對應版本的apk：

　　　（3）代碼中獲取配置文件"BuildConfig.java"中的各變量來實現對應型號產品特定的功能和邏輯:

　　　　      上面構建打包的apk內部代碼邏輯是有差異的，首先看看生成的 BuildConfig.java 內容，及各版本的差異：

①release和debug版本的差異：　　　　　

　　　　②phone平台和tv平台版本的差異：

　　

　　因此，在java代碼中可以通過如下方式分別實現代碼邏輯（以下通過FLAVOR變量控制，也可使用或搭配其他變量）：

　　比如在我本地工具類 Utils.java 中定義了對應的字符串變量，對應 BuildConfig.java中生成的值：

    public static final String FLAVOR_Phone = "orginalPhone";
    public static final String FLAVOR_Tv = "orginalTv";

　　然后其它功能類的代碼中就可以通過判斷當前的配置變量實現對應型號的邏輯：

                if (Utils.FLAVOR_Phone.equals(BuildConfig.FLAVOR)) {
                    //手機平台想實現的代碼邏輯
                } else if (Utils.FLAVOR_Tv.equals(BuildConfig.FLAVOR)) {
                    //電視機平台想實現的代碼邏輯
                } else {
                    //默認配置平台想實現的代碼邏輯
                }

 

　　此后，便可以通過 Build Variant 來選擇某個配置，編譯出對應的apk版本，而不用改動或者分別維護一份代碼。

 

-end-