![](https://habrastorage.org/getpro/habr/upload_files/c13/8fa/5e7/c138fa5e7298d4afb0c91411c021be23.png)
Разработав инструмент для визуализации RAM и zRAM в Android, я обнаружила, что в телефонах происходит активная конкуренция за ресурсы. И если процессу понадобятся ресурсы, которые уже заняты кем-то другим, он отберет их, что может привести к критическим ситуациям и конфликтам оборудования.
Пользовались ли вы когда-нибудь такими утилитами как htop, top, vmstat? Если у вас вообще установлен Linux, то скорее всего да. И они действительно хорошо показывают статистику использования ресурсов в ОС. Я исследовала операционные системы, и мне не хватало понимания того, как реально выглядит физическое адресное пространство: какие конкретно адреса заняты, какие свободны, что происходит, если процессы запрашивают одни и те же адреса, как часто это происходит.
Была гипотеза, что в Android (и в Linux), возникает активная конкуренция за ресурсы. Спойлер из названия статьи: она подтвердилась.
Я разработала приложение, визуализирующее размещение процессов в памяти в телефонах с операционной системой Android. Данные считываются для каждой страницы памяти для выбранного процесса. Эти данные также можно дополнительно обработать. Разработанный инструмент позволяет пользователю исследовать как оперативную память, так и ZRAM, отображать полученную информацию в графическом виде. Пользователь может выбрать процессы из дерева cgroups.
Главное окно приложения выглядит следующим образом. Далее будет рассмотрена именно карта памяти, которая отображается по центру.
![](https://habrastorage.org/getpro/habr/upload_files/43e/9a9/246/43e9a924653c9d721cb98d936b9b0fc1.jpeg)
Немного теории
Управление памятью в Android является частью функциональности ядра Linux. Ядро имеет полный доступ к системной памяти и позволяет процессам безопасно обращаться к этой памяти по мере необходимости. Приложениям требуется много ресурсов, и поэтому диагностика, анализ и отладка используются для оптимального выделения ресурсов для приложений. Понимание динамики перераспределения памяти может дать гораздо более четкую картину системы. Между тем, мобильные операционные системы имеют больше ограничений, связанных с аппаратным и программным обеспечением, по сравнению с настольными операционными системами.
Управление памятью в ОС Android организовано с помощью страниц размером 4 КБ. Ядро отслеживает состояние каждой страницы физической памяти, представленной в системе.
Я исследовала методы управления памятью в Android и Linux и сравнила доступные инструменты для проверки и мониторинга памяти. Нет инструментов, которые могли бы визуализировать картину. А также трудно интерпретировать числа, поэтому я ввела качественный индикатор и отобразила карту памяти постранично.
apagescan собирает информацию о распределении памяти между несколькими процессами, затем создает снимки памяти и фиксирует динамические изменения памяти. apagescan работает с procFS для чтения любого количества страниц в оперативной памяти, предоставляя информацию о каждой странице, включая флаги present/swapped/dirty и anon/not anon.
Каждая страница может находиться в одном из следующих состояний:
Present / not Present: Текущая страница отображается на страницу в физической памяти. Если страница не present, ее можно свапнуть (переместить) на диск.
Dirty / Clean: Грязные (dirty) страницы - это страницы, которые были изменены, поскольку они были выгружены в физическую память из дисковой памяти и ожидают записи обратно на диск. Чистые (clean) страницы - это страницы, которые не были модифицированы процессом.
Named / Anonymous: Именованные (named) чистые страницы могут быть восстановлены из специального файла. Анонимные (anonymous) страницы поддерживаются разделом подкачки (swap) или физической памятью. Анонимные чистые страницы могут быть восстановлены из /dev/zero.
Также пользователи могут выбирать процессы из cgroups для проверки. cgroups это механизм для группировки процессов на уровне ядра.
Полученные снимки памяти
На Nexus 5 были запущены три приложения, которые использовались в общей сложности в течение двух минут, в то время как apagescan собирал данные с задержкой 0 сек. между измерениями. Было сделано 60 снимков физической памяти. Каждый квадрат (точка) на рисунке это страница в памяти телефона. Черной жирной линией внизу рисунков отделен раздел подкачки.
В эксперименте использовались приложения камеры (синий цвет - 5837 PID), браузера (цвет фуксии - 5307 PID) и галереи (зеленый цвет - 5390 PID). На рис. ниже представлено начальное состояние памяти, когда использовалось приложение браузера, а другие приложения находились в фоновом режиме. Большая часть оперативной памяти занята браузером и гораздо меньше - камерой и галереей. Также отсутствуют страницы в области подкачки.
![Рисунок 1 - Снимок физической памяти. Браузер находится на переднем плане, галерея и камера - на заднем. Рисунок 1 - Снимок физической памяти. Браузер находится на переднем плане, галерея и камера - на заднем.](https://habrastorage.org/getpro/habr/upload_files/510/cf0/1e8/510cf01e8ae6fbf733dd6f59aaf2e6d9.jpeg)
Во время работы браузера произошли некоторые изменения в отображении памяти, но они стали заметны только тогда, когда приложение браузера перешло в фоновый режим и было выбрано приложение камеры (см. рис. 2). Некоторые страницы были вытеснены страницами камеры, но большинство из них остались на своих местах, а страницы камеры просто заняли свободное место.
![Рисунок 2 - Снимок физической памяти. Камера находится на переднем плане, галерея и браузер - на заднем. Рисунок 2 - Снимок физической памяти. Камера находится на переднем плане, галерея и браузер - на заднем.](https://habrastorage.org/getpro/habr/upload_files/595/e67/3e7/595e673e78d4e9ea9e71861a3986b9ef.jpeg)
На рис. 3-4 показана «конкуренция» между приложениями камеры и галереи (красная область) и процесс вытеснения страниц, когда приложение переходит в фоновый режим (синяя область). То есть на рисунках видно, как разные приложения обращаются к одним и тем же участкам памяти (точки на графиках перекрывают друг друга). И тестирование различных приложений, позволило мне увидеть, что конкуренция за ресурсы происходит достаточно часто. Особенно, если ресурсов не очень много, что, конечно, справедливо для мобильных телефонов.
![Рисунок 3 - Снимок физической памяти. Галерея находится на переднем плане, камера и браузер - на заднем плане. Рисунок 3 - Снимок физической памяти. Галерея находится на переднем плане, камера и браузер - на заднем плане.](https://habrastorage.org/getpro/habr/upload_files/b8c/b23/352/b8cb233521081bbebba005a4d7a7fd56.jpeg)
![Рисунок 4 - Снимок физической памяти. Камера находится на переднем плане, галерея и браузер - на заднем плане. Рисунок 4 - Снимок физической памяти. Камера находится на переднем плане, галерея и браузер - на заднем плане.](https://habrastorage.org/getpro/habr/upload_files/fad/e78/72d/fade7872d5495ba068846a8c43b43e52.jpeg)
Выводы
Знание об активной конкуренции за память в Android, может пригодиться как при разработке мобильных приложений, так и областей, связанных с планированием ресурсов в ОС Android (и Linux). Когда один процесс запрашивает ресурсы, которые уже заняты кем-то другим, первый просто отберет их. Это может привести к бесконечному переключению контекста во время нехватки ресурсов, а также к критическим ситуациям и конфликтам оборудования. При этом выявление того, как приложения борются за ресурсы, позволяет оптимизировать систему целиком.