Вячеслав поделился нюансами потребления памяти Android-сборками, с которыми столкнулся во время расследования проблем на CI. Обсудил, почему инструменты профайлинга JVM, такие как Visual VM, не подходят для анализа некоторых процессов: например, aapt2.
О спикере: Разработчик программного обеспечения в команде Speed. Фокусируется на оптимизации производительности и стабильности CI-системы для мобильных приложений.
00:00 | Начало 00:10 | Вступление 01:00 | Android CI в Авито 02:12 | Flaky-сборки 03:17 | Таблица с Flaky-сборками в рамках дежурства 03:58 | Заметили ошибку на дежурстве 04:12 | Что за verifyResources Gradle Task 05:02 | Avito build trace plugin 05:40 | Perfetto Traceviewer — смотрим build.trace 06:25 | Хотим гипотез — смотрим код Android Gradle Plugin 06:57 | Профилируем потребление памяти JVM-процесса 07:53 | Смотрим код verifyResources-таски дальше 08:51 | AAPT — Android Asset Packaging Tool 09:31 | Используем Docker для сборки Android-приложений 10:14 | Что такое cgroups 10:40 | У каждого контейнера свой лимит памяти 10:55 | Смотрим k8s-метрики для отдельного котейнера 11:55 | Как понять, что проблема уйдет, если увеличим память 12:27 | Добавили логи ядра, поймали момент воспроизведения ошибки 12:50 | Превышение лимита → OOMKiller 14:37 | Это касается некоторых других Flaky-проблем 14:58 | Что в итоге 15:30 | Хотим упреждать такие аварии 15:49 | Смотрим в системный монитор во время сборки 16:03 | Записываем трейсы с помощью Perfetto 16:52 | Добавляем tracing процессов во время сборки 17:12 | Смотрим trace 17:20 | SQL-запрос, смотрим потребление во время сборки 18:23 | Хотим знать, что пришёл OOMKiller 18:45 | Финальный итог 19:40 | Ответы на вопросы