美文网首页Gradle For Android
Gradle For Android(2)--基础的定制构建

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

作者: None_Ling | 来源:发表于2018-10-17 15:37 被阅读5次

    理解Gradle文件

    当创建一个新的Project的时候,会默认生成3个Gradle文件。在项目的根目录(在Project的Top-Level)下会生成settings.gradlebuild.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_URLBuildConfig.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"也可以查看默认的任务。

    相关文章

      网友评论

        本文标题:Gradle For Android(2)--基础的定制构建

        本文链接:https://www.haomeiwen.com/subject/gsbhzftx.html