Mengoptimalkan Kecepatan Build Anda

Waktu build yang lama memperlambat proses development, jadi halaman ini menawarkan beberapa teknik untuk membantu Anda mengatasi bottleneck kecepatan build.

Proses yang biasa dilakukan untuk meningkatkan kecepatan build Anda adalah sebagai berikut:

Optimalkan konfigurasi build Anda dengan menjalankan beberapa langkah yang langsung memberikan manfaat untuk kebanyakan project Android Studio.
Membuat profil build Anda untuk mengidentifikasi dan mendiagnosis beberapa bottleneck yang lebih rumit yang mungkin spesifik bagi project atau workstation Anda.

Saat men-develop aplikasi, Anda harus menerapkan ke perangkat yang menjalankan Android 7.0 (API level 24) atau yang lebih tinggi bila memungkinkan. Versi platform Android yang lebih baru mengimplementasikan mekanisme yang lebih baik untuk mendorong update ke aplikasi Anda, seperti Android Runtime (ART) dan dukungan bawaan untuk beberapa file DEX.

Catatan: Setelah clean build pertama, Anda mungkin memperhatikan bahwa kinerja build selanjutnya—clean dan incremental—lebih cepat (bahkan tanpa menggunakan optimalisasi apa pun yang dijelaskan pada halaman ini). Ini karena daemon Gradle memiliki periode "pemanasan" untuk meningkatkan kinerja—serupa dengan proses JVM lainnya.

Mengoptimalkan konfigurasi build Anda

Ikuti tips berikut untuk meningkatkan kecepatan build project Android Studio Anda.

Menjaga alat Anda tetap terbaru

Alat Android menerima optimalisasi dan fitur baru bersamaan dengan hampir setiap update, dan beberapa tips pada halaman ini menganggap bahwa Anda menggunakan versi terbaru. Untuk memanfaatkan optimalisasi terbaru, jagalah fitur berikut agar selalu terbaru:

Membuat varian build untuk development

Banyak dari konfigurasi yang Anda butuhkan saat menyiapkan aplikasi untuk rilis sebenarnya tidak diperlukan saat men-develop aplikasi. Mengaktifkan proses build yang tidak diperlukan akan memperlambat incremental dan clean build, jadi konfigurasikan varian build agar hanya menyimpan konfigurasi build yang Anda butuhkan saat men-develop aplikasi. Contoh berikut membuat ragam "dev" dan ragam "prod" (untuk konfigurasi versi rilis Anda):

android {
  ...
  defaultConfig {...}
  buildTypes {...}
  productFlavors {
    // When building a variant that uses this flavor, the following configurations
    // override those in the defaultConfig block.
    dev {
      // To avoid using legacy multidex when building from the command line,
      // set minSdkVersion to 21 or higher. When using Android Studio 2.3 or higher,
      // the build automatically avoids legacy multidex when deploying to a device running
      // API level 21 or higher—regardless of what you set as your minSdkVersion.
      minSdkVersion 21
      versionNameSuffix "-dev"
      applicationIdSuffix '.dev'
    }

    prod {
      // If you've configured the defaultConfig block for the release version of
      // your app, you can leave this block empty and Gradle uses configurations in
      // the defaultConfig block instead. You still need to create this flavor.
      // Otherwise, all variants use the "dev" flavor configurations.
    }
  }
}

Bila konfigurasi build Anda sudah menggunakan ragam produk untuk membuat beragam versi aplikasi, Anda bisa menggabungkan konfigurasi "dev" dan "prod" dengan ragam itu menggunakan dimensi ragam. Misalnya, bila Anda sudah mengonfigurasi ragam "demo" dan "full", Anda bisa menggunakan contoh konfigurasi berikut untuk menciptakan ragam gabungan, seperti "devDemo" dan "prodFull":

android {
  ...
  defaultConfig {...}
  buildTypes {...}

  // Specifies the flavor dimensions you want to use. The order in which you
  // list each dimension determines its priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.

  flavorDimensions "stage", "mode"

  productFlavors {
    dev {
      dimension "stage"
      minSdkVersion 21
      versionNameSuffix "-dev"
      applicationIdSuffix '.dev'
      ...
    }

    prod {
      dimension "stage"
      ...
    }

    demo {
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }
  }
}

Menghindari mengompilasi sumber daya yang tidak perlu

Menghindari mengompilasi dan sumber daya pengemasan yang tidak Anda uji (seperti pelokalan bahasa tambahan dan sumber daya kepadatan layar). Anda bisa melakukannya dengan hanya menetapkan satu sumber daya bahasa dan kepadatan layar untuk ragam "dev", seperti yang ditunjukkan pada contoh berikut:

android {
  ...
  productFlavors {
    dev {
      ...
      // The following configuration limits the "dev" flavor to using
      // English stringresources and xxhdpi screen-density resources.
      resConfigs "en", "xxhdpi"
    }
    ...
  }
}

Menonaktifkan Crashlytics untuk build debug Anda

Bila Anda tidak perlu menjalankan laporan Crashlytics, percepat build debug Anda dengan menonaktifkan plugin dengan cara berikut:

android {
  ...
  buildTypes {
    debug {
      ext.enableCrashlytics = false
    }
}

Anda juga harus menonaktifkan kit Crashlytics pada waktu proses build debug dengan mengubah cara Anda melakukan inisialiasi dukungan Fabric di aplikasi, seperti yang ditunjukkan di bawah ini:

// Initializes Fabric for builds that don't use the debug build type.
Crashlytics crashlyticsKit = new Crashlytics.Builder()
    .core(new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
    .build();

Fabric.with(this, crashlyticsKit);

Bila Anda ingin menggunakan Crashlytics dengan build debug, Anda tetap bisa mempercepat incremental build dengan mencegah Crashlytics mengupdate sumber daya aplikasi dengan ID build uniknya sendiri selama setiap build. Untuk mencegah Crashlytics terus mengupdate ID build-nya, tambahkan kode berikut ke file build.gradle Anda:

android {
  ...
  buildTypes {
    debug {
      ext.alwaysUpdateBuildId = false
    }
}

Untuk informasi lebih lanjut tentang cara mengoptimalkan build Anda saat menggunakan Crashlytics, baca dokumentasi resmi.

Menggunakan nilai konfigurasi build statis dengan build debug Anda

Selalu gunakan nilai statis/hard-coded untuk properti yang masuk ke file manifes atau file sumber daya untuk tipe build debug Anda. Bila nilai dalam file manifes atau sumber daya aplikasi Anda perlu diupdate setiap kali build, maka Instant Run tidak bisa melakukan pertukaran kode—ia harus membangun dan menginstal APK baru.

Misalnya, menggunakan kode versi dinamis, nama versi, sumber daya, atau logika build lainnya yang mengubah file manifes memerlukan pembangunan APK lengkap setiap kali Anda mau melakukan perubahan—walaupun sebenarnya perubahan tersebut mungkin hanya memerlukan hot swap. Bila konfigurasi build Anda memerlukan sifat dinamis seperti itu, maka pisahkan mereka ke varian build rilis dan pertahankan nilai statis untuk build debug, seperti yang ditunjukkan pada file build.gradle di bawah ini.

int MILLIS_IN_MINUTE = 1000 * 60
int minutesSinceEpoch = System.currentTimeMillis() / MILLIS_IN_MINUTE

android {
    ...
    defaultConfig {
        // Making either of these two values dynamic in the defaultConfig will
        // require a full APK build and reinstallation because the AndroidManifest.xml
        // must be updated (which is not supported by Instant Run).
        versionCode 1
        versionName "1.0"
        ...
    }

    // The defaultConfig values above are fixed, so your incremental builds don't
    // need to rebuild the manifest (and therefore the whole APK, slowing build times).
    // But for release builds, it's okay. So the following script iterates through
    // all the known variants, finds those that are "release" build types, and
    // changes those properties to something dynamic.
    applicationVariants.all { variant ->
        if (variant.buildType.name == "release") {
            variant.mergedFlavor.versionCode = minutesSinceEpoch;
            variant.mergedFlavor.versionName = minutesSinceEpoch + "-" + variant.flavorName;
        }
    }
}

Menggunakan versi dependensi statis

Ketika mendeklarasikan dependensi di file build.gradle, Anda harus menghindari penggunaan nomor versi dengan tanda plus di bagian akhir, seperti 'com.android.tools.build:gradle:2.+'. Menggunakan nomor versi dinamis bisa menyebabkan update versi tak terduga, kesulitan mengatasi perbedaan versi, dan build lebih lambat yang disebabkan karena pemeriksaan update oleh Gradle. Sebagai gantinya, Anda sebaiknya menggunakan nomor versi statis/hard-coded.

Mengaktifkan mode offline

Jika koneksi jaringan Anda lambat, waktu build Anda mungkin akan terkena dampak saat Gradle mencoba menggunakan sumber daya jaringan untuk mengatasi dependensi. Anda bisa memberi tahu Gradle agar tidak menggunakan sumber daya jaringan dengan hanya menggunakan artefak yang telah di-cache secara lokal.

Untuk menggunakan Gradle secara offline saat membangun dengan Android Studio, lakukan langkah-langkah berikut:

Buka jendela Preferences dengan mengklik File > Settings (di Mac, Android Studio > Preferences).
Di panel sebelah kiri, klik Build, Execution, Deployment > Gradle.
Centang pada kotak centang Offline work.
Klik Apply atau OK.

Bila Anda membangun dari baris perintah, berikan opsi --offline.

Mengaktifkan konfigurasi sesuai permintaan

Agar Gradle tahu persis cara membangun aplikasi Anda, sistem build akan mengonfigurasi semua modul dalam project, dan dependensinya, sebelum setiap build (meskipun Anda sedang membangun dan menguji satu modul saja). Ini memperlambat proses build untuk project multi-modul yang besar. Untuk memberi tahu Gradle agar hanya mengonfigurasi modul yang ingin Anda bangun, aktifkan konfigurasi sesuai permintaan dengan mengikuti langkah-langkah berikut:

Buka jendela Preferences dengan mengklik File > Settings (di Mac, Android Studio > Preferences).
Di panel sebelah kiri, klik Build, Execution, Deployment > Compiler.
Centang pada kotak centang Configure on demand.
Klik Apply atau OK.

Membuat modul library

Cari kode dalam aplikasi Anda yang bisa diubah menjadi modul library Android. Memodulasi kode Anda dengan cara ini memungkinkan sistem build untuk mengompilasi hanya modul yang Anda ubah dan meng-cache keluaran tersebut untuk build masa mendatang. Ini juga membuat konfigurasi sesuai permintaan dan eksekusi project paralel lebih efektif (bila Anda mengaktifkan fitur tersebut).

Membuat tugas untuk logika build khusus

Setelah membuat profil build, jika terlihat bahwa porsi waktu build yang cukup lama dihabiskan di fase "Configuring Projects", tinjau skrip build.gradle Anda dan cari kode yang bisa Anda masukkan dalam tugas Gradle khusus. Dengan memindahkan beberapa logika build ke dalam sebuah tugas, ini akan dijalankan hanya jika diperlukan, hasilnya bisa di-cache untuk build selanjutnya, dan logika build tersebut dapat dijalankan secara paralel (bila Anda mengaktifkan eksekusi project paralel). Untuk mempelajari lebih lanjut, baca dokumentasi Gradle resmi.

Tips: Bila build Anda berisi sejumlah besar tugas khusus, Anda mungkin perlu memecah file build.gradle Anda dengan membuat kelas tugas khusus. Tambahkan kelas Anda ke direktori project-root/buildSrc/src/main/groovy/ dan Gradle secara otomatis memasukkannya ke dalam classpath untuk semua file build.gradle dalam project Anda.

Mengonfigurasi dexOptions dan mengaktifkan pre-dexing library

Android plugin menyediakan blok dexOptions sehingga Anda bisa mengonfigurasi properti build DEX berikut, yang dapat meningkatkan kecepatan build:

preDexLibraries: Mendeklarasikan apakah akan melakukan pre-dex dependensi library sehingga incremental build Anda lebih cepat. Karena fitur ini bisa memperlambat clean build, Anda mungkin perlu menonaktifkan fitur ini untuk server integrasi berkesinambungan.
maxProcessCount: Menetapkan jumlah thread maksimum yang digunakan saat menjalankan dex-in-process. Default-nya adalah 4.
javaMaxHeapSize: Menetapkan ukuran heap maksimum untuk compiler DEX. Meskipun demikian, alih-alih menyetel properti ini, Anda sebaiknya meningkatkan ukuran heap Gradle (yang dibagikan dengan compiler DEX saat dex-in-process diaktifkan).

Misalnya:

android {
  ...
  dexOptions {
    preDexLibraries true
    maxProcessCount 8
    // Instead of setting the heap size for the DEX process, increase Gradle's
    // heap size to enable dex-in-process. To learm more, read the next section.
    // javaMaxHeapSize "2048m"
  }
}

Anda sebaiknya bereksperimen dengan setelan ini dengan menaikkan nilainya dan mengamati efeknya dengan pembuatan profil build Anda. Kinerja mungkin mengalami dampak negatif bila Anda mengalokasikan terlalu banyak sumber daya untuk proses ini.

Catatan: Bila daemon Gradle sudah berjalan, Anda harus menghentikan proses sebelum melakukan menginisialisasinya dengan setelan baru. Anda bisa menutup daemon Gradle dengan memilih View > Tool Windows > Terminal dan memasukkan perintah berikut: gradlew --stop.

Meningkatkan ukuran heap Gradle dan mengaktifkan dex-in-process

Dex-in-process menjalankan compiler DEX di dalam proses build dan bukan dalam proses VM yang terpisah—ini menjadikan incremental dan clean build lebih cepat. Secara default, project baru yang dibuat dengan Android Studio 2.1 dan yang lebih tinggi mengalokasikan cukup memori ke proses build untuk mengaktifkan fitur ini. Jika Anda tidak membuat project menggunakan Android Studio 2.1 atau yang lebih tinggi, Anda harus menyetel ukuran heap maksimum daemon Gradle ke setidaknya 1536 MB. Contoh berikut menyetel ukuran heap Gradle menjadi 2048 MB di file gradle.properties project Anda:

org.gradle.jvmargs = -Xmx2048m

Beberapa project yang lebih besar mungkin mendapatkan keuntungan dari ukuran heap Gradle yang lebih besar lagi. Namun, Jika Anda menggunakan mesin ber-memori rendah, Anda mungkin perlu mengonfigurasi IDE agar menggunakan lebih sedikit memori. Untuk mempelajari bagaimana mengubah jumlah sumber daya yang Anda alokasikan ke IDE dan Gradle memengaruhi kinerja build Anda, bukalah bagian tentang pembuatan profil build Anda.

Bila Anda menentukan nilai android.dexOptions.javaMaxHeapSize di file build.gradle modul, yang mengontrol ukuran heap untuk compiler DEX, Anda harus menyetel ukuran heap Gradle sehingga berukuran 512 MB lebih besar dari nilai yang Anda tetapkan untuk properti javaMaxHeapSize dan setidaknya berukuran 1536 MB. Misalnya, bila Anda menyetel javaMaxHeapSize ke 1280 MB, Anda harus menyetel org.gradle.jvmargs minimal 1792 MB (1280 + 512)—meskipun ukuran heap yang lebih besar akan semakin baik. Anda tidak perlu menetapkan nilai javaMaxHeapSize untuk mengaktifkan dex-in-process. Bila Anda mengecualikan javaMaxHeapSize dari konfigurasi build, pastikan untuk menyetel ukuran heap Gradle ke 1536 MB atau yang lebih tinggi.

Mengonversi gambar ke WebP

WebP adalah format file gambar yang memberikan kompresi lossy (seperti JPEG) serta transparansi (seperti PNG) tetapi bisa memberikan kompresi yang lebih baik daripada JPEG atau PNG. Mengurangi ukuran file gambar, tanpa harus melakukan kompresi waktu-build, bisa mempercepat build, terutama bila aplikasi Anda menggunakan banyak sumber daya gambar. Namun, Anda mungkin melihat sedikit peningkatan penggunaan CPU perangkat saat melakukan dekompresi gambar WebP. Dengan menggunakan Android Studio, Anda bisa dengan mudah mengonversi gambar Anda ke WebP.

Menonaktifkan pemrosesan PNG

Bila Anda tidak bisa (atau tidak ingin) mengonversi gambar PNG Anda ke WebP, Anda tetap dapat mempercepat build dengan menonaktifkan kompresi gambar otomatis setiap kali Anda membangun aplikasi. Untuk menonaktifkan optimalisasi ini, tambahkan kode berikut ke file build.gradle Anda:

android {
  ...
  aaptOptions {
    cruncherEnabled false
  }
}

Karena tipe build atau ragam produk tidak menentukan properti ini, Anda harus menyetel properti ini secara manual ke true saat membangun versi rilis aplikasi Anda.

Mengaktifkan Instant Run

Instant Run secara signifikan mengurangi waktu yang dibutuhkan untuk mengupdate aplikasi Anda dengan mendorong perubahan kode dan sumber daya tertentu tanpa membangun APK baru—dan, pada beberapa kasus, bahkan tanpa me-restart aktivitas saat ini. Gunakan Instant Run dengan mengklik Apply Changes setelah melakukan perubahan pada aplikasi, dan ini diaktifkan secara default saat Anda melakukan hal berikut:

Build aplikasi Anda menggunakan varian build debug.
Gunakan Android plugin untuk Gradle versi 2.3.0 atau yang lebih tinggi.
Setel minSdkVersion ke 15 atau yang lebih tinggi di file build.gradle tingkat modul aplikasi Anda.
Terapkan aplikasi Anda ke perangkat yang menjalankan Android 5.0 (API level 21) dan yang lebih tinggi dengan mengklik Run .

Jika Anda tidak melihat tombol Apply Changes di toolbar setelah persyaratan ini terpenuhi, pastikan Instant Run tidak dinonaktifkan dalam setelan IDE dengan mengikuti langkah-langkah berikut:

Buka kotak dialog Settings atau Preferences.
Pilih Build, Execution, Deployment > Instant Run.
Pastikan Enable Instant Run telah dicentang.

Mengaktifkan Build Cache

Build cache menyimpan keluaran tertentu yang dihasilkan oleh Android plugin untuk Gradle saat membangun project Anda (seperti AAR yang tidak dikemas dan dependensi remote pre-dexed). Clean build Anda jauh lebih cepat saat menggunakan cache karena sistem build hanya bisa menggunakan kembali file-file yang di-cache pada waktu build berikutnya, daripada membuatnya kembali.

Project baru yang menggunakan Android plugin 2.3.0 dan yang lebih tinggi mengaktifkan build cache secara default (kecuali bila Anda secara eksplisit menonaktifkan build cache). Untuk mempelajari lebih lanjut, baca Mempercepat clean build dengan build cache.

Menonaktifkan prosesor anotasi

Incremental Java compilation dinonaktifkan saat menggunakan prosesor anotasi. Jika memungkinkan, cobalah hindari penggunaan prosesor anotasi agar mendapatkan manfaat dari mengompilasi kelas yang Anda ubah di antara build saja.

Membuat profil build Anda

Project yang lebih besar, atau yang mengimplementasikan banyak logika build khusus, mungkin mengharuskan Anda untuk melihat lebih mendalam ke proses build untuk menemukan bottleneck. Anda bisa melakukannya dengan membuat profil waktu yang dibutuhkan Gradle untuk mengeksekusi setiap fase siklus hidup dan setiap tugas build. Misalnya, bila profil build menunjukkan bahwa Gradle menghabiskan terlalu banyak waktu dalam mengonfigurasi project, ini mungkin mengindikasikan bahwa Anda perlu memindahkan logika build khusus keluar dari fase konfigurasi. Selain itu, bila tugas mergeDevDebugResources menghabiskan sejumlah besar waktu build, ini mungkin mengindikasikan bahwa Anda perlu mengonversi gambar Anda menjadi WebP atau menonaktifkan pemrosesan PNG.

Menggunakan pembuatan profil untuk meningkatkan kecepatan build biasanya melibatkan proses menjalankan build dengan pembuatan profil diaktifkan, melakukan beberapa perubahan pada konfigurasi build, dan melakukan pembuatan profil lagi untuk mengamati hasil perubahan Anda.

Untuk membuat dan melihat profil build, lakukan langkah-langkah berikut:

Dengan project Anda terbuka di Android Studio, pilih View > Tool Windows > Terminal untuk membuka baris perintah di akar project.
Lakukan clean build dengan memasukkan perintah berikut. Saat Anda membuat profil build, Anda harus melakukan clean build di antara masing-masing build yang Anda profil karena Gradle melewati tugas saat masukan ke tugas (seperti kode sumber) tidak berubah. Dengan demikian, build kedua tanpa perubahan masukan selalu berjalan lebih cepat karena tugas tidak dijalankan ulang. Jadi, menjalankan tugas clean di antara build memastikan bahwa Anda membuat profil proses build secara penuh.
```
// On Mac or Linux, run the Gradle wrapper using "./gradlew".
gradlew clean
```
Jalankan build debug dari salah satu ragam produk Anda, seperti ragam "dev", dengan tanda berikut:
```
gradlew --profile --recompile-scripts --offline --rerun-tasks assembleFlavorDebug
```
- --profile: Mengaktifkan pembuatan profil.
- --recompile-scripts: Memaksakan skrip agar dikompilasi ulang sembari melewati caching.
- --offline: Menonaktifkan Gradle agar tidak mengambil dependensi online. Ini memastikan bahwa penundaan yang disebabkan oleh Gradle yang mencoba mengupdate dependensi tidak mengganggu data pembuatan profil Anda. Anda sebaiknya sudah membangun project Anda sekali untuk memastikan bahwa Gradle telah didownload dan meng-cache dependensi Anda.
- --rerun-tasks: Memaksakan Gradle untuk menjalankan ulang semua tugas dan mengabaikan optimalisasi tugas apa pun.
Setelah build selesai, gunakan jendela Project buka direktori project-root/build/reports/profile/ (seperti yang ditunjukkan pada gambar 1).
Gambar 1. Tampilan Project yang menunjukkan lokasi laporan profil.
Klik kanan file profile-timestamp.html dan pilih Open in Browser > Default. Laporan tersebut akan terlihat serupa dengan yang ditunjukkan pada gambar 2. Anda bisa memeriksa setiap tab dalam laporan untuk mempelajari tentang build Anda, seperti tab Task Execution yang menunjukkan berapa lama waktu yang diperlukan Gradle untuk mengeksekusi setiap tugas build.

Gambar 2. Menampilkan laporan di browser.
Opsional: Sebelum membuat perubahan pada project atau konfigurasi build Anda, ulangi perintah di langkah 3, tetapi hilangkan tanda --rerun-tasks. Karena Gradle mencoba menghemat waktu dengan tidak mengeksekusi ulang tugas yang masukannya tidak berubah (ini ditunjukkan dengan tanda UP-TO-DATE di tab Task Execution laporan, seperti yang ditunjukkan pada gambar 3), Anda bisa mengidentifikasi tugas apa saja yang melakukan pekerjaan padahal seharusnya tidak. Misalnya, bila :app:processDevUniversalDebugManifest tidak ditandai sebagai UP-TO-DATE, ini mungkin mengindikasikan bahwa konfigurasi build Anda secara dinamis mengupdate manifes bersamaan dengan setiap build. Namun, beberapa tugas perlu dijalankan pada setiap build, seperti :app:checkDevDebugManifest.

Gambar 3. Menampilkan hasil eksekusi tugas.

Sekarang setelah Anda memiliki laporan profil build, Anda bisa mencari kesempatan optimalisasi dengan memeriksa informasi dalam setiap tab laporan. Beberapa setelan build memerlukan eksperimen karena keuntungannya mungkin berbeda antara project dan workstation. Misalnya, project dengan basis kode berukuran besar bisa secara optimal memanfaatkan ProGuard untuk menghapus kode yang tidak terpakai dan mengecilkan ukuran APK. Namun, project yang lebih kecil mungkin akan lebih diuntungkan dengan menonaktifkan ProGuard sepenuhnya. Selain itu, meningkatkan ukuran heap Gradle bisa berdampak negatif pada kinerja di mesin dengan memori rendah.

Setelah melakukan perubahan pada konfigurasi build, amati hasil perubahan Anda dengan mengulangi langkah-langkah di atas dan membuat profil build baru. Misalnya, gambar 4 menunjukkan laporan untuk aplikasi contoh yang sama setelah menerapkan beberapa optimalisasi dasar yang dijelaskan di halaman ini.

Gambar 4. Menampilkan laporan baru setelah mengoptimalkan kecepatan build.

Tips: Untuk alat pembuatan profil yang lebih kuat, pertimbangkan untuk menggunakan profiler open-source Gradle.