settings.gradle

Setting文件可以說是子項目（也可以說是Module）的配置文件，大多數(shù)setting.gradle的作用是為了配置子工程，再Gradle多工程是通過工程樹表示的，如在Android studio中我們指定相應(yīng)的module能在主工程當中使用，需要這樣

   include ':example'

正常情況下，你對著一個module，點擊右鍵，它是不會有delete這個選項的。你要是在settings.gradle那里去掉了，在對著那個module那里點右鍵，就會出來delete了。所以，那個settings.gradle，他的作用大概就是告訴AS，這個項目里面有哪些Module，如果里面沒有寫到的，AS就找不到了。

20180309171200884.png

我在settings.gradle文件里加入對應(yīng)的module就可以使用了

根目錄-build.gradle

// Gradle中可以使用“//”或“/**/”來添加注釋，與Java類似。
// 根目錄下的build.gradle用于添加子工程或模塊共用的配置項。
// 此處的"buildscript"用于配置Project的build script的classpath。
//-------------配置工程的倉庫地址---------
buildscript {
//如果需要的話，從https://jcenter.bintray.com/下載code reposities。
  repositories {
    jcenter()
  }
// 定義classpath，gradle會從“repositories”中下載對應(yīng)版本的Gradle。如果使用gradle wrapper的話，感覺這個配置會被忽略。Wrapper會自己去下載所使用的gradle版本。
//-------------------------配置工程的"插件"依賴地址(即gradle程序的第三庫)-------------------------
  dependencies {

    //ependencies閉包中使用classpath聲明了一個Gradle插件。為什么要聲明這個插件呢？因為Gradle并不是專門為構(gòu)建Android項目而開發(fā)的，java，c++等很多項目都可以使用Gradle來構(gòu)建。因此如果我們要想使用它來構(gòu)建Android項目，則需要聲明com.android.tools.build:gradle:2.2.2這個插件。

    classpath 'com.android.tools.build:gradle:2.2.2'
  }


}
// 該配置會被應(yīng)用到所有的子工程。
allprojects {
  repositories {
    google()
    jcenter()
    maven { url "https://jitpack.io" }
  }
}


// 運行g(shù)radle clean時，執(zhí)行此處定義的task。
// 該任務(wù)繼承自Delete，刪除根目錄中的build目錄。
// 相當于執(zhí)行Delete.delete(rootProject.buildDir)。
// gradle使用groovy語言，調(diào)用method時可以不用加（）。
task clean(type: Delete) {
  delete rootProject.buildDir
}

//兩處repositories的閉包中都聲明了jcenter()進行配置，那么這個jcenter是什么意思呢？
//其實它是一個代碼托管倉庫，很多Android開源項目都會選擇將代碼托管到j(luò)center上，
//聲明了這行配置之后，我們就可以在項目中輕松引用任何jcenter上的開源項目了。

app目錄下的的build.gradle

//第一行應(yīng)用了一個插件，一般有兩種值可選：com.android.application表示這是一個應(yīng)用程序模塊，com.android.library表示這是一個庫模塊。
//應(yīng)用程序模塊和庫模塊的最大區(qū)別在于，
//一個是可以直接運行的，一個只能作為代碼庫依附于別的應(yīng)用程序模塊來運行。
apply plugin: 'com.android.application'

android {
    //compileSdkVersion用于指定項目的編譯版本
    compileSdkVersion 23
    //buildToolsVersion 用于指定項目構(gòu)建工具的版本
    buildToolsVersion "23.0.3"

    //這里在android閉包中又嵌套了一個defaultConfig閉包，defaultConfig閉包中可以對項目的更多細節(jié)進行配置
    defaultConfig {
          //applicationId 用于指定項目的包名，前面我們在創(chuàng)建項目的時候其實已經(jīng)指定過包名了，如果你想在后面對其進行修改，那么就是在這里修改的
          applicationId "com.example.helloworld"
          //用于指定項目最低兼容的Android系統(tǒng)版本
          minSdkVersion 15
          //指定的值表示你在該目標版本上已經(jīng)做過了充分的測試，系統(tǒng)將會為你的應(yīng)用程序啟用一些最新的功能和特性。
          //比如說Android 6.0系統(tǒng)中引入了運行時權(quán)限這個功能。而如果你將targetSdkVersion 指定成22，
          //那么就說明你的程序最高只在Android 5.1系統(tǒng)上做過充分的測試，Android 6.0系統(tǒng)中引入的新功能自然就不會啟用了。
          targetSdkVersion 23

          //versionCode用于指定項目的版本號，versionName用于指定項目的版本名
          //這兩個屬性在生成安裝文件的時候非常重要。
          //用于指定項目的版本號
          versionCode 1
          //用于指定項目的版本名
          versionName "1.0"

          testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
     }

          //buildTypes閉包中用于指定生成安裝文件的相關(guān)配置，通常只會有兩個子閉包，一個是debug，一個是release。
          //debug閉包用于指定生成測試版安裝文件的配置，release閉包用于指定生成正式版安裝文件的配置。
          //debug閉包是可以忽略不寫的，因此我們看到上面的代碼中就只有一個release閉包。
    buildTypes {
            release {
          //minifyEnabled用于指定是否對項目的代碼進行混淆，true 表示混淆，false 表示不混淆。
                      minifyEnabled false
          //proguardFiles 用于指定混淆時使用的規(guī)則文件，這里指定了兩個文件
          //第一個proguard-android.,txt 是在Android SDK目錄下的，里面是所有項目通用的混淆規(guī)則
          //第二個 proguard-rules.pro 是在當前項目的根目錄下的，里面可以編寫當前項目特有的混淆規(guī)則。
                      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
                    }
            }
    }




          //這個閉包的功能非常強大，它可以指定當前項目所有的依賴關(guān)系。
          //通常AndroidStudio項目一共有3種依賴方式：本地依賴、庫依賴和遠程依賴。
          //本地依賴可以對本地的jar包或目錄添加依賴關(guān)系，
          //庫依賴可以對項目中的庫模塊添加依賴關(guān)系，
          //遠程依賴則可以對jcenter庫上的開源項目添加依賴關(guān)系。

    dependencies {
          //compile fileTree就是一個本地依賴聲明，它表示將libs目錄下所有.jar后綴的文件都添加到項目的構(gòu)建路徑當中。
            compile fileTree(include: ['*.jar'], dir: 'libs')
            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:23.4.0就是一個標準的遠程依賴庫格式，
          //其中com.android.support是域名部分，用于和其他公司的庫做區(qū)分；
          //appcompat-v7是組名稱，用于和同一個公司中不同的庫做區(qū)分；
          //23.4.0是版本號，用于和同一個庫不同的版本做區(qū)分。
          
          //加上這句聲明后，Gradle在構(gòu)建項目時會首先檢查一個本地是否已經(jīng)有這個庫的緩存，如果沒有的話則會去自動聯(lián)網(wǎng)下載，然后再添加到項目的構(gòu)建路徑當中。
          //至于庫依賴聲明這里沒有用到，它的基本格式是compile project后面加上要依賴的庫名稱，
          //比如說有一個庫模塊的名字叫helper，那么添加這個庫的依賴關(guān)系只需要加入compile project(':helper')這句聲明即可。

            compile 'com.android.support:appcompat-v7:23.4.0'
            testCompile 'junit:junit:4.12'
     }

android gradle依賴：implementation 和compile的區(qū)別

dependencies {
      implementation fileTree(dir: 'libs', include: ['*.jar'])
          implementation 'com.android.support:appcompat-v7:26.1.0'
          implementation 'com.android.support.constraint:constraint-layout:1.0.2'
          testImplementation 'junit:junit:4.12'
          androidTestImplementation 'com.android.support.test:runner:1.0.1'
          androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
      }

首先是2.x版本的依賴方式

2.0.png

3.0的

old.png

可以看到在Android studio3.0中，
compile依賴關(guān)系已被棄用，被implementation和api替代，
provided被compile only替代，apk被runtime only替代。

implementation和api的區(qū)別：

api：跟 2.x 版本的 compile完全相同

newOr.png

    dependencies {
        . . . . 
        implementation project（path：'：libraryC'）
    }

那么LibraryC 中的接口，僅僅只能給 LibraryA 使用，而我們的 App Module 是無法訪問到 LibraryC 提供的接口的，也就是將該依賴隱藏在內(nèi)部，而不對外部公開。這就是implementation關(guān)鍵字的作用。

建議

在Google IO 相關(guān)話題的中提到了一個建議，就是依賴首先應(yīng)該設(shè)置為implement的，如果沒有錯，那就用implement，如果有錯，那么使用api指令，這樣會使編譯速度有所增快。

那為什么要這么做呢？

答案是： 1. 加快編譯速度。2. 隱藏對外不必要的接口。

為什么能加快編譯速度呢？

這對于大型項目含有多個Module模塊的， 以上圖為例，比如我們改動 LibraryC 接口的相關(guān)代碼，這時候編譯只需要單獨編譯LibraryA模塊就行， 如果使用的是api或者舊時代的compile，由于App Module 也可以訪問到 LibraryC,所以 App Module部分也需要重新編譯。當然這是在全編的情況下。

compile（api）

這種是我們最常用的方式，使用該方式依賴的庫將會參與編譯和打包。
當我們依賴一些第三方的庫時，可能會遇到com.android.support沖突的問題，就是因為開發(fā)者使用的compile依賴的com.android.support包，而他所依賴的包與我們本地所依賴的com.android.support包版本不一樣，所以就會報All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes這個錯誤。

解決辦法可以看這篇博客：com.android.support沖突的解決辦法

provided（compileOnly）

//場景:1如果主工程已經(jīng)有某庫了, 他的庫工程也需要引入該庫,可用provided
//2比如熱更新,只需編譯時生成某些庫,打包不需要該庫,那也可以

只在編譯時有效，不會參與打包
可以在自己的module中使用該方式依賴一些比如com.android.support，gson這些使用者常用的庫，避免沖突。

apk（runtimeOnly）

只在生成apk的時候參與打包，編譯時不會參與，很少用。

testCompile（testImplementation）

testCompile 只在單元測試代碼的編譯以及最終打包測試apk時有效。

debugCompile（debugImplementation）

debugCompile 只在 debug 模式的編譯和最終的 debug apk 打包時有效

releaseCompile（releaseImplementation）

Release compile僅僅針對 Release 模式的編譯和最終的 Release apk 打包。
參考鏈接：
Android Studio3.x新的依賴方式（implementation、api、compileOnly）
還再用compile依賴？那你就落后啦
android gradle tools 3.X 中依賴，implement、api 指令