Pengoptimalan memori sangat penting untuk memberikan pengalaman bermain game yang stabil dan berperforma tinggi di Android. Panduan ini memberikan ringkasan tentang alasan pentingnya efisiensi memori, cara sistem operasi Android mengelola batas memori proses, dan metrik memori baru di Konsol Google Play untuk membantu Anda memantau dan meningkatkan kualitas teknis game.
Pentingnya pengoptimalan memori
Mengoptimalkan memori game sangat penting untuk mempertahankan retensi pemain, memperluas kompatibilitas perangkat, dan mematuhi standar kualitas platform:
- Pencegahan cold start (pengalaman dan retensi pengguna): Saat pemain beralih sementara dari game Anda (misalnya, untuk menjawab notifikasi atau memeriksa pesan), sistem operasi akan menempatkan proses game ke latar belakang. Jika jejak memori latar belakang game terlalu tinggi, Low Memory Killer (LMK) sistem akan memprioritaskan penghentian proses game untuk mengklaim kembali RAM untuk tugas latar depan. Saat pengguna melanjutkan game, game tidak akan dilanjutkan dengan cepat dan lancar, melainkan harus melalui cold start yang lama—memuat ulang aset visual, audio, dan program biner game engine yang berat dari penyimpanan. Menjaga penggunaan memori latar belakang tetap rendah akan mencegah penghentian latar belakang otomatis ini, mempertahankan status pengguna, dan memastikan pemain dapat segera melanjutkan sesi mereka. Untuk mengetahui detail selengkapnya tentang perilaku LMK sistem, lihat panduan Android Vitals - Low memory killer.
- Stabilitas ekosistem dan perangkat: Penggunaan memori yang tidak efisien dan kebocoran memori menurunkan kondisi sistem secara keseluruhan. Saat memori sistem langka, sistem akan mengalami tekanan yang parah, sehingga menyebabkan penurunan kecepatan frame, ketersendatan UI, dan gangguan audio. Jika tekanan memori terlalu parah, Low Memory Killer (LMK) sistem akan menghentikan proses latar belakang secara agresif, sehingga memaksa aplikasi lain mengalami cold start yang lambat dan kehilangan status pengguna saat pemain beralih di antara tugas.
- Penghentian di level platform: Mulai Android 17 (level API 37), sistem lebih proaktif dalam menghentikan proses yang menggunakan terlalu banyak memori. Jika jejak game Anda terlalu tinggi, OS dapat menghentikan prosesnya secara tiba-tiba tanpa menghasilkan stack trace standar.
- Kompatibilitas perangkat: Meskipun perangkat unggulan memiliki RAM 12 GB hingga 16 GB, sebagian besar audiens game global menggunakan perangkat dengan RAM 4 GB atau 6 GB. Manajemen memori yang tepat memastikan game Anda tetap dapat diakses dan responsif di semua tingkat hardware tanpa memerlukan paket aset yang kompleks dan terpisah.
Memahami memori di Android
Untuk merancang strategi penganggaran memori yang efektif, developer harus memahami cara platform Android mengelola memori fisik dan cara platform tersebut mengukur jejak aktif game Anda.
Konsep memori Android inti
Untuk konsep dasar terkait pengelolaan memori tingkat platform, lihat dokumentasi Ringkasan Pengelolaan Memori resmi. Referensi ini mencakup empat area arsitektur:
- Ringkasan memori: Android menggunakan paging dan pemetaan memori (mmap) untuk mengelola RAM. Android tidak mendukung file swap tradisional di disk; melainkan mengandalkan kompresi halaman (menggunakan zRAM) dan reklamasi halaman untuk mengosongkan memori fisik.
- Alokasi memori di antara proses: Android berbagi RAM di seluruh sistem. Sistem ini menetapkan heap tertentu untuk eksekusi virtual machine Dalvik atau ART, sekaligus memungkinkan lingkungan pengembangan native (seperti game engine C++) untuk meminta memori dari heap sistem native.
- Manajemen memori aplikasi: Beroperasi dalam model multiproses, Android mengharapkan aplikasi memantau status siklus prosesnya secara dinamis dan secara sukarela merilis resource yang tidak diperlukan (seperti grafis dan bitmap yang tidak di-cache) untuk mendukung kesehatan sistem.
- Ringkasan proses dan thread: Sistem mengategorikan proses ke dalam hierarki berdasarkan visibilitas dan kepentingannya saat ini yang dirasakan pengguna, yang menentukan proses mana yang tetap aktif dan mana yang dihentikan terlebih dahulu selama kondisi memori rendah.
Metrik total jejak memori
Pembatas Memori Android 17 tingkat platform mengevaluasi konsumsi proses menggunakan Total Jejak Memori, bukan total ukuran resident (RSS) atau ukuran memori virtual.
Total Jejak Memori = RSS Anonim (RssAnon) + Swap Tidak Terkompresi (VmSwap)
Untuk mencegah game melampaui batas platform, Anda harus memahami dengan tepat apa yang direpresentasikan oleh metrik ini di tingkat sistem. Untuk mengetahui informasi selengkapnya tentang metrik ini, alokasi RAM fisik, dan cara penanganan halaman yang didukung file, lihat Memahami Metrik RSS dan Swap dalam panduan Memantau Penggunaan Memori.
Batasan memori
Untuk menjaga stabilitas sistem dan memastikan bahwa aplikasi tidak menggunakan resource secara berlebihan, platform Android mengelola batas memori untuk proses yang berjalan.
Pembatas Memori di Android 17 dan yang lebih baru
Android 17 (API level 37) dan yang lebih tinggi mengelola batas memori yang ketat per aplikasi menggunakan cgroup v2 Linux untuk mencegah setiap aplikasi menyebabkan ketidakstabilan di seluruh sistem. Untuk mengetahui detail selengkapnya tentang implementasi teknis, lihat Panduan Pembatas Memori AOSP dan Blog Memprioritaskan Efisiensi Memori: Langkah-Langkah Penting untuk Android 17.
- Mekanisme: Memory Limiter memantau semua proses aplikasi dan
menetapkan batas secara dinamis berdasarkan status siklus proses:
- Proses yang terlihat (latar depan): Proses aplikasi yang saat ini menampilkan UI diharapkan menjalankan set kerja resource yang lebih besar, dan diberikan batas yang lebih besar.
- Proses yang tidak terlihat (latar belakang atau layanan): Proses aplikasi yang melakukan pekerjaan aktif tanpa menampilkan UI dibatasi oleh anggaran yang lebih ketat dan lebih ketat.
- Atribut kernel: Layanan ini mengandalkan dua atribut utama:
memory.high: Batas yang dapat dilewati. Jika batas ini terlampaui, kernel akan membatasi proses dan mencoba mengklaim kembali memori secara agresif. Klaim ulang ini dapat menyebabkan game mengalami penurunan performa.memory.swap.max: Mengelola batas ketat pada ruang swap atau zRAM yang dapat digunakan proses.
- Perilaku penghentian: Jika proses terus mengalokasikan memori anonim
melebihi
memory.highdan menghabiskan kapasitas swap-nya, alokasi akan gagal, dan OS akan menghentikan proses secara otomatis. Penghentian ini dicatat dalam log menggunakanApplicationExitInfodengan alasan keluar Pembatas Memori (tersedia mulai Android 17, 26Q4).
Batas memori baru di Konsol Play Vitals
Untuk membantu developer mengidentifikasi masalah memori secara proaktif, Google Play memperkenalkan metrik baru di Android Vitals Konsol Play. Konsol Play melacak jejak memori RSS Anonim + Swap persentil ke-90 (P90) dari sesi game Anda untuk mengidentifikasi pencilan ekstrem.
Peringatan dan batas penerapan diskalakan berdasarkan kapasitas RAM fisik perangkat dan status proses. Batas ini berlaku dalam dua fase yang berbeda.
Untuk mengetahui panduan mendetail dan batas memori, lihat Android vitals - 'Apa yang dimaksud dengan batas perilaku buruk?.
Layanan yang dirasakan pengguna
Layanan yang Terlihat adalah proses latar belakang penting yang dianggap oleh sistem Android dapat terlihat oleh pengguna. Status ini mencakup semua proses yang berjalan:
- Layanan latar depan (FGS)
- Tugas yang diprioritaskan
- Tugas transfer data yang dimulai pengguna
- Layanan yang terikat sistem atau layanan yang terikat oleh aplikasi lain
Karena Layanan yang Dapat Dilihat dirancang untuk tugas penting yang berjalan lama di latar belakang, layanan ini sangat rentan terhadap kebocoran siklus proses kumulatif. Batas memori platform Android memperlakukan status ini sebagai bukan Latar Depan, yang berarti jika game Anda berjalan di latar belakang, tetapi terus menjalankan Layanan yang Dapat Disimak, game tersebut akan tunduk pada batas memori latar belakang atau layanan yang lebih ketat yang ditampilkan di halaman Pusat Bantuan Google Play. Game harus secara agresif memangkas aset yang tidak diperlukan saat berpindah dari latar depan ke status Layanan yang Dapat Disimak di latar belakang.
Persyaratan R8
Untuk meminimalkan ukuran bytecode dan mengurangi overhead proses Java dasar, Konsol Google Play mengevaluasi pengoptimalan kode sebagai bagian dari pedoman kualitas aplikasinya. Untuk mengetahui informasi selengkapnya tentang persyaratan dan batas pengoptimalan yang berlaku untuk game, lihat Pengoptimalan kode DEX dalam dokumentasi Android vitals.
Untuk mengonfigurasi R8 dalam project Android standar, ikuti panduan Mengaktifkan pengoptimalan aplikasi. Untuk mengaktifkan setelan penyingkatan dan pengoptimalan lanjutan, lihat Menggunakan R8 dalam mode penuh. Untuk mengidentifikasi aturan mana yang mencegah R8 meng-obfuscate class atau menghapus kode yang tidak digunakan, gunakan R8 Configuration Analyzer.
Jika Anda mem-build dengan game engine, perilaku default R8 bervariasi menurut engine dan versi:
- Unity: Minifikasi kode dinonaktifkan secara default, jadi Anda harus mengaktifkannya di setelan project. Untuk mengetahui informasi selengkapnya tentang dukungan versi dan langkah-langkah konfigurasi, lihat Menyingkat dan mengoptimalkan kode Unity dengan R8.
- Unreal Engine: Mulai UE 4.25, R8 diaktifkan secara default di build Rilis, sehingga Anda harus mengelola aturan keep untuk jembatan dan plugin JNI. Untuk mengetahui informasi selengkapnya tentang detail versi dan konfigurasi UPL, lihat Menyingkat dan mengoptimalkan kode Unreal Engine dengan R8.
Persyaratan bitmap
Bitmap mewakili sebagian besar penggunaan memori pada game modern dengan fidelitas tinggi. Karena data piksel Bitmap disimpan langsung di heap native yang tidak dikelola di Android 8.0 (API level 26) dan yang lebih tinggi, pemuatan gambar yang tidak dioptimalkan dapat mendorong proses melewati batas memori platform. Untuk mengetahui praktik terbaik terkait penskalaan dan penyimpanan gambar dalam cache, lihat Mengoptimalkan penggunaan gambar.
Memantau penggunaan memori
Untuk mengoptimalkan memori game secara efektif, Anda harus memahami terlebih dahulu cara
platform Android mengukur jejaknya. Android 17 memperbarui metrik memori
untuk melacak jumlah RSS Anonim (RssAnon) dan Swap yang tidak dikompresi (VmSwap), tidak termasuk memori yang didukung file atau pribadi GPU. Panduan ini menjelaskan
cara menggunakan alat tingkat sistem seperti Perfetto dan meminfo, menerapkan
API diagnostik seperti ProfilingManager dan onTrimMemory, serta mengekstrak
alokasi memori yang akurat dalam Unity dan Unreal Engine. Pahami cara
membuat profil game secara akurat dan menghindari gangguan performa yang terkait dengan
polling memori runtime tradisional.
Untuk mengetahui informasi selengkapnya, lihat Memantau Penggunaan Memori.
Strategi pengurangan memori
Meskipun game engine menyederhanakan pengembangan lintas platform, penanganan memori default-nya dapat memicu batas memori tingkat OS. Halaman ini menjelaskan langkah-langkah pengoptimalan praktis yang disesuaikan secara khusus untuk Unity dan Unreal Engine. Pahami
alasan mengandalkan onTrimMemory berbasis Java dapat menyebabkan deadlock di Unity—dan cara
menggunakan callback siklus proses native sebagai gantinya. Anda juga akan menemukan pengoptimalan tingkat aset utama, seperti menggunakan kompresi tekstur ASTC 8x8 dan mengonfigurasi penghapusan aset, agar game Anda tetap berjalan lancar di semua tingkat hardware.
Untuk mengetahui informasi selengkapnya, lihat Mengurangi Penggunaan Memori.