Планирование производительности

Статья
08/25/2023

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

Указание целей

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

Другие метрики имеют менее очевидное влияние на взаимодействие с пользователем, например память. Вероятность завершения приложения при приостановке или неактивном росте объема памяти, используемого активным приложением. Это общее правило, что высокая загрузка памяти ухудшает работу для всех приложений в системе, поэтому наличие цели на потребление памяти разумно. Учитывайте грубый размер приложения, который воспринимается пользователями: малый, средний или большой. Ожидания вокруг производительности соотносятся с этим восприятием. Например, может потребоваться небольшое приложение, которое не использует много носителей для использования менее 100 МБ памяти.

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

Time

Думайте о допустимых диапазонах истекшего времени (классов взаимодействия) для выполнения задач в приложении. Для каждого класса взаимодействия назначьте метку, воспринимаемую тональность пользователя, а также идеальную и максимальную длительность. Ниже приведены некоторые предложения.

Метка класса взаимодействия	Восприятие пользователей	Идеально подходит	Максимум	Примеры
Быстро	Минимальная заметная задержка	100 миллисекунд	200 миллисекунда	Откройте панель приложения; Нажмите кнопку (первый ответ)
"Typical" (Стандартный)	Быстрая, но не быстрая	300 миллисекунда	500 миллисекунда	Изменения размера; семантический масштаб
Адаптивный интерфейс	Не быстро, но чувствует себя адаптивным	500 миллисекунда	1 с	Перейдите на другую страницу; возобновление приложения из приостановленного состояния
Launch	Конкурентный опыт	1 с	3 секунды	Запуск приложения в первый раз или после его завершения
Непрерывные	Больше не чувствует себя адаптивным	500 миллисекунда	5 секунд	Скачивание файла из Интернета
Плен	Длинные; пользователь может отключиться	500 миллисекунда	10 seconds	Установка нескольких приложений из Магазина

Теперь вы можете назначить классы взаимодействия сценариям производительности приложения. Вы можете назначить ссылку на точку времени приложения, часть пользовательского интерфейса и класс взаимодействия для каждого сценария. Ниже приведены некоторые предложения для примера продуктов питания и столового приложения.

Сценарий	Точка времени	Взаимодействие с пользователем	Класс взаимодействия
Перейдите на страницу рецепта	Первый ответ	Анимация перехода страницы запущена	Fast (100-200 миллисекундах)
	Адаптивный интерфейс	Список ингредиентов загружен; нет изображений	Адаптивная (500 миллисекунд - 1 секунда)
	Видимый полный	Все загруженное содержимое; изображения, показанные	Непрерывный (500 миллисекунд - 5 секунд)
Поиск рецепта	Первый ответ	Нажмите кнопку поиска	Fast (100 – 200 миллисекунда)
Поиск рецепта	Видимый полный	Список названий локальных рецептов	Типичная (300 – 500 миллисекундах)

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

С указанными целями теперь вы сможете протестировать, проанализировать и оптимизировать приложение.

Текучесть

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

Нет перерисовки экрана остановок и запусков (сбои).
Анимация отрисовывается в 60 кадров в секунду (FPS).
Когда пользователь сдвигает или прокручивает прокрутку, приложение представляет 3-6 страниц содержимого в секунду.

Эффективность

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

Для процесса приложения процент ЦП находится ниже или ниже N, а использование памяти в МБ находится в или ниже M в любое время.
Если приложение неактивно, N и M равны нулю для процесса приложения.
Ваше приложение может активно использоваться в течение X часов в заряде батареи; если ваше приложение неактивно, устройство сохраняет свою плату в течение Y часов.

Проектирование приложения для повышения производительности

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

Пользовательский интерфейс

Максимальное увеличение эффективности анализа и загрузки и эффективности памяти для каждой страницы пользовательского интерфейса приложения (особенно начальной страницы), оптимизируя разметку XAML. Вкратце отложите загрузку пользовательского интерфейса и кода до тех пор, пока не потребуется.
Для ListView и GridView сделайте все элементы одинаковым размером и используйте столько методов оптимизации ListView и GridView, сколько можно.
Объявите пользовательский интерфейс в виде разметки, которую платформа может загружать и повторно использовать в блоках, а не создавать ее императивно в коде.
Отложите создание элементов пользовательского интерфейса до тех пор, пока они не понадобятся пользователю. См. атрибут x:Load.
Предпочитайте переходы тем и анимации раскадровки анимаций. Дополнительные сведения см. в обзоре анимации. Помните, что раскадровки анимации требуют постоянных обновлений на экране, а также активного ЦП и графического конвейера. Чтобы сохранить батарею, не выполняйте анимацию, если пользователь не взаимодействует с приложением.
Загруженные изображения должны быть загружены по размеру, соответствующему представлению, в котором вы представляете его, с помощью метода GetThumbnailAsync.

ЦП, память и питание

Планирование работы с более низким приоритетом для выполнения в потоках с более низким приоритетом и (или) ядрах. См. асинхронное программирование, свойство Диспетчера и класс CoreDispatcher.
Свести к минимуму объем памяти приложения, освобождая дорогостоящие ресурсы (например, носители) при приостановке.
Свести к минимуму рабочий набор кода.
Избегайте утечки памяти, отменяя регистрацию обработчиков событий и разоменовывание элементов пользовательского интерфейса по возможности.
Ради батареи следует быть консервативным с тем, как часто вы опрашивуете данные, запрашиваете датчик или планируете работу на ЦП при простое.

Доступ к данным

Если это возможно, предварительное получение содержимого. Сведения о автоматической предварительной выборке см. в классе ContentPrefetcher. Сведения о предварительной выборке вручную см. в пространстве имен Windows.ApplicationModel.Background и классе MaintenanceTrigger.
Если это возможно, кэшируйте содержимое, которое дорого для доступа. См. свойства LocalFolder и Local Параметры.
При отсутствии кэша отображается пользовательский интерфейс заполнителя как можно быстрее, что указывает, что приложение по-прежнему загружает содержимое. Переход от заполнителя к динамическому содержимому таким образом, что пользователь не является jarring. Например, не изменяйте положение содержимого под пальцем пользователя или указателем мыши, так как приложение загружает динамическое содержимое.

Запуск и возобновление приложения

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

Адаптивный пользовательский интерфейс и ориентация

Используйте класс VisualStateManager.
Завершайте только требуемую работу немедленно, отложение интенсивной работы приложения до более поздней версии— приложение имеет от 200 до 800 миллисекунд, чтобы завершить работу, прежде чем пользователь увидит пользовательский интерфейс приложения в обрезаном состоянии.

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

Инструмент для производительности

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

Универсальная платформа Windows (UWP) предоставляет API ведения журнала, поддерживаемые трассировкой событий для Windows (ETW), которые вместе предлагают расширенное решение для ведения журнала событий и трассировки. API- интерфейсы, которые входят в пространство имен Windows.Foundation.Diagnostics, включают классы FileLoggingSession, LoggingActivity, LoggingChannel и LoggingSession.

Чтобы записать сообщение в отчет в определенной точке во время работы приложения, создайте объект LogChannel, а затем вызовите метод LogMessage объекта, как показано ниже.

// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here' s my logged message.");

// ...

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

// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...

См. также пример ведения журнала.

С помощью инструментированного приложения можно протестировать и оценить производительность приложения.

Тестирование и измерение в отношении целей производительности

Часть плана производительности — определить точки во время разработки, где вы будете измерять производительность. Это служит различным целям в зависимости от того, измеряете ли вы во время прототипирования, разработки или развертывания. Измерение производительности во время ранних этапов прототипа может быть чрезвычайно ценным, поэтому мы рекомендуем сделать это, как только у вас есть код, который делает значимую работу. Ранние измерения дают вам хорошее представление о том, где важные затраты находятся в приложении, и информирование о принятии решений по проектированию. Это приводит к высокой производительности и масштабированию приложений. Как правило, это дороже, чтобы изменить конструкции позже, чем раньше. Измерение производительности в конце цикла продукта может привести к взломам в последнюю минуту и низкой производительности.

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

Тестирование на широкий спектр аппаратных конфигураций, включая все одно и настольные компьютеры, ноутбуки, ультрабуки и планшеты и другие мобильные устройства.
Проверка на широкий спектр размеров экрана. В то время как более широкие размеры экрана могут отображать гораздо больше содержимого, в результате чего все это дополнительное содержимое может негативно повлиять на производительность.
Исключите столько переменных тестирования, сколько можно.
- Отключите фоновые приложения на тестовом устройстве. Для этого в Windows выберите Параметры на экране блокировки персонализации>меню . > Выберите каждое активное приложение и выберите "Нет".
- Скомпилируйте приложение в машинный код, создав его в конфигурации выпуска перед развертыванием на тестовом устройстве.
- Чтобы убедиться, что автоматическое обслуживание не влияет на производительность тестового устройства, активируйте его вручную и дождитесь завершения. В Windows в меню выполните поиск по запросу "Безопасность и обслуживание". В области обслуживания в разделе "Автоматическое обслуживание" выберите "Начать обслуживание" и подождите, пока состояние будет изменено с текущего обслуживания.
- Запустите приложение несколько раз, чтобы устранить переменные случайного тестирования и обеспечить согласованность измерений.
Проверка снижения доступности питания. Устройство пользователей может значительно меньше мощности, чем компьютер разработки. Windows была разработана с низкой мощностью устройств, таких как мобильные устройства, в виду. Приложения, которые выполняются на платформе, должны обеспечить их производительность на этих устройствах. Как эвристика, ожидается, что низкое питание устройства работает примерно в четверти скорости компьютера настольного компьютера и задайте свои цели соответствующим образом.
Используйте сочетание таких средств, как Microsoft Visual Studio и Windows Анализатор производительности для измерения производительности приложения. Visual Studio предназначен для предоставления анализа, ориентированного на приложения, например связывания исходного кода. Windows Анализатор производительности предназначен для обеспечения системного анализа, например предоставления системных сведений, сведений о событиях обработки сенсорного ввода-вывода, а также сведений о затратах на ввод и вывод диска (I/O) и единицу обработки графики (GPU). Оба средства предоставляют запись трассировки и экспорт, а также могут повторно открывать общие и после смерти трассировки.
Перед отправкой своего приложения на сертификацию в Store убедитесь, что в ваши планы тестирования включены связанные с производительностью тестовые случаи, как описано в тестах комплекта сертификации приложений для Windows и разделе "Производительность и надежность" тестовых случаев приложений UWP.

Дополнительные сведения см. в этих ресурсах и средствах профилирования.

Windows Performance Analyzer
Набор средств для оценки производительности Windows
Анализ производительности с помощью средств диагностики Visual Studio
Производительность XAML //build/session

Ответ на результаты теста производительности

После анализа результатов теста производительности определите, необходимы ли какие-либо изменения, например:

Следует ли изменить какие-либо решения по проектированию приложений или оптимизировать код?
Следует ли добавлять, удалять или изменять инструментирование в коде?
Следует ли пересмотреть какие-либо из ваших целей производительности?

Если необходимы какие-либо изменения, внесите их, а затем вернитесь к инструментированию или тестированию и повторите.

Оптимизация

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