Android中关于gradled的理解以及如何签名和打包

本文转自：http://www.cnblogs.com/smyhvae/p/4456420.html点击打开链接

目录：

1、gradle的概念

2、gradle配置jar包，和libs文件夹导入jar包的区别

3、签名打包：

    （1）Studio

    （2）命令行

    （3）gradle wrapper的原理

4、BuildConfig的使用

5、简单介绍module中build.gradle文件参数含义

 

一、gradle的概念：

• gradle是一个构建工具
• gradle是以Groovy语言为基础的
• gradle主要面向的是Java语言

打开Android Studio内置的终端，在输入如下命令查看gradle版本：

gradlew -v

 

如果是第一次运行这个命令，系统会帮我们下载gradle到本地，下载到的路径是：

输入上述命令后，查看到gradle的版本2.2.1，如下图所示：

 

二、通过gradle来导入jar包：

我们在上一篇文章中第二段的第3小节中讲到了通过拷贝文件到libs文件夹来导入jar包。这次来讲一下怎么通过gradle来配置jar包。我们还是以谷歌的gjson.jar为例，如果之前已经通过拷贝文件方式倒入过了，请先自行删掉。

1、通过gradle配置第三方jar包

我们看到，每个module都有一个build.gradle文件，它其实是对应module的配置文件。关于build.gradle文件中具体内容的含义，我们将在最后一段进行讲解。

我们先来看一下名为app的这个module，它的build.gradle对应的图形界面其实是下面这个Project Stucture：

上图中，切换到dependencies标签下，如下图所示：

上图中，点击添加，然后选择"Library dependency"，弹出如下界面：

上图中，我们在搜索框中输入“gson”，然后确定，就弹出了箭头处的我们需要的jar包，添加它即可：

之后我们会发现，app这个module的build.gradle中多了一行代码，表示引入了gson.jar：

其实，如果你能记得住上方这行代码，直接写出代码来也是可以导入的。

此时，gson这个jar包不再是出现在libs这个文件夹下了，而是出现在最下方的External Libraries中，如下图所示：（而且是最新版本哦）

2、gradle导入jar包的特点：（和libs文件夹导入jar包的区别）

• gradle导入jar包更方便，一行代码即可搞定。不像后者那样还要自己去官方下载。
• 如果官方将jar包更新了，我们只需要在build.gradle中改一下版本号就行了，不用重新去官网下载。

 

3、通过gradle导入的jar包是从哪里来的：

需要注意的是：不是所有的jar包都是可以通过gradle来导入的。那通过gradle导入的jar包是从哪里来的呢？解释如下：

我们发现HelloWorld这个project的目录下有一个build.gradle文件，打开它：

上图中第17行的"jcenter()"的意思是，所有通过gradle导入的jar包都是从http://bintray.com/bintray/jcenter这个中央仓库上扒下来的。如果你需要的jar包在这个网站上没有，那就无法通过gradle的方式来导入哦。

顺便提一下，上图中第8行的classpath中的gradle 1.1.0是android的一个gradle插件（也是从中央仓库扒下来的）。而我们自己使用的gradle版本如下图所示：

我们自己下载好的gradle的路径如下：

三、签名打包的两种方式：

注：给我们自己开发的app签名，就代表着我自己的版权，以后要进行升级，也必须要使用相同的签名才行。签名就代表着自己的身份（即keystore），多个app可以使用同一个签名。

如果不知道签名是啥意思，请自行百度哦。在eclipse中签名的方法是：选中工程，邮件选择"export-android-export android application"，

1、方式1：通过Android Studio进行签名：

选中app这个module，选择菜单栏"Build-Generate signed apk"：

弹出如下界面：

上图中，如果你是第一次使用签名，就单击红框部分创建一个新的签名；如果你之前有过签名的文件，就选择蓝框部分进行导入即可。那我就先选择红框部分吧：

上图中，点击"finish"之后，可以看到Android Studio的最下方显示：Gradle正在执行assembleRelease这样一个任务，如下图所示：

生成签名好的apk之后，会弹出提示：

 

 

2、方式2：通过命令行的方式进行签名：

（1）加载Key Store:

我们先删掉上面的通过第一种方式所签名的apk文件。接下来进行第二种方式来签名，即命令行的方式。

打开Project Stucture图形化界面：

上图中，选中app这个module，然后切换到singning标签栏，紧接着点击添加，然后生成release签名信息，紧接着点击"OK"。接着做如下操作：

上图中，切换到Build Types标签，将Signing config选择为"release"，即将刚刚生成的release签名信息配置进去。

操作完成之后，我们可以看到app这个module的build.gradle文件多出了如下红框部分的代码：

然后执行菜单栏的"build-clean Project"：

(2)生成realease版本的apk：

紧接着在命令行Terminal输入如下命令：（AS已经将命令行Terminal集成到了软件当中）

gradlew assembleRelease

如果运行成功，效果如下：

生成的签名好的apk在如下位置：

 

3、为什么要使用gradlew命令而不是gradle命令：

在HelloWorld工程目录下有一个gradle文件夹，在gradle/wrapper目录下有一个gradle-wrapper.properties文件，打开它：

上图代表着HelloWorld这个工程所依赖的gradle的版本信息。上图的红线表示，如果我们的工程中没有gradle，软件会根据这个url去下载gradle，终于知道为啥第一次打开AS时会这么慢了吧？

如果我们执行了gradlew命令，实际上是执行上面的gradle wrapper，然后找到我们已经下载好的gradle 2.2.1。如果现在有很多个工程，但是每个工程的gradle版本都不一样，我就必须要将每个版本的gradle都要配置到环境变量当中，而执行了gradlew命令，就会避免这个麻烦。

四、BuildConfig文件：

BuildConfig是IDE自动生成的一个类，在elipse中即存放在gen目录下（如R文件）。而在Adroid Studio中，BuildConfig文件存放的位置是：app/build/generated/source/buildconfig/dubug//BuildConfig.java中。如下图所示：

五、module中build.gradle文件参数含义：

主要是module的build.gradle，截图如下：

01行：apply plugin: 'com.android.application'    表示该module是这个应用程序的module

15行：applicationId "com.smyhvae.helloworld"    应用程序的包名

16、17行：向下兼容的最小版本、编译版本。    注：在app/src/main/AndroidManifest.xml中不再出现这个信息了。

23行：需不需要利用24行的proguard文件来混淆代码。在release状态下，最好改为true。

下面的内容转自stormzhang AndroidDeveloper的公众号，欢迎关注

https://mp.weixin.qq.com/s?__biz=MzA4NTQwNDcyMA==&mid=2650661971&idx=1&sn=3fb69537bbc5fbb14d152ba6381c3b83&scene=1&srcid=0715jio7joUcUHjrZOEY1kXo&pass_ticket=8Wd27hpqB3M%2B4paP4EQlK8x0r9%2BKNH2qlXuTgK2J2FnM8logOCiQ3bmFPFobWqvX#rd点击打开链接

点击打开链接

一：什么是构建工具？            

   

我们大家都知道 Gradle 是一种构建工具，那么什么是构建工具呢？    

   

网上一大堆的文字解释我觉得很难理解，这里我以咱们 Android 开发来举个例子吧。    

   

我们以前开发都是用 Eclipse ，而 Eclipse 大家都知道是一种 IDE （集成开发环境），最初是用来做 Java 开发的，而 Android 是基于 Java 语言的，所以最初 Google 还是希望 Android 能在 Eclipse 上进行开发，为了满足这个需求，Google 开发了一个叫 ADT （Android Developer Tools）的东西，相信以前从 Eclipse 时代过来的对 ADT 应该都不陌生，正是因为有了 ADT ，从此我们只需要码好代码，然后直接在 Eclipse 上进行编译、运行、签名、打包等一系列流程，而这背后的工作都是 ADT 的功劳。某种意义上 ADT 就是我们的构建工具。    

   

而自 Google 推出 Android Studio 以来，就宣布默认使用 Gradle 来作为构建工具，并且之后放弃更新 ADT ，从此 Gradle 走入 Android 开发者的视野，而我也是在 AS 的 Beta 版开始接触并学习 Gradle。    

   

一般来说，构建工具除了以上提到的编译、运行、签名、打包等，还具备依赖管理的功能，什么是依赖管理呢？还是拿 Eclipse 来说，我们以前在 Eclipse 上开发 Android ，如果需要用到第三方库的时候一般都是先下载 jar 文件，然后把 jar 文件添加到 libs 目录，然后项目中就可以引用了。但是你不觉得这种管理方式很麻烦么？假设第三方库有更新，需要下载最新的 Jar 文件，然后替换掉原来的，引用的库少还好，一旦引用的第三方库多，那简直麻烦死，可以说这种方式只有依赖，而没有管理。    

   

现在大家不陌生的 Gradle 引用第三方库方式是这样的：    

   

compile 'com.android.support:support-v4:24.0.1'    

   

类似这样的依赖方式，是不是很方便？而且很直观，直接可以看到源地址，升级的话直接改下版本号就可以了，这就是所谓的依赖管理。    

   

所以构建工具就是对你的项目进行编译、运行、签名、打包、依赖管理等一系列功能的合集，传统的构建工具有 Make、Ant、Maven、Ivy等，而 Gradle 是新一代的自动化构建工具。    

   

3   什么是 Gradle ？            

   

上面说了，Gradle 是新一代的自动化构建工具，它是一个独立的项目，跟 AS、Android 无关，官方网站：https://gradle.org/ , 类似 Ant、Maven这类构建工具都是基于 xml 来进行描述的，很臃肿，而 Gradle 采用的是一种叫做 Groovy 的语言，语法跟 Java 语法很像，但是是一种动态语言，而且在 Java 基础上做了不少改进，用起来更加简洁、灵活，而且 Gradle 完全兼容 Maven、Ivy，这点基本上宣布了 Maven、Ivy 可以被抛弃了，Gradle 的推出主要以 Java 应用为主，当然目前还支持 Android、C、C++。    

   

4    Gradle 与 Android Studio 的关系            

   

上面也提到，Gradle 跟 Android Studio 其实没有关系，但是 Gradle 官方还是很看重 Android 开发的，Google 在推出 AS 的时候选中了 Gradle 作为构建工具，为了支持 Gradle 能在 AS 上使用，Google 做了个 AS 的插件叫 Android Gradle Plugin  ，所以我们能在 AS 上使用 Gradle 完全是因为这个插件的原因。在项目的根目录有个 build.gradle 文件，里面有这么一句代码：    

   

classpath 'com.android.tools.build:gradle:2.1.2'    

   

这个就是依赖 gradle 插件的代码，后面的版本号代表的是 android gradle plugin 的版本，而不是 Gradle 的版本，这个是 Google 定的，跟 Gradle 官方没关系。关于 android gradle plugin 的更多信息可以到这里查看，这里列举了 android gradle plugin 每个版本的具体变化与具体功能：    

   

http://tools.android.com/tech-docs/new-build-system    

   

友情提示，需要科学上网！    

   

5  Gradle Wrapper            

   

现在默认新建一个项目，然后点击 AS 上的运行，默认就会直接帮你安装 Gradle ，我们不需要额外的安装 Gradle 了，但是其实这个 Gradle 不是真正的 Gradle ，他叫 Gradle Wrapper ，意为 Gradle 的包装，什么意思呢？假设我们本地有多个项目，一个是比较老的项目，还用着 Gradle 1.0 的版本，一个是比较新的项目用了 Gradle 2.0 的版本，但是你两个项目肯定都想要同时运行的，如果你只装了 Gradle 1.0 的话那肯定不行，所以为了解决这个问题，Google 推出了 Gradle Wrapper 的概念，就是他在你每个项目都配置了一个指定版本的 Gradle ，你可以理解为每个 Android 项目本地都有一个小型的 Gradle ，通过这个每个项目你可以支持用不同的 Gradle 版本来构建项目。    

   

理解了 Gradle Wrapper 的概念就好办了，以下的所有操作都是基于 Gradle Wrapper 的。    

   

默认我们在 AS 上第一次创建项目会自动下载 Gradle 的，这个过程很漫长，出奇的慢，但是第一次之后就ok了，接下来就是教大家用命令行测试下，请大家在终端或者 AS 带的终端上切换到所在项目的目录，然后输入 ./gradlew -v (win用户直接输入 gradlew -v) ，即可以查看当前项目所用的 gradle 的版本，gradlew 即为 gradle wrapper 的缩写，如果你是第一次执行命令行，那么会出现一个下载的提示，紧接着会打印一个个的点，这个过程很漫长，依赖你的网速，时间几分钟到几十分钟不等。   

   

有人有疑问，我 AS 上明明已经可以正常运行该项目的，说明 Gradle 已经下载过了，为什么命令行还要再下载一次？我也一直有这个疑问，理论上是不该再下载的，但是事实他就是要重新下载一次，我猜测可能是bug吧。    

   

如果下载完成输入 ./gradlew -v 出现如下结果，证明你的项目是ok的，否则就是你的项目配置有问题了。    

   

   

   

6   Android 项目包含的 Gradle 配置文件            

   

这里姑且以我很早在 GitHub 开源的 9GAG 项目为例，来稍微介绍下一个完整的 Android 项目包含的基本 Gradle 相关的配置文件：    

   

   

   

红色标记部分从上到下咱们来一步步分析：    

   

9GAG/app/build.gradle    

这个文件是 app 文件夹下这个 Module 的 gradle 配置文件，也可以算是整个项目最主要的 gradle 配置文件，具体里面的配置以后再介绍。    

   

9GAG/extras/ShimmerAndroid/build.gradle    

每一个 Module 都需要有一个 gradle 配置文件，语法都是一样，唯一不同的是开头声明的是    

apply plugin: ‘com.android.library’    

   

9GAG/gradle    

这个目录下有个 wrapper 文件夹，里面可以看到有两个文件，我们主要看下 gradle-wrapper.properties 这个文件的内容：    

   

   

   

可以看到里面声明了 gradle 的目录与下载路径以及当前项目使用的 gradle 版本，这些默认的路径我们一般不会更改的，这个文件里指明的 gradle 版本不对也是很多导包不成功的原因之一。    

   

9GAG/build.gradle    

这个文件是整个项目的 gradle 基础配置文件，默认的内容就是声明了 android gradle plugin 的版本。    

   

9GAG/settings.gradle    

这个文件是全局的项目配置文件，里面主要声明一些需要加入 gradle 的 module，我们来看看 9GAG 该文件的内容：    

   

   

   

7   如何正确导入下载的开源项目？            

   

我们经常会在 GitHub 发现一些优秀的开源项目，然后想要下载学习，然而第一步一般都是把源码导入到 AS 里，然后运行起来看下效果，但是经常会运行失败，这里我来给大家说下导入开源项目的正确姿势：    

   

下载一个Demo，先打开每个 module下的 gradle 文件，即 app 目录下的 build.gradle 以及各个 library 下的 build.gradle ,首先查看 compileSdkVersion 和 buildToolsVersion，因为有些时候你本地的版本和下载的版本不一致，那么就会导致失败。    

然后就是检查 gradle-wrapper ，Google 有些时候要求不同的 AS 支持不同的 gradle 版本。比如 AS 1.0 的时候要求必须使用 gradle 1.x 的版本，等到 AS 2.0 的时候，Google 不支持 gradle1.x 的版本，这个时候你必须手动更新下 android gradle plugin 的版本，然后重新同步下。    

   

检查以上两个地方基本就可以导入并运行了，如果还有其他问题，那可能就是环境或者项目本身的问题了。    

   

8   认识下几个命令            

   

上面提到了，假设我们没有 IDE ，只有类似 Sublime、Atom、Vim这种轻量编辑器怎么办？那我们就没法开发 Android 了么？然而只要有构建工具，不需要 IDE 我们一样有办法开发，这个时候我们就需要用到几个有用的 Gradle 命令了：    

   

./gradlew -v 版本号    

   

./gradlew clean 清除9GAG/app目录下的build文件夹    

   

./gradlew build 检查依赖并编译打包    

   

这里注意的是 ./gradlew build 命令把 debug、release 环境的包都打出来，如果正式发布只需要打 Release 的包，该怎么办呢，下面介绍一个很有用的命令 assemble, 如    

   

./gradlew assembleDebug 编译并打Debug包    

   

./gradlew assembleRelease 编译并打Release的包    

   

值得注意的是，以上所有命令都是在终端里执行，并且必须要切换到所在项目的根目录下执行，win系统直接执行 gradlew 。    

 Gradle 相关的文件            

我们在 Android Stduio 上新建一个全新的 Android 项目，姑且取个名字叫 demo ，一般就包含了三个相关的 gradle 配置文件，分别是根目录下的 build.gradle、settings.gradle 和 app 目录下的 build.gradle 文件，前两个文件配置比较简单，上篇文章也已经有所介绍，今天来主要介绍下 app/build.gradle 文件的详细配置。    

   

2   app/build.gradle 配置文件            

一般来说，新建的一个项目，在 app 目录会生成一个 build.gradle 文件，app 目录基本是项目的一个主要目录了，所有的功能开发都是在这个目录下，自然该目录下的 build.gradle 也是整个项目最重要的配置文件，这个文件对全新的项目来说会包含三部分    

   

• 最顶部的 apply plugin 声明

• android {} 节点

• dependencies {} 节点

   

apply plugin 声明    

最顶部有一行代码是这样的：

apply plugin: 'com.android.application'    

代表该项目是一个 Android 项目，而且一个 Android 项目只有一句这个声明，别问为什么这样写，这是规范。    

   

如果你的项目有引用一些 module ，你可以理解成通过源码的方式引用一些 android library ，那么你的 module 开头需要声明是一个 android library ，那需要这样写：   

apply plugin: 'com.android.library'    

是不是很容易理解？    

   

dependencies 节点    

我们先来看下 dependencies 节点，dependencies 是 denpendency 的复数，意为依赖的意思，所以这里就是用来管理依赖的地方。这里以我的开源项目 9GAG 为例，依赖一般有三种：    

   

   

我们知道我们可以在 AS 中直接依赖 jar 文件，靠的就是这行代码 compile fileTree(dir: 'libs', include: ['*.jar']) ，意思是编译 libs 目录下的所有 jar 包，当然你可以更改这个目录。    

   

第二种就比较常见了，现在大家都已经很熟悉了，就是直接依赖远程项目名字 + 版本号，至于该项目是放在哪里的呢？一般是放在 jcenter 和 maven 仓库的，这个可以在项目根目录下的 build.gradle 指定远程仓库地址，甚至可以在本地搭建一个私有仓库，然后指定本地仓库地址。    

   

第三种就是类似原始的引用 android library 的方式，一般是你们公司内部的项目，或者改第三方库的源码，同时本地又没有搭建私有仓库，才会选择这种方式。这种方式目前很不推荐了，大部分情况第二种方式完全足够了，但是大家知道这也是一种依赖方式。    

   

android 节点    

以上两个节点都相对简单点，这个节点是跟项目配置紧密相关的，简单有简单的配置方法，复杂也有复杂的配置方法，这里我先列举一些项目常用的配置，并且加上了注释方便大家理解：    

   

   

这部分应该比较简单，没有不理解的吧?就不过多解释了。    

   

   

buildTypes 意为编译类型，这里声明了 debug 和 release 两种类型，当然你也可以声明其他类型，名字随意取，可以看到 debug 和 release 两种类型签名所用的配置不一样，这个配置具体详细也就是在上部分 signingConfigs 节点指定的，那里面的一些密码信息是在你生成 keystore 文件时设置的。    

   

这里配置完成之后就可以通过上篇文章提到的的命令 gradlew assembleDebug 或者 gradlew assembleRelease 进行打包了，这里估计有同学会问这个命令跟 buildTypes 有没有什么关系呢？聪明，是有关系的，这里用到的其实就是 assemble 命令，而 assemble + buildTypes 会生成一个 task ，所以 gradlew assembleDebug 和 gradlew assembleRelease 都是属于拼接的一个 task ，如果你 buildTypes 定义了一个 abc 的类型，那你就会有一个 gradlew assembleAbc 的 task 可以执行。    

   

但是关于 task 远不止与此，这里先提一下，后面再给大家单独介绍。    

  

 

3   从 Eclipse 迁移到 AS            

上面的一些命令差多介绍完了一些项目的基本配置，大家基本也都明白各个配置的意思了，相信大家大部分也都在用 AS 了，但是不排除仍有部分读者还在用着 Eclipse ，或者正准备从 Eclipse 迁移到 AS 上，从 Eclipse 迁移到 AS 上应该会遇到不少问题，但是我认为一个最大的问题就是 gradle 脚本的生成，Eclipse 支持直接导出 AS 项目，就给我们生成了 gradle 脚本，当然如果你对 gradle 熟悉的话完全可以自己新建 gradle 文件，然后自己把一些 gradle 配置手动写上去。    

   

还有一个最大的问题是目录结构，我们知道 Eclipse 上的目录结构是:    

 

demo    

        |-- app    

                 |--libs    

                 |--src    

                 |--res    

而 AS 上的项目结构是：    

demo    

       |--libs    

       |--src    

               |--main    

                          |--java    

                          |--res    

所以如果不想对目录结构进行更改的话，直接用上面 gradle 脚本进行构建会失败，而这时候你需要添加如下配置：    

   

   

上面也没啥解释的，就是手动指定编译对应的目录，相信大家看得懂。    

4   总结            

当然 Gradle 的配置不止以上介绍的，还有其他配置，如忽略 Lint 的检查报错，打包的时候忽略一些文件、指定 Java 版本等：    

   

     

这些问题不必太在意，一般你在编译或者打包出错的时候 gradle 会提示你什么错误的，按照提示进行修改就行了。