Kinerja dalam Pengembangan Seluler: apa itu, metrik apa dan cara meningkatkannya

Mengapa aplikasi lambat?

Kinerja aplikasi terkait langsung dengan jank — keterlambatan yang terlihat antara tindakan pengguna dan respons UI. Penyebab utama: pemblokiran thread utama (operasi berat di thread UI), penggambaran ulang tata letak yang sering (overdraw), kebocoran memori (GC sering), algoritma yang tidak optimal (O(n²) pada data besar). Frame Rate (FPS) — jumlah bingkai per detik. Untuk pengalaman yang nyaman, diperlukan 60 FPS yang stabil (Android) atau 120 FPS (iPhone Pro, iPad Pro). VSync menyinkronkan rendering dengan kecepatan refresh layar.

Jank terjadi ketika rendering satu bingkai melebihi 16,6 md (untuk 60 FPS) atau 8,3 md (untuk 120 FPS). Pembuatan profil GPU (Profile GPU Rendering di Android, Core Animation di iOS) menunjukkan tahap rendering mana yang memakan waktu paling banyak. Tahapan utama: Layout (penempatan elemen), Draw (menggambar), Display (transfer ke buffer bingkai). Masalah paling umum adalah inflasi tata letak dalam XML, terutama saat menggunakan ConstraintLayout bertingkat yang kompleks.

Time-to-Interactive (TTI) — waktu yang dibutuhkan aplikasi untuk siap berinteraksi sepenuhnya. TTI mencakup Cold Start, pemuatan data, dan inisialisasi pustaka. Google merekomendasikan TTI di bawah 5 detik, Apple — di bawah 2 detik untuk layar utama. Lazy Loading — teknik pemuatan konten dan pustaka yang ditunda, sangat penting untuk meningkatkan TTI. Di IT Sectr, kami menggunakan inisialisasi malas secara default di semua proyek.

ANR dan Crash

ANR dan Crash adalah musuh utama kinerja aplikasi seluler. ANR (Application Not Responding) — kotak dialog di Android yang muncul jika thread utama diblokir lebih dari 5 detik. Penyebab: permintaan jaringan sinkron di thread UI, bekerja dengan database tanpa coroutine, dekode bitmap besar tanpa downsampling, deadlock di thread utama. Tumpukan panggilan ANR disimpan di /data/anr/traces.txt dan memungkinkan penentuan lokasi pemblokiran yang tepat.

Crash — penghentian aplikasi yang tidak terduga. Di Android — Exception (Java/Kotlin) atau Signal (kode asli). Di iOS — NSException atau sinyal (EXC_BAD_ACCESS — akses ke memori yang dibebaskan). Alat Pelaporan Crash: Firebase Crashlytics, Sentry, BugSnag. Mereka mengumpulkan stacktrace, data perangkat, dan langkah reproduksi. Stack Overflow — luapan tumpukan panggilan karena rekursi tak terbatas. OutOfMemoryError — ketika heap penuh.

StrictMode — alat Android untuk mendeteksi pelanggaran keamanan thread. Memungkinkan pengaturan aturan: ThreadPolicy (larang disk/jaringan di thread utama), VmPolicy (deteksi kebocoran Activity, SQLite, CloseGuard). StrictMode sebaiknya diaktifkan hanya di build debug — di rilis seharusnya tidak berfungsi. Di iOS, padanannya adalah Main Thread Checker (Xcode), yang secara otomatis mendeteksi panggilan UIKit yang tidak di thread utama.

Manajemen Memori (GC, ARC, Retain Cycle)

Kebocoran Memori

Kebocoran memori (Memory Leak) — situasi ketika suatu objek tetap berada di memori meskipun aplikasi tidak lagi menggunakannya. Ini secara langsung menurunkan kinerja aplikasi. Di Android, GC (Garbage Collection) tidak dapat mengumpulkan objek jika ada referensi kuat ke objek tersebut. Penyebab umum: referensi statis ke Activity, callback/observer yang tidak dibatalkan, kelas dalam dengan referensi implisit ke kelas luar, Handler dengan pesan yang tidak dibersihkan. LeakCanary — pustaka untuk deteksi kebocoran otomatis.

Retain Cycle (Siklus Retensi)

ARC (Automatic Reference Counting) — model manajemen memori di iOS. Setiap objek memiliki penghitung referensi (retain count). Ketika penghitung mencapai nol, memori dibebaskan. Retain Cycle terjadi ketika dua objek saling memegang referensi kuat (A → B dan B → A). ARC tidak akan pernah menghitung nol. Solusi: referensi lemah (weak) atau tanpa pemilik (unowned). Weak secara otomatis menjadi nil saat objek dibebaskan. Unowned tidak menjadi nil tetapi menjamin objek tetap hidup.

GC vs ARC

GC (Garbage Collection) bekerja di Android (Java/Kotlin). GC secara periodik menjeda eksekusi (jeda Stop-the-World) untuk menemukan dan membebaskan objek yang tidak dapat dijangkau. Pemicu GC: ketika heap terisi hingga persentase tertentu. ARC bekerja di iOS (Swift/Objective-C) dan tidak memiliki jeda — penghitung diperbarui secara atomik pada setiap penugasan. ARC lebih dapat diprediksi, tetapi dapat mengakumulasi operasi retain/release yang berlebihan pada frekuensi penugasan tinggi.

Referensi Lemah (Weak Reference) dan Referensi Kuat (Strong Reference) — jenis referensi menentukan apakah GC/ARC dapat membebaskan objek. Strong Reference — objek tidak akan dikumpulkan selama referensi ini ada. Weak Reference — GC/ARC dapat mengumpulkan objek; referensi lemah menjadi nil (di Swift/Java WeakReference). Unowned Reference (Swift) — tidak menjadi nil saat dibebaskan; mengaksesnya setelah objek mati menyebabkan crash. Di Android, java.lang.ref.WeakReference digunakan untuk referensi lemah.

Contoh deteksi kebocoran di Android dengan LeakCanary:

// Утечка: анонимный класс держит ссылку на Activity
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val handler = object : Handler(Looper.getMainLooper()) {
            override fun handleMessage(msg: Message) {
                // Используем `this@MainActivity`, сохраняя ссылку на Activity
                Log.d("TAG", "Handler received message")
            }
        }
        handler.sendEmptyMessageDelayed(0, 60000)
    }
}

// Исправление: статический Handler + WeakReference
class SafeHandler(activity: MainActivity) : Handler() {
    private val weakActivity =
        WeakReference(activity)

    override fun handleMessage(msg: Message) {
        weakActivity.get() ?: return
        Log.d("TAG", "Handler received message")
    }
}

Pembuatan Profil (Instruments, Android Profiler)

Pembuatan profil adalah proses mengukur kinerja aplikasi: CPU, memori, jaringan, konsumsi daya. Tanpa pembuatan profil, optimasi buta tidak berguna — Anda tidak akan tahu bagian kode mana yang benar-benar lambat.

Instruments (Xcode) — alat terkuat untuk iOS. Time Profiler menunjukkan fungsi mana yang paling banyak mengonsumsi CPU. Allocations melacak pembuatan dan pembebasan objek. Leaks secara otomatis menemukan retain cycles. Langkah pembuatan profil: (1) jalankan Instruments; (2) pilih template (Time Profiler untuk CPU); (3) jalankan skenario bermasalah; (4) analisis tumpukan panggilan — kolom terlebar adalah fungsi ter"panas".

Android Profiler terintegrasi di Android Studio (View → Tool Windows → Profiler). CPU Profiler menunjukkan beban setiap thread. Memory Profiler — heap dump dan pelacakan alokasi. Network Profiler — semua permintaan HTTP dengan waktu. Energy Profiler — konsumsi daya: WakeLock, Location, Network. Untuk pelacakan terperinci, gunakan Systrace (Android 10+) atau Perfetto — pelacakan sistem dengan presisi mikrodetik.

Startup Aplikasi (Cold/Warm/Hot Start)

Startup aplikasi adalah salah satu indikator kinerja utama. Ini dibagi menjadi tiga jenis: Cold Start — aplikasi dimulai dari awal: proses dibuat, Application.onCreate (Android) / AppDelegate.applicationDidFinishLaunching (iOS), pemuatan kelas, inisialisasi pustaka. Warm Start — proses ada, tetapi Activity/ViewController dihancurkan (misalnya, saat rotasi layar atau kembali dari memori). Hot Start — Activity/ViewController ada di memori, aplikasi hanya ditampilkan (beralih dari aplikasi lain).

Cold Start adalah metrik terpenting. Di Android mencakup: (1) launch Activity — pemuatan XML, inisialisasi View; (2) bingkai pertama — waktu hingga rendering pertama. Google merekomendasikan: launch Activity < 200 md, bingkai pertama < 500 md, TTI < 5 detik. Optimasi Cold Start: kurangi Application.onCreate (coroutine untuk inisialisasi malas), gunakan SplashScreen API (Android 12+), tunda inisialisasi pustaka (WorkManager, DI), hapus ContentProviders yang tidak perlu.

Di iOS, Cold Start mencakup: pemuatan biner Mach-O, dyld (paut dinamis), inisialisasi runtime Objective-C, delegasi aplikasi, pengontrol pertama. Chrome Custom Tabs (Android) dan Universal Links (iOS) — teknologi untuk membuka konten eksternal dengan cepat di aplikasi tanpa Cold Start penuh. Disarankan untuk menguji Cold Start pada perangkat nyata kelas menengah.

Optimasi Ukuran

Ukuran aplikasi adalah faktor kinerja untuk instalasi dan pembaruan. Ini memengaruhi konversi: setiap 10 MB mengurangi konversi sebesar 1%. Google Play merekomendasikan ukuran APK di bawah 150 MB; App Store — di bawah 200 MB (jaringan seluler — 100 MB). Metode optimasi utama: kompresi gambar (WebP sebagai pengganti PNG menghemat 25-35%), vektorisasi (VectorDrawable di Android, SF Symbols di iOS), penghapusan kode yang tidak digunakan (R8/ProGuard), penghapusan sumber daya yang tidak digunakan (lint → unused resources).

App Bundle (Android) — format publikasi di mana Google Play menghasilkan APK yang dioptimalkan untuk setiap perangkat. App Bundle mengurangi ukuran unduhan sebesar 20-40%. Dynamic Delivery — modul yang diunduh sesuai permintaan (on-demand feature modules). Di iOS, padanannya adalah On-Demand Resources (ODR): sumber daya yang diunduh setelah startup pertama (level game, video).

Lazy Loading — teknik di mana modul dan pustaka tidak dimuat saat startup, tetapi dimuat sesuai kebutuhan. Split APK (Android) dan App Slicing (iOS) — pembagian aplikasi ke dalam slot arsitektur: arm64-v8a, x86_64. Optimasi Ukuran Aplikasi — proses berkelanjutan: analisis komposisi APK (Analyze APK di Android Studio), hapus ikon duplikat, gunakan SVG sebagai pengganti beberapa kepadatan PNG. Di IT Sectr, kami menyertakan pemeriksaan ukuran build di CI/CD untuk setiap MR.