Gradle For Android(2)--基础的定制构建

2018-10-17 本文已影响5人 None_Ling

理解Gradle文件

当创建一个新的Project的时候，会默认生成3个Gradle文件。在项目的根目录(在Project的Top-Level)下会生成settings.gradle和build.gradle。而在Android app模块中会创建一个build.gradle文件。目录结构如下：

 MyApp
   ├── build.gradle
   ├── settings.gradle
   └── app
       └── build.gradle

Settings文件

对于一个新的Project，settings.gradle文件只会有一行

include ':app'

这个setting.gradle在初始化阶段被执行，并且定义了哪些Module应该在构建中被包含。在该例中，只有:app模块被包含。只有一个模块的Project可以不需要该文件，而多个模块的Project的必须要该文件，否则Gradle不知道哪些模块需要被包含(include)。

在这种场景下，Gradle创建了为每个Settings文件都创建了一个Serttings对象，并且可以从该对象中调用所需要的Methods。我们不需要知道Settings类的细节，但是最好关注一下。

顶层的build.gradle

顶层的build.gradle文件中，我们可以配置一些options，这些options可以应用于所有在这个Project中的Module。它默认包含以下两个代码块：

buildscript {
      repositories {
            jcenter() 
      }
      dependencies {
           classpath 'com.android.tools.build:gradle:1.2.3'
      } 
}
allprojects {
      repositories {
            jcenter() }
      }
}

buildscript代码块中是真正构建的配置的地方。respositories代码块配置了JCenter作为仓库。在这种情况下，仓库代表了这个Project所依赖的资源或者说我们所需要的一些可下载的Libraries都是保存在这个仓库中。JCenter是一个知名的Maven仓库。

dependencies代码块用来配置构建过程的依赖。也就是说，我们不应该在Top-Level的build.gradle中包含Application或者Libraries的依赖。它唯一的依赖关系应该为是默认定义的Android Plugin。它会去遍历每一个Android Module，因为它是会执行Android-Related Tasks的插件。

allprojects代码块用来定义需要被应用到每一个Module中的属性。我们甚至可以在这个代码块中创建Task，而这些Task可以在各个Module中被应用。

Module中的build.gradle

Module层的build.gradle文件包含了一些options，这些options只能应用在Android app module中。它也能够覆盖Project层的build.gradle文件中的属性。该模块的file如下：

apply plugin: 'com.android.application'
android {
       compileSdkVersion 22
       buildToolsVersion "22.0.1"
       defaultConfig {
           applicationId "com.gradleforandroid.gettingstarted"
           minSdkVersion 14
           targetSdkVersion 22
           versionCode 1
           versionName "1.0"
       }

       buildTypes {
           release {
               minifyEnabled false
               proguardFiles getDefaultProguardFile
                ('proguard-android.txt'), 'proguard-rules.pro'
           }
      } 
}
dependencies {
       compile fileTree(dir: 'libs', include: ['*.jar'])
       compile 'com.android.support:appcompat-v7:22.2.0'
}

其中三个主要的代码块：

plugin：第一行应用了Android的application plugin，配置在顶层的build.gradle中。这个插件主要由Android工具团队写并且维护的，提供了所有需要构建application以及libraries的build，test，package任务
android：这个代码块主要包括了Android特殊的配置。只有两个属性需要配置compileSdkVersion以及buildToolsVersion。负责编译的sdk api版本以及build tools的版本。其中build tools包括了很多命令行的工具，比如说aapt，zipalign，dx，renderscript等等，使用这些工具我们可以生产出各种各样的中间件。我们可以通过SDK Manager下载build tools。

defaultConfig代码块配置了App核心的属性。在这个代码块中的属性会重写AndroidManifest.xml中相对应的属性。

applicationId属性会重写Manifest.xml中的packageName。在Gradle之前的构建系统中，PackageName有两个作用，唯一表示一个App以及用于为R.java赋予包名。而通过Gradle使用build variants使得构建不同版本的App变得更加简单了。比如，很容易构建一个付费/免费的版本。而这两个版本需要两个单独的PackageName，这样才能够被一起装到一个手机上。但是源代码以及R文件包名都还保持着相同的PackageName，以至于在构建多个版本的时候，需要把所有的源文件都进行修改。

因此，这也就是为什么Android Tool团队减弱了packageName的这两个用途。定义在Manifest中的PackageName仍然会用于SourceCode以及R文件。而Google Play则会使用application id作为唯一标识符来区分App。

包括minSdkVersion，targetSdkVersion，versionCode，versionName等等在内的所有值都会覆盖掉Manifest.xml中的值，如果在build.gradle中定义了这些值，Manifest.xml中就可以不定义了，但是以防万一最好还是在Manifest.xml中定义好，避免遗漏出错。

buildType代码块定义了构建不同类型的App的地方。后续会再详细说明。

dependencies代码块是标准Gradle配置的一部分，这也就是它为什么会在android代码块之外的原因。并且它定义了app或者library中所有的依赖关系。默认一个新的Android App会对libs目录下的所有jar包有依赖。取决于新Project的启动项配置。

了解Tasks

为了了解整个Project中哪些Task是可用的，我们可以通过gradlew tasks来列出所有可用的Tasks。如下图所示：

可用的Tasks

在一个新创建的Android Project中，它包括了:

Android tasks
build tasks
build setup tasks
help tasks
install Tasks
verification Tasks
...

如果不止想看到Tasks，而是各个Task之间的依赖关系，可以使用gradlew tasks --all。当你希望打印出执行一个特殊的Task的所有步骤时，可以加上参数-m或者--dry-run。

Android Tasks

Android Plugin继承自基础的Task，并且实现了自己一些功能。这些Tasks在Android中会有如下表现：

assemble：为每个Build Type构建APK
clean：移除所有Build中间件以及Apk文件等等
check：执行Lint的检查，并且如果Lint出现问题的时候，会打断Build过程
build：执行assemble以及check任务

Assemble任务默认由assembleDebug以及assembleRelease构成，如果有更多的Build Type的话，则会有更多的任务。也就是说，执行Aseemble将会为每个Build Type触发一个构建。

除了继承了这些Tasks之外，Android Plugin也添加了一些新的Task。以下为最重要的新的Tasks：

connectedCheck：在已经连接的设备或者模拟器上执行tests任务
deviceCheck：为其他插件在远程设备上调试提供的占位任务
installDebug/installRelease：在已经连接的设备或者模拟器上安装一个特定的版本
所有的install任务都会有相对应的uninstall任务

build任务依赖于check任务，而不是connectedCheck或者deviceCheck。这保证了常规的检查不需要连接设备。执行完check任务后，会生成一个Lint Report文件，其中保存着warnings以及errors，可以在app/build/outputs/lint-results.html中找到。

Lint Report

当Assemble一个Release版本时，Lint将检查可能会导致App Crash的问题。如果找到的话，就会中断Build，并且在Command-Line中打印出错误。并且也会在app/build/outputs中生成lint-results-release-fatal.html文件。如果有多个错误，则通过HTML的Report报告然后滑动到报错的位置就可以看到了。

在Android Studio中，右侧的Gradle窗口双击对应的Task即可开始执行。也就不用在命令行工具中输入命令了。

Gradle窗口

BuildConfig以及Resources

从SDK Tool版本17之后，Build Tool会生成一个名为BuildConfig的类，其中包含了根据build type生成的DEBUG常量。这对控制日志打印是非常有利的。而且，这也为Debug或者Release的常量区分带来了很多的方案，比如我们需要根据Build Type来开启/关闭一些Features，或者设置Server的URLs等等，例如：

android {
       buildTypes {
           debug {
               buildConfigField "String", "API_URL","\"http://test.example.com/api\""
               buildConfigField "boolean", "LOG_HTTP_CALLS", "true"
           }
           release {
               buildConfigField "String", "API_URL","\"http://example.com/api\""
               buildConfigField "boolean", "LOG_HTTP_CALLS", "false"
          } 
      }
}

通过双引号中添加的String值会被生成一个真实的String。通过添加了buildConfigField这一行，我们可以使用BuildConfig.API_URL和BuildConfig.LOG_HTTP来引用不同的值。

而最近，Android Tool团队也会通过以下方式来配置资源：

android {
       buildTypes {
           debug {
               resValue "string", "app_name", "Example DEBUG"
          }
           release {
               resValue "string", "app_name", "Example"
          }
        }
}

Project级别的Settings

如果拥有多个Android Modules的话，它可以非常简便的修改每个Module中的build.gradle中的值，而不用手动的去修改了。我们已经看到了allprojects代码块在顶层的build.gradle中定义了reositories，并且你可以使用相同的方式来应用Android指定的Settings：

allprojects {
       apply plugin: 'com.android.application'
       android {
           compileSdkVersion 22
           buildToolsVersion "22.0.1"
      } 
}

这段代码块只会应用于所有的Android App Project，因为需要应用Android Plugin去使用Android特殊的Settings。一种更好的方案是在顶层的build.gradle中定义这些值，然后在各个Module中应用。也就意味着，我们可以在build.gradle文件中绑定ext代码块，其中定义一些自定义的属性：

ext {
       compileSdkVersion = 22
       buildToolsVersion = "22.0.1"
}

通过这种方式来在Module级别的build.gradle中使用rootProject来获取使用的值。

android {
       compileSdkVersion rootProject.ext.compileSdkVersion
       buildToolsVersion rootProject.ext.buildToolsVersion
}

Project properties

定义Project的Properties有几种方式，最常用的三种：

使用ext代码块
使用gradle.properties文件
通过-P的命令行参数

以下为这三种方式的示例代码：

ext {
     local = 'Hello from build.gradle'
}
task printProperties << {
     println local        // Local extra property
     println propertiesFile        // Property from file
     if (project.hasProperty('cmd')) {
         println cmd        // Command line property
     }
}

在gradle.properties文件中定义如下：

propertiesFile = Hello from gradle.properties

如果通过命令行参数执行printProperties任务的话，输出如下：

$ gradlew printProperties -P cmd='Hello from the command line'
:printProperties
Hello from build.gradle
Hello from gradle.properties
Hello from the command line

默认的任务

如果使用gradle没有指定具体的任务的话，则会执行help任务。如果需要指定默认的任务的话，则需要在顶层的build.gradle中加入默认任务：

defaultTasks 'clean', 'assembleDebug'

这样的话，执行gradlew就会默认执行这两个任务。而通过gradlew tasks | grep "Default tasks"也可以查看默认的任务。