Tentang pengelolaan memori

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 Anda sangat penting untuk mempertahankan retensi pemain, memperluas kompatibilitas perangkat, dan mematuhi standar kualitas platform:

  • Pencegahan cold start (pengalaman dan retensi pengguna): Saat pemain beralih dari game Anda untuk sementara (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 merebut kembali RAM bagi tugas latar depan. Saat pengguna melanjutkan permainan berikutnya, bukan melanjutkan permainan dengan lancar dan instan, game harus mengalami cold start yang panjang—memuat ulang aset grafis, audio, dan biner mesin game yang berat dari penyimpanan. Menjaga penggunaan memori latar belakang Anda tetap rendah akan mencegah penghentian latar belakang tanpa pemberitahuan ini, sehingga mempertahankan status pengguna dan memastikan pemain dapat melanjutkan sesi mereka dengan segera. Untuk mengetahui detail selengkapnya tentang perilaku LMK sistem, lihat panduan Android Vitals - Penghentian proses karena memori rendah.
  • Stabilitas ekosistem dan perangkat: Penggunaan memori yang tidak efisien dan kebocoran memori menurunkan kualitas kesehatan sistem secara keseluruhan. Saat memori sistem langka, sistem akan menghadapi tekanan berat, sehingga menyebabkan penurunan kecepatan frame, ketersendatan UI, dan gangguan audio. Jika tekanan memori terlalu berat, Low Memory Killer (LMK) sistem akan menghentikan proses latar belakang secara agresif, sehingga menyebabkan aplikasi lain mengalami cold start yang lambat dan kehilangan status pengguna saat pemain beralih antar-tugas.
  • Penghentian tingkat 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 membuat rekaman aktivitas stack standar.
  • Kompatibilitas perangkat: Meskipun perangkat kelas atas memiliki RAM 12 GB hingga 16 GB, sebagian besar audiens game global menggunakan perangkat dengan RAM 4 GB atau 6 GB. Pengelolaan 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 mengukur jejak aktif game Anda.

Konsep memori inti Android

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 memory mapping (mmap) untuk mengelola RAM. ChromeOS tidak mendukung file swap tradisional di disk. Sebagai gantinya, ChromeOS mengandalkan kompresi halaman (menggunakan zRAM) dan reklamasi halaman untuk membebaskan memori fisik.
  • Alokasi memori di antara proses: Android berbagi RAM di seluruh sistem. Heap ini menetapkan heap tertentu untuk eksekusi mesin virtual Dalvik atau ART, sekaligus memungkinkan lingkungan pengembangan native (seperti mesin game C++) untuk meminta memori dari heap sistem native.
  • Pengelolaan memori aplikasi: Beroperasi di bawah model multi-proses, Android mengharapkan aplikasi memantau status siklus prosesnya secara dinamis dan melepaskan resource yang tidak perlu secara sukarela (seperti grafik 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, sehingga menentukan proses mana yang tetap aktif dan proses mana yang dihentikan terlebih dahulu saat kondisi memori rendah.

Metrik total jejak memori

Proses evaluasi Pembatas Memori Android 17 tingkat platform menggunakan konsumsi proses Total Jejak Memori, bukan total ukuran residen (RSS) atau ukuran memori virtual.

Total Jejak Memori = RSS Anonim (RssAnon) + Swap yang Tidak Dikompresi (VmSwap)

Untuk mencegah game melampaui batas platform, Anda harus memahami secara persis apa yang diwakili 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 aplikasi tidak menggunakan resource yang berlebihan, platform Android mengelola batas memori untuk proses yang sedang berjalan.

Pembatas Memori di Android 17 dan yang lebih tinggi

Android 17 (level API 37) dan yang lebih tinggi mengelola batas memori per aplikasi yang ketat menggunakan cgroup v2 Linux untuk mencegah aplikasi individual menyebabkan ketidakstabilan di seluruh sistem. Untuk mengetahui detail selengkapnya tentang penerapan teknis, lihat Panduan Pembatas Memori AOSP dan Memprioritaskan Efisiensi Memori: Langkah-Langkah Penting untuk Blog Android 17.

  • Mekanisme: Pembatas Memori memantau semua proses aplikasi dan menetapkan batas secara dinamis berdasarkan status siklus prosesnya:
    • Proses yang terlihat (latar depan): Proses aplikasi yang saat ini menampilkan UI diharapkan menjalankan set kerja resource yang lebih besar, dan diberi batas yang lebih besar.
    • Proses yang tidak terlihat (latar belakang atau layanan): Proses aplikasi yang melakukan pekerjaan aktif tanpa menampilkan UI dibatasi dengan anggaran yang lebih ketat dan lebih membatasi.
  • Atribut kernel: Layanan ini mengandalkan dua atribut utama:
    • memory.high: Batas yang dapat dilewati. Jika terlampaui, kernel akan membatasi proses dan mencoba mengklaim kembali memori secara agresif. Pengambilan kembali ini dapat menyebabkan penurunan performa game.
    • memory.swap.max: Mengelola batas ketat pada ruang swap atau zRAM yang dapat digunakan proses.
  • Perilaku penghentian: Jika proses terus mengalokasikan memori anonim setelah memory.high dan kehabisan kapasitas swap, alokasi akan gagal, dan OS akan menghentikan proses secara diam-diam. Penghentian ini dicatat menggunakan ApplicationExitInfo dengan alasan keluar Pembatas Memori (tersedia mulai Android 17, 26Q4).

Batas memori baru di Vitals Konsol Play

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) sesi game Anda untuk mengidentifikasi pencilan ekstrem.

Nilai minimum peringatan dan penegakan diskalakan berdasarkan kapasitas RAM fisik dan status proses perangkat. Batas ini berlaku dalam dua fase yang berbeda.

Untuk mengetahui panduan mendetail dan batas memori, lihat Android vitals - 'What are the bad behavior thresholds?.

Layanan yang dirasakan pengguna

Layanan yang Dapat Dirasakan adalah proses latar belakang penting yang dianggap terlihat oleh pengguna oleh sistem Android. Status ini mencakup semua proses yang sedang 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 Perceptible Services 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 Dirasakan, game tersebut akan tunduk pada batas memori latar belakang atau layanan yang lebih ketat yang ditampilkan di halaman Pusat Bantuan 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 panduan kualitas aplikasi. Untuk detail selengkapnya tentang cara mengonfigurasi pipeline build, lihat panduan Mengaktifkan pengoptimalan aplikasi dengan R8.

Untuk mengonfigurasi R8 di project Anda, ikuti panduan Mengaktifkan pengoptimalan aplikasi dengan R8. 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 tidak terpakai, gunakan Gunakan Penganalisis Konfigurasi R8.

Persyaratan bitmap

Bitmap merepresentasikan sebagian besar penggunaan memori pada game fidelitas tinggi modern. Karena data piksel Bitmap disimpan langsung di heap native yang tidak dikelola di Android 8.0 (level API 26) dan yang lebih tinggi, pemuatan gambar yang tidak dioptimalkan dapat mendorong proses melewati batas memori platform. Untuk mengetahui praktik terbaik tentang penskalaan dan penyimpanan dalam cache gambar, 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 GPU-private. Panduan ini menjelaskan cara memanfaatkan alat tingkat sistem seperti Perfetto dan meminfo, mengimplementasikan API diagnostik seperti ProfilingManager dan onTrimMemory, serta mengekstrak alokasi memori yang tepat dalam Unity dan Unreal Engine. Pahami cara membuat profil game Anda secara akurat dan menghindari jeda performa yang terkait dengan polling memori runtime tradisional.

Untuk mengetahui informasi selengkapnya, lihat Memantau Penggunaan Memori.

Strategi pengurangan memori

Meskipun mesin game menyederhanakan pengembangan lintas platform, penanganan memori defaultnya dapat memicu batas memori tingkat OS. Halaman ini menjelaskan langkah-langkah pengoptimalan praktis yang secara khusus disesuaikan untuk Unity dan Unreal Engine. Pahami mengapa mengandalkan onTrimMemory berbasis Java dapat menyebabkan kebuntuan 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 pelepasan aset, untuk memastikan game Anda berjalan lancar di semua tingkat hardware.

Untuk mengetahui informasi selengkapnya, lihat Mengurangi Penggunaan Memori.