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

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

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

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

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

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

Время

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

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

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

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

Текучесть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

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

// ...

Чтобы регистрировать события запуска и остановки в отчете за период времени во время работы приложения, создайте объект logActivity 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). Оба инструмента предоставляют сбор и экспорт трассировок, а также могут повторно открывать общие и пост-мортем трассировки.
• Перед отправкой приложения в Магазин для сертификации обязательно включите в планы тестирования тестовые случаи, связанные с производительностью, как это описано в разделе "Тесты производительности" комплекта сертификации приложений Windows и в разделе "Производительность и стабильность" тестовых случаев приложений UWP .

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

• анализатор производительности Windows
• Набор средств для оценки производительности Windows
• Анализ производительности с помощью средств диагностики Visual Studio
• Сессия «//build/»: Производительность XAML
• Сессия //build/ Новые инструменты XAML в Visual Studio 2015

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

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

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

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

Оптимизация

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