前一篇文章,对Gradle进行了一个概述,同时对于Groovy语言进行了简单的介绍,有了以前的基础,如今就能够进行更细致化的学习,来学习一下在AndroidStudio中如何来配置咱们的Build文件,来完成一些特定的功能,进行自定义构建。本文将先从各个gradle文件入手,分析各个文件中,咱们能够进行哪些配置,这些配置又能够起到什么做用,如何经过gradle来知足对于构建的自定义需求。html
咱们新建一个Android项目,AndroidStudio会默认为咱们生成如下几个文件,Project的构建文件,Module的构建文件,Project配置文件,混淆规则文件等,那么这些文件都具备什么功能,咱们又能够进行何种配置呢?java
settings.gradleandroid
include ':app'
新建的工程,默认只有上述一条语句,用于指示 Gradle 在构建应用时应将哪些模块包括在内。对大多数项目而言,该文件可能只有上述一条,可是当咱们项目中,引入了其它的功能module,或者业务逻辑module,就须要咱们在include语句中添加相应的module。安全
build.gradle闭包
build文件有两个,一个是针对咱们的Module,一个是针对Project。app
在Project中,默认生成以下配置ide
// Top-level build file where you can add configuration options common to all sub-projects/modules. buildscript { repositories { jcenter() } dependencies { classpath 'com.android.tools.build:gradle:2.2.3' // NOTE: Do not place your application dependencies here; they belong in the individual module build.gradle files } }
在Project的build文件中,咱们能够来添加一些子module所共有的一些配置,而无需单独在每个子module中进行配置。可进行依赖仓库是jcenter仍是其它依赖仓库等。在module中默认生成的是对于咱们的module自身构建的时候进行的一些配置选项。模块化
gradle.properties工具
为gradle的配置文件,里面能够定义一些常量供build.gradle使用,如版本号等,当随着咱们的业务增加,build文件也会变大,可维护性变差,当咱们想修改一些内容的时候,须要逐个去找,可是,当咱们将其中的一些配置常量放置在一个单独的文件中,相比以前,可维护性就有所提高。咱们能够将构建SDK版本等一些信息添加到该文件中。学习
COMPILE_SDK_VERSION = 23 BUILD_TOOLS_VERSION = 23.0.1 VERSION_CODE = 1
而后,咱们就能够在build文件中进行引用了。引用方式,直接经过变量名就能够。
构建类型
构建类型定义 Gradle 在构建和打包您的应用时使用的某些属性,一般针对开发生命周期的不一样阶段进行配置。例如,调试构建类型支持调试选项,使用调试密钥签署 APK;而发布构建类型则可压缩、混淆 APK 以及使用发布密钥签署 APK 进行分发。您必须至少定义一个构建类型才能构建应用——Android Studio 默认状况下会建立调试和发布构建类型。要开始为应用自定义打包设置,请学习如何配置构建类型。
默认构建方式
defaultConfig { applicationId "com.chenjensen.gradlelearn" minSdkVersion 14 targetSdkVersion 24 versionCode 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" }
咱们能够根据本身的需求,好比只针对发布的版本进行混淆等操做,而对于debug版本不进行,咱们能够在buildType中进行配置。
buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } debug { } }
产品风味
产品风味表明您能够发布给用户的不一样应用版本,例如免费和付费的应用版本。您能够将产品风味自定义为使用不一样的代码和资源,同时对全部应用版本共有的部分加以共享和重复利用。产品风味是可选项,而且您必须手动建立。咱们能够在productFlavors {} 代码块中配置咱们所须要的的设置。产品风味支持与 defaultConfig 相同的属性,这是由于 defaultConfig 实际上属于 ProductFlavor 类。这意味着,您能够在 defaultConfig {} 代码块中提供全部风味的基本配置,每种风味都可替换任何默认值,例如 applicationId。
ApplicationId
用来做为咱们的APK的包名,用来对于不一样的包的区分,对于manifest
中的package
字段则是用来命名资源类的包名,最后生成的 R 类文件位于该包下,若是其余包里面的代码须要引用资源时可经过该路径进行调用。
例如
productFlavors { demo { applicationId "com.example.myapp.demo" versionName "1.0-demo" } full { applicationId "com.example.myapp.full" versionName "1.0-full" } }
经过对于产品风味的配置,咱们能够针对不一样的应用市场发布不一样的应用包,针对不一样的应用包,咱们能够进行细致化到具体的SDK版本等的配置。采用的不一样的应用市场分发,可让咱们针对不一样应市场下发下的下载率的采集。
依赖项
构建系统管理来自您的本地文件系统以及来自远程存储区的项目依赖项。这样一来,您就没必要手动搜索、下载依赖项的二进制文件包以及将它们复制到项目目录内。
Android中有三种添加依赖的方式
//依赖咱们本地的module compile project(":mylibrary") //远程的二进制依赖项 compile 'com.android.support:appcompat-v7:25.1.0' //本地二进制依赖方式,将检测咱们的本地的libs中的jar文件 compile fileTree(dir: 'libs', include: ['*.jar']) //javaTest依赖 testCompile 'junit:junit:4.12' //AndroidTest依赖 androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
当咱们添加了一个依赖,该依赖还依赖了其它的依赖,而咱们想把其中的一个依赖去掉,compile方法,能够接受一个闭包参数,咱们能够利用这个闭包来将其中的部分依赖剔出掉。
androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', { exclude group: 'com.android.support', module: 'support-annotations' })
经过compile配置,Gradle 将此配置的依赖项添加到类路径和应用的 APK。除了compile配置,还有apk,provided。
apk
指定 Gradle 须要将其与应用的 APK 一块儿打包的仅运行时依赖项。您能够将此配置与 JAR 二进制依赖项一块儿使用,而不能与其余库模块依赖项或 AAR 二进制依赖项一块儿使用。
provided
指定 Gradle 不与应用的 APK 一块儿打包的编译时依赖项。若是运行时无需此依赖项,这将有助于缩减 APK 的大小。您能够将此配置与 JAR 二进制依赖项一块儿使用,而不能与其余库模块依赖项或 AAR 二进制依赖项一块儿使用。
签署
构建系统能够在构建配置中指定签署设置,并可在构建过程当中自动签署您的 APK。构建系统经过使用已知凭据的默认密钥和证书签署调试版本,以免在构建时提示密码。除非为此构建显式定义签署配置,不然,构建系统不会签署发布版本。若是没有发布密钥,能够按签署应用中所述生成一个。因为调试证书经过构建工具建立而且在设计上不安全,大多数应用商店(包括 Google Play 商店)都不接受使用调试证书签署要发布的 APK。
签署的应用
应用升级:当系统安装应用的更新时,它会比较新版本和现有版本中的证书。若是证书匹配,则系统容许更新。若是使用不一样的证书签署新版本,则必须为应用分配另外一个软件包名称 - 在此状况下,用户将新版本做为全新应用安装。
应用模块化:Android 容许经过相同证书签署的多个 APK 在同一个进程中运行(若是应用请求这样),以便系统将它们视为单个应用。经过此方式,能够在模块中部署您的应用,且用户能够独立更新每一个模块。
在您建立签署配置时,Android Studio 会以纯文本形式将您的签署信息添加到模块的 build.gradle 文件中。若是是团队协做开发或者将您代码开源,那么应当将此敏感信息从构建文件中移出,以避免被其余人轻易获取。为此,建立一个单独的属性文件来存储安全信息。而后在本地获取外部文件的配置,而后在发布代码的时候,保留咱们的秘钥配置文件。
在项目的根目录下建立一个名称为 keystore.properties 的文件。
storePassword=myStorePassword keyPassword=mykeyPassword keyAlias=myKeyAlias storeFile=myStoreFileLocation
在模块的 build.gradle 文件中,于 android {} 块的前面添加用于加载 keystore.properties 文件的代码
def keystorePropertiesFile = rootProject.file("keystore.properties") // Initialize a new Properties() object called keystoreProperties. def keystoreProperties = new Properties() // Load your keystore.properties file into the keystoreProperties object. keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
使用语法 keystoreProperties['属性名称'] 引用存储在 keystoreProperties 中的属性。修改模块 build.gradle 文件的 signingConfigs 块,以便使用此语法引用存储在 keystoreProperties 中的签署信息。
android { signingConfigs { config { keyAlias keystoreProperties['keyAlias'] keyPassword keystoreProperties['keyPassword'] storeFile file(keystoreProperties['storeFile']) storePassword keystoreProperties['storePassword'] } } ... }
ProGuard
构建系统让您可以为每一个构建变体指定不一样的 ProGuard 规则文件。构建系统可在构建过程当中运行 ProGuard 对类进行压缩和混淆处理。代码压缩经过 ProGuard 提供,ProGuard 会检测和移除封装应用中未使用的类、字段、方法和属性,包括自带代码库中的未使用项(这使其成为以变通方式解决 64k 引用限制的有用工具)。ProGuard 还可优化字节码,移除未使用的代码指令,以及用短名称混淆其他的类、字段和方法。混淆过的代码可令您的 APK 难以被逆向工程。对于ProGuard更详细的介绍能够参考以前关于项目构建的文章。
开启代码压缩
minifyEnabled true
启用ProGuard规则
proguardFiles getDefaultProguardFile(‘proguard-android.txt'), 'proguard-rules.pro'
getDefaultProguardFile(‘proguard-android.txt') 方法可从 Android SDK tools/proguard/ 文件夹获取默认 ProGuard 设置。
proguard-rules.pro 文件用于添加自定义 ProGuard 规则。默认状况下,该文件位于模块根目录
每次执行完成ProGuard以后,都会产生以下文件
dump.txtAPK 中全部类文件的内部结构。
mapping.txt
提供原始与混淆过的类、方法和字段名称之间的转换。
seeds.txt
列出未进行混淆的类和成员。
usage.txt
列出从 APK 移除的代码。
这些文件保存在 <module-name>/build/outputs/mapping/release/。
对于其中一些类,咱们不想对其进行混淆的,须要咱们在ProGuard 配置文件中添加一行 -keep 代码。例如:
-keep public class MyClass