{31 день с Mango} День 24: Инструмент профилирования

Это День 24 в серии статей 31 день с Mango (перевод оригинальной серии 31 Days of Mango), и был написан приглашенным автором Chris Koenig. Вы можете найти Chris в твиттере @chriskoenig.
Производительность является важным аспектом всех приложений, особенно для приложений, которые работают на ограниченных ресурсах, на мобильных устройствах зависящих от сети. Пользователю сравнительно легко сказать, что работающее приложение «медленное», но не так-то просто выявиь причину проблем с производительностью. Внесение изменений в исходный код, не понимая влияние на производительность, может привести к ненужному рефакторингу и потенциально усугубить проблему.
Что же делать? С выпуском Windows Phone «Mango», мы можем легко определить источник проблем с производительностью нашего приложения — вплоть до функций, которые вызывают у вас вопросы. Войдите в инструмент Windows Phone Profiler. Вы можете использовать новый Windows Phone Profiler для выявления проблем с производительностью приложений, включая потребление памяти, эффективность визуальной иерархии, время запуска приложения, а также выявление продолжительно выполняющихся функций.
Чтобы запустить сессию анализа производительности, откройте проект Windows Phone в Visual Studio и выберите «Start Windows Phone Performance Analysis» в меню Debug или нажмите комбинацию клавиш Alt-F1:

Удостоверьтесь, что вы запускаете Windows Phone Profiler, а не. NET Profiler, который находится в меню Debug и указан как “Start performance analysis (ALT-F2)”.
Первое, что вы увидите — на странице вам будет задан вопрос для выбора вида анализа, который вы хотите сделать. Если вы не знаете точно, есть ли проблема потребления памяти, вы всегда должны начинать с анализа Execution:

При нажатии на ссылку «Launch Application» приложение запустится на эмуляторе или соответствующем устройстве с автоматическим добавлением к вашей сессии всех средств мониторинга кода. После запуска приложения, перемещайтесь по приложению для выполнения тех функций вашего приложения, которые являются наиболее критичным или которые будут наиболее часто использованы пользователями. Когда вы будете проходиться по вашему приложению в нужных местах, отслеживаемая информация будет автоматически собраться и записываться Visual Studio для последующего просмотра.
После того как сессия тестирования завершится, вернитесь к Visual Studio и нажмите на ссылку «Stop Profiling»:

В этот момент Visual Studio начнет сохранять все данные профиля производительности в файл SAP и добавит этот файл к вашему проекту. Этот файл будет привязан к вашему проекту вместе с датой и временем тестирования (например в таком виде: DatabaseForMango_2011_11_14_17_59_27.sap). Эта запись может быть просмотрена сейчас, или сохранена для последующего просмотра. Основной вид результатов — это множество представленных графиков. Эти графики представляют собой ряд различных измерений, которые находятся друг под другом, чтобы создать временную диаграму производительности вашего приложения.

Начиная с верхнего, эти графики показывают:
Frame Rate (Частота кадров): показывает частоту фреймов для каждого фрейма отрендеренного в пользовательском интерфейсе. Низкие значения здесь являются потенциально слабым местом и требуют дополнительного изучения.
CPU Usage % (Использование Центрального Процессора %): Показывает загрузку процессора в различных частях приложения
— Зеленые столбики представляют собой поток пользовательского интерфейса — это одно из того, за чем следует наблюдать, так как активное использование потока пользовательского интерфейса является причиной того, что интерфейс перестает отвечать на запросы на ввод данных от пользователя. Любые значения более чем 50% являются потенциально проблемной зоной.
— Синие столбики представляют собой потоки приложения — это включает и созданные пользователем фоновые потоки и составной поток (чем выше значение, тем лучше, по сравнению с потоком пользовательского интерфейса).
— Серые столбики представляют системные потоки — это потоки, которые НЕ являются частью вашего приложения, но представляют собой фоновые задачи и т.д.
— Белые столбики представляют потоки ожидания — такие, как «System Idle Process» в диспетчере задач Windows, это представляет собой доступный процент производительности процессора. Большее значение означает более чуткое реагирование пользовательского интерфейса.
Memory Usage in MB (Использование памяти в Мб):Обратите на это внимание, если вы имеете значения больше, чем 90 Мб в любом месте и запустите другой тест — 90 Мб это предельное значение для успешной сертификации приложения в Маркетплейс.
Storyboards (Раскадровка): S отображается в каждом фрейме, где запускается раскадровка.
— Красной показывает раскадровки, зависящие от Центрального Процессора (это плохо, как они выполняются на потоке процессора и это непосредственно влияет на производительность пользовательского интерфейса)
— Фиолетовый представляет раскадровки связанные с GPU (это хорошо, как они выполняются в композиционном потоке и не влияют на производительность пользовательского интерфейса).
Image Loads (Загрузка Изображений): Значком «I» отмечается момент на графике, в который изображение загружается в память.
Garbage Collection Events(Выполнение сборщика мусора): Значком «G» отмечается момент, в которой запускается сборщик мусора.

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

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

Внимание: Очень низкая частота фреймов потенциально вызванных высокими издержками трассировки.
Общее время трассировки (0, 35 секунды) очень высоко.  Элемент System.Windows.Controls.ScrollViewer : ScrollViewer потратил больше всего времени при трассировке и вносит свой вклад в низкую частоту кадров.  Это может быть потому, что зависящая от Центрального Процессора анимация вызывает обновление трассировки. Перейдите в меню Performance Warnings в панели навигации и выберите вид Frames.  Отсортируйте фреймы, нажав заголовок столбеца CPU Time и выберите фреймы с наибольшим процессорным временем. На виде Frames выберите опцию Visual Tree и визуально найдите System.Windows.Controls.ScrollViewer: ScrollViewer в этом дереве.

Это предупреждение вызвано низкой частотой кадров и зависит от того как трассировка построена по отношению к ScrollViewer. Предлагаемое решение показывает, что мы должны углубиться в меню Performance Warnings и выбрать вид Frames. Если вы внимательно посмотрите на раздел Detailed Performance, вы увидите, что рядом с пунктом Performance Warnings есть кнопка, которая управляет всплывающим меню, содержащим несколько вариантов, в которые мы можем «углубиться» за дополнительной информацией.  Если вы выберете вариант «Frames» , вы увидите что-то вроде этого:

Этот список фактически выбранных кадров показывает, что многие из них имеют загрузку процессора более чем 50% — в данном случае есть даже один с более чем 80%! Если выбрать фрейм и вернуться в навигационное меню рядом c пунктом Frames, о котором говорилось ранее,  можно видеть, что доступны еще несколько уровней детализации для этого конкретного фрейма. Выберете отдельный фрейм, чтобы получить дополнительную информацию о том, что происходит с конкретным фреймом. Взгляд на такие элементы, как опция Functions позволит вам увидеть, какие методы вызываются в вашем приложении, и предоставит вам ссылки на ваш исходный код для этих методов в приложениии, которые выполняются. Вы также можете посмотреть на визуальную иерархию, типы элементов и кэш обновлений. Эти сообщения об ошибках, в сочетании с прямыми указаниями на то, где искать проблемы и инструменты дающие возможность вам углубиться в корень проблемы, что дает вам большой обзор внутри вашего приложения, чтобы обнаружить потенциально проблемные места и исправить их перед отправкой для сертификации в Маркетплейс.
Теперь, когда мы увидели, как этот инструмент работает, несколько советов по его использования, что поможет ускориться вам на вашем пути к эффективному применению:
— Начните с выполнения тестов производительности (Execution Performance), чтобы увидеть есть ли какие-либо проблемы с памятью, о чем свидетельствует график использования памяти (Memory Usage ). Если вы обнаружили места внутри вашего приложения, которые потребляют более 90 Мб оперативной памяти, запустите второй тест, сфокусированный на настройки памяти (Memory). Вы обнаружите, что обычно любые проблемы производительности могут быть диагностированы первым тестом, поэтому использование второго теста оправдано только когда проблема касается памяти.
— Не забудьте протестировать быстрое переключение приложений, захоранивание и соответствующие процессы активации — все это важные части вашего приложения. Чтобы заставить ваше приложение захораниваться, когда вы нажимаете кнопку Пуск, зайдите в свойства проекта во вкладку Debug и отметьте параметр “Tombstone upon deactivation while debugging”. В противном случае, по-умолчанию ваше приложение использует быстрое переключение между приложениями.
— Всегда тестируйте производительность на устройстве — производительность вашего компьютера не сравнима с производительность устройства. Это восходит к старой аксиоме тестирования: «это приложение создано для работы не на вашем компьютере». Устройство Windows Phone является обладает более ограниченными ресурсами, чем типичная рабочая станция, поэтому порблемы с памятью и производительностью, более вероятны на устройстве, чем на эмуляторе. Запуск таких тестов на устройстве производится так же, как традиционная отладка на устройстве — просто измените цель развертывания (Deployment) c «Windows Phone Emulator» на «Windows Phone Device» в стандартной панели инструментов Visual Studio.
Вот некоторые ссылки на дополнительные ресурсы по анализу производительности для Windows Phone:

Windows Phone Performance Analysis
How to: Capture and Analyze Performance Data Using Windows Phone Performance Analysis
How to: Identify and Fix Common Performance Issues Using Windows Phone Performance Analysis

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *