Android : 代码多维度管理(产品风味)

一、关于配置产品风味

　　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-