Gradle 主要分為三大功能:函式庫管理、Task 與 Plugin
開發過程中除了撰寫程式碼以外常常會引入函式庫,但手動下載實在是很沒效率,,所以通通交給 Gradle 處理!
有點類似 JavaScript 開發常用的 npm,不過 Gradle 是用宣告式的建置腳本管理函式庫,開發者只要把需要用到的函式庫宣告在 Gradle 設定檔內,它就會自動遞迴解析並下載依賴的函式庫,並在建置時自動添加 classpath
我之所以稱它為開發管理工具,是因為除了管理函式庫還能執行特定操作達成特定目的,這些操作被稱作 task,有點像 Makefile 的 target
不只程式本身能引用別人寫好的函式庫,Gradle 也能引入擴充元件來增加功能,譬如 Android 擴充元件為 Gradle 新增建置 debug APK、release APK 等多個 task,讓開發者在 build.gradle.kts
寫好相關設定後就能快速建置
Gradle 最早只支援用 Groovy 寫的腳本,後才新增 Kotlin DSL 的支援,兩者風格其實有點類似,如果已經用習慣 Groovy 其實可以不用切換,不過我自己學過 Kotlin 想說統一比較方便,所以後面的範例都會用 Kotlin DSL
檔名後綴是 .gradle
def composeVersion = '1.2.1'
implementation "androidx.compose.foundation:foundation:$composeVersion"
implementation "androidx.compose.runtime:runtime:$composeVersion"
implementation "androidx.compose.ui:ui:$composeVersion"
檔名後綴是 .gradle.kts
val composeVersion = "1.2.1"
implementation("androidx.compose.foundation:foundation:$composeVersion")
implementation("androidx.compose.runtime:runtime:$composeVersion")
implementation("androidx.compose.ui:ui:$composeVersion")
Gradle 本身的設定
關於 build 本身的設定
其他與建置相關的設定
專案中常常會看到兩個 build.gradle.kts
,外層的是 project-level,app 資料夾底下的是 module-level,到這裡可能會有疑問:為什麼 Gradle 有 module 這種結構呢?
一個專案可能不只有一個產品,可能同時底下有 API module、函式庫 module 跟主程式 module,不同產品需要的函式庫、建置方式與 task 不相同,但會共用部份流程或函式庫等等,所以要一個 Project 底下會有分別獨立的 module,而 Android Studio 創建好的專案裡面已經建好一個名為 app 的 module,這就是為什麼會有兩個 build.gradle.kts
,不過我目前沒有 multi-module 得需求,後面講的 build.gradle.kts
沒特別說明都是 module-level 的
app/build.gradle.kts
內容plugins
區塊宣告想要引入的 Gradle plugin
plugins {
id("com.android.application")
kotlin("android")
// ......
}
android
區塊調整 Android 建置相關的設定,像是 SDK 版本、APP 版本等等
android {
compileSdk = 33
namespace = "at.mikuc.openfcu"
defaultConfig {
applicationId = "at.mikuc.openfcu"
minSdk = 26
targetSdk = 33
versionCode = 1
// ......
}
// ......
}
dependencies
區塊宣告引入的函式庫,也是最常用到的區塊
dependencies {
implementation("androidx.core:core-ktx:1.9.0")
val kotestVersion = "5.4.2"
testImplementation("io.kotest:kotest-runner-junit5:$kotestVersion")
// ......
}