Ringkasan build Gradle

Aplikasi Android biasanya dibuat menggunakan build Gradle sistem file. Sebelum kita membahas detail cara mengkonfigurasi build, kita akan menjelajahi 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 mengemas aplikasi atau library. Gradle menggunakan pendekatan berbasis tugas untuk mengatur dan menjalankan perintah-perintah ini.

Tasks merangkum perintah yang menerjemahkan inputnya menjadi output. Plugin menentukan tugas dan konfigurasinya. Mendaftar sebuah plugin ke build Anda mendaftarkan tugasnya, lalu menghubungkannya menggunakan input dan output-nya. Misalnya, menerapkan Plugin Android Gradle (AGP) ke file build Anda akan mendaftarkan semua tugas yang diperlukan untuk membangun APK, atau Library Android. Plugin java-library memungkinkan Anda membuat jar dari sumber Java pada kode sumber. Plugin serupa tersedia untuk Kotlin dan bahasa lainnya, namun plugin lainnya dimaksudkan untuk memperluas plugin. Misalnya, plugin protobuf dimaksudkan untuk menambahkan protobuf mendukung plugin yang ada seperti AGP atau java-library.

Gradle lebih memilih konvensi daripada konfigurasi sehingga plugin akan memiliki hasil yang baik nilai default siap pakai, tetapi Anda dapat mengonfigurasi build lebih lanjut melalui Domain-Specific Language (DSL) deklaratif. DSL dirancang sehingga Anda dapat menentukan apa yang akan dibuat, bukan cara membuatnya. Logika di plugin mengelola "{i>how<i}". Konfigurasi tersebut ditentukan dalam beberapa file build di project (dan subproject).

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 mereka harus ditulis di {i>disk<i}. Menghubungkan output tugas ke output lain {i>input<i} tugas, menautkan tugas bersama-sama sehingga salah satunya harus dijalankan sebelum yang lain.

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

Apa yang terjadi saat build Gradle berjalan?

Build Gradle berjalan dalam tiga fase. Masing-masing fase ini mengeksekusi bagian yang berbeda yang Anda definisikan dalam file build.

  • Inisialisasi menentukan project dan subproject mana yang disertakan dalam build, dan mengatur classpath yang berisi file build Anda dan plugin. Fase ini berfokus pada file setelan tempat Anda mendeklarasikan project build dan lokasi pengambilan plugin dan library.
  • Configuration mendaftarkan tugas untuk setiap project, dan menjalankan build untuk menerapkan spesifikasi build pengguna. Penting untuk memahami kode konfigurasi Anda tidak akan memiliki akses ke data atau file yang dihasilkan selama eksekusi.
  • Execution menjalankan "bangunan" yang sebenarnya aplikasi Anda. Output adalah Directed Acyclic Graph (DAG) tugas, yang mewakili semua langkah build yang diperlukan, yang diminta oleh pengguna ( tugas yang disediakan pada command line atau sebagai default dalam file build). Ini menggambarkan hubungan antar tugas, baik secara eksplisit dalam sebuah deklarasi, atau berdasarkan input dan output-nya. Jika tugas memiliki input yang adalah {i>output<i} dari tugas lain, maka itu harus berjalan setelah tugas lain. Ini fase kehabisan tugas dalam urutan yang ditentukan dalam grafik; jika 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 yang berbeda. Pendekatan deklaratif ini berfokus pada menentukan data Anda, bukan menulis instruksi langkah demi langkah (imperatif).

DSL mencoba membuat lebih mudah bagi semua orang, pakar domain dan {i>programmer<i}, untuk berkontribusi pada proyek, menentukan bahasa kecil yang mewakili data dalam dengan cara yang lebih alami. Plugin Gradle dapat memperluas DSL untuk mengonfigurasi data yang butuhkan untuk tugas-tugas mereka.

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 mengkonfigurasinya, dan sebuah 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, sistem penyimpanan dan pengelolaan. {i>Library<i} disimpan di repositori (server atau direktori), dengan metadata yang meliputi versi dan dependensinya pada {i>library<i} lain. Anda menentukan repositori untuk pencarian, versi dependensi yang ingin Anda gunakan, dan akan mengunduhnya selama proses build.

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

Pendekatan ini meningkatkan pengelolaan build secara signifikan. Anda akan sering mendengar repositori yang disebut "Maven repository", tetapi semuanya adalah bagaimana artefak dikemas dan dipublikasikan. Repositori dan {i>metadata <i}ini telah digunakan kembali di beberapa sistem build, termasuk Gradle (dan Gradle dapat memublikasikan repositori ini). Repositori publik memungkinkan berbagi untuk semua penggunaan, dan repositori perusahaan menyimpan dependensi internal di internal.

Anda juga dapat memodularisasi project Anda menjadi subproject (juga dikenal sebagai "modul" di Android Studio), yang juga dapat digunakan sebagai dependensi. Setiap subproyek menghasilkan {i>output<i} (seperti stoples) yang dapat digunakan oleh sub-proyek atau proyek tingkat atas. Hal ini dapat meningkatkan waktu build dengan mengisolasi bagian mana yang perlu dibuat ulang, serta memisahkan tanggung jawab dalam aplikasi.

Kita akan membahas lebih detail tentang cara menentukan dependensi di bagian Add build dependensi.

Varian build

Saat membuat aplikasi Android, Anda biasanya perlu membangun beberapa varian. Varian berisi kode yang berbeda atau dibuat dengan pilihan, dan terdiri dari jenis build dan ragam produk.

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

Build debug tidak meminifikasi atau meng-obfuscate aplikasi, sehingga mempercepat membuat dan mempertahankan semua simbol sebagaimana adanya. Hal ini juga menandai aplikasi sebagai "debuggable", menandatanganinya dengan kunci debug generik dan mengaktifkan akses ke file aplikasi yang terinstal di perangkat. Hal ini memungkinkan Anda untuk mengeksplorasi menyimpan data dalam file dan {i>database<i} saat menjalankan aplikasi.

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

Dengan menggunakan ragam produk, Anda dapat mengubah sumber dan dependensi yang disertakan varian untuk aplikasi. Misalnya, Anda dapat membuat "demo" dan "full" untuk aplikasi Anda, atau mungkin "gratis" dan "berbayar" rasa. Anda menulis kode sumber umum di "main" (utama) set sumber, dan mengganti atau menambahkan sumber dalam {i> set <i}sumber yang dinamai berdasarkan ragamnya.

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

  • demoRelease
  • demoDebug
  • fullRelease
  • fullDebug

Langkah berikutnya

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