Оцените производительность

Используйте Simpleperf для оценки производительности устройства. Simpleperf — это нативный инструмент профилирования как приложений, так и нативных процессов на Android. Используйте CPU Profiler для проверки использования ЦП приложениями и активности потоков в режиме реального времени.

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

  • Предсказуемая, ощутимая производительность . Происходит ли пропуск кадров в пользовательском интерфейсе (UI) или он стабильно отображается с частотой 60 кадров в секунду? Воспроизводится ли звук без артефактов или щелчков? Какова задержка между касанием пользователем экрана и отображением эффекта на экране?
  • Время, необходимое для выполнения длительных операций (например, открытия приложений).

Первый недостаток заметнее второго. Пользователи обычно замечают задержки, но они не смогут отличить 500 мс от 600 мс времени запуска приложения, если не будут сравнивать два устройства рядом. Задержка сенсорного экрана заметна сразу и существенно влияет на восприятие устройства.

В результате, на быстродействующем устройстве конвейер обработки пользовательского интерфейса является наиболее важным элементом системы, за исключением того, что необходимо для поддержания его работоспособности. Это означает, что конвейер обработки пользовательского интерфейса должен преобладать над любой другой работой, не необходимой для плавной работы интерфейса. Для поддержания плавной работы интерфейса необходимо отложить фоновую синхронизацию, доставку уведомлений и аналогичные задачи, если работа с пользовательским интерфейсом может быть выполнена. Допустимо пожертвовать производительностью более длительных операций (время выполнения HDR+, запуск приложения и т. д.) ради поддержания плавной работы интерфейса.

Пропускная способность против дрожания

При оценке производительности устройства важными показателями являются пропускная способность и дрожание сигнала .

Емкость

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

Производительность системы зависит от доступных вычислительных ресурсов. Основной способ изменения производительности — изменение частоты ЦП/ГП, но существуют и другие, например, изменение количества ядер ЦП. Соответственно, производительность системы связана с энергопотреблением; изменение производительности всегда приводит к аналогичному изменению энергопотребления.

Необходимая в данный момент вычислительная мощность в подавляющем большинстве случаев определяется запущенным приложением. В результате платформа мало что может сделать для корректировки требуемой мощности для конкретной рабочей нагрузки, и средства для этого ограничены улучшениями во время выполнения (фреймворк Android, ART, Bionic, компилятор/драйверы GPU, ядро).

Дрожь

В то время как требуемая производительность для рабочей нагрузки очевидна, дрожание (jitter) — более расплывчатое понятие. Для хорошего ознакомления с дрожанием как препятствием для быстрых систем мы рекомендуем прочитать статью под названием «Случай недостающей производительности суперкомпьютера: достижение оптимальной производительности на 8192 процессорах ASCI Q» . (Это исследование причин, по которым суперкомпьютер ASCI Q не достиг ожидаемой производительности, и оно является отличным введением в оптимизацию больших систем.)

На этой странице термин «дрожание» используется для описания того, что в статье ASCI Q называется шумом . Дрожание — это случайное поведение системы, которое препятствует выполнению заметной работы. Часто это работа, которую необходимо выполнить, но она может не иметь строгих временных требований, которые бы обусловливали её выполнение в определённый момент времени. Поскольку это случайное явление, крайне сложно опровергнуть существование дрожания для данной рабочей нагрузки. Также крайне сложно доказать, что известный источник дрожания был причиной конкретной проблемы с производительностью. Инструменты, наиболее часто используемые для диагностики причин дрожания (такие как трассировка или логирование), могут сами вносить своё дрожание.

Источники нестабильности, наблюдаемые в реальных условиях эксплуатации Android, включают:

  • Задержка планировщика
  • Обработчики прерываний
  • Код драйвера выполняется слишком долго при отключенных прерываниях или вытеснении прерываний.
  • Длительно работающие программные прерывания
  • Конфликт блокировок (приложение, фреймворк, драйвер ядра, блокировка Binder, блокировка mmap)
  • Конфликт дескрипторов файлов, при котором поток с низким приоритетом удерживает блокировку файла, препятствуя выполнению потока с высоким приоритетом.
  • Выполнение критически важного для пользовательского интерфейса кода в очередях задач, где оно может быть отложено.
  • Переходы в режим простоя ЦП
  • Ведение журнала
  • Задержки ввода-вывода
  • Ненужное создание процессов (например, широковещательных сообщений CONNECTIVITY_CHANGE )
  • Чрезмерное использование кэша страниц из-за недостатка свободной памяти

Необходимое время для заданного периода дрожания может уменьшаться или не уменьшаться с увеличением пропускной способности. Например, если драйвер отключает прерывания во время ожидания чтения с шины I2C, это займет фиксированное время независимо от того, работает ли процессор на частоте 384 МГц или 2 ГГц. Увеличение пропускной способности не является целесообразным решением для повышения производительности при наличии дрожания. В результате, более быстрые процессоры обычно не улучшают производительность в условиях ограниченного дрожания.

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

Потребление памяти

Традиционно считается, что причиной низкой производительности является чрезмерное потребление памяти. Хотя само по себе потребление не является проблемой производительности, оно может вызывать колебания производительности из-за накладных расходов lowmemorykiller, перезапусков служб и перегрузки кэша страниц. Сокращение потребления памяти может предотвратить прямые причины низкой производительности, но могут существовать и другие целенаправленные улучшения, которые также позволяют избежать этих причин (например, фиксация фреймворка, чтобы предотвратить его выгрузку в память, если вскоре после этого произойдет его загрузка).

Проанализируйте начальные характеристики устройства.

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

Вместо этого при запуске нового устройства используйте следующий общий подход:

  1. Добейтесь загрузки системы в пользовательский интерфейс со всеми запущенными драйверами и некоторыми базовыми настройками регулятора частоты (если вы измените настройки регулятора частоты, повторите все описанные ниже шаги).
  2. Убедитесь, что ядро ​​поддерживает точку трассировки sched_blocked_reason , а также другие точки трассировки в конвейере отображения, которые указывают на момент доставки кадра на дисплей.
  3. Проведите длительное трассирование всего конвейера пользовательского интерфейса (от получения входных данных через прерывание до окончательного вывода результатов) при запуске легковесной и стабильной рабочей нагрузки (например, UiBench или тест мяча в TouchLatency) .
  4. Устраните обнаруженные пропуски кадров в режиме легкой и стабильной нагрузки.
  5. Повторяйте шаги 3-4, пока не сможете запускать программу без потери кадров в течение 20 и более секунд подряд.
  6. Перейдите к другим видимым пользователю источникам сбоев.

К другим простым действиям, которые можно выполнить на начальном этапе запуска устройства, относятся:

  • Убедитесь, что в вашем ядре установлен патч трассировки sched_blocked_reason . Эта точка трассировки включается с помощью категории трассировки sched в systrace и предоставляет функцию, отвечающую за засыпание, когда поток переходит в режим непрерывного сна. Это критически важно для анализа производительности, поскольку непрерывный сон является очень распространенным индикатором джиттера.
  • Убедитесь, что у вас достаточно трассировки для конвейеров графического процессора и отображения. На последних однокристальных системах Qualcomm точки трассировки включаются с помощью: 
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    Эти события остаются активными при запуске systrace, поэтому вы можете увидеть дополнительную информацию о конвейере отображения (MDSS) в разделе mdss_fb0 в трассировке. На однокристальных системах Qualcomm вы не увидите никакой дополнительной информации о графическом процессоре в стандартном представлении systrace, но результаты присутствуют в самой трассировке (подробнее см. раздел «Понимание systrace» ).

    От такого рода трассировки изображения вам нужен единичный сигнал, непосредственно указывающий на то, что кадр был доставлен на дисплей. Исходя из этого, вы можете определить, удалось ли вам успешно достичь заданного времени кадра; если событие Xn происходит менее чем через 16,7 мс после события Xn -1 (при условии 60 Гц дисплея), то вы знаете, что джиттера не было. Если ваш SOC не предоставляет таких сигналов, обратитесь к поставщику, чтобы получить их. Отладка джиттера крайне сложна без однозначного сигнала о завершении кадра.

Используйте синтетические тесты производительности.

Синтетические тесты полезны для проверки наличия базовой функциональности устройства. Однако рассматривать тесты как косвенный показатель воспринимаемой производительности устройства нецелесообразно.

На основе опыта работы с SOC-системами установлено, что различия в производительности синтетических бенчмарков между различными SOC-системами не коррелируют с аналогичными различиями в ощутимой производительности пользовательского интерфейса (количество потерянных кадров, время кадра в 99-м процентиле и т. д.). Синтетические бенчмарки оценивают только производительность; дрожание сигнала влияет на измеряемую производительность этих бенчмарков только за счет потери времени при выполнении основной операции бенчмарка. В результате, результаты синтетических бенчмарков в основном нерелевантны в качестве показателя производительности, воспринимаемой пользователем.

Рассмотрим две однокристальные системы (SOC), работающие в бенчмарке X, который отображает 1000 кадров пользовательского интерфейса и сообщает общее время рендеринга (чем ниже результат, тем лучше).

  • Процессор SOC 1 обрабатывает каждый кадр в бенчмарке X за 10 мс и набирает 10 000 баллов.
  • Процессор SOC 2 обрабатывает 99% кадров за 1 мс, но только 1% кадров за 100 мс, и набирает 19 900 баллов, что является значительно лучшим результатом.

Если результаты бенчмарка отражают реальную производительность пользовательского интерфейса, то SOC 2 окажется непригодным для использования. При частоте обновления 60 Гц, SOC 2 будет демонстрировать прерывистую работу с каждым 1,5-секундным кадром. В то же время SOC 1 (более медленный SOC по данным Benchmark X) будет работать идеально плавно.

Используйте отчеты об ошибках

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

Используйте TouchLatency

Несколько примеров некорректного поведения связаны с TouchLatency, предпочтительной периодической рабочей нагрузкой, используемой для Pixel и Pixel XL. Она доступна в frameworks/base/tests/TouchLatency и имеет два режима: задержка касания и прыгающий мячик (для переключения режимов нажмите кнопку в правом верхнем углу).

Тест с прыгающим мячиком настолько прост, насколько кажется: мячик бесконечно прыгает по экрану, независимо от действий пользователя. Обычно это также самый сложный тест для идеального выполнения, но чем ближе результат к отсутствию пропущенных кадров, тем лучше будет работать ваше устройство. Сложность теста с прыгающим мячиком заключается в том, что это тривиальная, но идеально стабильная нагрузка, работающая на очень низкой тактовой частоте (это предполагает наличие у устройства регулятора частоты; если устройство работает на фиксированной тактовой частоте, при первом запуске теста с прыгающим мячиком следует снизить тактовую частоту ЦП/ГП почти до минимума). По мере того, как система переходит в режим ожидания и тактовая частота приближается к значению в режиме простоя, требуемое время работы ЦП/ГП на кадр увеличивается. Вы можете наблюдать за мячиком и видеть рывки, а также пропущенные кадры в systrace.

Благодаря стабильной рабочей нагрузке, большинство источников дрожания можно выявить гораздо проще, чем в большинстве видимых пользователю рабочих нагрузок, отслеживая, что именно работает в системе во время каждого пропущенного кадра, а не конвейер пользовательского интерфейса. Более низкие тактовые частоты усиливают эффект дрожания, повышая вероятность того, что любое дрожание приведет к выпадению кадра. В результате, чем ближе TouchLatency к 60 FPS, тем меньше вероятность возникновения некорректного поведения системы, вызывающего спорадические, трудновоспроизводимые рывки в больших приложениях.

Поскольку дрожание сигнала часто (но не всегда) не зависит от тактовой частоты, для диагностики дрожания сигнала используйте тест, работающий на очень низких частотах, по следующим причинам:

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