当前位置: 首页>移动开发>正文

gradle grpc集成 gradle configure project


4.3  Gradle工作流程

Gradle的工作流程其实蛮简单,用一个图26来表达:

 图26告诉我们,Gradle工作包含三个阶段:

  • 首先是初始化阶段。对我们前面的multi-project build而言,就是执行settings.gradle
  • Initiliazation phase的下一个阶段是Configration阶段。
  • Configration阶段的目标是解析每个project中的build.gradle。比如multi-project build例子中,解析每个子目录中的build.gradle。在这两个阶段之间,我们可以加一些定制化的Hook。这当然是通过API来添加的。
  • Configuration阶段完了后,整个build的project以及内部的Task关系就确定了。恩?前面说过,一个Project包含很多Task,每个Task之间有依赖关系。Configuration会建立一个有向图来描述Task之间的依赖关系。所以,我们可以添加一个HOOK,即当Task关系图建立好后,执行一些操作。
  • 最后一个阶段就是执行任务了。当然,任务执行完后,我们还可以加Hook。

 我在:

  • settings.gradle加了一个输出。
  • 在posdevice的build.gradle加了图25中的beforeProject函数。
  • 在CPosSystemSdk加了taskGraph whenReady函数和buidFinished函数。

好了,Hook的代码怎么写,估计你很好奇,而且肯定会埋汰,怎么就还没告诉我怎么写Gradle。马上了!

最后,关于Gradle的工作流程,你只要记住:

  • Gradle有一个初始化流程,这个时候settings.gradle会执行。
  • 在配置阶段,每个Project都会被解析,其内部的任务也会被添加到一个有向图里,用于解决执行过程中的依赖关系。
  • 然后才是执行阶段。你在gradle xxx中指定什么任务,gradle就会将这个xxx任务链上的所有任务全部按依赖顺序执行一遍!

下面来告诉你怎么写代码!

4.4  Gradle编程模型及API实例详解

希望你在进入此节之前,一定花时间把前面内容看一遍!!!

https://docs.gradle.org/current/dsl/

Gradle基于Groovy,Groovy又基于Java。所以,Gradle执行的时候和Groovy一样,会把脚本转换成Java对象。Gradle主要有三种对象,这三种对象和三种不同的脚本文件对应,在gradle执行的时候,会将脚本转换成对应的对端:

  • Gradle对象:当我们执行gradle xxx或者什么的时候,gradle会从默认的配置脚本中构造出一个Gradle对象。在整个执行过程中,只有这么一个对象。Gradle对象的数据类型就是Gradle。我们一般很少去定制这个默认的配置脚本。
  • Project对象:每一个build.gradle会转换成一个Project对象。
  • Settings对象:显然,每一个settings.gradle都会转换成一个Settings对象。

注意,对于其他gradle文件,除非定义了class,否则会转换成一个实现了Script接口的对象。这一点和3.5节中Groovy的脚本类相似

当我们执行gradle的时候,gradle首先是按顺序解析各个gradle文件。这里边就有所所谓的生命周期的问题,即先解析谁,后解析谁。图27是Gradle文档中对生命周期的介绍:结合上一节的内容,相信大家都能看明白了。现在只需要看红框里的内容:

4.4.1  Gradle对象

我们先来看Gradle对象,它有哪些属性呢?如图28所示:

 我在posdevice build.gradle中和settings.gradle中分别加了如下输出:

//在settings.gradle中,则输出"In settings,gradle id is"  
println "In posdevice, gradle id is " +gradle.hashCode()  
println "Home Dir:" + gradle.gradleHomeDir  
println "User Home Dir:" + gradle.gradleUserHomeDir  
println "Parent: " + gradle.parent

得到结果如图29所示:

  • 你看,在settings.gradle和posdevice build.gradle中,我们得到的gradle实例对象的hashCode是一样的(都是791279786)。
  • HomeDir是我在哪个目录存储的gradle可执行程序。
  • User Home Dir:是gradle自己设置的目录,里边存储了一些配置文件,以及编译过程中的缓存文件,生成的类文件,编译中依赖的插件等等。

Gradle的函数接口在文档中也有。

4.4.2  Project对象

每一个build.gradle文件都会转换成一个Project对象。在Gradle术语中,Project对象对应的是Build Script。

Project包含若干Tasks。另外,由于Project对应具体的工程,所以需要为Project加载所需要的插件,比如为Java工程加载Java插件。其实,一个Project包含多少Task往往是插件决定的。

所以,在Project中,我们要:

  • 加载插件。
  • 不同插件有不同的行话,即不同的配置。我们要在Project中配置好,这样插件就知道从哪里读取源文件等
  • 设置属性。

1.  加载插件

Project的API位于https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html。加载插件是调用它的apply函数.apply其实是Project实现的PluginAware接口定义的:

 来看代码:

[apply函数的用法]

apply是一个函数,此处调用的是图30中最后一个apply函数。注意,Groovy支持函数调用的时候通过  参数名1:参数值2,参数名2:参数值2 的方式来传递参数

apply plugin: 'com.android.library'    <==如果是编译Library,则加载此插件
apply plugin: 'com.android.application'  <==如果是编译Android APP,则加载此插件

除了加载二进制的插件(上面的插件其实都是下载了对应的jar包,这也是通常意义上我们所理解的插件),还可以加载一个gradle文件。为什么要加载gradle文件呢?

其实这和代码的模块划分有关。一般而言,我会把一些通用的函数放到一个名叫utils.gradle文件里。然后在其他工程的build.gradle来加载这个utils.gradle。这样,通过一些处理,我就可以调用utils.gradle中定义的函数了。

加载utils.gradle插件的代码如下:

utils.gradle是我封装的一个gradle脚本,里边定义了一些方便函数,比如读取AndroidManifest.xml中

的versionName,或者是copy jar包/APK包到指定的目录

apply from: rootProject.getRootDir().getAbsolutePath() + "/utils.gradle"

也是使用apply的最后一个函数。那么,apply最后一个函数到底支持哪些参数呢?还是得看图31中的API说明:

 我这里不遗余力的列出API图片,就是希望大家在写脚本的时候,碰到不会的,一定要去查看API文档!

2.  设置属性

如果是单个脚本,则不需要考虑属性的跨脚本传播,但是Gradle往往包含不止一个build.gradle文件,比如我设置的utils.gradle,settings.gradle。如何在多个脚本中设置属性呢?

Gradle提供了一种名为extra property的方法。extra property是额外属性的意思,在第一次定义该属性的时候需要通过ext前缀来标示它是一个额外的属性。定义好之后,后面的存取就不需要ext前缀了。ext属性支持Project和Gradle对象。即Project和Gradle对象都可以设置ext属性

举个例子:

我在settings.gradle中想为Gradle对象设置一些外置属性,所以在initMinshengGradleEnvironment函数中

def initMinshengGradleEnvironment(){  
    //属性值从local.properites中读取  
    Propertiesproperties = new Properties()  
    FilepropertyFile = new File(rootDir.getAbsolutePath() +"/local.properties")  
   properties.load(propertyFile.newDataInputStream())  
    //gradle就是gradle对象。它默认是Settings和Project的成员变量。可直接获取  
   //ext前缀,表明操作的是外置属性。api是一个新的属性名。前面说过,只在  
   //第一次定义或者设置它的时候需要ext前缀  
    gradle.ext.api =properties.getProperty('sdk.api')  
     
    println gradle.api  //再次存取api的时候,就不需要ext前缀了  
    ......  
    }

再来一个例子强化一下:

我在utils.gradle中定义了一些函数,然后想在其他build.gradle中调用这些函数。那该怎么做呢?

[utils.gradle]

//utils.gradle中定义了一个获取AndroidManifests.xmlversionName的函数  
def  getVersionNameAdvanced(){  
?  下面这行代码中的project是谁?  
   defxmlFile = project.file("AndroidManifest.xml")  
   defrootManifest = new XmlSlurper().parse(xmlFile)  
   returnrootManifest['@android:versionName']    
}  
//现在,想把这个API输出到各个Project。由于这个utils.gradle会被每一个Project Apply,所以  
//我可以把getVersionNameAdvanced定义成一个closure,然后赋值到一个外部属性  
?  下面的ext是谁的ext?  
ext{ //此段花括号中代码是闭包  
    //除了ext.xxx=value这种定义方法外,还可以使用ext{}这种书写方法。  
    //ext{}不是ext(Closure)对应的函数调用。但是ext{}中的{}确实是闭包。  
    getVersionNameAdvanced = this.&getVersionNameAdvanced  
 }

上面代码中有两个问题:

  • project是谁?
  • ext是谁的ext?

上面两个问题比较关键,我也是花了很长时间才搞清楚。这两个问题归结到一起,其实就是:

加载utils.gradle的Project对象和utils.gradle本身所代表的Script对象到底有什么关系?

我们在Groovy中也讲过怎么在一个Script中import另外一个Script中定义的类或者函数(见3.5 脚本类、文件I/O和XML操作一节)。在Gradle中,这一块的处理比Groovy要复杂,具体怎么搞我还没完全弄清楚,但是Project和utils.gradle对于的Script的对象的关系是:

  • 当一个Project apply一个gradle文件的时候,这个gradle文件会转换成一个Script对象。这个,相信大家都已经知道了。
  • Script中有一个delegate对象,这个delegate默认是加载(即调用apply)它的Project对象。但是,在apply函数中,有一个from参数,还有一个to参数(参考图31)。通过to参数,你可以把delegate对象指定为别的东西。
  • delegate对象是什么意思?当你在Script中操作一些不是Script自己定义的变量,或者函数时候,gradle会到Script的delegate对象去找,看看有没有定义这些变量或函数。

现在你知道问题1,2和答案了:

  • 问题1:project就是加载utils.gradle的project。由于posdevice有5个project,所以utils.gradle会分别加载到5个project中。所以,getVersionNameAdvanced才不用区分到底是哪个project。反正一个project有一个utils.gradle对应的Script。
  • 问题2:ext:自然就是Project对应的ext了。此处为Project添加了一些closure。那么,在Project中就可以调用getVersionNameAdvanced函数了

比如:我在posdevice每个build.gradle中都有如下的代码:

tasks.getByName("assemble"){  
   it.doLast{  
       println "$project.name: After assemble, jar libs are copied tolocal repository"  
        copyOutput(true)  //copyOutput是utils.gradle输出的closure  
     }  
}

通过这种方式,我将一些常用的函数放到utils.gradle中,然后为加载它的Project设置ext属性。最后,Project中就可以调用这种赋值函数了!

注意:此处我研究的还不是很深,而且我个人感觉:

  1. 在Java和Groovy中:我们会把常用的函数放到一个辅助类和公共类中,然后在别的地方import并调用它们。
  2. 但是在Gradle,更正规的方法是在xxx.gradle中定义插件。然后通过添加Task的方式来完成工作。gradle的user guide有详细介绍如何实现自己的插件。

3.  Task介绍

Task是Gradle中的一种数据类型,它代表了一些要执行或者要干的工作。不同的插件可以添加不同的Task。每一个Task都需要和一个Project关联。

Task的API文档位于https://docs.gradle.org/current/dsl/org.gradle.api.Task.html。关于Task,我这里简单介绍下build.gradle中怎么写它,以及Task中一些常见的类型

关于Task。来看下面的例子:

[build.gradle]

//Task是和Project关联的,所以,我们要利用Project的task函数来创建一个Task  
task myTask  <==myTask是新建Task的名字  
task myTask { configure closure }  
task myType << { task action } <==注意,<<符号是doLast的缩写  
task myTask(type: SomeType)  
task myTask(type: SomeType) { configure closure }

上述代码中都用了Project的一个函数,名为task,注意:

  • 一个Task包含若干Action。所以,Task有doFirst和doLast两个函数,用于添加需要最先执行的Action和需要和需要最后执行的Action。Action就是一个闭包。
  • Task创建的时候可以指定Type,通过type:名字表达。这是什么意思呢?其实就是告诉Gradle,这个新建的Task对象会从哪个基类Task派生。比如,Gradle本身提供了一些通用的Task,最常见的有Copy 任务。Copy是Gradle中的一个类。当我们:task myTask(type:Copy)的时候,创建的Task就是一个Copy Task。
  • 当我们使用 task myTask{ xxx}的时候。花括号是一个closure。这会导致gradle在创建这个Task之后,返回给用户之前,会先执行closure的内容。
  • 当我们使用task myTask << {xxx}的时候,我们创建了一个Task对象,同时把closure做为一个action加到这个Task的action队列中,并且告诉它“最后才执行这个closure”(注意,<<符号是doLast的代表)。

图32是Project中关于task函数说明:

 陆陆续续讲了这么些内容,我自己感觉都有点烦了。是得,Gradle用一整本书来讲都嫌不够呢。

anyway,到目前为止,我介绍的都是一些比较基础的东西,还不是特别多。但是后续例子该涉及到的知识点都有了。下面我们直接上例子。这里有两个例子:

  • posdevice的例子
  • 另外一个是单个project的例子

4.4.3  posdevice实例

现在正是开始通过例子来介绍怎么玩gradle。这里要特别强调一点,根据Gradle的哲学。gradle文件中包含一些所谓的Script Block(姑且这么称它)。Script Block作用是让我们来配置相关的信息。不同的SB有不同的需要配置的东西。这也是我最早说的行话。比如,源码对应的SB,就需要我们配置源码在哪个文件夹里。关于SB,我们后面将见识到!

posdevice是一个multi project。下面包含5个Project。对于这种Project,请大家回想下我们该创建哪些文件?

  • settings.gradle是必不可少的
  • 根目录下的build.gradle。这个我们没讲过,因为posdevice的根目录本身不包含代码,而是包含其他5个子project。
  • 每个project目录下包含对于的build.gradle
  • 另外,我把常用的函数封装到一个名为utils.gradle的脚本里了。

马上一个一个来看它们。

1.  utils.gradle

utils.gradle是我自己加的,为我们团队特意加了一些常见函数。主要代码如下:

[utils.gradle]

import groovy.util.XmlSlurper  //解析XML时候要引入这个groovy的package  
   
def copyFile(String srcFile,dstFile){  
     ......//拷贝文件函数,用于将最后的生成物拷贝到指定的目录  
}  
def rmFile(String targetFile){  
    .....//删除指定目录中的文件  
}  
   
def cleanOutput(boolean bJar = true){  
    ....//clean的时候清理  
}  
   
def copyOutput(boolean bJar = true){  
    ....//copyOutput内部会调用copyFile完成一次build的产出物拷贝  
}  
   
def getVersionNameAdvanced(){//老朋友  
   defxmlFile = project.file("AndroidManifest.xml")  
   defrootManifest = new XmlSlurper().parse(xmlFile)  
   returnrootManifest['@android:versionName']    
}  
   
//对于android library编译,我会disable所有的debug编译任务  
def disableDebugBuild(){  
  //project.tasks包含了所有的tasks,下面的findAll是寻找那些名字中带debug的Task。  
  //返回值保存到targetTasks容器中  
  def targetTasks = project.tasks.findAll{task ->  
     task.name.contains("Debug")  
  }  
  //对满足条件的task,设置它为disable。如此这般,这个Task就不会被执行  
 targetTasks.each{  
     println"disable debug task  :${it.name}"  
    it.setEnabled false  
  }  
}  
//将函数设置为extra属性中去,这样,加载utils.gradle的Project就能调用此文件中定义的函数了  
ext{  
    copyFile= this.?File  
    rmFile =this.&rmFile  
   cleanOutput = this.&cleanOutput  
   copyOutput = this.?Output  
   getVersionNameAdvanced = this.&getVersionNameAdvanced  
   disableDebugBuild = this.&disableDebugBuild  
}

图33展示了被disable的Debug任务的部分信息:

 2.  settings.gradle

这个文件中我们该干什么?调用include把需要包含的子Project加进来。代码如下:

[settings.gradle]

/*我们团队内部建立的编译环境初始化函数 
  这个函数的目的是 
  1  解析一个名为local.properties的文件,读取AndroidSDK和NDK的路径 
  2  获取最终产出物目录的路径。这样,编译完的apk或者jar包将拷贝到这个最终产出物目录中 
  3 获取Android SDK指定编译的版本 
*/  
def initMinshengGradleEnvironment(){  
    println"initialize Minsheng Gradle Environment ....."  
   Properties properties = new Properties()  
   //local.properites也放在posdevice目录下  
    FilepropertyFile = new File(rootDir.getAbsolutePath()+ "/local.properties")  
   properties.load(propertyFile.newDataInputStream())  
    /* 
      根据Project、Gradle生命周期的介绍,settings对象的创建位于具体Project创建之前 
      而Gradle底对象已经创建好了。所以,我们把local.properties的信息读出来后,通过 
     extra属性的方式设置到gradle对象中 
      而具体Project在执行的时候,就可以直接从gradle对象中得到这些属性了! 
    */  
    gradle.ext.api =properties.getProperty('sdk.api')  
    gradle.ext.sdkDir =properties.getProperty('sdk.dir')  
     gradle.ext.ndkDir =properties.getProperty('ndk.dir')  
     gradle.ext.localDir =properties.getProperty('local.dir')  
    //指定debugkeystore文件的位置,debug版apk签名的时候会用到  
    gradle.ext.debugKeystore= properties.getProperty('debug.keystore')  
     ......  
    println"initialize Minsheng Gradle Environment completes..."  
}  
//初始化  
initMinshengGradleEnvironment()  
//添加子Project信息  
include 'CPosSystemSdk' , 'CPosDeviceSdk' ,'CPosSdkDemo','CPosDeviceServerApk', 'CPosSystemSdkWizarPosImpl'

注意,对于Android来说,local.properties文件是必须的,它的内容如下:

[local.properties]

local.dir=/home/innost/workspace/minsheng-flat-dir/  
//注意,根据Android Gradle的规范,只有下面两个属性是必须的,其余都是我自己加的  
sdk.dir=/home/innost/workspace/android-aosp-sdk/  
ndk.dir=/home/innost/workspace/android-aosp-ndk/  
debug.keystore=/home/innost/workspace/tools/mykeystore.jks  
sdk.api=android-19

再次强调,sdk.dir和ndk.dir是Android Gradle必须要指定的,其他都是我自己加的属性。当然。不编译ndk,就不需要ndk.dir属性了。

3.  posdevice build.gradle

作为multi-project根目录,一般情况下,它的build.gradle是做一些全局配置。来看我的build.gradle

[posdevice build.gradle]

//下面这个subprojects{}就是一个Script Block  
subprojects {  
  println"Configure for $project.name" //遍历子Project,project变量对应每个子Project  
  buildscript {  //这也是一个SB  
    repositories {//repositories是一个SB  
       ///jcenter是一个函数,表示编译过程中依赖的库,所需的插件可以在jcenter仓库中  
       //下载。  
       jcenter()  
    }  
    dependencies { //SB  
        //dependencies表示我们编译的时候,依赖android开发的gradle插件。插件对应的  
       //class path是com.android.tools.build。版本是1.2.3  
        classpath'com.android.tools.build:gradle:1.2.3'  
    }  
   //为每个子Project加载utils.gradle 。当然,这句话可以放到buildscript花括号之后  
   applyfrom: rootProject.getRootDir().getAbsolutePath() + "/utils.gradle"  
 }//buildscript结束  
}

感觉解释得好苍白,SB在Gradle的API文档中也是有的。先来看Gradle定义了哪些SB。如图34所示:

 你看,subprojects、dependencies、repositories都是SB。那么SB到底是什么?它是怎么完成所谓配置的呢?

仔细研究,你会发现SB后面都需要跟一个花括号,而花括号,恩,我们感觉里边可能一个Closure。由于图34说,这些SB的Description都有“Configure xxx for this project”,所以很可能subprojects是一个函数,然后其参数是一个Closure。是这样的吗?

Absolutely right。只是这些函数你直接到Project API里不一定能找全。不过要是你好奇心重,不妨到https://docs.gradle.org/current/javadoc/,选择Index这一项,然后ctrl+f,输入图34中任何一个Block,你都会找到对应的函数。比如我替你找了几个API,如图35所示:

 特别提示:当你下次看到一个不认识的SB的时候,就去看API吧。

下面来解释代码中的各个SB:

  • subprojects:它会遍历posdevice中的每个子Project。在它的Closure中,默认参数是子Project对应的Project对象。由于其他SB都在subprojects花括号中,所以相当于对每个Project都配置了一些信息。
  • buildscript:它的closure是在一个类型为ScriptHandler的对象上执行的。主意用来所依赖的classpath等信息。通过查看ScriptHandler API可知,在buildscript SB中,你可以调用ScriptHandler提供的repositories(Closure )、dependencies(Closure)函数。这也是为什么repositories和dependencies两个SB为什么要放在buildscript的花括号中的原因。明白了?这就是所谓的行话,得知道规矩。不知道规矩你就乱了。记不住规矩,又不知道查SDK,那么就彻底抓瞎,只能到网上到处找答案了!
  • 关于repositories和dependencies,大家直接看API吧。后面碰到了具体代码我们再来介绍

4.  CPosDeviceSdk build.gradle

CPosDeviceSdk是一个Android Library。按Google的想法,Android Library编译出来的应该是一个AAR文件。但是我的项目有些特殊,我需要发布CPosDeviceSdk.jar包给其他人使用。jar在编译过程中会生成,但是它不属于Android Library的标准输出。在这种情况下,我需要在编译完成后,主动copy jar包到我自己设计的产出物目录中。

//Library工程必须加载此插件。注意,加载了Android插件就不要加载Java插件了。因为Android  
//插件本身就是拓展了Java插件  
apply plugin: 'com.android.library'   
//android的编译,增加了一种新类型的ScriptBlock-->android  
android {  
       //你看,我在local.properties中设置的API版本号,就可以一次设置,多个Project使用了  
      //借助我特意设计的gradle.ext.api属性  
       compileSdkVersion =gradle.api  //这两个红色的参数必须设置  
       buildToolsVersion  = "22.0.1"  
       sourceSets{ //配置源码路径。这个sourceSets是Java插件引入的  
       main{ //main:Android也用了  
           manifest.srcFile 'AndroidManifest.xml' //这是一个函数,设置manifest.srcFile  
           aidl.srcDirs=['src'] //设置aidl文件的目录  
           java.srcDirs=['src'] //设置java文件的目录  
        }  
     }  
   dependencies {  //配置依赖关系  
      //compile表示编译和运行时候需要的jar包,fileTree是一个函数,  
     //dir:'libs',表示搜索目录的名称是libs。include:['*.jar'],表示搜索目录下满足*.jar名字的jar  
     //包都作为依赖jar文件  
       compile fileTree(dir: 'libs', include: ['*.jar'])  
   }  
}  //android SB配置完了  
//clean是一个Task的名字,这个Task好像是Java插件(这里是Android插件)引入的。  
//dependsOn是一个函数,下面这句话的意思是 clean任务依赖cposCleanTask任务。所以  
//当你gradle clean以执行clean Task的时候,cposCleanTask也会执行  
clean.dependsOn 'cposCleanTask'  
//创建一个Task,  
task cposCleanTask() <<{  
    cleanOutput(true)  //cleanOutput是utils.gradle中通过extra属性设置的Closure  
}  
//前面说了,我要把jar包拷贝到指定的目录。对于Android编译,我一般指定gradle assemble  
//它默认编译debug和release两种输出。所以,下面这个段代码表示:  
//tasks代表一个Projects中的所有Task,是一个容器。getByName表示找到指定名称的任务。  
//我这里要找的assemble任务,然后我通过doLast添加了一个Action。这个Action就是copy  
//产出物到我设置的目标目录中去  
tasks.getByName("assemble"){  
   it.doLast{  
       println "$project.name: After assemble, jar libs are copied tolocal repository"  
        copyOutput(true)  
     }  
}  
/* 
  因为我的项目只提供最终的release编译出来的Jar包给其他人,所以不需要编译debug版的东西 
  当Project创建完所有任务的有向图后,我通过afterEvaluate函数设置一个回调Closure。在这个回调 
  Closure里,我disable了所有Debug的Task 
*/  
project.afterEvaluate{  
    disableDebugBuild()  
}

Android自己定义了好多ScriptBlock。Android定义的DSL参考文档在

https://developer.android.com/tools/building/plugin-for-gradle.html下载。注意,它居然没有提供在线文档。

图36所示为Android的DSL参考信息。

图37为buildToolsVersion和compileSdkVersion的说明:

 从图37可知,这两个变量是必须要设置的.....

5.  CPosDeviceServerApk build.gradle

再来看一个APK的build,它包含NDK的编译,并且还要签名。根据项目的需求,我们只能签debug版的,而release版的签名得发布unsigned包给领导签名。另外,CPosDeviceServerAPK依赖CPosDeviceSdk。

虽然我可以先编译CPosDeviceSdk,得到对应的jar包,然后设置CPosDeviceServerApk直接依赖这个jar包就好。但是我更希望CPosDeviceServerApk能直接依赖于CPosDeviceSdk这个工程。这样,整个posdevice可以做到这几个Project的依赖关系是最新的。

[build.gradle]

apply plugin: 'com.android.application'  //APK编译必须加载这个插件  
android {  
      compileSdkVersion gradle.api  
      buildToolsVersion "22.0.1"  
      sourceSets{  //差不多的设置  
       main{  
           manifest.srcFile 'AndroidManifest.xml'  
          //通过设置jni目录为空,我们可不使用apk插件的jni编译功能。为什么?因为据说  
         //APK插件的jni功能好像不是很好使....晕菜  
          jni.srcDirs = []   
           jniLibs.srcDir 'libs'  
            aidl.srcDirs=['src']  
           java.srcDirs=['src']  
           res.srcDirs=['res']  
        }  
    }//main结束  
   signingConfigs { //设置签名信息配置  
       debug {  //如果我们在local.properties设置使用特殊的keystore,则使用它  
           //下面这些设置,无非是函数调用....请务必阅读API文档  
           if(project.gradle.debugKeystore != null){  
              storeFile file("file://${project.gradle.debugKeystore}")  
              storePassword "android"  
              keyAlias "androiddebugkey"  
              keyPassword "android"  
           }  
        }  
   }//signingConfigs结束  
     buildTypes {  
       debug {  
           signingConfig signingConfigs.debug  
           jniDebuggable false  
        }  
    }//buildTypes结束  
   dependencies {  
        //compile:project函数可指定依赖multi-project中的某个子project  
       compile project(':CPosDeviceSdk')  
       compile fileTree(dir: 'libs', include: ['*.jar'])  
   } //dependices结束  
  repositories{  
   flatDir {//flatDir:告诉gradle,编译中依赖的jar包存储在dirs指定的目录  
           name "minsheng-gradle-local-repository"  
            dirsgradle.LOCAL_JAR_OUT //LOCAL_JAR_OUT是我存放编译出来的jar包的位置  
   }  
  }//repositories结束  
}//android结束  
/* 
   创建一个Task,类型是Exec,这表明它会执行一个命令。我这里让他执行ndk的 
   ndk-build命令,用于编译ndk。关于Exec类型的Task,请自行脑补Gradle的API 
*/  
//注意此处创建task的方法,是直接{}喔,那么它后面的tasks.withType(JavaCompile)  
//设置的依赖关系,还有意义吗?Think!如果你能想明白,gradle掌握也就差不多了  
task buildNative(type: Exec, description: 'CompileJNI source via NDK') {  
       if(project.gradle.ndkDir == null) //看看有没有指定ndk.dir路径  
          println "CANNOT Build NDK"  
       else{  
            commandLine "/${project.gradle.ndkDir}/ndk-build",  
               '-C', file('jni').absolutePath,  
               '-j', Runtime.runtime.availableProcessors(),  
               'all', 'NDK_DEBUG=0'  
        }  
  }  
 tasks.withType(JavaCompile) {  
       compileTask -> compileTask.dependsOn buildNative  
  }  
  ......    
 //对于APK,除了拷贝APK文件到指定目录外,我还特意为它们加上了自动版本命名的功能  
 tasks.getByName("assemble"){  
       it.doLast{  
       println "$project.name: After assemble, jar libs are copied tolocal repository"  
       project.ext.versionName = android.defaultConfig.versionName  
       println "\t versionName = $versionName"  
       copyOutput(false)  
     }  
}

6.  结果展示

在posdevice下执行gradle assemble命令,最终的输出文件都会拷贝到我指定的目录,结果如图38所示:

 gradle assemble的执行结果:

  • library包都编译release版的,copy到xxx/javaLib目录下
  • apk编译debug和release-unsigned版的,copy到apps目录下
  • 所有产出物都自动从AndroidManifest.xml中提取versionName。

4.4.4  实例2

下面这个实例也是来自一个实际的APP。这个APP对应的是一个单独的Project。但是根据我前面的建议,我会把它改造成支持Multi-Projects Build的样子。即在工程目录下放一个settings.build。

另外,这个app有一个特点。它有三个版本,分别是debug、release和demo。这三个版本对应的代码都完全一样,但是在运行的时候需要从assets/runtime_config文件中读取参数。参数不同,则运行的时候会跳转到debug、release或者demo的逻辑上。

注意:我知道assets/runtime_config这种做法不decent,但,这是一个既有项目,我们只能做小范围的适配,而不是伤筋动骨改用更好的方法。另外,从未来的需求来看,暂时也没有大改的必要。

引入gradle后,我们该如何处理呢?

解决方法是:在编译build、release和demo版本前,在build.gradle中自动设置runtime_config的内容。代码如下所示:

[build.gradle]

apply plugin: 'com.android.application'  //加载APP插件  
//加载utils.gradle  
apply from:rootProject.getRootDir().getAbsolutePath() + "/utils.gradle"  
//buildscript设置android app插件的位置  
buildscript {  
   repositories { jcenter() }  
   dependencies { classpath 'com.android.tools.build:gradle:1.2.3' }  
}  
//androidScriptBlock  
android {  
   compileSdkVersion gradle.api  
   buildToolsVersion "22.0.1"  
   sourceSets{//源码设置SB  
        main{  
           manifest.srcFile 'AndroidManifest.xml'  
           jni.srcDirs = []  
           jniLibs.srcDir 'libs'  
           aidl.srcDirs=['src']  
           java.srcDirs=['src']  
           res.srcDirs=['res']  
           assets.srcDirs = ['assets'] //多了一个assets目录  
        }  
    }  
   signingConfigs {//签名设置  
       debug {  //debug对应的SB。注意  
           if(project.gradle.debugKeystore != null){  
               storeFile file("file://${project.gradle.debugKeystore}")  
               storePassword "android"  
               keyAlias "androiddebugkey"  
               keyPassword "android"  
           }  
        }  
    }  
    /* 
     最关键的内容来了: buildTypesScriptBlock. 
     buildTypes和上面的signingConfigs,当我们在build.gradle中通过{}配置它的时候, 
     其背后的所代表的对象是NamedDomainObjectContainer<BuildType> 和 
     NamedDomainObjectContainer<SigningConfig> 
     注意,NamedDomainObjectContainer<BuildType/或者SigningConfig>是一种容器, 
     容器的元素是BuildType或者SigningConfig。我们在debug{}要填充BuildType或者 
    SigningConfig所包的元素,比如storePassword就是SigningConfig类的成员。而proguardFile等 
    是BuildType的成员。 
    那么,为什么要使用NamedDomainObjectContainer这种数据结构呢?因为往这种容器里 
    添加元素可以采用这样的方法: 比如signingConfig为例 
    signingConfig{//这是一个NamedDomainObjectContainer<SigningConfig> 
       test1{//新建一个名为test1的SigningConfig元素,然后添加到容器里 
         //在这个花括号中设置SigningConfig的成员变量的值 
       } 
      test2{//新建一个名为test2的SigningConfig元素,然后添加到容器里 
         //在这个花括号中设置SigningConfig的成员变量的值 
      } 
    } 
    在buildTypes中,Android默认为这几个NamedDomainObjectContainer添加了 
    debug和release对应的对象。如果我们再添加别的名字的东西,那么gradleassemble的时候 
    也会编译这个名字的apk出来。比如,我添加一个名为test的buildTypes,那么gradle assemble 
    就会编译一个xxx-test-yy.apk。在此,test就好像debug、release一样。 
   */  
   buildTypes{  
        debug{ //修改debug的signingConfig为signingConfig.debug配置  
           signingConfig signingConfigs.debug  
        }  
        demo{ //demo版需要混淆  
           proguardFile 'proguard-project.txt'  
           signingConfig signingConfigs.debug  
        }  
       //release版没有设置,所以默认没有签名,没有混淆  
    }  
      ......//其他和posdevice 类似的处理。来看如何动态生成runtime_config文件  
   def  runtime_config_file = 'assets/runtime_config'  
   /* 
   我们在gradle解析完整个任务之后,找到对应的Task,然后在里边添加一个doFirst Action 
   这样能确保编译开始的时候,我们就把runtime_config文件准备好了。 
   注意,必须在afterEvaluate里边才能做,否则gradle没有建立完任务有向图,你是找不到 
   什么preDebugBuild之类的任务的 
   */  
   project.afterEvaluate{  
      //找到preDebugBuild任务,然后添加一个Action   
      tasks.getByName("preDebugBuild"){  
           it.doFirst{  
               println "generate debug configuration for ${project.name}"  
               def configFile = new File(runtime_config_file)  
               configFile.withOutputStream{os->  
                   os << I am Debug\n'  //往配置文件里写 I am Debug  
                }  
           }  
        }  
       //找到preReleaseBuild任务  
       tasks.getByName("preReleaseBuild"){  
           it.doFirst{  
               println "generate release configuration for ${project.name}"  
               def configFile = new File(runtime_config_file)  
               configFile.withOutputStream{os->  
                   os << I am release\n'  
               }  
           }  
        }  
       //找到preDemoBuild。这个任务明显是因为我们在buildType里添加了一个demo的元素  
      //所以Android APP插件自动为我们生成的  
       tasks.getByName("preDemoBuild"){  
           it.doFirst{  
               println "generate offlinedemo configuration for${project.name}"  
               def configFile = new File(runtime_config_file)  
               configFile.withOutputStream{os->  
                   os << I am Demo\n'  
               }  
            }  
        }  
    }  
}  
 .....//copyOutput

 

最终的结果如图39所示:

 几个问题,为什么我知道有preXXXBuild这样的任务?

答案:gradle tasks --all查看所有任务。然后,多尝试几次,直到成功

五、总结

到此,我个人觉得Gradle相关的内容都讲完了。很难相信我仅花了1个小时不到的时间就为实例2添加了gradle编译支持。在一周以前,我还觉得这是个心病。回想学习gradle的一个月时间里,走过不少弯路,求解问题的思路也和最开始不一样:

  • 最开始的时候,我一直把gradle当做脚本看。然后到处到网上找怎么配置gradle。可能能编译成功,但是完全不知道为什么。比如NameDomainObjectContainer,为什么有debug、release。能自己加别的吗?不知道怎么加,没有章法,没有参考。出了问题只能google,找到一个解法,试一试,成功就不管。这么搞,心里不踏实。
  • 另外,对语法不熟悉,尤其是Groovy语法,虽然看了下快速教材,但总感觉一到gradle就看不懂。主要问题还是闭包,比如Groovy那一节写得文件拷贝的例子中的withOutputStream,还有gradle中的withType,都是些啥玩意啊?
  • 所以后来下决心先把Groovy学会,主要是把自己暴露在闭包里边。另外,Groovy是一门语言,总得有SDK说明吧。写了几个例子,慢慢体会到Groovy的好处,也熟悉Groovy的语法了。
  • 接着开始看Gradle。Gradle有几本书,我看过Gradle in Action。说实话,看得非常痛苦。现在想起来,Gradle其实比较简单,知道它的生命周期,知道它怎么解析脚本,知道它的API,几乎很快就能干活。而Gradle In Action一上来就很细,而且没有从API角度介绍。说个很有趣的事情,书中有个类似下面的例子
task myTask  <<  {
   println ' I am myTask'
}

书中说,如果代码没有加<<,则这个任务在脚本initialization(也就是你无论执行什么任务,这个任务都会被执行,I am myTask都会被输出)的时候执行,如果加了<<,则在gradle myTask后才执行。


https://www.xamrdz.com/mobile/4c81961304.html

相关文章: