记录使用Android Studio以及Gradle的心路历程。系列文章将持续更新中。。。

加速篇

第一次加载项目缓慢

对于初用Android Studio的朋友来说，项目构建是一个很缓慢的过程，因为中间会下载好多好多东西。这里我仅总结下如何提升编译过程中的下载组件部分，其他什么daemon或是configureondemand我在使用时候发现几乎没有什么效果。
我以lottie-android为例，先看看它的目录结构

lottie-android

(1) 确定根目录下的build.gradle中 Android Gradle Plugin版本是否与本地插件版本一直，若不一直修改为本地插件版本

Android Gradle Plugin插件版本

这里是2.3.0-beta3，我本地是2.2.3，直接修改成我本地的版本号即可
(2) 确定 gradle/wrapper/gradle-wrapper.properties文件中gradle的版本在 C:\Users\用户名\.gradle\wrapper\dists是否已经离线存在

gradle的版本

这里是3.3，我本地是2.14.1，直接修改成我本地的版本号即可
(3) 分别查看各个module中的build.gradle里面 compileSdkVersion、buildToolsVersion、com.android.support等Android SDK的相应版本是否已经存在。
(4) 如果存在其他第三方库，若能提前下载完成最好。已经下载完成的库存放在 C:\Users\用户名\.gradle\caches\modules-2\files-2.1里面

第三方库存放路径

以fresco为例，如果你之前在其他电脑上找到相应完整的目录，请拷贝到其中，以节省下载所需时间
(5) 明确版本号写法的差别。先看下这几种写法，以gson为例

dependencies {
    compile 'com.google.code.gson:gson:2.2.1'
    compile 'com.google.code.gson:gson:2.2.＋'
    compile 'com.google.code.gson:gson:2.＋'
    compile 'com.google.code.gson:gson:＋'
}

大家大概心里有数了吧，版本号模糊，就意味着每次都要去对比同步得到最新版本，时间就花费在这个上面了，所以我们的版本号一定要写精确，这样才能节省这些时间

基础配置篇

设置全局编译器的版本

在使用retrolambda的时候有过对java编译器的配置
如果仅需某一个module单独支持，只要在相应module的build.gradle下进行配置即可

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

如果你希望全局配置，则需要配置根目录下的build.gradle，在其allprojects中进行配置即可

allprojects {
    repositories {
        jcenter()
    }
    tasks.withType(JavaCompile) {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}

注意设置java1.8版本需要开启jack编译，否则会抛出Error:Jack is required to support java 8 language features

defaultConfig {
    ...
    jackOptions {
        enabled true
    }
}

签名文件的存放与配置

在你的工程里，是不是这样对签名进行如下配置？

   signingConfigs {
         storeFile file("android.keystore")
         storePassword "abcd1234"
         keyAlias "android.keystore"
         keyPassword "abcd1234"
    }

这种看上去很直观，但是不好的地方就是安全性不够格。我们可以将这些高危参数放到专门的配置文件中，并且在提交代码的时候将其从版本管理中忽略。
我们将配置信息写在gradle.properties中

# keystore配置信息
storeFile_=android.keystore
storePassword_=abcd1234
keyAlias_=android.keystore
keyPassword_=abcd1234

必要信息写完之后，即可修改build.gradle中的signingConfigs，直接引用gradle.properties中的配置信息

storeFile file(storeFile_)
storePassword storePassword_
keyAlias keyAlias_
keyPassword keyPassword_

其实你可以在任何目录放置这个签名文件。如果签名信息没有放到gradle.properties或者local.properties里，那就需要自己通过代码来读取配置信息，从而获取相应的数值。这里示例是keystore.txt文件，目录与gradle.properties同级

keystore.txt

内容就不加展示了，与之前gradle.properties里面配置的一样，来看看如何加载

// 加载签名配置文件
Properties props = new Properties()
props.load(new FileInputStream(file("../gradle.properties")))
android {
    signingConfigs {
        release {
            storeFile file(props['storeFile_'])
            storePassword props['storePassword_']
            keyAlias props['keyAlias_']
            keyPassword props['keyPassword_']
        }
    }
}

占位符的使用

占位符常用在androidManifest.xml中，随后可在相应module的build.gradle中将其进行赋值。这个大多用在多渠道打包设置渠道名称上
先看下manifest文件，以友盟多渠道举例说明，这里的占位符就是UMENG_CHANNEL


        .............

我在defaultConfig下配置manifestPlaceholders，这里将UMENG_CHANNEL的值设置为“测试渠道”

manifestPlaceholders = [UMENG_CHANNEL : "测试渠道"]

最后使用代码验证一下

try {
    ApplicationInfo info=getPackageManager().getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA);
    Log.d("MainActivity", info.metaData.getString("UMENG_CHANNEL"));
} catch (PackageManager.NameNotFoundException e) {
    e.printStackTrace();
}

正常打印

最终结果

同样的配置也可以在productFlavors上，这个就是多渠道打包中统计渠道来源的常规方法

    productFlavors {
        version1 {
            manifestPlaceholders = [UMENG_CHANNEL : "version1"]
        }
        version2 {
            manifestPlaceholders = [UMENG_CHANNEL : "version2"]
        }
    }

设置第三方远程仓库

如果我们的项目不在center或者MavenCenter的话，我们就需要单独配置maven信息了，因为我目前没有尝试搭建过maven仓库，所以在github截图来展示。关于本地Maven的操作，请参考发布Android studio项目到本地Maven仓库

maven

如果仓库在本地的话，相应url换成本地地址即可。
我一般使用的是jitpack这个远程仓库，他可以直接与github进行关联，从而生成相应的版本信息。关于jitpack的使用请参考优雅的发布Android开源库(论JitPack的优越性)

allprojects {
    repositories {
        jcenter()
        maven { url 'https://jitpack.io' }
    }
}

构建参数篇

多编译环境设置

这个就涉及到buildTypes了。在默认情况下，buildTypes可以让gradle插件自动构建一个release版本app以及一个debug版本app。这两个版本区别主要在app配置以及签名上。debug包使用默认签名信息，这个签名文件在/.android/debug.keystore，而release包需要你稍后自行配置。如果你需要创建其他的build type，你可以在buildTypes这个DSL下进行配置。
这里我给出一个简单的buildTypes配置范例

   signingConfigs {
        release {
            try {
                storeFile file("android.keystore")
                storePassword "abcd1234"
                keyAlias "android.keystore"
                keyPassword "abcd1234"
            } catch (ex) {
                throw new InvalidUserDataException(ex.toString())
            }
        }
    }
    buildTypes {
        debug {
            applicationIdSuffix '.debug'
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        release {
            signingConfig signingConfigs.release
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            shrinkResources false
            zipAlignEnabled true
        }
        // 如果我们想要新增加一个buildType，又想要新的buildType继承之前配置好的参数，init.with()就很适合你了
        hiapk.initWith(buildTypes.debug)
        hiapk {
            applicationIdSuffix '.hi'
            versionNameSuffix '.hi'
        }
    }

如此配置之后，Build Variants模块如图所示，可以得到3个不同打包配置的apk文件

variants

同时右上角那边的gradle脚本信息中也得到3个不同的编译脚本

gradle projects

buildTypes在debug包里，applicationId后缀为.debug；release包中的signingConfig文件为signingConfigs下的release；最后还有一个自己添加的buildType--hiapk，他的配置复制于debug，同时修改了applicationId后缀与versionName后缀
我们可以使用 gradle build命令进行全部打包，也同样可以使用 gradle assembleHiapk这种单一打包方式进行打包。打包完成之后我们反编译一下来看看三个apk的manifest信息

hiapk

release

debug

可以很清楚的看出来其中的不同
这里还有其他的DSL简单介绍一下
signingConfigs:秘钥配置信息。
shrinkResources:是否清理无用资源文件，注意如果选择true，那么minifyEnabled也得为true才行，即开启混淆
zipAlignEnabled:是否开启zipAlign压缩

编译项目时设置可引用参数

在刚才的buildTypes中有一个重要的DSL——buildConfigField，在打包编译项目时可以直接设置一些作用于项目的参数，从而在项目中使用这些参数进行逻辑层处理。buildConfigField支持Java中基本数据类型，如果是字符串，记得转义后加双引号
这里我们定义一个字符串，名称叫SERVER_HOST

buildConfigField "String", "SERVER_HOST", "\"http://200.200.200.50/\""

设置完之后编译项目，在BuildConfig.java中可以查到之前配置的相关信息

BuildConfig.java

使用时候这样

Log.d("MainActivity", BuildConfig.SERVER_HOST);

查看控制台输出

buildconfigs

玩转依赖篇

说到依赖，一般情况下我们只需要将compile远程仓库地址拷贝一下就行了，其实依赖的学问很大，远远不是compile一下而已。

依赖方式

依赖类型

Compile: 默认配置，该依赖会参与编译并且打包到所有的build type以及flavors的apk中
Provided: 对所有的build type以及flavors来说只在编译时使用，只参与编译并不打包到最终apk
APK: 只会打包到apk文件中而不参与编译，所以不能在代码中直接调用jar中的类或方法，否则在编译时会报错
另外三种compile只跟测试有关
Test compile: 仅仅是针对单元测试代码编译以及最终打包测试apk时有效，而对正常的debug或者release apk包不起作用。
Debug compile: 仅仅针对debug模式的编译和最终的debug打包时有效。
Release compile: 仅仅针对release模式的编译和最终的release打包时有效。

依赖远程文件

这是最基本的用法，在上文也提及过了

compile 'io.reactivex.rxjava2:rxandroid:2.0.1'

依赖本地文件

当前模块下libs文件夹下的全部jar文件

compile fileTree(include: ['*.jar'], dir: 'libs')

指定路径下的全部jar文件

compile fileTree(dir: '../librarymodule/libs', include: '*.jar')

加载aar文件

repositories {
    flatDir {
        dirs 'libs'
    }
}

这意味着系统将在libs目录下搜索依赖。同样的如果你愿意的话可以加入多个目录。这里系统直接加载libs文件夹下的aar文件

compile(name: 'aar的名字（不用加后缀）', ext: 'aar')

依赖本地库工程

compile project(':librarymodule')

冲突的解决方法

先来看看几种不同的写法对库的加载有何区别

// 下载包含该库在内的其他所依赖的所有库
compile 'io.reactivex.rxjava2:rxandroid:2.0.1'

写法1

// 只下载该库，其他所依赖的所有库不下载
compile 'io.reactivex.rxjava2:rxandroid:2.0.1@aar'

写法2

// 在使用@aar的前提下还能下载其他依赖库，则需要添加transitive=true的条件
compile ("io.reactivex.rxjava2:rxandroid::2.0.1@aar") {
    transitive=true
}

写法3

// 去除某一个依赖库
compile ("io.reactivex.rxjava2:rxandroid:$rootProject.ext.rxandroid") {
    transitive=true
    exclude group: 'io.reactivex.rxjava2', module: 'rxjava'
}

写法4

这时候，我又加了一个rxbinding库，这时候依赖树是这样的结构

依赖树结构

如果我想将项目中的所有rxjava2引用都去除，可以用configurations实现

configurations {
    all*.exclude group: 'io.reactivex.rxjava2', module: 'rxjava'
}

或者这样

configurations {
    compile.exclude module: 'rxjava'
}

如果在configuration中定义一个exclude，那么所有单独设置的transitive dependency都会被去除。你可以只指定group的名字, 或只指定module的名字，或二者都指定

configurations

明白如上写法造成的区别之后，你应该就知道如何解决包冲突了吧
这里对gradle dependencies中的->、 (*)进行解释
固定版本: 唯一的依赖
固定版本(*):还存在该库其他版本的依赖或者间接依赖，并且默认选择(*)所标注的版本。这里rxjava版本就是使用rxbinding里的2.0.2
版本1->版本2(*):还存在该库其他版本的依赖或者间接依赖，并且并且选择版本2。这里rxandroid版本就是使用2.0.1
configurations DSL还可以通过Force强制约束某个库的版本，比如我这里将appcompat-v7包限定为25.1.0

configurations.all {
    resolutionStrategy {
        force "com.android.support:appcompat-v7:25.1.0"
    }
}

force

按构建目标定制依赖库

如果你想给productFlavors中的version2添加相应的依赖，只需要在它的名称后面加上Compile这样配置即可

version2Compile 'com.github.AlphaBoom:ClassifyView:0.5.2'

外部配置依赖版本

当我们直接建立完项目之后，android的相关配置就已经自动完成了，像这样

默认gradle配置

其实这样也算相对清爽吧，但是一旦引用库数量变多，这样或许就不够直观了。这种情况下，我们最好有一个单独的文件去统计这些配置。
我们新建一个config.gradle作为配置文件

config.gradle

具体配置如下

ext {
    androidGradleVersion = '2.3.1'
    AndroidSupportVersion = '25.3.1'
    AndroidConstraintLayoutVerson = '1.0.2'
    compileSdkVersion = 25
    buildToolsVersion = '25.0.2'

    defaultConfig = [
            applicationId : "com.renyu.gradledemo",
            minSdkVersion : 15,
            targetSdkVersion : 25,
            versionCode : 1,
            versionName : "1.0"
    ]
}

其中defaultConfig是一个map键值对，有别于上方的公共配置，这样看起来更清晰简洁
这里我们需要使用apply from来引用config.gradle。同理当你的gradle脚本太大的时候，你可以按照具体任务类型将一个大gradle脚本拆分成几个子脚本，然后分别apply from引入到主脚本中。

// 这里的apply是为了让子模块使用
apply from: "config.gradle"

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // root下build.gradle使用
        apply from: "config.gradle"
        classpath "com.android.tools.build:gradle:$androidGradleVersion"

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

再看看app模块下的build.gradle的配置

apply plugin: 'com.android.application'

android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion
    defaultConfig {
        applicationId rootProject.ext.defaultConfig.applicationId
        minSdkVersion rootProject.ext.defaultConfig.minSdkVersion
        targetSdkVersion rootProject.ext.defaultConfig.targetSdkVersion
        versionCode rootProject.ext.defaultConfig.versionCode
        versionName rootProject.ext.defaultConfig.versionName
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    compile "com.android.support:appcompat-v7:$rootProject.ext.AndroidSupportVersion"
    compile "com.android.support.constraint:constraint-layout:$rootProject.ext.AndroidConstraintLayoutVerson"
    testCompile 'junit:junit:4.12'
}

注意这里单引号与双引号的区别，对于字符串你既可以使用单引号或者双引号，但是字符串可以插入表达式

对layout进行模块化分包

一般情况下我们app的布局文件会随着项目的开发而发生爆炸式的增长

一般项目layout下文件列表

这种组织结构会让人眼花缭乱不知所措，时间久了就会忘记某个功能用的都是哪些布局文件了。今儿就来向大家介绍如何对layout进行模块化分包。
首先来看看效果

对layout进行模块化分包

怎么样，main模块与main2模块他们的布局是相互独立保存的，没有堆叠在一起。那么这个是怎么做到的呢？之前大家从eclipse直接转项目到Android Studio上的时候，不知道有没有注意到在app模块下的build.gradle有一个DSL叫sourceSets，通过修改sourceSets中的属性，可以指定哪些源文件（或文件夹下的源文件）要被编译，哪些源文件要被排除。Gradle就是通过它实现项目的布局定义。Android Studio插件默认实现了两个sourceSet：main和test。每个sourceSet都提供了一系列的属性，通过修改这些属性，可以定义该sourceSet所包含的源文件，比如java.srcDirs，res.srcDirs

sourceSets {
   main {
      java
      res
   }
   test {
      java
      res
   }
}

了解完原理之后那就看看怎么搞吧

按照自己的项目需求建立layout目录，例如本文就是/alllayouts/main/layout与/alllayouts/main2/layout
在module对应的build.gradle下添加sourceSets配置

sourceSets {
        main {
            res.srcDirs = [
                    'src/main/res/alllayouts/main',
                    'src/main/res/alllayouts/main2',
                    'src/main/res'
            ]
        }
    }

注意：最后一行要添加

Sync Now

多渠道多版本打包调试

之前在使用buildTypes的时候，我们提到过使用buildConfigField完成相应的参数初始化，这里还有一个更高级的功能，就是使用productFlavors来修改每个版本的不同部分，或者通过判断当前所使用的app是哪个版本，执行对应版本的代码。
还是先简单看下结构

productFlavors结构

然后开始build.gradle的相关配置

productFlavors {
    version1 {
    }
    version2 {
    }
}
sourceSets {
        main {
            java.srcDirs = ['src/main/java']
        }
        version1.java.srcDirs = ['src/version1/java']
        version2.java.srcDirs = ['src/version2/java']
    }

VersionInfo同时在version1与version2包里进行定义，区别仅仅在变量的值上。在sourceSets对差异部分进行配置，注意一下路径。

public class VersionInfo {
    String v="2";
}

public class VersionInfo {
    String v="1";
}

最后我们进行编译打包

编译完成后的结果

反编译查看两个包中的文件

version1

version2

这样即完成加载不同的类对象

这里还有一个补充，如果你想修改不同渠道包的包名等信息，你可以直接在productFlavors下进行配置。applicationId这个DSL用于修改它们的applicationId，resValue支持res/values下的资源定义，与之前的buildConfigField区别是字符串无需加转义后的双引号。这里是app_name，所以app的应用名称也会被修改

productFlavors {  
    version1 {  
        applicationId "com.renyu.gradledemo.v1"  
        resValue "string", "app_name", "版本1"  
    }  
    version2 {  
        applicationId "com.renyu.gradledemo.v2"  
        resValue "string", "app_name", "版本2"  
    }  
}

自定义apk文件输出路径及apk文件名

image.png

我希望可以像上图一样自定义apk的文件路径以及名称，这个也很简单，直接看代码

applicationVariants.all { variant ->
                variant.outputs.each { output ->
                    output.outputFile =
                            new File(rootProject.ext.appReleaseDir + getDate() +
                                    "_v" + rootProject.ext.defaultConfig.versionName +
                                    "_" +
                                    variant.productFlavors[0].name +
                                    rootProject.ext.appSuffixName)
                }
            }

new File中的内容就是我们的路径跟文件名，这个相信大家都能理解。我们在之前的config.gradle中新增一个appReleaseDir作为文件目录，然后用打包时间+版本号+渠道名称+文件后缀名作为文件名
config.gradle新增内容如下

    appReleaseDir = 'C:\\Users\\renyu\\Desktop\\'
    appSuffixName = "_release.apk"

build.gradle中的getDate()方法

def getDate()  {
    def date = new Date()
    def formattedDate = date.format('yyyyMMddHHmm')
    return formattedDate
}

NDK篇

abiFilters可以优先适配需要适配的cpu，其他做兼容处理。
如本例我们放置了armeabi、armeabi-v7a、x86三种类型CPU的so，其他的就让手机自己去做兼容处理去了

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

其他

莫名的抽风

之前在使用听云进行监控的时候，遇到一个很尴尬的事情：我仅仅在其中一个项目里面部署了听云，为什么在其他项目里面会出现听云的类找不到的错误呢？

java.lang.NoClassDefFoundError: com.networkbench.agent.impl.instrumentation

这时候无论你将全部听云配置都删除或是在.gradle里面将听云引用删除，都无法解决这个问题，这个就是android studio缓存的问题。那么怎么才能清理缓存呢？其实很简单，看图，在"file"菜单下有一个"Invalidate Caches / Restart"，只要重启这个就行了

Invalidate Caches / Restart

build文件夹无法删除

我们在执行build或者clean的时候，会遇到Build文件夹不能删除的情况。这时候我一般使用360去手动强制删除，但是有没有其他工具可以更加直接方便地去做这些事情呢？答案是肯定的。这里我推荐使用LockHunter——一个极简单的文件解锁工具，它可以删除一些被阻止的文件。

LockHunter

当然本文不会教你如何使用这个软件，而在于如何在控制台执行其提供的相关命令操作符
LockHunter.exe [/unlock] [/delete] [/kill] [/silent] [/exit] [file_or_folder_path]

file_or_folder_path 文件路径，文件夹或路径的前导部分。例如 K:， C:\Program Files
/unlock或-u 解锁file_or_folder_path。它关闭从file_or_folder_path开始的files\文件夹的所有句柄，并卸载位于从file_or_folder_path开始的files\文件夹中的.dll。
/delete或-d 解锁并删除file_or_folder_path。如果file_or_folder_path是路径的部分名称（例如“C:\ Docu”是“C:\Documents and Settings”的部分名称），则从file_or_folder_path开始的所有文件和文件夹将被删除。注意，如果从file_or_folder_path启动进程，它们将阻止删除文件夹\文件。使用/kill参数强制终止这些应用程序。
/kill或-k 终止从file_or_folder_path启动的所有应用程序。如果file_or_folder_path是路径的部分名称（例如“c:\Docu”是“C:\Documents and Settings”的部分名称），则从file_or_folder_path字符串开始启动路径的所有进程将被终止。
/silent或-sm 不会显示GUI。程序以静音模式启动，执行一个传递的命令（例如/unlock）并终止。
/exit或-x 当所有操作完成时自动退出。此选项可能仅在您希望看到GUI，所有显示的警告但不希望手动按下“退出”按钮时才需要。
下面演示一下如何删除根目录下的build文件夹与app模块下的build文件夹

task cleanRootBuildDir(type: Exec) {
    ext.lockhunter = "D:\\LockHunter\\LockHunter.exe"
    def rootBuildDir = file("../build")
    commandLine "$lockhunter", "/delete", "/silent", rootBuildDir
}
task cleanAppBuildDir(type: Exec) {
    ext.lockhunter = "D:\\LockHunter\\LockHunter.exe"
    def appBuildDir = file("build")
    commandLine "$lockhunter", "/delete", "/silent", appBuildDir
}

分别在控制台中执行gradle cleanRootBuildDir或者gradle cleanAppBuildDir即可。注意网上有很多介绍android studio中如何使用LockHunter的文章，但是他们的命令行执行语句都是错的

参考文章

Android layout用gradle分包
Gradle之dependencies
Gradle配置dependencies
productFlavors 实现多渠道多版本打包调试
发布Android studio项目到本地Maven仓库
优雅的发布Android开源库(论JitPack的优越性)
Gradle配置最佳实践
GRADLE构建最佳实践

Gradle使用技巧总结

加速篇

第一次加载项目缓慢

基础配置篇

设置全局编译器的版本

签名文件的存放与配置

占位符的使用

设置第三方远程仓库

构建参数篇

多编译环境设置

编译项目时设置可引用参数

玩转依赖篇

依赖方式

依赖远程文件

依赖本地文件

依赖本地库工程

冲突的解决方法

按构建目标定制依赖库

外部配置依赖版本

对layout进行模块化分包

多渠道多版本打包调试

自定义apk文件输出路径及apk文件名

NDK篇

其他

莫名的抽风

build文件夹无法删除

参考文章

你可能感兴趣的:(Gradle使用技巧总结)