Bagaimana Lyft Mendeteksi Kebocoran Memori Android dalam Produksi

Meskipun alat modern untuk Android dan iOS memungkinkan deteksi kebocoran memori menggunakan build lokal, ini cukup untuk memastikan bahwa aplikasi menunjukkan perilaku memori yang benar dalam produksi, yang berjalan di berbagai perangkat dalam kondisi yang berbeda. Untuk alasan ini, insinyur Lyft menggabungkan pengujian A/B dan visualisasi memori untuk mengidentifikasi fitur mana yang mengalami kebocoran memori.

Saat fitur yang besar dan kompleks dirilis, penting untuk memastikan bahwa fitur tersebut tidak menyebabkan kemunduran dalam hal penggunaan memori. Ini sangat penting jika fitur tersebut berisi kode C/C++ yang memiliki kemungkinan kebocoran memori lebih tinggi.

Pendekatan umum yang diikuti oleh teknisi Lyft melibatkan pengukuran perilaku memori dasar dari versi standar aplikasi mereka dan membandingkannya dengan data yang dikumpulkan untuk sebagian basis pengguna mereka yang menerima fitur tertentu dalam pengujian A/B.

Untuk membuat profil keseluruhan memori yang digunakan oleh aplikasi mereka, insinyur Lyft menggunakan beberapa API Android untuk mengambil metrik penggunaan memori: ukuran set proporsional (PSS), ukuran set unik (USS), dan ukuran memori statis (RSS). . Mereka akhirnya menyesuaikan RSS menurut fitur-fiturnya dalam hal kinerja dan kemungkinan menggunakannya tanpa membatasi laju sampel. Metrik lain yang diminati oleh para insinyur Lyft adalah tumpukan JVM dan ukuran tumpukan asli, yang satu setnya didukung langsung oleh runtime Android.

Metrik memori dikumpulkan dalam dua skenario penting: setiap kali halaman antarmuka pengguna ditutup dan pada interval 1 menit untuk menghitung kemungkinan pengguna tetap berada di halaman antarmuka pengguna yang sama untuk waktu yang lama.

Yang mengatakan, untuk memahami jika suatu fitur memperkenalkan regresi memori, insinyur Lyft melihat perilaku memori untuk sekelompok pengguna yang menjalankan versi stok aplikasi (dengan fitur dinonaktifkan) dan untuk sekelompok pengguna yang menjalankan versi aplikasi. dijalankan dengan fitur yang diaktifkan Penggunaan memori akan bervariasi di antara pengguna, jadi dalam kedua kasus, jejak memori program diwakili oleh kurva. Jika kurva jejak memori untuk kedua kasus berbeda, seperti yang ditunjukkan pada gambar di bawah, ini merupakan indikasi regresi memori.

Kasus yang sangat menarik adalah kebocoran memori, yang hanya memengaruhi sebagian kecil pengguna. Dalam hal ini, kurva jejak memori kira-kira akan sama, kecuali pada persentil yang lebih tinggi, bergantung pada ukuran basis pengguna yang terpengaruh. Ini diilustrasikan pada gambar di bawah untuk kebocoran memori yang terjadi dalam keadaan yang sangat spesifik dan hanya memengaruhi persentil terakhir dari basis pengguna.

Menurut para insinyur Lyft, pendekatan yang dijelaskan dalam makalah mereka efektif untuk mendeteksi kebocoran memori, terutama untuk kebocoran yang terjadi dalam kondisi sangat spesifik yang mudah terlewatkan saat pengujian secara lokal. Jangan lewatkan artikel utama untuk detail lengkapnya.