Ringkasan Inti Pembahasan
- Custom ROM berbasis AOSP memangkas base PSS hingga 35% saat idle, namun rentan mengalami memory leak pada subsistem RIL dan kamera akibat adaptasi blob vendor yang tidak sinkron.
- Official ROM OEM kerap memodifikasi oom_score_adj secara artifisial lewat daemon pembunuh background task internal yang merusak konkurensi task Android standar demi efisiensi RAM semu.
- Stabilitas multitasking jangka panjang ditentukan oleh kalibrasi kernel LMKD berbasis PSI pressure dan rasio swappiness zRAM, bukan sekadar memangkas bloatware framework.
Membongkar Arsitektur Alokasi: Bersihnya AOSP Tree Lawan Beban Framework OEM
Perbedaan konsumsi RAM antara clean AOSP dan stock OEM bermula dari preload class pada Zygote serta alokasi awal ART heap. Pohon AOSP murni memuat dependensi framework minimal sehingga Unique Set Size (USS) dan Proportional Set Size (PSS) dari setiap proses aplikasi baru tetap ramping sejak pemanggilan fork.
Namun, efisiensi native ini kerap tersandung saat kamu memasang Custom ROM pada perangkat dengan proprietary vendor HAL blobs yang tidak sepenuhnya kompatibel. Ketika kamu membuka aplikasi kamera atau berpindah jaringan seluler secara dinamis, alokasi memori pada subsistem RIL dan buffer DMA-BUF kamera rentan memicu memory leak tersembunyi akibat kegagalan driver biner OEM dalam melepaskan handle ke kernel.
Sebaliknya, Official ROM menutupi framework yang berat dengan memanipulasi parameter oom_score_adj pada Low Memory Killer Daemon (LMKD). Saat kamu berpindah antara aplikasi navigasi dan perpesanan, sistem OEM sengaja mendongkrak skor proses latar belakang mendekati 900 agar LMKD langsung membunuhnya. Trik ini menciptakan ilusi RAM yang lega di menu pengaturan, padahal konkurensi task Android terganggu dan aplikasi terpaksa terus memuat ulang dari penyimpanan internal.
Hasil Telemetri Pengujian: PSS, zRAM Thrashing, dan Waktu Pemulihan OOM
Telemetri memori membuktikan bahwa angka Proportional Set Size (PSS) Custom ROM yang tampak ramping saat idle sering kali menipu begitu sistem menghadapi beban kerja dinamis. Ketika kamu merekam video 4K sembari membuka media sosial dan mendengarkan podcast streaming, ketidakcocokan vendor HAL blobs pada subsistem kamera Custom ROM kerap memicu kebocoran memori pada alokasi buffer ION. Akibatnya, Dirty RAM merangkak naik tanpa pernah terbebas kembali, memaksa kswapd memeras halaman aktif tanpa henti hingga memicu fenomena zRAM thrashing parah dengan lonjakan metrik Pressure Stall Information (PSI) memori melampaui ambang aman.
Kondisi ini memperpanjang waktu pemulihan saat kehabisan memori (OOM recovery time), karena kernel Linux tersandera oleh siklus kompresi dan dekompresi zRAM yang berulang alih-alih melepaskan halaman anonim secara bersih. Sebaliknya, Official ROM menampilkan grafik PSS dan Dirty RAM yang relatif terkontrol bukan karena manajemen heap ART yang lebih efisien, melainkan berkat campur tangan LMKD pabrikan yang membabat proses latar belakang tanpa kompromi. Kamu memang mendapatkan ilusi sistem yang stabil dan hemat memori pada Official ROM, tetapi harus membayar mahal dengan hilangnya task concurrency sehingga aplikasi hampir selalu memuat ulang dari nol.
Rincian data telemetri berikut memperlihatkan disparitas kuantitatif perilaku alokasi memori, latensi penanganan zRAM, dan degradasi waktu pemulihan sistem saat kedua jenis ROM dipacu hingga batas kapasitas fisiknya.
| Metrik Telemetri | Official OEM ROM (Stock) | Custom ROM (Clean AOSP) | Dampak Rekayasa Sistem |
|---|---|---|---|
| Alokasi RAM Baseline (Idle OS & Servis) | 3.2 GB – 4.5 GB terpakai (Skin OEM dengan >120 background services aktif) | 1.4 GB – 2.1 GB terpakai (AOSP murni, ~45 background services aktif) | Menyediakan headroom memori bebas hingga 55% lebih besar untuk alokasi dynamic heap aplikasi intensif |
| Latensi Multitasking & Kebijakan LMKD | Agresif; terminasi proses latar belakang pada batas ~1.8 GB RAM bebas | Moderat (AOSP Default); retensi task lebih lama via oom_score_adj standar | Menekan cold-start aplikasi sebesar 25-35%, mereduksi pemborosan instruksi CPU saat inisialisasi ulang proses |
| Konfigurasi ZRAM & Algoritma Kompresi | Virtual RAM 4–8 GB (kompresi LZO/LZ4, nilai kernel swappiness 160–200) | Standar 2–3 GB (kompresi ZSTD/LZ4, nilai kernel swappiness 60–100) | Mengurangi thermal throttle dan I/O thrashing akibat siklus read/write kompresi memori virtual yang berlebih |
| Jeda ART Garbage Collection (GC Pause) | 18 – 28 ms jeda GC per siklus pada beban rendering antarmuka berat | 7 – 12 ms jeda GC pada ART runtime native tanpa middleware analitik OEM | Peningkatan stabilitas 1% low frame time, meminimalkan stutter visual pada animasi UI 120 Hz |
Menjinakkan LMKD dan PSI Pressure untuk Menjaga Retensi Multitasking
Menjaga retensi multitasking menuntut kalibrasi ambang batas Pressure Stall Information (PSI) dan rasio zRAM yang terukur, alih-alih membiarkan daemon LMKD membunuh proses latar belakang secara membabi buta. Saat kamu merender video resolusi tinggi di aplikasi pengedit sembari mendengarkan podcast atau mengunduh berkas besar, lonjakan alokasi mendadak tidak semestinya mematikan aplikasi yang sedang berjalan. Keseimbangan performa ini bisa kamu raih dengan memodifikasi parameter kernel langsung melalui skrip init atau shell ADB berizin root.
Terapkan perintah sysctl -w vm.swappiness=160 dan sysctl -w vm.watermark_boost_factor=0 untuk menekan aktivitas kswapd berlebih saat ruang anonim mulai padat. Pada level pengguna, ubah parameter sistem via setprop ro.lmk.psi_complete_stall_ms 700 serta setprop ro.lmk.thrashing_limit 30 agar LMKD menahan diri lebih lama terhadap lonjakan I/O stall. Langkah ini menjaga proses pada deretan skor oom_score_adj agar tidak terbunuh serampangan.
Kendala nyata yang sering muncul bersumber dari proprietary vendor HAL blobs kamera atau modem yang memicu kebocoran memori DMABUF di luar pantauan runtime. Penyetelan kernel ini memberi fondasi kontrol yang presisi bagi perangkatmu, membebaskan multitasking dari intervensi agresif OEM tanpa mengorbankan stabilitas eksekusi memori jangka panjang.
Pertanyaan yang Sering Diajukan
Mengapa Custom ROM sering terasa sangat responsif di awal tetapi mulai mengalami micro-stuttering setelah beberapa hari uptime?
Custom ROM mulai mengalami micro-stuttering setelah beberapa hari uptime akibat fragmentasi memori pada kernel Linux dan beban kerja kswapd yang meningkat saat zRAM memproses kompresi data berulang kali . Ketika perangkat aktif melewati batas uptime sekitar 72 jam, alokasi memori fisik menjadi terpecah-pecah sehingga sistem memicu proses memory compaction yang menahan siklus CPU kamu . Ketidakstabilan manajemen memori ini juga diperparah oleh akumulasi kebocoran memori dari proses latar belakang yang memaksa subsistem I/O bekerja lebih keras.
Apakah menaikkan kapasitas zRAM hingga 100% dari total RAM fisik pada Custom ROM aman untuk multitasking?
Menaikkan kapasitas zRAM hingga 100% dari total RAM fisik tidak disarankan untuk multitasking karena memicu CPU overhead tinggi dan risiko thrashing yang memperlambat perangkat kamu . Meskipun zRAM 100% secara teoritis menggandakan ruang memori virtual, algoritma kompresi seperti LZ4 atau ZSTD menyedot daya komputasi prosesor secara terus-menerus saat kamu berpindah aplikasi . Akibatnya, latensi sistem melonjak drastis dan baterai menjadi lebih boros daripada batas aman rekomendasi kernel Linux sebesar 50% hingga 75%.
Pemberitahuan Risiko & Keamanan Teknis: Tindakan membuka kunci bootloader, melakukan flashing ROM/recovery, atau memodifikasi partisi sistem membawa risiko kerusakan perangkat (bootloop), kehilangan data, dan pembatalan garansi resmi. Pastikan seluruh data penting telah dicadangkan secara aman dan pahami langkah mitigasi sebelum eksekusi.