Примеры измерения и анализа производительности,Примеры измерения и анализа производительности,Примеры измерения и анализа производительности,Примеры измерения и анализа производительности

В этих примерах показано, как использовать трассировку системы с помощью Macrobenchmark вместе с профилированием памяти для измерения и устранения определенных видов проблем с производительностью.

Отладка запуска приложения с помощью systrace

При отладке времени запуска мы рекомендуем использовать журналы systrace. Systrace — это система, которая использует предварительно оснащенный код для вывода информации о том, сколько времени занимают определенные события, когда они происходят. Эти трассировки позволяют вам видеть, что происходит в вашем приложении или даже в других процессах в системе. Платформа Android и библиотеки Jetpack имеют инструменты для обработки многих ключевых событий в приложении, которые соответствующим образом протоколируются. Вы также можете оснастить свои приложения собственными трассировками, которые будут отображаться в тех же инструментах визуализации systrace, чтобы дать общую картину того, что произошло в приложении.

Использование systrace или Perfetto

Дополнительные сведения об основах использования systrace см. в следующем видеоролике: Отладка производительности приложений .

Чтобы проанализировать время запуска, вы должны сначала понять, что происходит во время запуска. Если вам нужна дополнительная информация, кроме той, что описана на этой странице, документация по времени запуска приложения содержит обзор процесса запуска приложения.

Этапы запуска приложения:

• Запустить процесс
• Инициализация универсальных объектов приложения
• Создать и инициализировать активность
• Раздувание макета
• Рисуем первый кадр

Типы стартапов имеют следующие этапы:

• Холодный старт: это происходит, когда приложение запускается впервые после загрузки или когда процесс приложения был остановлен пользователем или системой. При запуске создается новый процесс без сохраненного состояния .
• Теплый старт: это происходит, когда приложение уже работает в фоновом режиме, но действие необходимо воссоздать и перенести на передний план. Действие либо воссоздается при повторном использовании существующего процесса, либо процесс воссоздается с сохраненным состоянием. Библиотека тестирования Macrobenchmark поддерживает последовательное тестирование при «горячем» запуске с использованием первого варианта.
• Горячий старт: это происходит, когда процесс и действие все еще выполняются, и их просто нужно вывести на передний план, возможно, при необходимости воссоздав некоторые объекты, а также отрисовав новое действие на переднем плане. Это самый короткий сценарий запуска.

Мы рекомендуем собирать системные трассировки с помощью встроенного в устройство приложения для отслеживания системы, доступного в разделе «Параметры разработчика» . Если вы хотите использовать инструменты командной строки, Perfetto доступен для использования с Android 10 (уровень API 29) и выше, тогда как устройства более ранних версий должны использовать systrace .

Обратите внимание, что термин «первый кадр» употребляется несколько неправильно, поскольку приложения могут значительно различаться по тому, как они обрабатывают запуск после создания первоначального действия. Некоторые приложения будут продолжать инфляцию в течение нескольких кадров, а другие даже сразу перейдут на второстепенную активность.

По возможности мы рекомендуем включать вызов reportFullyDrawn (доступен на Android 10 и более поздних версиях) после завершения запуска с точки зрения приложения.

В этих системных трассировках следует искать следующие вещи:

Рисунок 1. Конкуренция за ресурсы, защищенные монитором, может привести к значительной задержке запуска приложения.

Рисунок 2. Найдите ненужные транзакции на критическом пути вашего приложения.

Рисунок 3. Параллельная сборка мусора является обычным явлением и оказывает относительно небольшое влияние, но если вы с ней сталкиваетесь, часто рассмотрите возможность ее изучения с помощью профилировщика памяти Android Studio.

Рис. 4. Проверка ввода-вывода во время запуска и поиск длительных зависаний.

Обратите внимание на рисунок 4: другие процессы, выполняющие ввод-вывод одновременно, могут вызвать конфликты ввода-вывода, поэтому убедитесь, что другие процессы не запущены.

Значительная активность в других потоках может помешать потоку пользовательского интерфейса, поэтому следите за фоновой работой во время запуска. Обратите внимание, что устройства могут иметь разные конфигурации ЦП, поэтому количество потоков, которые могут выполняться параллельно, может различаться в зависимости от устройства.

Также ознакомьтесь с руководством по распространенным источникам мусора.

Используйте профилировщик памяти Android Studio

Профилировщик памяти Android Studio — это мощный инструмент для уменьшения нехватки памяти, которая может быть вызвана утечками памяти или неправильным использованием. Он обеспечивает просмотр распределения и коллекций объектов в реальном времени.

Чтобы устранить проблемы с памятью в вашем приложении, вы можете использовать профилировщик памяти, чтобы отслеживать, почему и как часто происходят сборки мусора, а также возможные утечки памяти, приводящие к постоянному увеличению кучи с течением времени.

Профилирование памяти приложения разбивается на следующие этапы:

1. Обнаружение проблем с памятью

Чтобы обнаружить проблемы с памятью, начните с записи сеанса профилирования памяти для вашего приложения. Затем найдите объект, объем памяти которого увеличивается, что в конечном итоге вызывает событие сборки мусора.

Рисунок 5. Профилировщик памяти, показывающий увеличение выделения объектов с течением времени.

Рисунок 6. Профилировщик памяти, показывающий события сборки мусора.{.:image-caption}

После того как вы определили вариант использования, который увеличивает нагрузку на память, начните анализировать основные причины.

2. Диагностика горячих точек нехватки памяти

Выберите диапазон на временной шкале, чтобы визуализировать как распределение, так и небольшой размер.

Рисунок 7. Профилировщик памяти, показывающий распределение и размеры для выбранного диапазона на временной шкале.

Существует несколько способов сортировки этих данных. В следующих разделах приведены некоторые примеры того, как каждое представление может помочь вам проанализировать проблемы.

Распределить по классам

Упорядочение по классам полезно, когда вы хотите найти классы, генерирующие объекты, которые в противном случае следует кэшировать или повторно использовать из пула памяти.

Например, представьте, что вы видите приложение, создающее 2000 объектов класса Vertex каждую секунду. Это увеличит количество выделений на 2000 каждую секунду, и вы увидите это при сортировке по классу. Следует ли повторно использовать такие объекты, чтобы избежать создания мусора? Если ответ положительный, то, вероятно, потребуется реализация пула памяти.

Примечание. В целом пулы объектов не обязательно являются рекомендуемым подходом; в большинстве случаев лучше просто выделить нужные вам объекты. В некоторых ограниченных ситуациях, таких как объекты, инициализация которых очень дорога, объединение объектов в пулы может быть выгодным, но обязательно профилируйте и измерьте, чтобы увидеть, стоит ли это, прежде чем принимать и реализовывать в своем коде.

Упорядочить по стеку вызовов

Упорядочение с помощью стека вызовов полезно, когда существует «горячий» путь выделения памяти, например, внутри цикла или определенной функции, выполняющей много работы по распределению. Просмотр по стеку вызовов позволит вам увидеть эти горячие точки распределения.

Мелкий или сохраненный размер

Малый размер отслеживает только память самого объекта, поэтому он наиболее полезен для отслеживания простых классов, состоящих в основном из примитивов.

Сохраненный размер показывает общий объем памяти, выделенный объектом напрямую, а также другие выделенные объекты, на которые ссылается только этот объект. Это полезно для отслеживания нехватки памяти из-за сложных объектов, которые требуют выделения других объектов, а не только примитивных полей. Чтобы получить это значение, создайте дамп памяти с помощью профилировщика памяти. Объекты, размещенные в этой куче, добавляются на экран.

Рисунок 8. Вы можете создать дамп памяти в любое время, нажав кнопку «Дамп кучи Java» на панели инструментов профилировщика памяти.

Рисунок 9. При создании дампа памяти отображается столбец, показывающий распределение объектов в этой куче.

3. Измерьте влияние оптимизации

Одним из улучшений оптимизации памяти, которое легко измерить, является сбор мусора. Когда оптимизация снижает нагрузку на память, вы должны увидеть меньше сборок мусора (GC). Чтобы измерить это, измерьте время между сборками мусора на временной шкале профилировщика. После оптимизации памяти вы должны увидеть более длительные интервалы между сборками мусора.

Конечным результатом таких улучшений памяти является:

• Приложение будет закрываться реже из-за проблем с нехваткой памяти, если приложение не испытывает постоянной нехватки памяти.
• Меньшее количество сборщиков мусора улучшает показатели мусора. Это связано с тем, что сборщики мусора вызывают конфликт ЦП, что может привести к отсрочке задач рендеринга во время выполнения сборщика мусора.

{% дословно %} {% endverbatim %} ,

В этих примерах показано, как использовать трассировку системы с помощью Macrobenchmark вместе с профилированием памяти для измерения и устранения определенных видов проблем с производительностью.

Отладка запуска приложения с помощью systrace

При отладке времени запуска мы рекомендуем использовать журналы systrace. Systrace — это система, которая использует предварительно оснащенный код для вывода информации о том, сколько времени занимают определенные события, когда они происходят. Эти трассировки позволяют вам видеть, что происходит в вашем приложении или даже в других процессах в системе. Платформа Android и библиотеки Jetpack имеют инструменты для обработки многих ключевых событий в приложении, которые соответствующим образом протоколируются. Вы также можете оснастить свои приложения собственными трассировками, которые будут отображаться в тех же инструментах визуализации systrace, чтобы дать общую картину того, что произошло в приложении.

Использование systrace или Perfetto

Дополнительные сведения об основах использования systrace см. в следующем видеоролике: Отладка производительности приложений .

Чтобы проанализировать время запуска, вы должны сначала понять, что происходит во время запуска. Если вам нужна дополнительная информация, кроме той, что описана на этой странице, документация по времени запуска приложения содержит обзор процесса запуска приложения.

Этапы запуска приложения:

• Запустить процесс
• Инициализация универсальных объектов приложения
• Создать и инициализировать активность
• Раздувание макета
• Рисуем первый кадр

Типы стартапов имеют следующие этапы:

• Холодный запуск: это происходит, когда приложение запускается впервые после загрузки или когда процесс приложения был остановлен пользователем или системой. При запуске создается новый процесс без сохраненного состояния .
• Теплый старт: это происходит, когда приложение уже работает в фоновом режиме, но действие необходимо воссоздать и перенести на передний план. Действие либо воссоздается при повторном использовании существующего процесса, либо процесс воссоздается с сохраненным состоянием. Библиотека тестирования Macrobenchmark поддерживает последовательное тестирование при «горячем» запуске с использованием первого варианта.
• Горячий старт: это происходит, когда процесс и действие все еще выполняются, и их просто нужно вывести на передний план, возможно, при необходимости воссоздав некоторые объекты, а также отрисовав новое действие на переднем плане. Это самый короткий сценарий запуска.

Мы рекомендуем захватывать системные трассировки с помощью встроенного в устройство приложения для отслеживания системы, доступного в разделе «Параметры разработчика» . Если вы хотите использовать инструменты командной строки, Perfetto доступен для использования с Android 10 (уровень API 29) и выше, тогда как устройства более ранних версий должны использовать systrace .

Обратите внимание, что термин «первый кадр» употребляется несколько неправильно, поскольку приложения могут значительно различаться по тому, как они обрабатывают запуск после создания первоначального действия. Некоторые приложения будут продолжать инфляцию в течение нескольких кадров, а другие даже сразу перейдут на второстепенную активность.

По возможности мы рекомендуем включать вызов reportFullyDrawn (доступен на Android 10 и более поздних версиях) после завершения запуска с точки зрения приложения.

В этих системных трассировках следует искать следующие вещи:

Рисунок 1. Конкуренция за ресурсы, защищенные монитором, может привести к значительной задержке запуска приложения.

Рисунок 2. Найдите ненужные транзакции на критическом пути вашего приложения.

Рисунок 3. Параллельная сборка мусора является обычным явлением и оказывает относительно небольшое влияние, но если вы с ней сталкиваетесь, часто рассмотрите возможность ее изучения с помощью профилировщика памяти Android Studio.

Рис. 4. Проверка ввода-вывода во время запуска и поиск длительных зависаний.

Обратите внимание на рисунок 4: другие процессы, выполняющие ввод-вывод одновременно, могут вызвать конфликты ввода-вывода, поэтому убедитесь, что другие процессы не запущены.

Значительная активность в других потоках может помешать потоку пользовательского интерфейса, поэтому следите за фоновой работой во время запуска. Обратите внимание, что устройства могут иметь разные конфигурации ЦП, поэтому количество потоков, которые могут выполняться параллельно, может различаться в зависимости от устройства.

Также ознакомьтесь с руководством по распространенным источникам мусора.

Используйте профилировщик памяти Android Studio

Профилировщик памяти Android Studio — это мощный инструмент для уменьшения нехватки памяти, которая может быть вызвана утечками памяти или неправильным использованием. Он обеспечивает просмотр распределения и коллекций объектов в реальном времени.

Чтобы устранить проблемы с памятью в вашем приложении, вы можете использовать профилировщик памяти, чтобы отслеживать, почему и как часто происходят сборки мусора, а также возможные утечки памяти, приводящие к постоянному увеличению кучи с течением времени.

Профилирование памяти приложения разбивается на следующие этапы:

1. Обнаружение проблем с памятью

Чтобы обнаружить проблемы с памятью, начните с записи сеанса профилирования памяти для вашего приложения. Затем найдите объект, объем памяти которого увеличивается, что в конечном итоге вызывает событие сборки мусора.

Рисунок 5. Профилировщик памяти, показывающий увеличение выделения объектов с течением времени.

Рисунок 6. Профилировщик памяти, показывающий события сборки мусора.{.:image-caption}

После того как вы определили вариант использования, который увеличивает нагрузку на память, начните анализировать основные причины.

2. Диагностика горячих точек нехватки памяти

Выберите диапазон на временной шкале, чтобы визуализировать как распределение, так и небольшой размер.

Рисунок 7. Профилировщик памяти, показывающий распределение и размеры для выбранного диапазона на временной шкале.

Существует несколько способов сортировки этих данных. В следующих разделах приведены некоторые примеры того, как каждое представление может помочь вам проанализировать проблемы.

Распределить по классам

Упорядочение по классам полезно, когда вы хотите найти классы, генерирующие объекты, которые в противном случае следует кэшировать или повторно использовать из пула памяти.

Например, представьте, что вы видите приложение, создающее 2000 объектов класса Vertex каждую секунду. Это увеличит количество выделений на 2000 каждую секунду, и вы увидите это при сортировке по классу. Следует ли повторно использовать такие объекты, чтобы избежать создания мусора? Если ответ положительный, то, скорее всего, потребуется реализация пула памяти.

Примечание. В целом пулы объектов не обязательно являются рекомендуемым подходом; в большинстве случаев лучше просто выделить нужные вам объекты. В некоторых ограниченных ситуациях, таких как объекты, инициализация которых очень дорога, объединение объектов в пулы может быть полезным, но обязательно профилируйте и измерьте, чтобы увидеть, стоит ли это, прежде чем принимать и реализовывать в своем коде.

Упорядочить по стеку вызовов

Упорядочение с помощью стека вызовов полезно, когда существует «горячий» путь выделения памяти, например, внутри цикла или определенной функции, выполняющей много работы по распределению. Просмотр по стеку вызовов позволит вам увидеть эти горячие точки распределения.

Мелкий или сохраненный размер

Малый размер отслеживает только память самого объекта, поэтому он наиболее полезен для отслеживания простых классов, состоящих в основном из примитивов.

Сохраненный размер показывает общий объем памяти, выделенный объектом напрямую, а также другие выделенные объекты, на которые ссылается только этот объект. Это полезно для отслеживания нехватки памяти из-за сложных объектов, которые требуют выделения других объектов, а не только примитивных полей. Чтобы получить это значение, создайте дамп памяти с помощью профилировщика памяти. Объекты, размещенные в этой куче, добавляются на экран.

Рисунок 8. Вы можете создать дамп памяти в любое время, нажав кнопку «Дамп кучи Java» на панели инструментов профилировщика памяти.

Рисунок 9. При создании дампа памяти отображается столбец, показывающий распределение объектов в этой куче.

3. Измерьте влияние оптимизации

Одним из улучшений оптимизации памяти, которое легко измерить, является сбор мусора. Когда оптимизация снижает нагрузку на память, вы должны увидеть меньше сборок мусора (GC). Чтобы измерить это, измерьте время между сборками мусора на временной шкале профилировщика. После оптимизации памяти вы должны увидеть более длительные интервалы между сборками мусора.

Конечным результатом таких улучшений памяти является:

• Приложение будет реже закрываться из-за проблем с нехваткой памяти, если приложение не испытывает постоянной нехватки памяти.
• Меньшее количество сборщиков мусора улучшает показатели мусора. Это связано с тем, что сборщики мусора вызывают конфликт ЦП, что может привести к отсрочке задач рендеринга во время выполнения сборщика мусора.

{% дословно %} {% endverbatim %} ,

В этих примерах показано, как использовать трассировку системы с помощью Macrobenchmark вместе с профилированием памяти для измерения и устранения определенных видов проблем с производительностью.

Отладка запуска приложения с помощью systrace

При отладке времени запуска мы рекомендуем использовать журналы systrace. Systrace — это система, которая использует предварительно оснащенный код для вывода информации о том, сколько времени занимают определенные события, когда они происходят. Эти трассировки позволяют вам видеть, что происходит в вашем приложении или даже в других процессах в системе. Платформа Android и библиотеки Jetpack имеют инструменты для обработки многих ключевых событий в приложении, которые соответствующим образом протоколируются. Вы также можете оснастить свои приложения собственными трассировками, которые будут отображаться в тех же инструментах визуализации systrace, чтобы дать общую картину того, что произошло в приложении.

Использование systrace или Perfetto

Дополнительные сведения об основах использования systrace см. в следующем видеоролике: Отладка производительности приложений .

Чтобы проанализировать время запуска, вы должны сначала понять, что происходит во время запуска. Если вам нужна дополнительная информация, кроме той, что описана на этой странице, документация по времени запуска приложения содержит обзор процесса запуска приложения.

Этапы запуска приложения:

• Запустить процесс
• Инициализация универсальных объектов приложения
• Создать и инициализировать активность
• Раздувание макета
• Рисуем первый кадр

Типы стартапов имеют следующие этапы:

• Холодный старт: это происходит, когда приложение запускается впервые после загрузки или когда процесс приложения был остановлен пользователем или системой. При запуске создается новый процесс без сохраненного состояния .
• Теплый старт: это происходит, когда приложение уже работает в фоновом режиме, но действие необходимо воссоздать и перенести на передний план. Действие либо воссоздается при повторном использовании существующего процесса, либо процесс воссоздается с сохраненным состоянием. Библиотека тестирования Macrobenchmark поддерживает последовательное тестирование «горячего» запуска с использованием первого варианта.
• Горячий старт: это происходит, когда процесс и действие все еще выполняются, и их просто нужно вывести на передний план, возможно, при необходимости воссоздав некоторые объекты, а также отрисовав новое действие на переднем плане. Это самый короткий сценарий запуска.

Мы рекомендуем собирать системные трассировки с помощью встроенного в устройство приложения для отслеживания системы, доступного в разделе «Параметры разработчика» . Если вы хотите использовать инструменты командной строки, Perfetto доступен для использования с Android 10 (уровень API 29) и выше, тогда как устройства более ранних версий должны использовать systrace .

Обратите внимание, что термин «первый кадр» употребляется несколько неправильно, поскольку приложения могут значительно различаться по тому, как они обрабатывают запуск после создания первоначального действия. Некоторые приложения будут продолжать инфляцию в течение нескольких кадров, а другие даже сразу перейдут на второстепенную активность.

По возможности мы рекомендуем включать вызов reportFullyDrawn (доступен на Android 10 и более поздних версиях) после завершения запуска с точки зрения приложения.

В этих системных трассировках следует искать следующие вещи:

Рисунок 1. Конкуренция за ресурсы, защищенные монитором, может привести к значительной задержке запуска приложения.

Рисунок 2. Найдите ненужные транзакции на критическом пути вашего приложения.

Рисунок 3. Параллельная сборка мусора распространена и оказывает относительно небольшое влияние, но если вы с ней сталкиваетесь, часто рассмотрите возможность исследования ее с помощью профилировщика памяти Android Studio.

Рисунок 4. Проверка ввода-вывода во время запуска и поиск длительных зависаний.

Обратите внимание на рисунок 4: другие процессы, выполняющие ввод-вывод одновременно, могут вызвать конфликты ввода-вывода, поэтому убедитесь, что другие процессы не запущены.

Значительная активность в других потоках может помешать потоку пользовательского интерфейса, поэтому следите за фоновой работой во время запуска. Обратите внимание, что устройства могут иметь разные конфигурации ЦП, поэтому количество потоков, которые могут выполняться параллельно, может различаться в зависимости от устройства.

Также ознакомьтесь с руководством по распространенным источникам мусора.

Используйте профилировщик памяти Android Studio

Профилировщик памяти Android Studio — это мощный инструмент для уменьшения нехватки памяти, которая может быть вызвана утечками памяти или неправильным использованием. Он обеспечивает просмотр распределения и коллекций объектов в реальном времени.

Чтобы устранить проблемы с памятью в вашем приложении, вы можете использовать профилировщик памяти, чтобы отслеживать, почему и как часто происходят сборки мусора, а также возможные утечки памяти, приводящие к постоянному увеличению кучи с течением времени.

Профилирование памяти приложения разбивается на следующие этапы:

1. Обнаружение проблем с памятью

Чтобы обнаружить проблемы с памятью, начните с записи сеанса профилирования памяти для вашего приложения. Затем найдите объект, объем памяти которого увеличивается, что в конечном итоге вызывает событие сборки мусора.

Рисунок 5. Профилировщик памяти, показывающий увеличение выделения объектов с течением времени.

Рисунок 6. Профилировщик памяти, показывающий события сборки мусора.{.:image-caption}

После того как вы определили вариант использования, который увеличивает нагрузку на память, начните анализировать основные причины.

2. Диагностика горячих точек нехватки памяти

Выберите диапазон на временной шкале, чтобы визуализировать как распределение, так и небольшой размер.

Рисунок 7. Профилировщик памяти, показывающий распределение и размеры для выбранного диапазона на временной шкале.

Существует несколько способов сортировки этих данных. В следующих разделах приведены некоторые примеры того, как каждое представление может помочь вам проанализировать проблемы.

Распределить по классам

Упорядочение по классам полезно, когда вы хотите найти классы, генерирующие объекты, которые в противном случае следует кэшировать или повторно использовать из пула памяти.

Например, представьте, что вы видите приложение, создающее 2000 объектов класса Vertex каждую секунду. Это увеличит количество выделений на 2000 каждую секунду, и вы увидите это при сортировке по классу. Следует ли повторно использовать такие объекты, чтобы избежать создания мусора? Если ответ положительный, то, вероятно, потребуется реализация пула памяти.

Примечание. В целом пулы объектов не обязательно являются рекомендуемым подходом; в большинстве случаев лучше просто выделить нужные вам объекты. В некоторых ограниченных ситуациях, таких как объекты, инициализация которых очень дорога, объединение объектов в пулы может быть полезным, но обязательно профилируйте и измерьте, чтобы увидеть, стоит ли это, прежде чем принимать и реализовывать в своем коде.

Упорядочить по стеку вызовов

Упорядочение с помощью стека вызовов полезно, когда существует «горячий» путь выделения памяти, например, внутри цикла или определенной функции, выполняющей много работы по распределению. Просмотр по стеку вызовов позволит вам увидеть эти горячие точки распределения.

Мелкий или сохраненный размер

Малый размер отслеживает только память самого объекта, поэтому он наиболее полезен для отслеживания простых классов, состоящих в основном из примитивов.

Сохраненный размер показывает общий объем памяти, выделенный объектом напрямую, а также другие выделенные объекты, на которые ссылается только этот объект. Это полезно для отслеживания нехватки памяти из-за сложных объектов, которые требуют выделения других объектов, а не только примитивных полей. Чтобы получить это значение, создайте дамп памяти с помощью профилировщика памяти. Объекты, размещенные в этой куче, добавляются на экран.

Рисунок 8. Вы можете создать дамп памяти в любое время, нажав кнопку «Дамп кучи Java» на панели инструментов профилировщика памяти.

Рисунок 9. При создании дампа памяти отображается столбец, показывающий распределение объектов в этой куче.

3. Измерьте влияние оптимизации

Одним из улучшений оптимизации памяти, которое легко измерить, является сбор мусора. Когда оптимизация снижает нагрузку на память, вы должны увидеть меньше сборок мусора (GC). Чтобы измерить это, измерьте время между сборками мусора на временной шкале профилировщика. После оптимизации памяти вы должны увидеть более длительные интервалы между сборками мусора.

Конечным результатом таких улучшений памяти является:

• Приложение будет реже закрываться из-за проблем с нехваткой памяти, если приложение не испытывает постоянной нехватки памяти.
• Меньшее количество сборщиков мусора улучшает показатели мусора. Это связано с тем, что сборщики мусора вызывают конфликт ЦП, что может привести к отсрочке задач рендеринга во время выполнения сборщика мусора.

{% дословно %} {% endverbatim %} ,

В этих примерах показано, как использовать трассировку системы с помощью Macrobenchmark вместе с профилированием памяти для измерения и устранения определенных видов проблем с производительностью.

Отладка запуска приложения с помощью systrace

При отладке времени запуска мы рекомендуем использовать журналы systrace. Systrace — это система, которая использует предварительно оснащенный код для вывода информации о том, сколько времени занимают определенные события, когда они происходят. Эти трассировки позволяют вам видеть, что происходит в вашем приложении или даже в других процессах в системе. Платформа Android и библиотеки Jetpack имеют инструменты для обработки многих ключевых событий в приложении, которые соответствующим образом протоколируются. Вы также можете оснастить свои приложения собственными трассировками, которые будут отображаться в тех же инструментах визуализации systrace, чтобы дать общую картину того, что произошло в приложении.

Использование systrace или Perfetto

Дополнительные сведения об основах использования systrace см. в следующем видеоролике: Отладка производительности приложений .

Чтобы проанализировать время запуска, вы должны сначала понять, что происходит во время запуска. Если вам нужна дополнительная информация, кроме той, что описана на этой странице, документация по времени запуска приложения содержит обзор процесса запуска приложения.

Этапы запуска приложения:

• Запустить процесс
• Инициализация универсальных объектов приложения
• Создать и инициализировать активность
• Раздувание макета
• Рисуем первый кадр

Типы стартапов имеют следующие этапы:

• Холодный старт: это происходит, когда приложение запускается впервые после загрузки или когда процесс приложения был завершен пользователем или системой. При запуске создается новый процесс без сохраненного состояния .
• Теплый старт: это происходит, когда приложение уже работает в фоновом режиме, но действие необходимо воссоздать и перенести на передний план. Действие либо воссоздается при повторном использовании существующего процесса, либо процесс воссоздается с сохраненным состоянием. Библиотека тестирования Macrobenchmark поддерживает последовательное тестирование при «горячем» запуске с использованием первого варианта.
• Горячий старт: это происходит, когда процесс и действие все еще выполняются, и их просто нужно вывести на передний план, возможно, при необходимости воссоздав некоторые объекты, а также отрисовав новое действие на переднем плане. Это самый короткий сценарий запуска.

Мы рекомендуем собирать системные трассировки с помощью встроенного в устройство приложения для отслеживания системы, доступного в разделе «Параметры разработчика» . Если вы хотите использовать инструменты командной строки, Perfetto доступен для использования с Android 10 (уровень API 29) и выше, тогда как устройства более ранних версий должны использовать systrace .

Обратите внимание, что термин «первый кадр» употребляется несколько неправильно, поскольку приложения могут значительно различаться по тому, как они обрабатывают запуск после создания первоначального действия. Некоторые приложения будут продолжать инфляцию в течение нескольких кадров, а другие даже сразу перейдут на второстепенную активность.

По возможности мы рекомендуем включать вызов reportFullyDrawn (доступен на Android 10 и более поздних версиях) после завершения запуска с точки зрения приложения.

В этих системных трассировках следует искать следующие вещи:

Рисунок 1. Конкуренция за ресурсы, защищенные монитором, может привести к значительной задержке запуска приложения.

Рисунок 2. Найдите ненужные транзакции на критическом пути вашего приложения.

Рисунок 3. Параллельная сборка мусора распространена и оказывает относительно небольшое влияние, но если вы с ней сталкиваетесь, часто рассмотрите возможность исследования ее с помощью профилировщика памяти Android Studio.

Рис. 4. Проверка ввода-вывода во время запуска и поиск длительных зависаний.

Обратите внимание на рисунок 4: другие процессы, выполняющие ввод-вывод одновременно, могут вызвать конфликты ввода-вывода, поэтому убедитесь, что другие процессы не запущены.

Значительная активность в других потоках может помешать потоку пользовательского интерфейса, поэтому следите за фоновой работой во время запуска. Обратите внимание, что устройства могут иметь разные конфигурации ЦП, поэтому количество потоков, которые могут выполняться параллельно, может различаться в зависимости от устройства.

Также ознакомьтесь с руководством по распространенным источникам мусора.

Используйте профилировщик памяти Android Studio

Профилировщик памяти Android Studio — это мощный инструмент для уменьшения нехватки памяти, которая может быть вызвана утечками памяти или неправильными шаблонами использования. Он обеспечивает просмотр распределения и коллекций объектов в реальном времени.

Чтобы устранить проблемы с памятью в вашем приложении, вы можете использовать профилировщик памяти, чтобы отслеживать, почему и как часто происходят сборки мусора, а также возможные утечки памяти, приводящие к постоянному увеличению кучи с течением времени.

Профилирование памяти приложения разбивается на следующие этапы:

1. Обнаружение проблем с памятью

Чтобы обнаружить проблемы с памятью, начните с записи сеанса профилирования памяти для вашего приложения. Затем найдите объект, объем памяти которого увеличивается, что в конечном итоге вызывает событие сборки мусора.

Рисунок 5. Профилировщик памяти, показывающий увеличение выделения объектов с течением времени.

Рисунок 6. Профилировщик памяти, показывающий события сборки мусора.{.:image-caption}

После того как вы определили вариант использования, который увеличивает нагрузку на память, начните анализировать основные причины.

2. Диагностика горячих точек нехватки памяти

Выберите диапазон на временной шкале, чтобы визуализировать как распределение, так и небольшой размер.

Рисунок 7. Профилировщик памяти, показывающий выделения и размеры для выбранного диапазона на временной шкале.

Существует несколько способов сортировки этих данных. В следующих разделах приведены некоторые примеры того, как каждое представление может помочь вам проанализировать проблемы.

Распределить по классам

Упорядочение по классам полезно, когда вы хотите найти классы, генерирующие объекты, которые в противном случае следует кэшировать или повторно использовать из пула памяти.

Например, представьте, что вы видите приложение, создающее 2000 объектов класса Vertex каждую секунду. Это увеличит количество выделений на 2000 каждую секунду, и вы увидите это при сортировке по классу. Следует ли повторно использовать такие объекты, чтобы избежать создания мусора? Если ответ положительный, то, скорее всего, потребуется реализация пула памяти.

Примечание. В целом пулы объектов не обязательно являются рекомендуемым подходом; в большинстве случаев лучше просто выделить нужные вам объекты. В некоторых ограниченных ситуациях, таких как объекты, которые очень дороги для инициализации, объединение объектов может быть выгодным, но обязательно профилируйте и измеряйте, чтобы увидеть, стоит ли оно, прежде чем предположить и реализовать в вашем коде.

Договориться по Callstack

Организация с помощью CallStack полезно, когда есть горячий путь, где распределяется память, например, внутри цикла или определенная функция, выполняющая большую работу по распределению. Просмотр с помощью CallStack позволит вам увидеть эти горячие точки распределения.

Неглубокий против оставшегося размера

Небольшой размер отслеживает только память самого объекта, поэтому он наиболее полезен для отслеживания простых классов, состоящих в основном из примитивов.

Оставленный размер показывает общую память, выделенную объектом непосредственно, а также другие выделенные объекты, которые ссылаются исключительно объектом. Это полезно для отслеживания давления памяти из -за сложных объектов, которые требуют распределения других объектов, а не только примитивных полей. Чтобы получить это значение, создайте дамп памяти, используя профилировщик памяти. Объекты, выделенные в этой куче, добавляются на дисплей.

Рисунок 8. Вы можете создать дамп памяти в любое время, нажав на кнопку «Куча Java» на панели инструментов профилировщика памяти.

Рисунок 9. Скрещивание дампа памяти отображает столбец, показывающий распределения объектов в этой куче.

3. Измерьте влияние оптимизации

Улучшение оптимизации памяти, которое легко измерить, - это сбор мусора. Когда оптимизация снижает давление в памяти, вы должны увидеть меньше коллекций мусора (GCS). Чтобы измерить это, измерьте время между GCS на временной шкале Profiler. Вы должны увидеть более длительные продолжительности между GCS после оптимизации памяти.

Конечное влияние улучшений памяти, таких как это:

• Приложение будет убито реже из -за проблем с памятью, если приложение не будет постоянно испытывать давление в памяти.
• Наличие меньшего количества GCS улучшает метрики Jank. Это связано с тем, что GCS вызывает конфликт ЦП, что может привести к отложению задач, когда происходит GC.

{% дословно %} {% дословно %}