Тестирование производительности интерфейса позволяет убедиться в том, что ваше приложение не только соответствует функциональным требованиям, но и гарантирует пользователю безупречное взаимодействие с интерфейсом с постоянной частотой отображения 60 кадров в секунду (почему именно 60 кадров/с?), без каких-либо задержек и пропущенных кадров или, как их называют, глюков. В этой статье рассматриваются инструменты для измерения производительности интерфейса, а также предлагается подход к интеграции этих процедур измерения производительности в ваши методы тестирования приложений.
Чтобы улучшить производительность, прежде всего у вас должна иметься возможность измерить производительность вашей системы. Когда это сделано, необходимо диагностировать и определить проблемы, которые могут возникнуть на разных этапах процесса разработки.
dumpsys – это инструмент Android, который запускается на устройстве и создает дамп интересной информации о состоянии системных служб. После передачи в dumpsys команды gfxinfo в журнал устройства (logcat) записываются сведения о производительности, касающиеся скорости анимации на этапе записи.
> adb shell dumpsys gfxinfo <PACKAGE_NAME>
Эта команда может создавать множество различных вариантов данных кадровой синхронизации.
В M Preview эта команда фиксирует в logcat агрегированный анализ данных о кадрах, полученных за весь жизненный цикл процесса. Например:
Stats since: 752958278148ns Total frames rendered: 82189 Janky frames: 35335 (42.99%) 90th percentile: 34ms 95th percentile: 42ms 99th percentile: 69ms Number Missed Vsync: 4706 Number High input latency: 142 Number Slow UI thread: 17270 Number Slow bitmap uploads: 1542 Number Slow draw: 23342
Приведенные выше статистические данные высокого уровня демонстрируют производительность отрисовки, которой обладает приложение, а также ее стабильность при обработке множества кадров.
В M Preview представлена новая команда для gfxinfo – framestats. Она позволяет получить чрезвычайно точную информацию о кадровой синхронизации из последних кадров, что поможет вам отслеживать проблемы и устранять их.
>adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats
Данная команда предоставляет информацию о кадровой синхронизации буквально по наносекундам на основании последних 120 кадров, созданных приложением. Ниже приводится пример необработанного результата из журнала adb после выполнения команды dumpsys gfxinfo <PACKAGE_NAME> framestats:
0,49762224585003,49762241251670,9223372036854775807,0,49762257627204,49762257646058,49762257969704,49762258002100,49762265541631,49762273951162,49762300914808,49762303675954, 0,49762445152142,49762445152142,9223372036854775807,0,49762446678818,49762446705589,49762447268818,49762447388037,49762453551527,49762457134131,49762474889027,49762476150120, 0,49762462118845,49762462118845,9223372036854775807,0,49762462595381,49762462619287,49762462919964,49762462968454,49762476194547,49762476483454,49762480214964,49762480911527, 0,49762479085548,49762479085548,9223372036854775807,0,49762480066370,49762480099339,49762481013089,49762481085850,49762482232152,49762482478350,49762485657620,49762486116683,
Каждая строка здесь представляет собой кадр, созданный приложением. В каждой строке имеется фиксированное количество столбцов, где указано время, затраченное на каждом этапе процесса создания кадра. Более подробно этот формат рассматривается в следующем разделе, включая сведения о том, что означает каждый столбец.
Поскольку блок данных выводится в формате CSV, вы можете с легкостью вставить его в любую программу для работы с электронными таблицами, а также собрать и обработать данные с помощью сценария. Ниже рассматривается формат столбцов выходных данных. Все временные метки указаны в наносекундах.
Эти данные можно использовать несколькими способами. Простым, но полезным примером может служить график, иллюстрирующий распределение времени кадров (FRAME_COMPLETED - INTENDED_VSYNC) в различных диапазонах задержки (см. рисунок ниже). На графике ясно видно, что с большинством кадров никаких проблем не возникло (ниже отметки в 16 мс; обозначено красным), однако для некоторых кадров это значение значительно превышено. Можно обратиться к этому графику и пронаблюдать изменения по времени, чтобы увидеть общую картину смещения или новые отличающиеся значения. Также можно создать график задержи ввода, времени, затраченного на разметку или других интересующих вас показателей, руководствуясь множеством временных меток, имеющихся в данных.
Если в разделе настроек для разработчиков для параметра Profile GPU rendering задано значение In adb shell dumpsys gfxinfo,
команда adb shell dumpsys gfxinfo выдает сведения о синхронизации
по времени для последних 120 кадров. При этом вы увидите несколько категорий значений,
разделенные знаком табуляции. Эти данные могут оказаться полезными для определения частей конвейера отрисовки, которые могут работать с задержкой
при высоком уровне обработки.
Как и в случае с командой framestats, описанной выше, вы можете с легкостью вставить полученные данные в любую программу для работы с электронными таблицами, а также собрать и обработать их с помощью сценария. На графике ниже иллюстрируется разбивка со сведениями о количестве созданных кадров и времени, которое приложение затратило на это.
Результаты выполнения команды gfxinfo, копирования полученного результата, передачи его в приложение для работы с электронными таблицами и построения графика представлены в виде столбцов.
Каждый столбец представляет собой один кадр анимации; его высота обозначает количество миллисекунд, затраченных на вычисление этого кадра. Каждый цветной сегмент столбца обозначает различный этап процесса рендеринга, что позволяет определить проблемные компоненты приложения в плане производительности. Дополнительные сведения о процессе рендеринга, а также о том, как оптимизировать его, представлены в видео, посвященном аннулированию, макетам и производительности.
При выполнении команды framestats, равно как и при вычислении простой кадровой синхронизации, данные собираются за достаточно короткий промежуток времени – порядка двух секунд рендеринга. Чтобы точно указать этот промежуток времени (например, чтобы ограничить данные определенной анимацией), можно сбросить все счетчики и объединить собранные статистические данные.
>adb shell dumpsys gfxinfo <PACKAGE_NAME> reset
Это также можно сделать совместно с выполнением самих команд создания дампа, чтобы выполнять сбор и сброс регулярно, непрерывно получая данные за промежутки времени продолжительностью менее двух секунд.
Определение снижений производительности послужит отличным началом для отслеживания проблем, а также позволит всегда поддерживать хорошую работоспособность приложения. Однако инструмент dumpsys позволяет лишь определить наличие проблем и приблизительный уровень их серьезности. Вам же требуется диагностировать каждую конкретную проблему с производительностью и найти подходящие способы ее устранения. Для этих целей прекрасно подходит инструмент systrace.
Дополнительные сведения о принципе работы конвейера рендеринга платформы Android, информация об общих проблемах, с которыми можно столкнуться при его использовании, а также способы их устранения представлены на указанных ниже полезных ресурсах.
Один из подходов к тестированию производительности интерфейса заключается в простом привлечении тестировщиков, чтобы они выполнили ряд операций с целевым приложением, а также либо просто визуально убедились в отсутствии глюков, либо уделили достаточно много времени тестированию приложения с помощью соответствующего инструмента. Однако такой подход имеет один важный недостаток – человек физически не способен обрабатывать информацию при очень быстрой смене кадров. Кроме того, такая работа занимает много времени, утомляет и не гарантирует полное отсутствие ошибок.
Гораздо эффективнее записать ключевые показатели производительности, полученные в ходе автоматического тестирования интерфейса, и проанализировать их. В состав Android M Developer Preview входят новые функции ведения журналов, которые позволяют с легкостью определить объем и серьезность глюков анимации в приложении. Их также можно использовать для того, чтобы создать строгий процесс определения текущей производительности и отслеживать соответствие требованиям будущих задач производительности.
В этой статье мы расскажем вам, как мы рекомендуем использовать такие данные, чтобы автоматизировать тестирование производительности.
Этот подход большей частью сводится к двум ключевым шагам. Шаг первый: определите, что вы тестируете и как вы это делаете. Шаг второй: произведите настройку среды автоматизированного тестирования и ее обслуживание.
Прежде чем приступить к автоматизированному тестированию, необходимо принять ряд важных решений, чтобы правильно определить область тестирования и ваши требования.
Помните, что плохая производительность чаще всего выражается для пользователей в отсутствии плавной анимации. Поэтому при определении того, какие типы действий в пользовательском интерфейсе следует протестировать, полезно сосредоточить внимание на ключевых анимациях, наиболее важных для взаимодействия пользователя с приложением. Ниже представлены примеры наиболее распространенных сценариев, которые может оказаться полезным определить.
Определите, какие из этих ключевых анимаций следует протестироваит в первую очередь. При принятии решения подключите инженеров, дизайнеров и менеджеров по продукту.
С профессиональной точки зрения, может оказаться крайне важным решить, каких именно показателей производительности вы хотите добиться, и сосредоточить усилия на создании необходимых тестов и сборе соответствующих данных. Например:
Во всех перечисленных случаях вам потребуется хронологическое отслеживание показателей, демонстрирующих производительность разных версий вашего приложения.
Производительность приложения может меняться в зависимости от того, на каком устройстве оно установлено. Некоторые устройства могут обладать недостаточным объемом памяти, менее производительными графическими процессорами или слабыми ЦП. Это означает, что анимации, которые прекрасно работают на устройстве с одним оборудованием, могут вообще не работать на устройстве с другим оборудованием, и, что хуже всего, препятствовать нормальной работе другой части конвейера. Поэтому, учитывая такую разницу в отображении интерфейса для пользователей, выберите диапазон устройств для выполнения тестов, включив в него как современные высокотехнологичные, так и бюджетные устройства, планшеты и т. д. При выборе диапазона устройств учитывайте разницу в производительности ЦП , ОЗУ, разрешение экрана, его размер и т. д. Тесты, которые успешно прошли на устройстве верхнего ценового сегмента, могут завершиться сбоем на бюджетных моделях.
Такие наборы инструментов, как UI Automator и Espresso, призваны помочь автоматизировать действия пользователей при взаимодействии с вашим приложением. Это простые инструменты, имитирующие работу пользователя на устройстве. Для использования этих инструментов вам необходимо создать уникальные сценарии, которые будут включать выполнение ряда действий, и воспроизвести их на устройстве.
Используя эти автоматизированные тесты в сочетании с командой dumpsys gfxinfo, вы можете быстро создать
воспроизводимую систему, позволяющую выполнять тестирование и анализировать
полученную информацию о производительности для каждого определенного условия.
Получив возможность протестировать интерфейс, а также настроив конвейер на сбор результатов отдельного теста, важно выбрать инструмент, который позволит многократно выполнить тест на нескольких устройствах, а также объединить данные о результатах тестирования производительности для их дальнейшего анализа вашими специалистами по разработке.
Следует отметить, что инструменты для тестирования интерфейса (такие как UI Automator) можно запускать прямо на целевом устройстве или в эмуляторе. Тогда как сбор командой dumpsys gfxinfo информации о производительности выполняется на хост-компьютере, который отправляет команды из ADB. Чтобы объединить усилия этих двух инструментов, был разработан MonkeyRunner. Эта система написания сценариев, работающая на хост-компьютере, отправляет команды на подключенные устройства, а также получает данные от них.
Набор сценариев для надлежащей автоматизации тестирования производительности интерфейса должен включать использование системы MonkeyRunner хотя бы для выполнения следующих задач:
После обнаружения проблемных мест или причин снижения производительности необходимо понять, что должно быть исправлено и внести соответствующие изменения. Если используемый инструмент для автоматизированного тестирования обеспечивает соблюдение точной разбивки кадровой синхронизации по времени, то с его помощью можно тщательно изучить недавние подозрительные изменения в коде или макете (в случае со снижением производительности), а также ограничить область системы, которая подлежит анализу, когда вы переключаетесь на изучение проблемы вручную. В последнем случае прекрасно подойдет systrace. С помощью этого инструмента вы можете получить подробнейшую информацию о синхронизации относительно каждого этапа конвейера рендеринга, относительно каждого потока и каждого ядра системы, а также относительно любых настраиваемых маркеров событий, которые вы задаете.
Важно отметить трудности, с которыми можно столкнуться при получении и анализе данных синхронизации, связанных с производительностью визуализации. Результаты по своей природе недетерминированные и зачастую изменяются в зависимости от состояния системы, объема доступной памяти, температурного дросселирования и времени суток. Смысл в том, что вы можете выполнить один и тот же тест дважды и получить результаты, которые будут похожи, но не совпадут в точности.
Правильный сбор и профилирование данных означает выполнение одного и того же теста несколько раз и накопление результатов для вычисления среднего значения (для простоты назовем это пакетом результатов). Это позволяет получить приблизительное представление о производительности теста, когда нет необходимости в точных данных.
Пакеты можно использовать при изучении изменений кода, чтобы увидеть их относительное влияние на производительность. Если средняя частота кадров для пакета результатов, полученных до изменения, больше значения для пакета, полученного после изменения, обычно вы получаете общее повышение производительности в результате этого конкретного изменения.
При выполнении любого автоматизированного тестирования интерфейса следует учитывать этот момент, равно как и любые аномалии, которые могут возникнуть во время теста. Например, если производительность вашего приложения неожиданно резко падает из-за проблем с оборудованием устройства (которые не вызваны вашим приложением), возможно, вы захотите выполнить пакет повторно, чтобы получить менее беспорядочные данные о синхронизации.
Итак, сколько раз следует выполнять тест, прежде чем его результаты станут значимыми? Не менее 10! Чем больше раз вы выполняете тест (например, можно сделать 50–100 прогонов), тем выше точность результатов (хотя, конечно, ради точности приходится поступаться временем).