Ringkasan build Gradle

Aplikasi Android biasanya dibuat 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 yang dimaksud dengan 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.

Tasks mengenkapsulasi 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 Android Gradle (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 lain, 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 memilih konvensi daripada konfigurasi sehingga plugin akan langsung datang dengan nilai default yang baik, tetapi Anda dapat mengonfigurasi build lebih lanjut melalui Domain-Specific Language (DSL) deklaratif. DSL dirancang agar Anda dapat menentukan apa yang akan di-build, bukan cara mem-build-nya. Logika dalam plugin mengelola "bagaimana". Konfigurasi tersebut ditentukan di beberapa file build di project (dan subproject) Anda.

Input tugas dapat berupa file dan direktori serta informasi lain yang dienkode sebagai jenis Java (bilangan bulat, string, atau class kustom). Output hanya dapat berupa direktori atau file karena harus ditulis di disk. Menghubungkan output tugas ke input tugas lain, menautkan tugas bersama-sama sehingga satu tugas harus dijalankan sebelum yang lain.

Meskipun Gradle mendukung penulisan kode arbitrer dan deklarasi tugas dalam file build, hal ini dapat mempersulit alat untuk memahami build dan Anda mengelolanya. Misalnya, Anda dapat menulis pengujian untuk kode di dalam plugin, tetapi tidak di 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 berbagai bagian kode yang Anda tentukan di file build.

  • Inisialisasi menentukan project dan subproject yang disertakan dalam build, serta menyiapkan classpath yang berisi file build dan plugin yang diterapkan. Fase ini berfokus pada file setelan tempat Anda mendeklarasikan project untuk di-build dan lokasi tempat mengambil plugin dan library.
  • 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 menjalankan "pembangunan" aplikasi Anda. Output konfigurasi adalah Directed Acyclic Graph (DAG) tugas, yang mewakili semua langkah build yang diperlukan yang diminta oleh pengguna (tugas yang disediakan di command line atau sebagai default dalam file build). Grafik ini merepresentasikan hubungan antar-tugas, baik secara eksplisit dalam deklarasi tugas, maupun berdasarkan input dan outputnya. Jika tugas memiliki input yang merupakan output dari tugas lain, tugas tersebut harus berjalan setelah tugas lainnya. Fase ini menjalankan tugas yang sudah tidak berlaku dalam urutan yang ditentukan dalam grafik; jika input tugas belum berubah sejak eksekusi terakhirnya, Gradle akan melewatinya.

Untuk informasi selengkapnya, lihat Siklus proses build Gradle.

DSL Konfigurasi

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

DSL mencoba memudahkan semua orang, pakar domain, dan programmer, untuk berkontribusi pada project, dengan menentukan bahasa kecil yang mewakili data dengan cara yang lebih alami. Plugin Gradle dapat memperluas DSL untuk mengonfigurasi data yang diperlukan untuk tugasnya.

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

Kotlin

android {
    namespace = "com.example.app"
    compileSdk = 34
    // ...

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 34
        // ...
    }
}

Groovy

android {
    namespace 'com.example.myapplication'
    compileSdk 34
    // ...

    defaultConfig {
        applicationId "com.example.myapplication"
        minSdk 24
        // ...
    }
}

Di balik layar, kode DSL mirip dengan:

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

interface ApplicationExtension {
    var compileSdk: Int
    var namespace: String?

    val defaultConfig: DefaultConfig

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

Setiap blok dalam 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 lebih terasa seperti spesifikasi data.

Dependensi eksternal

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

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

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

Anda juga dapat memodularisasi 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 atas. Hal ini dapat meningkatkan waktu build dengan mengisolasi bagian mana yang perlu di-build 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 dibuat 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 yang lainnya (mungkin untuk pengujian internal atau staging).

Build debug tidak meminifikasi atau meng-obfuscate aplikasi, mempercepat build dan mempertahankan semua simbol apa adanya. Build juga menandai aplikasi sebagai "dapat di-debug", menandatanganinya dengan kunci debug generik dan memungkinkan akses ke file aplikasi yang terinstal pada 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 menggunakan ragam produk, Anda dapat mengubah sumber yang disertakan dan varian dependensi yang disertakan untuk aplikasi. Misalnya, Anda mungkin ingin membuat ragam "demo" dan "full" untuk aplikasi Anda, atau mungkin ragam "free" dan "paid". Anda menulis sumber umum di direktori set sumber "utama", dan mengganti atau menambahkan sumber dalam set sumber yang diberi nama sesuai ragam.

AGP membuat varian untuk setiap kombinasi jenis build dan ragam produk. Jika Anda tidak menentukan ragam, varian akan diberi nama berdasarkan 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.