Ringkasan build Gradle

Aplikasi Android biasanya dibangun menggunakan sistem build Gradle. Sebelum membahas detail cara mengonfigurasi build, kita akan mempelajari konsep di balik build sehingga Anda dapat melihat sistem secara keseluruhan.

Apa itu build?

Sistem build mengubah kode sumber Anda menjadi aplikasi yang dapat dieksekusi. Build sering kali melibatkan beberapa alat, untuk menganalisis, mengompilasi, menautkan, dan memaketkan aplikasi atau library Anda. Gradle menggunakan pendekatan berbasis tugas untuk mengatur dan menjalankan perintah ini.

Tugas merangkum perintah yang menerjemahkan inputnya menjadi output. Plugin menentukan tugas dan konfigurasinya. Menerapkan plugin ke build Anda akan mendaftarkan tugasnya, dan menghubungkannya menggunakan input dan outputnya. Misalnya, menerapkan Plugin Gradle Android (AGP) ke file build akan mendaftarkan semua tugas yang diperlukan untuk mem-build APK, atau Library Android. Plugin java-library memungkinkan Anda membuat jar dari kode sumber Java. Plugin serupa ada untuk Kotlin dan bahasa lainnya, tetapi plugin lain dimaksudkan untuk memperluas plugin. Misalnya, plugin protobuf dimaksudkan untuk menambahkan dukungan protobuf ke plugin yang ada seperti AGP atau java-library.

Gradle lebih mengutamakan konvensi daripada konfigurasi sehingga plugin akan memiliki nilai default yang baik secara langsung, tetapi Anda dapat mengonfigurasi build lebih lanjut melalui Domain-Specific Language (DSL) deklaratif. DSL dirancang sehingga Anda dapat menentukan apa yang akan di-build, bukan cara membangunnya. Logika dalam plugin mengelola "cara". Konfigurasi tersebut ditentukan di beberapa file build di project (dan subproject).

Input tugas dapat berupa file dan direktori serta informasi lain yang dienkode sebagai jenis Java (integer, string, atau class kustom). Output hanya dapat berupa direktori atau file karena harus ditulis ke disk. Menghubungkan output tugas ke input tugas lain, akan menautkan tugas sehingga salah satu tugas harus dijalankan sebelum tugas lainnya.

Meskipun Gradle mendukung penulisan kode dan deklarasi tugas arbitrer dalam file build, hal ini dapat mempersulit alat untuk memahami build Anda dan mempersulit Anda untuk memeliharanya. Misalnya, Anda dapat menulis pengujian untuk kode di dalam plugin, tetapi tidak di dalam file build. Sebagai gantinya, Anda harus membatasi logika build dan deklarasi tugas ke plugin (yang Anda atau orang lain tentukan) dan mendeklarasikan cara Anda ingin menggunakan logika tersebut dalam file build.

Apa yang terjadi saat build Gradle berjalan?

Build Gradle berjalan dalam tiga fase. Setiap fase ini mengeksekusi bagian kode yang berbeda yang Anda tentukan dalam file build.

• Inisialisasi menentukan project dan subproject mana yang disertakan dalam build, dan menyiapkan classpath yang berisi file build dan plugin yang diterapkan. Fase ini berfokus pada file setelan tempat Anda mendeklarasikan project yang akan dibangun dan lokasi tempat plugin dan library akan diambil.
• Konfigurasi mendaftarkan tugas untuk setiap project, dan menjalankan file build untuk menerapkan spesifikasi build pengguna. Penting untuk dipahami bahwa kode konfigurasi Anda tidak akan memiliki akses ke data atau file yang dihasilkan selama eksekusi.
• Execution melakukan "build" aplikasi Anda yang sebenarnya. Output konfigurasi adalah Directed Acyclic Graph (DAG) tugas, yang merepresentasikan semua langkah build yang diperlukan yang diminta oleh pengguna (tugas yang diberikan di command line atau sebagai default dalam file build). Grafik ini merepresentasikan hubungan antar-tugas, baik yang eksplisit dalam deklarasi tugas, maupun berdasarkan input dan output-nya. Jika tugas memiliki input yang merupakan output dari tugas lain, maka tugas tersebut harus dijalankan setelah tugas lainnya. Fase ini menjalankan tugas yang sudah tidak berlaku dalam urutan yang ditentukan dalam grafik; jika input tugas tidak berubah sejak eksekusi terakhirnya, Gradle akan melewatinya.

Untuk mengetahui informasi selengkapnya, lihat Siklus proses build Gradle.

DSL Konfigurasi

Gradle menggunakan Domain-Specific Language (DSL) untuk mengonfigurasi build. Pendekatan deklaratif ini berfokus pada penentuan data Anda, bukan penulisan petunjuk langkah demi langkah (imperatif). Anda dapat menulis file build menggunakan Kotlin atau Groovy, tetapi sebaiknya gunakan Kotlin.

DSL berupaya mempermudah semua orang, pakar domain, dan programmer, untuk berkontribusi pada project, dengan menentukan bahasa kecil yang merepresentasikan data dengan cara yang lebih alami. Plugin Gradle dapat memperluas DSL untuk mengonfigurasi data yang dibutuhkan untuk tugasnya.

Misalnya, mengonfigurasi bagian Android dari build Anda mungkin terlihat seperti:

android {
    namespace = "com.example.app"
    compileSdk {
        version = release(36) {
            minorApiLevel = 1
        }
    }
    // ...

    defaultConfig {
        applicationId = "com.example.app"
        minSdk {
            version = release(23)
        }
        targetSdk {
            version = release(36)
        }
        // ...
    }
}

android {
    namespace = 'com.example.app'
    compileSdk {
        version = release(36) {
            minorApiLevel = 1
        }
    }
    // ...

    defaultConfig {
        applicationId = 'com.example.app'
        minSdk {
            version = release(23)
        }
        targetSdk {
            version = release(36)
        }
        // ...
    }
}

Di balik layar, kode DSL mirip dengan:

fun Project.android(configure: ApplicationExtension.() -> Unit) {
    ...
}

interface ApplicationExtension {
    var namespace: String?

    fun compileSdk(configure: CompileSdkSpec.() -> Unit) {
        ...
    }

    val defaultConfig: DefaultConfig

    fun defaultConfig(configure: DefaultConfig.() -> Unit) {
        ...
    }
}

Setiap blok di DSL diwakili oleh fungsi yang menggunakan lambda untuk mengonfigurasinya, dan properti dengan nama yang sama untuk mengaksesnya. Hal ini membuat kode dalam file build Anda terasa lebih seperti spesifikasi data.

Dependensi eksternal

Sistem build Maven memperkenalkan spesifikasi dependensi, sistem penyimpanan, dan pengelolaan. Library disimpan di repositori (server atau direktori), dengan metadata yang mencakup versi dan dependensinya pada library lain. Anda menentukan repositori yang akan ditelusuri, versi dependensi yang ingin digunakan, dan sistem build akan mendownloadnya selama build.

Artefak Maven diidentifikasi berdasarkan nama grup (perusahaan, developer, dll.), nama artefak (nama library), dan versi artefak tersebut. Ini biasanya ditampilkan sebagai group:artifact:version.

Pendekatan ini meningkatkan pengelolaan build secara signifikan. Anda akan sering mendengar repositori seperti itu disebut "repositori Maven", tetapi semuanya berkaitan dengan cara artefak dikemas dan dipublikasikan. Repositori dan metadata ini telah digunakan kembali dalam beberapa sistem build, termasuk Gradle (dan Gradle dapat memublikasikan ke repositori ini). Repositori publik memungkinkan semua orang menggunakan dan membagikan, serta repositori perusahaan menyimpan dependensi internal di dalam perusahaan.

Anda juga dapat membuat modular project menjadi subproject (juga dikenal sebagai "modul" di Android Studio), yang juga dapat digunakan sebagai dependensi. Setiap subproject menghasilkan output (seperti JAR) yang dapat digunakan oleh subproject atau project tingkat teratas Anda. Hal ini dapat meningkatkan waktu build dengan mengisolasi bagian mana yang perlu dibangun ulang, serta memisahkan tanggung jawab dengan lebih baik dalam aplikasi.

Kita akan membahas lebih detail cara menentukan dependensi di Menambahkan dependensi build.

Varian build

Saat membuat aplikasi Android, Anda biasanya ingin membuat beberapa varian. Varian berisi kode yang berbeda atau dibangun dengan opsi yang berbeda, dan terdiri dari jenis build dan ragam produk.

Jenis build memvariasikan opsi build yang dideklarasikan. Secara default, AGP menyiapkan jenis build "release" dan "debug", tetapi Anda dapat menyesuaikannya dan menambahkan lebih banyak (mungkin untuk pengujian internal atau pra-rilis).

Build debug tidak mengecilkan atau meng-obfuscate aplikasi Anda, sehingga mempercepat build dan mempertahankan semua simbol apa adanya. Build ini juga menandai aplikasi sebagai "dapat di-debug", menandatanganinya dengan kunci debug generik, dan memungkinkan akses ke file aplikasi yang diinstal di perangkat. Hal ini memungkinkan Anda menjelajahi data tersimpan dalam file dan database saat menjalankan aplikasi.

Build rilis mengoptimalkan aplikasi, menandatanganinya dengan kunci rilis Anda, dan melindungi file aplikasi yang diinstal.

Dengan ragam produk, Anda dapat mengubah sumber yang disertakan dan varian dependensi untuk aplikasi. Misalnya, Anda mungkin ingin membuat varian "demo" dan "full" untuk aplikasi Anda, atau mungkin varian "free" dan "paid". Anda menulis sumber umum di direktori set sumber "main", dan mengganti atau menambahkan sumber di set sumber yang dinamai sesuai dengan ragam.

AGP membuat varian untuk setiap kombinasi jenis build dan ragam produk. Jika Anda tidak menentukan ragam, varian akan diberi nama sesuai dengan jenis build. Jika Anda menentukan keduanya, varian akan diberi nama <flavor><Buildtype>. Misalnya, dengan jenis build release dan debug, serta ragam demo dan full, AGP akan membuat varian:

• demoRelease
• demoDebug
• fullRelease
• fullDebug

Langkah berikutnya

Setelah melihat konsep build, lihat struktur build Android di project Anda.