Android 工程gradle知识点记录

Categories: android

原文链接：https://www.jianshu.com/p/8b8a550246bd

gradle-wrapper.properties：

Wrapper是对Gradle的一层包装，便于在团队开发过程中统一Gradle构建的版本号，这样大家都可以使用统一的Gradle版本进行构建。

img

上面我们看到的图就是Gradle提供内置的Wrapper task帮助我们自动生成Wrapper所需的目录文件。再看看我们Android项目里面自动生成的文件

img

img

终于，我们知道这几个自动生成的文件原来是Gradle Wrapper创建出来的。

那下面我们看看gradle-wrapper.properties这个文件的作用

img

看到项目里面的各个属性，下面再看看每个属性的作用

img

我们其实最关心的应该是distributionUrl这个属性，他是下载Gradle的路径，它下载的东西会出现在以下的文件夹中

img

看到了吧，这个文件夹包含了各个版本你下载的Gradle。

当我是初学者的时候老是会遇到一个问题，那就是下图：

img

导入项目的时候一直会停留在这个界面，这是为什么？其实原因很简单，就是你常用项目的Gradle版本跟你新导入项目的Gradle版本不一致造成的，那怎么解决？我本人自己是这么做的：

  1. 在能访问的情况下 ，由它自己去下载，不过下载时间有长有短，不能保证。
  2. 当你在公司被限网速的时候，当然也是我最常用的，就是把你最近常用项目的gradle-wrapper.properties文件替换掉你要导入项目的该文件，基本上我是这样解决的，当然有时候也会遇到替换掉报错的情况，不过比较少。

settings.gradle文件

它其实是用于初始化以及工程树的配置的，放在根工程目录下。

设置文件大多数的作用都是为了配置自工程。在Gradle众多工程是通过工程树表示的，相当于我们在Android Studio看到的Project和Module概念一样。根工程相当于Android Studio的Project，一个根工程可以有很多自工程，也就是很多Module，这样就和Android Studio定义的Module概念对应上了。

img

我们可以看到这个项目我们添加了7个module，一一对应，如果你的项目添加了项目依赖，那就会出现在这个文件当中。

好了，我们说完settings.gradle文件之后就慢慢进入其他文件了，但是首先我们要解释一下什么是Groovy：

Groovy

Groovy是基于JVM虚拟机的一种动态语言，它的语法和Java非常相似，由Java入门学习Groovy基本没有障碍。Groovy完全兼容Java，又在此基础上增加了很多动态类型和灵活的特性，比如支持密保，支持DSL，可以说它就是一门非常灵活的动态脚本语言。

一开始我总把Gradle和Groovy搞混了，现在我总把他们的关系弄清楚了。Gradle像是一个软件，而Groovy就是写这个软件的语言，这就很简单明了吧。那下面我们说到的内容都是用Groovy语法写的，但是这个知识点我就暂时不科普了，有兴趣的小伙伴可以去了解一下更深入的Groovy语法。

主工程下的build.gradle文件：

img

我们这里，分为四个标签来讲：

1.buildscript

buildscript中的声明是gradle脚本自身需要使用的资源。可以声明的资源包括依赖项、第三方插件、maven仓库地址等

2.ext

ext是自定义属性，现在很多人都喜欢把所有关于版本的信息都利用ext放在另一个自己新建的gradle文件中集中管理，下面我介绍一下ext是怎么用的：

img

1.首先我们新建两个文件，分别叫build.gradle和version.gradle

img

img

  1. 然后分别在两个文件中打上相应的代码

img

  1. 最后在Android Studio的Terminal移动到相应的文件夹中运行task。

我们可以很神奇的发现，当我们在build.gradle文件中输入了apply from:’version.gradle’这句话，我们就可以读取到该文件下ext的信息。

现在在项目中我也是这种方法统一管理所有第三方插件的版本号的，有兴趣的朋友也可以试试。

3.repositories

顾名思义就是仓库的意思啦，而jcenter()、maven()和google()就是托管第三方插件的平台

4.dependencies

当然配置了仓库还不够，我们还需要在dependencies{}里面的配置里，把需要配置的依赖用classpath配置上，因为这个dependencies在buildscript{}里面，所以代表的是Gradle需要的插件。

下面我们再看看build.gradle（Project）的另一部分代码

img

allprojects

allprojects块的repositories用于多项目构建，为所有项目提供共同所需依赖包。而子项目可以配置自己的repositories以获取自己独需的依赖包。

奇怪，有人会问，为什么同一个build.gradle（Project）文件中buildscript和allprojects里面的内容基本上是一样的呢，他们的区别在哪？

buildscript和allprojects的作用和区别

buildscript中的声明是gradle脚本自身需要使用的资源，就是说他是管家自己需要的资源，跟你这个大少爷其实并没有什么关系。而allprojects声明的却是你所有module所需要使用的资源，就是说如果大少爷你的每个module都需要用同一个第三库的时候，你可以在allprojects里面声明。这下解释应该可以明白了吧。

好了，下面该说说build.gradle（Project）文件的最后一个一段代码了

img

运行gradle clean时，执行此处定义的task。该任务继承自Delete，删除根目录中的build目录。相当于执行Delete.delete(rootProject.buildDir)。其实这个任务的执行就是可以删除生成的Build文件的，跟Android Studio的clean是一个道理。

moudle下的build.gradle文件：

apply plugin

img

首先要说下apply plugin：’×××’

这种叫做引入Gradle插件，而Gradle插件大致分为分为两种：

  1. apply plugin：’×××’：叫做二进制插件，二进制插件一般都是被打包在一个jar里独立发布的，比如我们自定义的插件，再发布的时候我们也可以为其指定plugin id，这个plugin id最好是一个全限定名称，就像你的包名一样；
  2. apply from：’×××’：叫做应用脚本插件，其实这不能算一个插件，它只是一个脚本。应用脚本插件，其实就是把这个脚本加载进来，和二进制插件不同的是它使用的是from关键字.后面紧跟的坫一个脚本文件，可以是本地的，也可以是网络存在的，如果是网络上的话要使用HTTP URL. 虽然它不是一个真正的插件，但是不能忽视它的作用.它是脚本文件模块化的基础，我们可以把庞大的脚本文件.进行分块、分段整理.拆分成一个个共用、职责分明的文件，然后使用apply from来引用它们，比如我们可以把常用的函数放在一个Utils.gradle脚本里，供其他脚本文件引用。示例中我们把 App的版本名称和版本号单独放在一个脚本文件里，清晰、简单、方便、快捷.我们也可以使用自动化对该文件自动处理，生成版本。

说说Gradle插件的作用

把插件应用到你的项目中，插件会扩展项目的功能，帮助你在项目的构建过程中做很多事情。

  1. 可以添加任务到你的项目中，帮你完成一些亊情，比如测试、编译、打包。
  2. 可以添加依赖配置到你的项目中，我们可以通过它们配置我们项目在构建过程中需要的依赖.比 如我们编译的时候依赖的第三方库等。
  3. 可以向项目中现有的对象类型添加新的扩展属性、 方法等，让你可以使用它们帮助我们配置、优化构建，比如android{}这个配置块就是Android Gradle插件为Project对象添加的一个扩展。
  4. 可以对项目进行一些约定，比如应用Java插 件之后，约定src/main/java目录下是我们的源代码存放位置，在编译的时候也是编译这个目录下的Java源代码文件。
‘com.android.application’

Android Gradle插件的分类其实是根据Android工程的属性分类的。在Andriod中有3类工程，一类是App应用工程，它可以生成一个可运行的apk应用：一类是Library库工程，它可以生成AAR包给其他的App工程公用，就和我们的Jar一样，但是它包含了Android的资源等信息，是一个特殊的Jar包；最后一类是Test测试工程，用于对App工程或者Library库工程进行单元测试。

  1. App插件id：com.android.application.
  2. Library插件id：com.android.library.
  3. Test插件id：com.android.test.

一般一个项目只会设置一个App插件，而module一般是会设置为Library插件。

img

android{}

是Android插件提供的一个扩展类型，可以让我们自定义Android Gradle工程，是Android Gradle工程配置的唯一入口。

compileSdkVersion

是编译所依赖的Android SDK的版本，这里是API Level。

buildToolsVersion

是构建该Android工程所用构建工具的版本。

defaultConfig{}

defaultConfig是默认的配置，它是一个ProductFlavor。ProductFlavor允许我们根据不同的情况同时生成多个不同的apk包。

applicationId

配置我们的包名，包名是app的唯一标识，其实他跟AndroidManifest里面的package是可以不同的，他们之间并没有直接的关系。

package指的是代码目录下路径；applicationId指的是app对外发布的唯一标识，会在签名、申请第三方库、发布时候用到。

minSdkVersion

是支持的Android系统的api level，这里是15，也就是说低于Android 15版本的机型不能使用这个app。

targetSdkVersion

表明我们是基于哪个Android版本开发的，这里是22。

versionCode

表明我们的app应用内部版本号，一般用于控制app升级，当然我在使用的bugly自动升级能不能接受到升级推送就是基于这个。

versionName

表明我们的app应用的版本名称，一般是发布的时候写在app上告诉用户的，这样当你修复了一个bug并更新了版本，别人却发现说怎么你这个bug还在，你这时候就可以自信的告诉他自己看下app的版本号。（亲身经历在撕逼的时候可以从容的应对）

multiDexEnabled

用于配置该BuildType是否启用自动拆分多个Dex的功能。一般用程序中代码太多，超过了65535个方法的时候。

ndk{}

多平台编译，生成有so包的时候使用，包括四个平台’armeabi’, ‘x86’, ‘armeabi-v7a’, ‘mips’。一般使用第三方提供的SDK的时候，可能会附带so库。

sourceSets

源代码集合，是Java插件用来描述和管理源代码及资源的一个抽象概念，是一个Java源代码文件和资源文件的集合，我们可以通过sourceSets更改源集的Java目录或者资源目录等。

譬如像上图，我通过sourceSets告诉了Gradle我的关于jni so包的存放路径就在app/libs上了，叫他编译的时候自己去找。

img

name：build type的名字

applicationIdSuffix：应用id后缀

versionNameSuffix：版本名称后缀

debuggable：是否生成一个debug的apk

minifyEnabled：是否混淆

proguardFiles：混淆文件

signingConfig：签名配置

manifestPlaceholders：清单占位符

shrinkResources：是否去除未利用的资源，默认false，表示不去除。

zipAlignEnable：是否使用zipalign工具压缩。

multiDexEnabled：是否拆成多个Dex

multiDexKeepFile：指定文本文件编译进主Dex文件中

multiDexKeepProguard：指定混淆文件编译进主Dex文件中

buildType

构建类型，在Android Gradle工程中，它已经帮我们内置了debug和release两个构建类型，两种模式主要车别在于，能否在设备上调试以及签名不一样，其他代码和文件资源都是一样的。一般用在代码混淆，而指定的混淆文件在下图的目录上，minifyEnabled=true就会开启混淆：

img

img

signingConfigs

签名配置，一个app只有在签名之后才能被发布、安装、使用，签名是保护app的方式，标记该app的唯一性。如果app被恶意删改，签名就不一样了，无法升级安装，一定程度保护了我们的app。而signingConfigs就很方便为我们提供这个签名的配置。storeFile签名文件，storePassword签名证书文件的密码，storeType签名证书类型，keyAlias签名证书中秘钥别名，keyPassword签名证书中改密钥的密码。

默认情况下，debug模式的签名已经被配置好了，使用的就是Android SDK自动生成的debug证书，它一般位于$HOME/.android/debug.keystore,其key和密码是已经知道的，一般情况下我们不需要单独配置debug模式的签名信息。

img

productFlavors

在我看来他就是Gradle的多渠道打包，你可以在不同的包定义不同的变量，实现自己的定制化版本的需求。

manifestPlaceholders

占位符，我们可以通过它动态配置AndroidManifest文件一些内容，譬如app的名字：

img

看看上图，我们就能发现我们在productFlavors中定义manifestPlaceholders = [APP_NAME: “(测试)”]之后，在AndroidManifest的label加上”${APP_NAME}”,我们就能控制每个包打出来的名字是我们想要不同的名字，譬如测试服务器和生产服务器的包应该名字不一样。

buildConfigField

他是BuildConfig文件的一个函数，而BuildConfig这个类是Android Gradle构建脚本在编译后生成的。而buildConfigField就是其中的自定义函数变量，看下图我们分别定义了三个常量：

img

我们可以在BuildConfig文件中看到我们声明的三个变量

img

然后我们就可以在代码中用这些变量控制不同版本的代码：

img

我们这样加个if，就可以轻轻松松的控制测试和生产版本付费的问题了，再也不用手动的改来改去了，那问题来了，我怎么去选择不同的版本呢，看下图：

img

如果你是Android Studio，找到Build Variants就可以选择你当前要编译的版本啦。

flavorDimensions

顾名思义就是维度，Gradle3.0以后必须要用flavorDimensions的变量 ，不然会报错：

Error:All flavors must now belong to a named flavor dimension.

The flavor ‘flavor_name’ is not assigned to a flavor dimension.

dexOptions{}

img

我们知道，Android中的Java源代码被编译成class字节码后，在打包成apk的时候

被dx命令优化成Android虚拟机可执行的DEX文件。

DEX文件比较紧凑，Android费尽心思做了这个DEX格式，就是为了能使我们的程序在Android中平台上运行快一些。对于这些生成DEX文件的过程和处理，Android Gradle插件都帮我们处理好了，Android Gradle插件会调用SDK中的dx命令进行处理。

但是有的时候可能会遇到提示内存不足的错误，大致提示异常是

java,lang.OutOfMemoryError: GC overhead limit exceeded,为什么会提示内存不足呢？

其实这个dx命令只是一个脚本，它调用的还是Java编写的dx.jar库，是Java程序处理的，所以当内存不足的时候，我们会看到这个Java异常信息.默认情况下给dx分配的内存是一个G8,也就是 1024MB。

所以我们只需要把内存设置大一点，就可以解决这个问题，上图我的项目就把内存设置为4g。

img

dependencies{}

我们平时用的最多的大概就这个了，

  1. 首先第一句compile fileTree(include: [‘.jar’], dir: ‘libs’)*，这样配置之后本地libs文件夹下的扩展名为jar的都会被依赖，非常方便。
  2. 如果你要引入某个本地module的话，那么需要用compile project(‘×××’)。
  3. 如果要引入网上仓库里面的依赖，我们需要这样写compile group：’com.squareup.okhttp3’,name:’okhttp’,version:’3.0.1’,当然这样是最完整的版本，缩写就把group、name、version去掉，然后以”:”分割即可。

compile ‘com.squareup.okhttp3:okhttp:3.0.1’

img

但是到了gradle3.0以后build.gradle中的依赖默认为implementation，而不是

之前的compile。另外，还有依赖指令api。

那么下面我们就来说说：

gradle 3.0中依赖implementation、api的区别：

其实api跟以前的compile没什么区别，将compile全部改成api是不会错的；

而implementation指令依赖是不会传递的，也就是说当前引用的第三方库仅限于本module内使用，其他module需要重新添加依赖才能用，下面用两个图说明：

img

img

相信看过图的人都会一目明了。

compileOnly

等同于provided，只在编译时有效，不会参与打包，不会包含到apk文件中。可以用来解决重复导入库的冲突

编译期注解的依赖—annotationProcessor

用过butterknife或者Dagger的同学可能对这种annotationProcessor引入方式有所印象，这种方式是只在编译的时候执行依赖的库，但是库最终不打包到apk中。结合编译期注解的作用，他是用来生成代码的，本身在运行时是不需要的。

还有在kotlin开发环境中，要用使用kapt

apply plugin: ‘kotlin-kapt‘ 
dependencies { 
   ... 
   kapt 'com.jakewharton:butterknife-compiler:8.4.0' 
}

jar包

jar包依赖的导入还是比较简单的：

implementation files('hibernate.jar', 'libs/spring.jar')//列出每个jar包的相对路径

implementation fileTree(dir: 'libs', include: ['*.jar'])//列出包含jar包的文件夹路径

但和远程仓库依赖引入方式不同，如果本地同时存在两个不同的jar包，或者本地已有jar包，再去远程依赖不同版本的jar包，就会报错。

img

解决方式：将其中的一个采用compileOnly替换implementation。顾名思义，compileOnly只在编译时起作用，不会包含到APK里面，在运行时也就避免找到重复的类了。

aar包

aar包和jar包有区别是需要引入路径要单独声明：

repositories { 
   flatDir { 
   		dirs 'libs' 
   } 
}

然后才是引入：

implementation(name: 'aar名字', ext: 'aar')

项目中这样的Module比较多，每个都需要声明路径，不便于管理的话，推荐在项目的根build.gradle中统一添加,将所有包含aar包的模块名列出，这样不论是本Module或其他Module都不需要单独配置路径了：

allprojects {
    repositories {
        jcenter()
        google()
        flatDir {
             dirs "../moudle-A/libs,../moudle-B/libs,../moudle-C/libs".split(",")
        }
    }
}

so文件

so文件引入只要声明存放路径就好了

sourceSets {
        main {
            jniLibs.srcDir 'libs'
        }
    }

但比较特殊的一点是，so文件需要放到具体的ABI目录下

img

为每个架构都做一个so文件，打包apk的时候会很大，所以如果打包想针对某一种或几种架构打包可以在defaultConfig 中使用ndk：

ndk {
            //选择要添加的对应cpu类型的.so库。
            abiFilters 'armeabi', 'armeabi-v7a' 
            // 还可以添加如： 'x86', 'x86_64', 'mips', 'mips64'
        }
Twitter Icon
Facebook Icon