第七章AndroidGradle插件
从这章开始我们就开始介绍Android Gradle插件了，会通过⼏章由浅⼊深的详细的介绍Android Gradle，本章会简单的介绍下Android Gradle 插件，然后通过⼀个例⼦对其有⼤概的了解，最后讲下如果从原来基于Eclipse进⾏Android开发的⽅式，转到基于Android Studio，使⽤Android Gradle插件开发的新⽅式
7.1 Android Gradle插件简介
从Gradle的⾓度看，我们知道Android其实就是Gradle的⼀个第三⽅插件，他是由Google 的Android团队开发的，但是从Android的⾓度
看，Android插件是基于Gradle构建的，和Android Studio完美⽆缝搭配的新⼀代构建系统，它不同于Eclipse+Ant的搭配，相⽐于旧的构建系统，它更灵活，更容易配置，还能很⽅便的创建衍⽣的版本--也就是我们常⽤的多渠道包。让我们看看Android官⽅对它的推崇程度：
1. 可以很容易的重⽤代码和资源
2. 可以很容易的创建应⽤的衍⽣版本，所以不管你是创建多个apk，还是不同功能的应⽤都很⽅便
3. 可以很容易的配置、扩展以及⾃定义构建过程
4. 和IDE⽆缝整合
上⾯说的IDE就是Android Studio，真是Android Gradle+Android Studio搭配，⼯作不累。
7.2 Android Gradle插件分类
Android Gradle插件的分类其实是根据Android⼯程的属性分类的，在Android中有三类⼯程，⼀类是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：st
通过应⽤以上三种不同的插件，就可以配置我们的⼯程是⼀个Android App⼯程，还是⼀个Android Library⼯程，或者是⼀个Android Test测试⼯程，然后配合着Android Studio，就可以分别对他们进⾏编译、测试、发布等操作。
7.3 应⽤Android Gradle插件
在讲Gradle插件的时候，我们讲了要应⽤⼀个插件，必须要知道他们的插件id，除此之外，如果是第三⽅的插件，还要配置他们的依赖classpath。Android Gradle插件就是属于第三⽅插件，它托管在Jcenter上，所以在应⽤他们之前，我们要先配置依赖classpath，这样当我们应⽤插件的时候，Gradle系统才能到他们。
我们配置⾥仓库为jcenter，这样当我们配置依赖的时候，gradle就会去这个仓库⾥寻我们的依赖。
然后我们在dependencies{}配置⾥我们需要的是Android Gradle1.5.0版本的插件。
buildscript{}这部分配置可以写到根⼯程的adle脚本⽂件中，这样所有的⼦⼯程就不⽤重复配置了。
以上配置好之后，我们就可以应⽤我们的Android Gradle插件了。
android{}是Android插件提供的⼀个扩展类型，可以让我们⾃定义Android Gradle⼯程。compileSdkVersion是编译所依赖的Android SDK的版本，这⾥是API Level；buildToolsVersion是构建该Android⼯程所以的构建⼯具的版本。
以前应⽤的是⼀个App⼯程插件，应⽤Android Library插件和Android Test插件也类似的，只需要换成相应的id即可。
7.4 Android Gradle⼯程⽰例
Android Gradle插件继承于Java插件，具有所有Java插件的特性，它也需要在Setting⽂件⾥通过include配置包含的⼦⼯程，也需要应⽤Android插件等等。
下⾯我们就通过⼀个App⼯程的⽰例，来演⽰下App的⼯程⽬录结构以及相关的Android Gradle配置。
我们可以通过Android Studio创建⼀个App⼯程，创建后我们可以看到其⼤概⼯程⽬录结构如下：
其⽬录结构和Java⼯程相⽐没有太⼤的变化，proguard-rules.pro是⼀个混淆配置⽂件；src⽬录下的androidTest、main、test分别是三个SourceSet，分别对应Android单元测试代码、Android App主代码和资源、普通的单元测试代码。我们注意到main⽂件夹，相⽐Java的，多了l，res这两个属于Android特有的⽂件⽬录，⽤于描述Android App的配置和资源⽂件。
下⾯我们来看看Android Gradle的adle配置⽂件
Android Gradle⼯程的配置，都是在android{}中，这是唯⼀的⼀个⼊⼝，通过它，可以对Android Gradle⼯程进⾏⾃定义的配置，其具体实现是com.adle.AppExtension，是Project的⼀个扩展，创建原型如下：
在com.android.application插件中，getExtensionClass()返回的就是com.adle.AppExtension，所以关于android的很多配置可以从这个类⾥去，参考我们前⾯讲的Gradle知识，可以到很多试⽤的配置或者可以利⽤的对象、⽅法或者属性等等，⽽这些并没有在Android⽂档⾥介绍的，这就是可以看源代码的好处。
7.4.1 com p ile Sd kVe r s ion
compileSdkVersion 23，是配置我们编译Android⼯程的SDK，这⾥的23是Android SDK的API Level，对应的是Android6.0的SDK，这个⼤家都清楚的。该配置的原型是⼀个compileSdkVersion⽅法
除此之外，他还有⼀个set⽅法，所以我们可以把它当成android的⼀个属性使⽤。
使⽤⽅式是：
这就是Gradle的灵活⽀出，通过不同的⽅法，就可以达到不同的配置⽅式。
7.4.2 buildToolsVersion
buildToolsVersion "23.0.1"表⽰我们使⽤的Android 构建⼯具的版本，我们可以在Android SDK⽬录⾥看到，它是⼀个⼯具包，包括
appt，dex等⼯具。它的原型也是⼀个⽅法。
从以上的⽅法原型中可以看到，我们可以通过buildToolsVersion⽅法赋值，也可以通过android.buildToolsVersion这个属性读写它的值。
7.4.3 d e f aultC onf ig
defaultConfig是默认的配置，它是⼀个ProductFlavor，ProductFlavor允许我们根据不同的情况同时⽣成多个不同的APK包，⽐如我们后⾯介绍的多渠道打包。如果不针对我们⾃定义的ProductFlavor单独配置的话，会为这个ProductFlavor使⽤默认的defaultConfig的配置。
例⼦中applicationId是配置我们的包名，这⾥是org.ample74
minSdkVersion 是最低⽀持的Android系统的API Level，这⾥是14
targetSdkVersion 表明我们是基于哪个Android版本开发的，这⾥是23
versionCode 我们的App应⽤内部版本号，⼀般⽤于控制App升级
versionName 我们的App应⽤的版本名称，⽤户可以看到，就是我们发布的版本，这⾥是1.0
以上所有配置对应的都是ProductFlavor类⾥的⽅法或者属性。
7.4.4 b uild T yp e s
buildTypes是⼀个NamedDomainObjectContainer类型，是⼀个域对象，还记得我们讲的SourceSet吗？这个和那个⼀样。SourceSet⾥有main、test等，同样的buildTypes⾥有release，debug等，我们可以在buildTypes{}⾥新增任意多个我们需要构建的类型，⽐如
debug，Gradle会帮我们⾃动创建⼀个对应的BuildType，名字就是我们定义的名字。
release就是⼀个BuildType，后⾯章节我们会详细介绍BuildType，例⼦中我们⽤到了两个配置
minifyEnabled 是否为该构建类型启⽤混淆，我们这⾥是false表⽰不启⽤，如果想要启⽤可以设置为true
proguardFiles，当我们启⽤混淆时，所使⽤的proguard的配置⽂件，我们可以通过它配置我们如何进⾏proguard混淆，⽐如混淆的级别，哪些类或者⽅法不进⾏混淆等等。它对应BuildType的proguardFiles⽅法，可以接受⼀个可变参数，所以我们同时可以配置多个配置⽂件，⽐如我们例⼦中的
proguardFiles getDefaultProguardFile(''), 'proguard-rules.pro'
getDefaultProguardFile是android扩展的⼀个⽅法，它可以获取你的Android SDK⽬录下的默认的proguard配置⽂件，在android-
sdk/tools/proguard/⽬录下，⽂件名就是我们传⼊的参数的名字。
其他还有很多有⽤的配置，我们后⾯的章节都会⼀⼀介绍，这⾥只简单的介绍⼊门⽰例，让⼤家对Android Gradle有⼀个⼤概的了解
7.5 Android Gradle任务
我们说过Android插件是基于Java插件，所以Android插件基本上包含⾥所有Java插件的功能，包括继承的任务，⽐如assemble、check、build等等，除此之外，Android在⼤类上还添加了connectedCheck、deviceCheck、lint、install、uninstall等任务，这些是属于Android特有的功能。
eclipse androidconnectedCheck 在所有链接的设备或者模拟器上运⾏check检查
deviceCheck 通过API连接远程设备运⾏checks。它被⽤于CI(译者注：持续集成)服务器上。
lint 在所有的ProductFlavor上运⾏lint检查。
install和uninstall类的任务可以直接在我们已链接的设备上安装或者卸载你的App。
除此之外，还有⼀些不太常⽤的任务，⽐如signingReport 可以打印App的签名；androidDependencies 可以打印android的依赖，还有其他⼀些类似的任务，⼤家可以通过./gradlew tasks来查看。
⼀般我们常⽤的任务是build、assemble 、clean、lint、以及check等，通过这些任务我们可以打包⽣成我们的Apk，对现有的Android⼯程进⾏lint检查等等。
7.6 从Eclipse迁移到Android Gradle⼯程
最开始的时候还没有Android Studio，也没有Android Gradle这个插件，我们都是使⽤Eclipse+ADT+Ant进⾏Android开发，⽤过Ant的，再和我们的Gradle对⽐⼀下，就会发现Gradle的灵活，还有Android Studio这个强⼤的IDE和Android Gradle完美配合，会使得我们开发效率⼤⼤提⾼，所以很多⼈都迫不及待的想从原来基于Eclipse+ADT+Ant，迁移到我们的Android Studio+Gradle，这⼀⼩结我们就简单的讲下如何迁移。
从Eclipse迁移到Android Studio有两种⽅式，⼀种是使⽤Android Studio直接导⼊Eclipse⼯程，另外⼀种使⽤Eclipse导出Android Gradle配置⽂件，转换为⼀个Gradle⼯程，然后再使⽤Android Studio把它作为⼀个Gradle⼯程导⼊。
7.6.1 使⽤A nd r oid Stud io导⼊
这种⽅式⽐较简单，要导⼊到Android Studio，我们打开Android Studio，选择File->Import Project，然后会弹出⼀个对话框，选择我们的Eclipse ADT⼯程的⽬录，然后就会打开⼀个向导，按向导⼀步步操作，最后完成的时候，会打开⼀个 "" ⽂件，⾥⾯描述的我们这次导⼊涉及到的⽂件迁移和改变等等，我们再根据我们上⾯讲的Android Gradle⼯程结构做调整即可。
以上是我导⼊的⼀个例⼦⽣成的，我们可以看到有⼀段Moved Files，也就是说，这种导⼊⽅式，会把我们原来
Eclipse+ADT项⽬的⽬录结构转换成了Android Studio的⽬录结构，破坏了原来的⽬录结构，如果对于⽬录结构有严格要求的，就不要使⽤这种⽅式了，可以使⽤我们下⾯讲的第⼆种⽅式，如果没有严格要求的，建议采⽤这种⽅式，因为这是Android Studio默认推荐的⽬录结构，也可以熟悉下，为以后的新的功能，甚⾄团队间的协作也⽅便，因为它毕竟是Android Studio的⼀种默认的约定，⼤家都熟悉，沟通交流简单。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。