App Size Optimization dalam pengembangan aplikasi mobile: dasar, metode, dan praktik

Apa itu App Size Optimization

App Size Optimization — disiplin dalam pengembangan aplikasi mobile yang bertujuan meminimalkan ukuran paket pemasangan aplikasi. Ini mencakup penghapusan kode dan sumber daya mati, kompresi gambar, optimasi pustaka, fragmentasi kompilasi untuk berbagai arsitektur, dan penggunaan teknologi pengiriman sesuai permintaan.

Ukuran aplikasi memengaruhi secara tidak merata segmen pengguna yang berbeda. Di wilayah dengan infrastruktur mobile yang maju (AS, Eropa, Jepang), perbedaan antara 50 dan 100 MB mungkin tidak terasa. Di wilayah berkembang (India, Indonesia, Brasil), setiap megabyte tambahan mengurangi konversi pemasangan karena batas tarif dan kecepatan internet mobile. Google Play membatasi ukuran APK hingga 200 MB, tetapi merekomendasikan menjaga ukuran di bawah 100 MB.

Untuk iOS App Store, ukuran unduhan maksimum melalui jaringan seluler adalah 200 MB (hingga 2023 adalah 150 MB). Jika IPA melebihi batas ini, pengguna hanya dapat memasang aplikasi melalui Wi-Fi. Apple juga mendukung App Thinning, yang mencakup Slicing, Bitcode, dan On-Demand Resources — teknologi yang secara otomatis mengurangi ukuran pemasangan pada perangkat tertentu tanpa campur tangan pengembang.

Mengapa ukuran aplikasi penting

Ukuran aplikasi tidak hanya memengaruhi konversi pemasangan, tetapi juga retensi, frekuensi pembaruan, dan kecepatan peluncuran pertama. Setiap megabyte tambahan adalah hambatan antara pengguna dan penggunaan produk Anda.

Dampak pada konversi pemasangan

Menurut data Google I/O 2024, pengurangan APK sebesar 10 MB meningkatkan konversi pemasangan rata-rata sebesar 3,5%. Untuk aplikasi berukuran 150+ MB, konversi bisa 20–30% lebih rendah daripada aplikasi kelas yang sama berukuran 50 MB. Efeknya terutama terlihat di Google Play, di mana pengguna melihat ukuran sebelum pemasangan. Di App Store, ukuran ditampilkan di halaman aplikasi, dan pengguna dengan tarif terbatas menunda pemasangan hingga Wi-Fi, setelah itu sering melupakan aplikasi.

Frekuensi pembaruan dan pembaruan melalui udara

Aplikasi besar lebih jarang diperbarui melalui udara — pengguna menunda unduhan tambalan hingga Wi-Fi, melewatkan perbaikan keamanan kritis. Google Play memungkinkan penggunaan Incremental Updates (tambalan hingga 10 MB), tetapi instalasi ulang penuh tetap mengunduh seluruh APK atau AAB. Apple App Store menggunakan Delta Updates, mengirimkan hanya file yang diubah, tetapi bahkan delta bisa signifikan saat mengubah sumber daya.

Peluncuran pertama dan pembongkaran

Ukuran secara langsung memengaruhi waktu peluncuran pertama: aplikasi harus membongkar sumber daya, mengompilasi kode (Android) atau menandatangani cache (iOS). Aplikasi berukuran 200 MB dapat menyala 10–15 detik lebih lambat daripada aplikasi 50 MB pada perangkat rata-rata. Ini memperburuk Onboarding Experience — pengguna dapat menutup aplikasi tanpa menunggu pemuatan.

Optimasi sumber daya dan aset

Sumber daya — gambar, font, suara, video — merupakan 60–80% dari ukuran aplikasi mobile pada umumnya. Optimasi sumber daya memberikan keuntungan terbesar dengan usaha minimal. Arah utama: kompresi, penghapusan duplikat dan aset yang tidak digunakan, pemilihan format yang tepat.

Optimasi gambar

WebP — format gambar dari Google, yang memberikan kompresi 25–35% lebih baik daripada PNG dan 15–20% lebih baik daripada JPEG dengan kualitas visual yang sama. Android mendukung WebP secara native sejak API 18. Untuk iOS, WebP didukung melalui pustaka SDWebImage atau Kingfisher, dan sejak iOS 17 dukungan native tersedia. AVIF — format yang lebih modern, memberikan penghematan tambahan 10–15% dibandingkan WebP, tetapi dengan decoding yang lebih lambat.

Penghapusan sumber daya yang tidak digunakan — cara paling sederhana untuk mengurangi ukuran. Di Android, gunakan refactoring dengan Android Studio: Analyze → Run Inspection → Unused Resources. Di iOS — Build Settings → Remove Unused Resources. Seringkali dalam proyek tersisa sprite dari versi sebelumnya, ikon lama, gambar layar mulai yang tidak digunakan yang menggelembungkan ukuran tanpa beban fungsional.

Optimasi font dan suara

Font khusus dapat memakan 5–15 MB, terutama jika seluruh keluarga terhubung (semua gaya: Regular, Bold, Italic, BoldItalic). Gunakan hanya gaya yang diperlukan dan subset karakter melalui subsetting — penghapusan glyph untuk bahasa yang tidak didukung oleh aplikasi. Layanan seperti Google Fonts dan Transfonter memungkinkan pembuatan set karakter minimal. Untuk suara, gunakan AAC/HE-AAC daripada WAV dan format tidak terkompresi — penghematan hingga 90% tanpa kehilangan kualitas.

Optimasi kode dan pustaka

Kode merupakan 20–40% dari ukuran aplikasi, tetapi optimasinya lebih sulit daripada sumber daya, karena memerlukan analisis dependensi, obfuskasi, dan penghapusan kode mati tanpa risiko merusak fungsionalitas.

ProGuard dan R8 untuk Android

ProGuard — alat untuk Android yang melakukan obfuskasi, minifikasi, dan optimasi kode. R8 — penerusnya, tertanam dalam Android Gradle Plugin, bekerja lebih cepat dan lebih efisien. R8 menghapus kelas dan metode yang tidak digunakan, memperpendek nama variabel, dan menulis ulang kode untuk mengurangi jumlah instruksi. Pengurangan ukuran file DEX yang umum dengan R8 adalah 30–50%.

// build.gradle — konfigurasi R8 untuk minifikasi
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Optimasi pustaka dan dependensi

Pustaka — penyebab umum ukuran membengkak. Satu pustaka dapat membawa dependensi transitif yang meningkatkan ukuran sebesar 5–20 MB tanpa manfaat langsung bagi aplikasi. Gunakan Gradle Version Catalog untuk Android dan Swift Package Manager untuk iOS dengan penyebutan dependensi secara eksplisit. Analisis ukuran menggunakan Build Analyzer di Android Studio atau Xcode Build Timeline. Ganti pustaka berat dengan alternatif yang lebih ringan: misalnya, OkHttp (3 MB) daripada Apache HTTP (15 MB).

Penghapusan kode yang tidak digunakan di iOS

Dead Code Stripping — penghapusan otomatis metode dan kelas yang tidak digunakan pada tahap penautan di Xcode. Diaktifkan melalui Build Settings → Dead Code Stripping = YES. Bitcode — representasi perantara yang dapat dikompilasi ulang oleh Apple untuk berbagai arsitektur, menghapus fungsi yang tidak digunakan. Namun sejak Xcode 14, Bitcode menjadi opsional, dan kontribusinya terhadap pengurangan ukuran adalah 5–15% untuk proyek Objective-C dan lebih sedikit untuk Swift.

App Thinning dan pengiriman sesuai permintaan

App Thinning — teknologi Apple yang secara otomatis mengurangi ukuran aplikasi yang dipasang dengan mengirimkan hanya sumber daya yang diperlukan untuk perangkat tertentu. Terdiri dari tiga komponen: Slicing, On-Demand Resources, dan Bitcode. Di Android, padanannya adalah Android App Bundle (AAB) dengan Dynamic Delivery.

Android App Bundle (AAB)

AAB — format publikasi di Google Play, di mana toko menghasilkan APK untuk setiap perangkat secara terpisah, hanya menyertakan sumber daya untuk arsitekturnya (armeabi-v7a, arm64-v8a), kerapatan layar (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) dan bahasa. Pengurangan ukuran pemasangan yang umum saat beralih dari APK universal ke AAB adalah 20–40%. Play Feature Delivery memungkinkan pengunduhan modul sesuai permintaan, sementara modul Install-time disertakan dalam pemasangan dasar.

// build.gradle — konfigurasi AAB dan Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources di iOS

On-Demand Resources (ODR) — mekanisme iOS di mana sumber daya (level game, gambar resolusi tinggi, video) diunduh dari server Apple hanya ketika benar-benar dibutuhkan oleh pengguna. Ukuran pemasangan awal dapat dikurangi 50–80%. Sumber daya dibagi menjadi tiga kategori: Initial Install Tags (diunduh saat pemasangan), Prefetched Tag Order (diunduh di latar belakang setelah pemasangan), dan On-Demand (diunduh hanya sesuai permintaan). Apple merekomendasikan penggunaan ODR untuk konten yang tidak diperlukan di layar pertama: level game, konten tambahan, instruksi video.

SwiftUI mendukung ODR melalui atribut Bundle.module, dan UIKit melalui NSBundleResourceRequest. Untuk game di Unity dan Unreal Engine, ODR diintegrasikan pada tingkat pembungkus native. Batasan utama — sumber daya ODR dihapus oleh sistem saat kekurangan ruang, oleh karena itu data yang kritis untuk pengoperasian harus disertakan dalam kompilasi utama.