前言
在上一篇中,讲解了AGP的基础配置以及多渠道打包,在这一篇中将会进一步对AGP进行讲解。
1、Android{}
android{},由AGP引入的其他节点:
- resValue
- buildConfigField
- adbOptions
这些节点在不会默认创建需要开发者手动定义。那么这些节点对应有什么功能呢?
1.1 resValue
看这个命名感觉像是资源相关的,直接上手代码看看。
android{
...略
defaultConfig {
...略
resValue 'string', 'aaa', 'aaa'
...略
}
flavorDimensions 'channel'
productFlavors {
baidu {
dimension 'channel'
//resValue 'string', 'app_name', '自定义名称' // 不能有重复的资源节点
resValue 'string', 'bbb', 'nnnn'
}
ali {
dimension 'channel'
}
}
...略
}
结合昨天的内容,这里可以看出,在defaultConfig
与自定义产品风味里面的baidu
里面分别定义了resValue
这个属性,现在构建编译看看效果。
如图所示
当构建成功时,我们打开构建成功对应文件夹里面的内容可以看出:刚刚我们通过关键字resValue
创建的字符串资源以及帮我们构建在资源文件里面了,通过注释也表明了对应生成的资源是通过什么产品维度创建的。既然在资源文件了,那应该能够正常使用吧。现在试试效果
如图所示
当构建成功时,通过Gradle生成的资源依然能够正常使用。难么问题来了,既然Gradle能生成资源,那它能不能修改资源呢?直接上手试一下就知道了!
如图所示
右边就是自带string里面的资源值,里面的内容时自带的;而左边就是我们要准备修改的值,现在运行构建下看看效果。
当构建项目的时候,就报错了,仔细看控制台,意思就是重复资源不可通过resValue
定义。
现在总结下这个resValue
的作用
- 使用resValue可以为当前的构建产品增加资源文件属性。
- resValue ‘string’, ‘name’, ‘value’
- string表示资源标签的类型。name,资源属性名称。value,对应的属性值。
- 注意,name如果已经存在,就不能进行覆盖。
- 不同的产品风味都可以添加自己的resValue,如果要所有产品风味都添加到,可以在defalutConfig{}进行添加。
1.2 buildConfigField
- 使用buildConifgField为产品修改BulidConfig中的类型。
- BuildConfig是在产品构建时自动生成的java类,里面存放了一些静态常量,编译后可以直接使用类中的常量。
- buildConfigField ‘String’, ‘fieldName’, ‘value’
- String表示字符串类型,可以是其它Java类型,但是要注意,这里做的是文本的替换。所以,如果是其它类型,可以使用全类名的方式。
- filedName表示属性名,value则是对应的值,由于是文本替换,如果value是字符串,需要自己加入双引号
概念说了这么多,直接上手代码看看效果。
android {
compileSdkVersion 30
defaultConfig {
...略
buildConfigField 'Boolean', 'DEBUG', 'true'
buildConfigField 'int','taskId', '16'
buildConfigField 'String','BASE_URL','"http:www.baidu.com"'
...略
}
productFlavors {
baidu {
dimension 'channel'
// resValue 'string', 'app_name', '自定义名称' // 不能有重复的资源节点
resValue 'string', 'bbb', 'nnnn'
buildConfigField 'String','CHANNEL_VALUE','"BAIDU"'
}
ali {
dimension 'channel'
}
}
}
从这段代码可知,在defaultConfig
与自定义产品唯独baidu
里面 分别用了buildConfigField
关键字,然后我们编译构建看看效果。
如图所示
系统将我们在Gradle通过buildConfigField
关键字创建的那些属性定义在BulidConfig
中了。而且对应注释也标明了来自于哪个产品维度。既然属性定义在BulidConfig
中了,那么肯定也能拿到逻辑代码里面用吧,试试看看效果:
效果完美运行,到这好像又掌握一种多渠道打包获取渠道号相关的知识点。而且我们请求接口的时候,也可以将BaseUrl定义在Gradle里面了。
那么新的问题来了,我不想在工程目录里面的Gradle里面写死我的BaseUrl类似的信息,想单独放在一个文件里该怎么操作呢?
这就要用到之前学过的知识点了:脚本插件
所以定一个属于自己的脚本:
MyConfig.gradle
ext{
DEBUG = true
BASE_URL="https://juejin.cn/user/2357827986264942"
taskId=15
LOGIN_URL=BASE_URL+"/xx/xx/login"
}
这里我将BASE_URL
改成了我的掘金首页,其他也随意修改了一下,随后将这个脚本引入工程项目并修改之前的获取方式可得:
plugins {
id 'com.android.application'
id 'kotlin-android'
}
apply from:'../MyConfig.gradle'
android {
compileSdkVersion 30
defaultConfig {
applicationId "com.hqk.gradledemo04"
minSdkVersion 21
targetSdkVersion 30
versionCode 1
versionName "1.0"
resValue 'string', 'aaa', 'aaa'
buildConfigField 'Boolean', 'DEBUG', "${DEBUG}"
buildConfigField 'int','taskId', "${taskId}"
buildConfigField 'String','BASE_URL',"\"${BASE_URL}\""
buildConfigField 'String','LOGIN_URL',"\"${LOGIN_URL}\""
}
}
这里先是引入了本地脚本插件,随后将里面的属性值已经改成动态获取。现在重新编译构建看看效果。
看这效果,完美运行成功。
1.3 adbOptions
在android{}中,可以为构建类型添加adb设置。直接上手代码:
android{
...略
// adb的操作选项
adbOptions {
installOptions '-r', '-s','-d'
//-l, -t, -d, -g
// -d 允许降级安装
// -g 为应有获取所有运行时的权限
// adb install有 l, r, t, s, d, g 这6个选项。
// -l: 锁定该应用程序
// -r: 替换已经存在的应用程序,强制安装
// -t: 允许测试包
// -s: 把应用装到sd卡上
// -d: 允许进行降级安装,也就是应用的版本比手机上的版本低
// -g: 为该应用授予所有运行时的权限
}
...略
}
这个很简单,就一些配置,可以跟多个,每一项功能注释都写得很全面。读者可以自己尝试玩一下。
结束语
到这,这一篇差不多讲解完了,AGP的相关配置到这篇也差不多结束了,从下一篇开始,将会开始讲解AGP实战相关。
文章评论