本文主要是讲解gradle的一丢丢优化
1、如此多的build.gradle文件
开发过程中，会经常与 gradle 的配置文件 build.gradle 打交道，如果 android studio 开启的是 android 视图，所有 build.gradle 都在 Gradle Scripts 中，要区分哪个 build.gradle 是哪个模块的，经常需要看该文件后面显示的路径或者模块名，而这些往往比较长，不太好区分。
最简单的当然是直接将build.gradle 改个名字就行了。很多人肯定自己尝试过，但发现改了名字之后，就发现根本不会生效，实际上，引入的文件是通过 settings.gradle 配置的。我们只需要在 settings.gradle 中配置指定模块的 buildFileName 即可，如：
同时，我们还可以修改根项目的 buildFileName ：
2、如此多的项目
当我们有多个 cocos 打包的 android 项目时，他们的目录都在 proj.android-studio 目录，而 gradle 默认是以目录名为项目名的，因此 gradle 项目在 android studio 中的名字也是这个名字。这就导致 android studio 的同名项目显示的是项目的绝对路径，而长长的项目路径绝对是不利于查找的
我们只需要在 settings.gradle 中修改项目的 name 即可
在project list中显示的项目名
3、如此多的包
有过多渠道包经历的人，肯定对维护几个项目 深恶痛绝，而维护一个项目的话，又有可能因为漏修改某段代码而导致逻辑的错误（非程序错误，因此打包没有任何影响）。android 的 gradle 插件非常贴心的帮我们解决了这个问题，就是productFlavors 功能。
3.1、多个包
我们只需要下面简单的配置，就可以添加oppo和vivo的包
android {
//...省略其他配置
flavorDimensions "default"
productFlavors {
oppo {
}
vivo {
}
}
}
生成的多平台的包
3.2、不同配置
既然涉及到多个包，那肯定也会碰到不同包的不同配置，这些也能轻松解决。
如果我们使用 xxx.gradle.kts 配置的话（xxx.gradle 使用的是 Groovy 实现的dsl，而 xxx.gradle.kts 使用的是 Kotlin 实现的dsl），android studio 会“贴心”的帮我们显示配置的类型：
通过上图我们可以发现，defaultConfig 配置的类型是 DefaultConfig，而 productFlavors 配置的类型是 ProductFlavor。阅读源码，我们可以发现，他俩都继承自 BaseFlavor
所以 defaultConfig 的配置，我们在 productFlavors 中都可以配置，比如包名。
注意：
我目前只使用了 包名、BuildConfig、resValue 和 Manifest占位符，其他配置是否生效未验证，但理论上应该问题不大，且通常我们要配置的也大多是以上几种。
3.3、不同参数
上一个章节末尾，我提到了我使用的 BuildConfig、resValue和Manifest占位符，他们可以非常方便的配置不同的参数。
3.3.1、BuildConfig
BuildConfig里包括了默认的一些字段，以及你配置的常量
/**
* Automatically generated file. DO NOT MODIFY
*/
package your._package.name;
public final class BuildConfig {
public static final boolean DEBUG = false;
public static final String APPLICATION_ID = "这里是你配置的包名";
public static final String BUILD_TYPE = "release";
public static final String FLAVOR = "oppo";
public static final int VERSION_CODE = 2;
public static final String VERSION_NAME = "0.0.2";
// 下面是你配置的常量
// Field from product flavor: oppo
public static final String APP_ID = "xxxxxx";
// Field from product flavor: oppo
public static final boolean FLAG = true;
// Field from product flavor: oppo
public static final int num = 11111;
}
上面展示的是一个BuildConfig的示例。
接下来，我们看看他是怎么配置的：
android {
//...省略其他配置
flavorDimensions "default"
productFlavors {
oppo {
buildConfigField "String", "APP_ID", "\"xxxxxx\""
buildConfigField "int", "num", "11111"
buildConfigField "boolean", "FLAG", "true"
}
}
}
上面的配置，实际上是调用 buildConfigField 方法来配置，因为 Groovy 语法，可以省略括号，实际上相当于 buildConfigField("String", "APP_ID", "\"xxxxxx\"")
- 第一个参数是变量类型，比如
String，int,boolean等，相信熟悉java的同学，很容易知道还有哪些类型。 - 第二个参数是变量名，只要是
java合法的标识符，都可以 - 第三个参数是变量具体的值，根据类型来配置
注意：
细心的同学可能已经发现，上面的字符串配置加了引号，这是因为插件不会根据我们设置的类型来帮我们转换配置的值，因此这里需要加上引号，表示这是一个字符串，否则生成的变量就是：
public static final String APP_ID = xxxxxx;// 这里会因为缺少引号，而编译失败
3.3.2 resValue
就是values中的配置
android {
//...省略其他配置
flavorDimensions "default"
productFlavors {
oppo {
resValue "string", "appName", "应用名"
}
}
}
与上一个章节 BuildConfig 一样，这里相当于 resValue("string", "appName", "应用名")
- 第一个参数是value的类型，比如
string，color等，熟悉android的同学，很容易知道还有哪些类型。 - 第二个参数是value的变量名，只要values目录下能配置的，这里都可以
- 第三个参数是value具体的值
这个配置相当于
在java代码中也能轻松使用（这里可能需要build一下，确保 R.java 文件更新和 gradleResValues.xml生成了）
注意：
resValue的配置不能与values目录中的配置重复，否则会出现 Error: Duplicate resources 错误
3.3.3 Manifest占位符
就是AndroidManifest.xml中的占位符，使用${xxx} 来占位
android {
//...省略其他配置
flavorDimensions "default"
productFlavors {
oppo {
manifestPlaceholders = [
"xxx": "xxxxx"
]
}
}
}
与json的object通过 {:}来配置不同， Groovy 中，[:]相当于map。这里是配置多个属性。
使用方法如下图所示
