Плавна робота застосунків залишається одним із головних пріоритетів Android, а для цього пристрої мають працювати швидко та без збоїв. Тому питання оптимізації пам'яті стає дедалі гострішим: виробники нових смартфонів через подорожчання мікросхем пам'яті не збільшують, а іноді навіть зменшують обсяг RAM, тоді як користувачі й надалі очікують від застосунків миттєвої та стабільної роботи.

З виходом Android 17 компанія Google запровадила окремі ліміти пам'яті для кожного застосунку — спершу на пристроях Pixel. Мета цього кроку — захистити систему від застосунків, які споживають надмірну кількість оперативної пам'яті й через це гальмують роботу всього пристрою. Протягом наступного року дедалі більше виробників планують застосувати ці обмеження на своїх лінійках смартфонів з обсягом RAM від 4GB до 16GB і вище. Застосунки, які перевищують встановлені межі, система сповільнюватиме, а в гіршому разі — завершуватиме примусово. Тож оптимізація споживання пам'яті стає необхідною умовою, щоб уникнути троттлінгу з боку операційної системи та зберегти комфортний досвід користування.

У матеріалі команда Android детальніше пояснює механізм роботи цих обмежень, розповідає, як вимірювати обсяг пам'яті, яку споживає застосунок, за допомогою нових метрик Android vitals, а також дає практичні рекомендації щодо оптимізації застосунків та ігор.

Як працюють обмеження пам'яті

Коли застосунок перевищує виділений йому бюджет пам'яті, Android послідовно вживає заходів для збереження відгукливості пристрою:

  1. Витіснення в zRAM: якщо застосунок досягає встановленого ліміту, система переміщує його сторінки пам'яті у zRAM — стиснуту область оперативної пам'яті. Це запобігає негайному видаленню процесу, проте стиснення та розпаковування даних додає навантаження на процесор, що може спричинити помітні затримки та ривки в інтерфейсі.
  2. Завершення процесу: якщо споживання пам'яті продовжує зростати навіть після переходу в zRAM, система примусово завершує процес застосунку. Щоб з'ясувати, чи постраждала сесія користувача через ці обмеження, розробники можуть викликати метод getDescription() у класі ApplicationExitInfo. Якщо причиною завершення стало обмеження системи, у полі причини вказується REASON_OTHER, а рядок опису міститиме позначку MemoryLimiter:AnonSwap. Також можна скористатися профілюванням за тригером TRIGGER_TYPE_ANOMALY, яке автоматично формує дампи купи (heap dumps) у момент досягнення ліміту пам'яті.

Детальніше про принципи роботи обмежень пам'яті на рівні окремих застосунків можна дізнатися в документації Android 17 App Memory Limits. Для перевірки поведінки застосунку на різних конфігураціях пристроїв передбачені команди adb у складі Memory Limiter.

Моніторинг і діагностика проблем з пам'яттю

Оптимізувати те, що неможливо вимірити, — марна справа. Щоб виявляти витоки пам'яті, надмірні виділення в купі та збої через нестачу пам'яті (Out-Of-Memory, OOM) в масштабах усієї екосистеми Android, варто використовувати одразу кілька інструментів моніторингу:

  • Загальний стан застосунку через Android vitals: розділ Android vitals у Google Play Console дає широке уявлення про ситуацію без додаткового навантаження на пристрій. Тут доступні ключові метрики — Memory Usage (сумарно Anonymous RSS та swap) і Bitmap Memory Usage. Це дозволяє побачити розподіл пам'яті між різними станами процесу (передній план, фон, сервіси, що помітні користувачу, та кешовані процеси), а також за класами RAM, і виявити відхилення від норми.
  • Відстеження завершень через Memory Limiter та OOM за допомогою Firebase Crashlytics: щоб дізнаватися про критичне падіння продуктивності через пам'ять ще до того, як це вплине на ключові показники, у Crashlytics версії 20.1.0 з'явилися додаткові діагностичні дані. Вони допомагають виявляти, пріоритизувати та усувати винятки через нестачу пам'яті та завершення процесів через Memory Limiter. Поєднання цих подій із власними логами та метаданими типу ключ-значення дає одразу зрозумілий контекст стану процесу в момент збою.
  • Трасування безпосередньо на пристроях через ProfilingManager: команди, що мають ресурси на побудову власної системи спостережуваності за продуктивністю, можуть скористатися API ProfilingManager, який з'явився в Android 15 (API level 35). Він дозволяє програмно запитувати та отримувати детальні дані для діагностики пам'яті — зокрема дампи Java-купи та профілі — безпосередньо з пристроїв користувачів у продакшені. Захоплення дампів купи можна прив'язати до конкретних системних сигналів, наприклад TRIGGER_TYPE_OOM та TRIGGER_TYPE_ANOMALY.

Про інші методи моніторингу пам'яті детальніше можна прочитати у відповідній документації Android.

Підсумки та наступні кроки

Оскільки Android розширює застосування обмежень пам'яті на всі класи оперативної пам'яті, зараз саме той час, щоб перевірити споживання пам'яті власним застосунком:

  1. Зосередитися на оптимізації пам'яті: захистити застосунок від впливу лімітів, дотримуючись рекомендованих практик.
  2. Налагодити моніторинг: стежити за поведінкою застосунку щодо споживання пам'яті, щоб вчасно виявляти й усувати аномалії.
  3. Оптимізувати ігри: скористатися останніми рекомендаціями для ігор та складних мультимедійних застосунків, щоб максимально заощадити пам'ять у різних станах процесу.

Корисні матеріали та посилання

  • Зміни поведінки в Android 17: обмеження пам'яті застосунків
  • Android Vitals: метрика Memory Usage (RSS + swap) та Bitmap Memory Usage
  • Блог розробників Android: кроки для підвищення ефективності використання пам'яті в Android 17
  • Посібник для розробників: керування пам'яттю застосунку

Джерело: Android Developers Blog