Если приложение на Android тормозит, жрёт батарею или падает с OutOfMemoryError, первое действие разработчика — открыть Android Profiler в Android Studio и посмотреть, что происходит с CPU, памятью и сетью в реальном времени. Встроенный профилировщик показывает потребление ресурсов без сторонних инструментов и помогает найти узкие места ещё до релиза.
В этом материале разберём, как запустить профилировщик, какие метрики он собирает, как читать графики и на что обращать внимание при поиске утечек памяти и лагов интерфейса. Инструкция ориентирована на актуальные версии Android Studio, но общие принципы работают и в более ранних выпусках среды.
Что такое Android Profiler и зачем он нужен
Android Profiler — это встроенный в Android Studio набор инструментов мониторинга, который отображает данные о работе приложения в реальном времени. Он заменил устаревший инструмент Android Monitor и стал стандартным способом диагностики производительности.
Профилировщик собирает данные с устройства или эмулятора, на котором запущено отлаживаемое приложение, и выводит их в виде временной шкалы. Вы видите, как меняется нагрузка на процессор, сколько памяти выделено, какие сетевые запросы выполняются и сколько энергии потребляет приложение.
- 🔍 Поиск утечек памяти и анализ кучи (heap dump)
- 📈 Мониторинг загрузки CPU и записи метод-трейсов
- 🌐 Анализ сетевых запросов и объёма трафика
- 🔋 Оценка энергопотребления и фоновых событий
Как открыть профилировщик
Запустить профилирование можно двумя способами. Первый — обычный запуск приложения в режиме отладки через Run → Debug, после чего внизу среды откройте вкладку Profiler. Второй — профилирование уже запущенного процесса: View → Tool Windows → Profiler, затем нажмите плюс и выберите устройство и процесс приложения.
Для корректной работы нужно устройство с включённой отладкой по USB или эмулятор. Учтите, что точность и набор доступных функций могут зависеть от версии Android на устройстве и от того, собран ли проект в debug-конфигурации. Release-сборки с обфускацией профилировать сложнее — имена методов будут искажены.
⚠️ Внимание: профилирование само по себе добавляет накладные расходы. Измерения на подключённом профилировщике могут показывать чуть худшие результаты, чем реальная работа приложения. Делайте выводы по относительным изменениям, а не по абсолютным цифрам.
Вкладка CPU: анализ загрузки процессора
Раздел CPU Profiler показывает загрузку процессора вашим приложением и системой в целом, а также количество активных потоков. Резкие пики на графике — кандидаты на оптимизацию: возможно, тяжёлая операция выполняется в главном потоке.
Главная возможность раздела — запись трейса методов. Нажмите Record, выберите тип записи (например, Sample Java Methods или Trace Java Methods), выполните проблемное действие в приложении и остановите запись. Профилировщик покажет дерево вызовов: какие методы выполнялись, сколько времени занял каждый и кто их вызывал.
Результаты можно просматривать в нескольких представлениях: Call Chart (временная диаграмма вызовов), Flame Chart (огненная диаграмма, удобная для поиска самых «горячих» путей), Top Down и Bottom Up (таблицы с суммарным временем методов). Начинать анализ удобнее всего с Flame Chart — широкие «полосы» сразу показывают, где тратится больше всего времени.
Вкладка Memory: память и утечки
Memory Profiler отображает график потребления памяти с разбивкой по категориям: Java, Native, Graphics, Stack и другие. Здесь же видны события сборки мусора и кнопка принудительного запуска GC.
Ключевой сценарий — поиск утечек памяти. Типичный признак: после повторного открытия и закрытия одного и того же экрана объём занятой памяти не возвращается к исходному уровню даже после сборки мусора. Чтобы подтвердить утечку, сделайте heap dump — снимок кучи — и изучите список объектов: сколько экземпляров Activity или Fragment живёт в памяти, хотя должно быть уничтожено.
При анализе дампа обращайте внимание на колонки Allocations (число выделений), Shallow Size (собственный размер объекта) и Retained Size (размер с учётом удерживаемых объектов). Большой Retained Size у «мёртвых» Activity почти всегда указывает на утечку — например, через статическую ссылку, незакрытый колбэк или долгоживущий поток.
| Раздел | Что показывает | Типичная задача |
|---|---|---|
| CPU | Загрузка процессора, потоки, трейсы методов | Поиск медленных методов |
| Memory | Категории памяти, аллокации, heap dump | Поиск утечек памяти |
| Network | Трафик, запросы, коды ответов | Оптимизация запросов |
| Energy | События, влияющие на батарею | Снижение энергопотребления |
Вкладки Network и Energy
Network Profiler строит график входящего и исходящего трафика и показывает список сетевых запросов на временной шкале. Выбрав конкретный запрос, вы увидите детали: заголовки, тело ответа, время выполнения. Это помогает находить дублирующиеся запросы, слишком большие ответы и отсутствие кэширования.
Energy Profiler отслеживает события, которые влияют на расход батареи: wake locks, задания JobScheduler, сетевую активность и использование GPS. Точное энергопотребление в милливаттах он не измеряет — инструмент показывает именно события и их длительность, чтобы вы могли оценить, какие части приложения держат устройство «в awake-состоянии».
⚠️ Внимание: данные Energy Profiler на эмуляторе носят условный характер. Для оценки реального влияния на батарею тестируйте на физическом устройстве.
Пошаговый сценарий: находим причину лагов интерфейса
Типичная задача — экран приложения «фризит» при прокрутке списка. Порядок действий с профилировщиком выглядит так:
☑️ Диагностика лагов UI через Profiler
Если в трейсе видно, что в главном потоке выполняется парсинг JSON, запрос к базе данных или декодирование больших изображений — причина найдена. Перенесите операцию в фоновый поток (корутины, RxJava, WorkManager — в зависимости от архитектуры проекта) и сделайте контрольный замер.
Что делать, если профилировщик не видит процесс
Проверьте, что устройство определяется через adb (команда adb devices), что приложение собрано в debug-варианте и что в настройках разработчика включена отладка по USB. Иногда помогает перезапуск Android Studio или смена USB-порта. На некоторых устройствах требуется дополнительное разрешение на отладку в системном диалоге.
Типичные ошибки при профилировании
Первая ошибка — делать выводы по одному замеру. Производительность зависит от состояния устройства: температуры, фоновых процессов, заряда батареи. Повторяйте замеры несколько раз и сравнивайте среднюю картину.
Вторая — профилировать release-сборку с включённой обфускацией и удивляться нечитаемым именам методов. Для диагностики используйте debug-сборку, а для финальной проверки — специальный profileable-вариант, если ваш проект его поддерживает.
Третья — игнорировать накладные расходы самого профилировщика: запись трейса методов замедляет выполнение, поэтому абсолютные значения времени в трейсе завышены. Сравнивайте методы между собой внутри одного трейса, а не с реальным временем работы приложения.
FAQ: частые вопросы
Можно ли профилировать release-сборку приложения?
Частично. Начиная с определённых версий Android поддерживаются profileable-сборки, которые позволяют собирать данные без полного debug-режима. Однако обфускация кода затрудняет чтение трейсов, поэтому для глубокого анализа удобнее debug-вариант.
Почему график памяти постоянно растёт, а потом резко падает?
Это нормальное поведение: память накапливается, пока не сработает сборщик мусора, после чего график падает. Тревожный признак — когда «дно» после каждой сборки мусора становится всё выше при повторении одних и тех же действий. Это указывает на возможную утечку.
Чем Android Profiler отличается от библиотеки LeakCanary?
Profiler — универсальный инструмент ручного анализа: вы сами делаете снимки кучи и ищете утечки. LeakCanary автоматически обнаруживает утечки Activity и Fragment во время отладки и показывает цепочку ссылок. Они дополняют друг друга: LeakCanary находит проблему, Profiler помогает разобраться в деталях.
Работает ли профилировщик на эмуляторе?
Да, все основные разделы работают на эмуляторе. Но данные по CPU и энергопотреблению будут отличаться от реального устройства, поэтому финальные выводы о производительности делайте на физическом девайсе.
Как сохранить результаты профилирования?
Записанные сессии (трейсы CPU, heap dump) можно экспортировать через контекстное меню сессии в панели Profiler и позже импортировать обратно для сравнения «до» и «после» оптимизации.