3.为Android构建变种版本

变种版本存在的原因

一个目标就是允许为同一个应用创建不同的版本

这里有几个主要的使用情景：

1、同一个应用的不同版本。例如一个免费的版本和一个收费的专业版本

2、同一个应用需要打包成不同的apk以发布应用市场。相关详细资料可以查阅http://developer.android.com/google/play/publishing/multiple-apks.html

3、综合1和2两种情景

这个目标就是要让在同一个项目里生成不同的APK成为可能，以取代以前需要使用一个库项目和两个及两个以上的应用项目分别生成不同APK的做法

---

Project Flavor

想要知道怎么构建变种版本，必须先了解一个Project Flavor的概念，一个Project Flavor定义了从项目中构建了一个应用的自定义版本。一个单一的项目可以同时定义多个不同的flavor来改变应用的输出。这个新的设计概念是为了解决不同的版本之间的差异非常小的情况。虽然最项目终生成了多个定制的版本，但是它们本质上都是同一个应用，那么这种做法可能是比使用库项目更好的实现方式

Product flavor需要在Module下的build.gradle文件中的productFlavors这个DSL容器中声明，例如下面这样定义

android {
    ....

    productFlavors {
        flavor1 {
            ...
        }

        flavor2 {
            ...
        }
    }
}

其中flavor1、flavor2是版本名称
注意：flavor的命名不能与已存在的Build Type或者androidTest这个sourceSet有冲突

---

如何构建变种版本

首先，我们来看看具体Build Type是怎么定义的

android {  
     buildTypes {  
          debug {  
               applicationIdSuffix ".debug"  
           }  
           jnidebug.initWith(buildTypes.debug)  
           jnidebug {  
               packageNameSuffix ".jnidebug"  
               jnidebugBuild true  
           }  
      }  
}  

从以上的代码我们不难看出，每一个Build Type都会生成一个新的APK。殊不知，Product Flavor同样也会做这些事情，那有人可能会问，到底项目输出的时候是以哪个为准呢？

其实，项目的输出将会拼接所有可能的Build Type和Product Flavor（如果有Flavor定义存在的话）的组合，这样拼接出来的才构成了最终的变种版本，简而言之就是下面这个公式

Build Type + Product Flavor = Build Variant

即：每一种组合（包含Build Type和Product Flavor）就是一个Build Variant（构建变种版本）