第 6 章 构建变种版本.pdfVIP

第 6 章 构建变种版本 不同定制的产品 构建类型 + 定制产品 = 构建变种版本 Product Flavor 的配置 源组件和依赖关系 构建和任务 测试 Multi-flavor variants 新构建系统的 个⽬标就是允许为同 个应⽤创建不同的版本。 这⾥有两个主要的使⽤情景： 1. 同 个应⽤的不同版本。例如 个免费的版本和 个收费的专业版本。 2. 同 个应⽤需要打包成不同的apk 以发布Google Play Store 。点击此处 查看更多 详细信息。 3. 综合1和2两种情景。 这个⽬标就是要让在同 个项⽬⾥⽣成不同的 PK成为可能，以取代以前需要使⽤ 个库项⽬和两个及两个以上的应⽤项⽬分别⽣成不同 PK的做法。 不同定制的产品 个product flavor定义了从项⽬中构建了 个应⽤的⾃定义版本。 个单 的项⽬可 以同时定义多个不同的flavor来改变应⽤的输出。 这个新的设计概念是为了解决不同的版本之间的差异⾮常⼩的情况。虽然最项⽬终⽣ 成了多个定制的版本，但是它们本质上都是同 个应⽤，那么这种做法可能是⽐使⽤ 库项⽬更好的实现⽅式。 Product flavor需要在productFlavors这个DSL容器中声明： android { productFlavors { flavor1 { ... } flavor2 { ... } } } 这⾥创建了两个flavor ，名为flavor1和flavor2。 注意： flavor 的命名不能与已存在的_Build Type_或者androidTest这个 _sourceSet_有冲突。 构建类型 + 定制产品 = 构建变种版本 正如前⾯章节所提到的，每 个_Build Type_都会⽣成 个新的 PK 。 _Product Flavor_ 同样也会做这些事情：项⽬的输出将会拼接所有可能的_Build Type_ 和Product Flavor （如果有Flavor定义存在的话）的组合。 每 种组合 （包含_Build Type_和Product Flavor ）就是 个Build Variant （构建变种版 本）。 例如，在上⾯的Flavor声明例⼦中与默认的debug和release两个_Build Type_将会⽣ 成4个Build Variant ： Flavor 1 - debug Flavor 1 - release Flavor2 - debug Flavor2 - release 项⽬中如果没有定义flavor 同样也会有Build Variant ，只是使⽤的是默认的flavor和配 置。default(默认)的flavor/config是没有名字的，所以⽣成的Build Variant列表看起 来就跟_Build Type_列表 样。 Product Flavor 的配置 每 个flavor都是通过闭包来配置的： android { ... defaultConfig { minSdkVersion 8 versionCode 1 } productFlavors { flavor1 { packageName com.example.flavor1 versionCode 2 } flavor2 { packageName com.example.flavor2 minSdkVersion 14 } } } 注意_ProductFlavor_类型的ductFlavors.*对象 与android.defaultConfig对象的类型是相同的。这意味着它们共享相同的属 性。 defaultConfig为所有的flavor提供基本的配置，每 个flavor都可以重设这些配置 的值。在上⾯的例⼦中，最