史上最全adle配置详解（⼩结）
Android Studio是采⽤gradle来构建项⽬的，gradle是基于groovy语⾔的，如果只是⽤它构建普通Android项⽬的话，是可以不去学groovy的。当我们创建⼀个Android项⽬时会包含两个adle配置详解⽂件，如下图：
⼀、Project的adle⽂件：
对应的adle代码如下：
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {//这⾥是gradle脚本执⾏所需依赖，分别是对应的maven库和插件
repositories {
google()//从Android Studio3.0后新增了google()配置，可以引⽤google上的开源项⽬
jcenter()//是⼀个类似于github的代码托管仓库，声明了jcenter()配置，可以轻松引⽤ jcenter上的开源项⽬
}
dependencies {
classpath 'ls.build:gradle:3.0.0'////此处是android的插件gradle，gradle是⼀个强⼤的项⽬构建⼯具
// NOTE: Do not place your application dependencies here; they belong
// in the individual adle files
}
}
allprojects {//这⾥是项⽬本⾝需要的依赖，⽐如项⽬所需的maven库
repositories {
google()
jcenter()
}
}
// 运⾏gradle clean时，执⾏此处定义的task任务。
/
/ 该任务继承⾃Delete，删除根⽬录中的build⽬录。
// 相当于执⾏Delete.delete(rootProject.buildDir)。
// gradle使⽤groovy语⾔，调⽤method时可以不⽤加（）。
task clean(type: Delete) {
delete rootProject.buildDir
}
buildscript{}闭包⾥是gradle脚本执⾏所需依赖，分别是对应的maven库和插件。
allprojects{}闭包⾥是项⽬本⾝需要的依赖，⽐如项⽬所需的maven库。
task clean(type: Delete){}是运⾏gradle clean时，执⾏此处定义的task任务，该任务继承⾃Delete，删除根⽬录中的build ⽬录。其中buildscript包含repositories闭包和dependencies闭包。
repositories{}闭包：配置远程仓库
该闭包中声明了jcenter()和google()的配置，其中jcenter是⼀个代码托管仓库，上⾯托管了很多Android开源项⽬，在这⾥配置了jcenter后我们可以在项⽬中⽅便引⽤jcenter上的开源项⽬，从Android Studio3.0后新增了google()配置，可以引⽤google上的开源项⽬。
dependencies{}闭包：配置构建⼯具
该闭包使⽤classpath声明了⼀个Gradle插件，由于Gradle并不只是⽤来构建Android项⽬，因此此处引⼊相关插件来构建Android项⽬，其中'3.3.3'为该插件的版本号，可以根据最新的版本号来调整。
⼆、Module的adle⽂件：
从⽂件内容可以看出，主要分为三⼤部分，如下图所⽰：
1、apply plugin：
// 声明是Android程序，
/
/com.android.application 表⽰这是⼀个应⽤程序模块
//com.android.library 标识这是⼀个库模块
//⽽这区别：前者可以直接运⾏，后着是依附别的应⽤程序运⾏
apply plugin: 'com.android.application'
⽂件中第⼀⾏使⽤apply plugin表⽰应⽤了⼀个插件，该插件⼀般有两种值可选：
'com.android.application'，表⽰该模块为应⽤程序模块，可以直接运⾏，打包得到的是.apk⽂件
'com.android.library'，表⽰该模块为库模块，只能作为代码库依附于别的应⽤程序模块来运⾏，打包得到的是.aar⽂件2、android{}闭包：
这个闭包主要为了配置项⽬构建的各种属性：
2.1、添加signingConfigs{}闭包：
signingConfigs {// ⾃动化打包配置
release {// 线上环境
keyAlias 'test'
keyPassword '123456'
storeFile file('test.keystore')
storePassword '123456'
}
debug {// 开发环境
keyAlias 'test'
keyPassword '123456'
storeFile file('test.keystore')
storePassword '123456'
}
}
可以⼿动添加签名配置，也可以通过Project Structure 选中app，点击Singing添加，具体步骤如下图所⽰：
签名配置完成后可以⽅便带签名打包，在module的Build Variants中有两个Type，分别是debug和release，可以选择任意⼀个类型进⾏打包，并且他们会利⽤各⾃配置的Key进⾏打包，执⾏ Run app或者Build->Build apk就会⾃动在module
name/app/build/outputs/apk路径下⽣成Apk⽂件。另⼀种打包⽅式是Build->Generate Signed APK填写签名信息⽣成Apk。
2.2、compileSdkVersion：设置编译时⽤的Android版本
2.3、buildToolsVersion：设置编译时使⽤的构建⼯具的版本，Android Studio
3.0后去除此项配置
2.4、defaultConfig{}闭包：
compileSdkVersion 27//设置编译时⽤的Android版本
defaultConfig {
applicationId "application"//项⽬的包名
minSdkVersion 16//项⽬最低兼容的版本
targetSdkVersion 27//项⽬的⽬标版本
versionCode 1//版本号
versionName "1.0"//版本名称
testInstrumentationRunner "st.runner.AndroidJUnitRunner"//表明要使⽤AndroidJUnitRunner进⾏单元测试
}
1. applicationId ：指定了项⽬的包名。
2. minSdkVersion ：指定项⽬最低兼容的版本，如果设备⼩于这个版本或者⼤于maxSdkVersion(⼀般不⽤)将⽆法安装这
个应⽤，这⾥指定为16，表⽰最低兼容到Android 4.1系统。
3. targetSdkVersion ：指定项⽬的⽬标版本，表⽰在该⽬标版本上已经做过充分测试，系统会为该应
⽤启动⼀些对应该⽬
标系统的最新功能特性，Android系统平台的⾏为变更，只有targetSdkVersion的属性值被设置为⼤于或等于该系统平台的API版本时，才会⽣效。例如，若指定targetSdkVersion值为22，则表⽰该程序最⾼只在Android5.1版本上做过充分测试，在Android6.0系统上（对应targetSdkVersion为23）拥有的新特性如系统运⾏时权限等功能就不会被启⽤。
4. versionCode ：表⽰版本号，⼀般每次打包上线时该值只能增加，打包后看不见。
5. versionName ：表⽰版本名称，展⽰在应⽤市场上。
6. testInstrumentationRunner "st.runner.AndroidJUnitRunner"表明要使⽤AndroidJUnitRunner进⾏单元
测试。
2.5、 buildTypes{}闭包：
这个闭包主要指定⽣成安装⽂件的主要配置，⼀般包含两个⼦闭包，⼀个是debug闭包，⽤于指定⽣成测试版安装⽂件的配置，可以忽略不写；另⼀个是release闭包，⽤于指定⽣成正式版安装⽂件的配置。两者能配置的参数相同，最⼤的区别默认属性配置不⼀样，两种模式⽀持的属性配置如下图：
buildTypes {// ⽣产/测试环境配置
release {// ⽣产环境
buildConfigField("boolean", "LOG_DEBUG", "false")//配置Log⽇志
buildConfigField("String", "URL_PERFIX", "\"release/\"")// 配置URL前缀
minifyEnabled false//是否对代码进⾏混淆
proguardFiles getDefaultProguardFile(''), 'proguard-rules.pro'//指定混淆的规则⽂件
lease//设置签名信息
pseudoLocalesEnabled false//是否在APK中⽣成伪语⾔环境，帮助国际化的东西，⼀般使⽤的不多
zipAlignEnabled true//是否对APK包执⾏ZIP对齐优化，减⼩zip体积，增加运⾏效率
applicationIdSuffix 'test'//在applicationId 中添加了⼀个后缀，⼀般使⽤的不多
versionNameSuffix 'test'//在applicationId 中添加了⼀个后缀，⼀般使⽤的不多
}
debug {// 测试环境
buildConfigField("boolean", "LOG_DEBUG", "true")//配置Log⽇志
buildConfigField("String", "URL_PERFIX", "\"test/\"")// 配置URL前缀
minifyEnabled false//是否对代码进⾏混淆
proguardFiles getDefaultProguardFile(''), 'proguard-rules.pro'//指定混淆的规则⽂件
signingConfig signingConfigs.debug//设置签名信息
debuggable false//是否⽀持断点调试
jniDebuggable false//是否可以调试NDK代码
renderscriptDebuggable false//是否开启渲染脚本就是⼀些c写的渲染⽅法
zipAlignEnabled true//是否对APK包执⾏ZIP对齐优化，减⼩zip体积，增加运⾏效率
pseudoLocalesEnabled false//是否在APK中⽣成伪语⾔环境，帮助国际化的东西，⼀般使⽤的不多
applicationIdSuffix 'test'//在applicationId 中添加了⼀个后缀，⼀般使⽤的不多
versionNameSuffix 'test'//在applicationId 中添加了⼀个后缀，⼀般使⽤的不多
}
}
release{}闭包和debug{}闭包两者能配置的参数相同，最⼤的区别默认属性配置不⼀样：
minifyEnabled ：表明是否对代码进⾏混淆，true表⽰对代码进⾏混淆，false表⽰对代码不进⾏混淆，默认的是false。
proguardFiles ：指定混淆的规则⽂件，这⾥指定了⽂件和proguard-rules.pro⽂件两个⽂
件，⽂件为默认的混淆⽂件，⾥⾯定义了⼀些通⽤的混淆规则。proguard-rules.pro⽂件位于当前项⽬的根⽬录下，可以在该⽂件中定义⼀些项⽬特有的混淆规则。
buildConfigField ：⽤于解决Beta版本服务和Release版本服务地址不同或者⼀些Log打印需求控制的。例如：配置buildConfigField("boolean", "LOG_DEBUG", "true")，这个⽅法接收三个⾮空的参数，第⼀个：确定值的类型，第⼆个：指定key的名字，第三个：传值，调⽤的时候BuildConfig.LOG_DEBUG即可调⽤。
debuggable ：表⽰是否⽀持断点调试，release默认为false，debug默认为true。
jniDebuggable ：表⽰是否可以调试NDK代码，使⽤lldb进⾏c和c++代码调试，release默认为false
signingConfig ：设置签名信息，通过lease或者signingConfigs.debug，配置相应的签名，但是添加此配置前必须先添加signingConfigs闭包，添加相应的签名信息。
renderscriptDebuggable ：表⽰是否开启渲染脚本就是⼀些c写的渲染⽅法，默认为false。
renderscriptOptimLevel ：表⽰渲染等级，默认是3。
pseudoLocalesEnabled ：是否在APK中⽣成伪语⾔环境，帮助国际化的东西，⼀般使⽤的不多。
applicationIdSuffix ：和defaultConfig中配置是⼀的，这⾥是在applicationId 中添加了⼀个后缀，⼀般使⽤的不多。
versionNameSuffix ：表⽰添加版本名称的后缀，⼀般使⽤的不多。
zipAlignEnabled ：表⽰是否对APK包执⾏ZIP对齐优化，减⼩zip体积，增加运⾏效率，release和debug默认都为true。
2.6、sourceSets{}闭包：配置⽬录指向
sourceSets {//⽬录指向配置
main {
jniLibs.srcDirs = ['libs']//指定lib库⽬录
}
}
配置 jniLibs.srcDirs = ['libs']，可以在Android studio的Android视图下⽣成jniLibs⽂件夹，可以⽅便我们存放jar包和库⽂件，其中Android视图下的jniLibs和project视图下的libs指向同⼀⽂件夹（app→libs），如下图所⽰：
2.7、packagingOptions{}闭包：打包时的相关配置
当项⽬中依赖的第三⽅库越来越多时，有可能会出现两个依赖库中存在同⼀个（名称）⽂件。如果这样，Gradle在打包时就会提⽰错误（警告）。那么就可以根据提⽰，然后使⽤以下⽅法将重复的⽂件剔除，⽐较常⽤的是通过exclude去除重复的⽂件，例如：
packagingOptions{
//pickFirsts做⽤是当有重复⽂件时打包会报错这样配置会使⽤第⼀个匹配的⽂件打包进⼊apkandroidsdk安装步骤
// 表⽰当apk中有重复的META-INF⽬录下有重复的LICENSE⽂件时只⽤第⼀个这样打包就不会报错
pickFirsts = ['META-INF/LICENSE']
//merges何必当出现重复⽂件时合并重复的⽂件然后打包⼊apk
//这个是有默认值得 merges = [] 这样会把默默认值去掉所以我们⽤下⾯这种⽅式在默认值后添加
merge 'META-INF/LICENSE'
//这个是在同时使⽤butterknife、dagger2做的⼀个处理。同理，遇到类似的问题，只要根据gradle的提⽰，做类似处理即可。
exclude 'META-INF/services/javax.annotation.processing.Processor'
}
2.8、productFlavors{}闭包：多个渠道配置
这个配置是经常会使⽤到的，通常在适配多个渠道的时候，需要为特定的渠道做部分特殊的处理，⽐如设置不同的包名、应⽤名等。场景：当我们使⽤友盟统计时，通常需要设置⼀个渠道ID，那么我们
就可以利⽤productFlavors来⽣成对应渠道信息的包，如：
android {
productFlavors {
wandoujia {
//豌⾖荚渠道包配置
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "wandoujia"]
//manifestPlaceholders的使⽤在后续章节（AndroidManifest⾥的占位符）中介绍
}
xiaomi {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"]
applicationId "adle.xiaomi" //配置包名
}
_360 {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "_360"]
}
//...
}
}

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。