Ускорьте появление своих приложений Windows Phone в Marketplace

Windows Phone SDK 7.1 включает отличные утилиты для оценки соответствия ваших приложений требованиям сертификации, а также для повышения их скорости работы в Windows Phone 7.5 до передачи в магазин приложений — Windows Phone Marketplace. В этой статье я подробно расскажу об использовании Marketplace Test Kit и утилиты Performance Analysis на примере одного приложения и поясню, как применять эти инструменты для оценки готовности вашего приложения к передаче в Marketplace. Вы увидите, как использовать данные, получаемые от этих инструментов, для внесения изменений, которые помогут вам добиться принятия вашего приложения в Marketplace с первой попытки. Подробнее о требованиях сертификации приложений для продажи через Marketplace см. статью в MSDN Library «Application Certification Requirements for Windows Phone» (wpdev.ms/certreq).

Все утилиты, использовавшиеся в этой статье, входят в Windows Phone SDK 7.1, который можно получить по ссылке wpdev.ms/wpsdk71rtw.

Приложение-пример и средства тестирования

Чтобы потренироваться в работе с Marketplace Test Kit и утилитой Performance Analysis, я создала приложение-пример Examine the Stamen — простую программу для идентификации цветов (растений). Когда я писала эту программу, я все время помнила о своей матери: она смогла бы научиться лучше разбираться в цветах. На начальном экране приложение показывает несколько небольших изображений цветов. Пользователь касается цветка, и приложение переходит на другую страницу, где отображает выбранный цветок в виде более крупной картинки. Еще одно касание, и с помощью MessageBox выводится название этого цветка. На рис. 1 представлены показываемые изображения в процессе моей навигации по приложению. [Кстати, для получения этих экранных снимков я использовала новую утилиту в Windows Phone Emulator. Подробнее на эту тему см. статью в MSDN Library «How to: Create Screenshots for Windows Phone Marketplace» (wpdev.ms/rYoZKP).

Рис. 1. Изображения, показываемые в программе Examine the Stamen

Хотя это приложение не совсем практичное, оно все же неплохо представляет модель навигации в Phone-приложении. Я оценю его с помощью Marketplace Test Kit в Visual Studio, а затем проведу его углубленный анализ, используя утилиту Windows Phone Performance Analysis. Выявив любые проблемы, я воспользуюсь документацией, чтобы понять, как устранить обнаруженные проблемы, и вновь протестирую это приложение с помощью упомянутого инструментария.

Итак, приступим.

Использование Marketplace Test Kit

Я создала вполне привлекательный UI для программы Examine the Stamen и подходящую модель навигации. В будущем я планирую добавить большее количество цветов, но прямо сейчас я хочу, чтобы мое приложение было принято в Market¬place. Поэтому следующий шаг — применение Marketplace Test Kit для оценки готовности моего приложения к передаче в Marketplace с помощью набора автоматизированных и ручных тестов, а также тестов с мониторингом.

Для запуска тестов я открываю проект своего приложения в Visual Studio и выбираю Marketplace Test Kit в меню Project.

В Visual Studio открывается новая вкладка, где показываются наборы тестов Marketplace Test Kit. Первая страница набора тестов приведена на рис. 2.

Рис. 2. Первая страница Marketplace Test Kit в Visual Studio

Доступные наборы тестов показаны на вкладках слева. Вкладка Application Details позволяет указывать образы приложения для автоматизированных тестов. Эти тесты оценивают размер XAP-пакета приложения, качество значков (iconography) и экранные снимки на соответствие требованиям сертификации и определяют возможности, используемые приложением. Ручные тесты (manual tests) обеспечивают возможность проверки приложения в определенных состояниях, чтобы убедиться в соответствии дополнительным правилам сертификации.

В этой статье я сосредоточусь на тестах с мониторингом (monitored tests). Подробнее обо всех наборах тестов см. страницу «Windows Phone Marketplace Test Kit» в MSDN Library (wpdev.ms/toHcRb).

TНабор тестов с мониторингом оценивает приложения на соответствие таким важным требованиям сертификации, как:

• время запуска;
• пиковое использование памяти приложением;
• обработка аппаратной кнопки Back;
• вероятность неожиданного закрытия приложения из-за появления необработанных исключений.

Выполнение тестов с мониторингом

Для выполнения тестов с мониторингом нужно запустить Release-сборку приложения, развернуть ее на устройстве (эти тесты не работают в эмуляторе) и «пройти» по всему приложению. Соответствующие параметры конфигурирования доступны через стандартную панель инструментов в Visual Studio. Цель выполнения тестов с мониторингом — листать приложение так, как это делал бы пользователь, проверяя все возможные пути навигации. Когда вы делаете это, набор тестов ведет мониторинг приложения и собирает данные о нем.

Проверяя свое приложение тестами с мониторингом, также проверьте, как оно работает в случае завершения и реактивации в течение короткого интервала времени. Этот процесс завершения и реактивации называют замораживанием (tombstoning). В Windows Phone 7.5 ваше приложение автоматически перейдет в спящее состояние (dormant) до замораживания.

Чтобы принудительно вызвать немедленное замораживание приложения для отладки и тестирования, установите флажок Tombstone upon deactivation while debugging на вкладке Debug в свойствах проекта. Откройте эти свойства командой Properties в меню Project. На рис. 3 показана вкладка Debug с этим флажком. Подробнее о замораживании см. страницу «Execution Model Overview for Windows Phone» в MSDN Library (wpdev.ms/ExMod).

Рис. 3. Выбор флажка для проверки замораживания в свойствах проекта

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

После настройки параметров я возвращаюсь на вкладку Marketplace Test Kit. Я указываю свое устройство, зарегистрированное для разработки и щелкаю Start Application на странице Monitored Tests этого набора тестов.

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

Пытаясь действовать так, как мог бы делать пользователь, гуляя по страницам, а потом заморозив и заново активировав приложение, я могу остановить приложение и сеанс тестирования. Для лучших результатов я выхожу из приложения нажатием кнопки Back на странице Start приложения, чтобы завершить сеанс тестирования. Можно было бы щелкнуть кнопку Close Application на странице Monitored Tests в наборе тестов, но наиболее точные результаты получаются при выходе из приложения с помощью кнопки Back. Когда приложение завершается, заканчиваются и сеансы мониторинга.

По окончании сеанса тестирования панель состояния результатов набора тестов сообщает, что идет анализ полученных данных, а затем, когда анализ выполнен, обновляется таблица результатов.

Увидев результаты для своего приложения (рис. 4), я была шокирована.

Рис. 4. Результаты тестов, свидетельствующие о двух ошибках

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

Использование утилиты Performance Analysis

В целом, чтобы ваши приложения стали популярными в Marketplace, они должны быть быстрыми и отзывчивыми. Как минимум, вы должны изучить и исправить проблемы, выявленные набором тестов. Для обеих этих целей можно использовать утилиту Windows Phone Performance Analysis, также называемую средством профилирования (profiler).

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

Средство профилирования предлагает два варианта.

• Execution profiling (профилирование выполнения) Средство профилирования выполнения оценит частоту кадров, выдаваемую вашим приложением, загруженность процессора и общее использование памяти. С его помощью можно посмотреть скорость заполнения (fill rate) и увидеть, сколько визуальных элементов создается, а также узнать другие детали выполнения приложения, способные повлиять на скорость его работы.
• Memory profiling (профилирование памяти) Средство профилирования памяти показывает использование памяти, загрузки образа и события сбора мусора. С его помощью можно увидеть закономерности в использовании памяти, которые могут указывать на утечку памяти.

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

Открыв проект приложения в Visual Studio, выбираем из меню Debug команду Start Windows Phone Performance Analysis. (Заметьте: если вы используете Visual Studio Premium или Ultimate, не выбирайте Start Performance Analysis, так как этот вариант неприменим к проектам для Phone.)

После запуска утилиты Performance Analysis в Visual Studio будет открыта новая вкладка с названием текущего сеанса профилирования. Это название включает имя проекта, дату и время сеанса профилирования, а также суффикс .sap, используемый в качестве расширения файлов с результатами профилирования. Эти файлы всегда сохраняются в проекте, поэтому вы можете неоднократно просматривать их. На рис. 5 показана вкладка Performance Analysis до запуска каких-либо тестов.

Рис. 5. Вкладка Performance Analysis до выполнения каких-либо тестов

На вкладке средства профилирования я выбираю вариант Execution. Для лучших результатов я проверяю, что Windows Phone Device и Release по-прежнему выбраны в параметрах развертывания и отладки на панели инструментов Visual Studio, и убеждаюсь, что мое устройство подключено и разблокировано. (Заметьте, что приложение можно развернуть в эмуляторе при использовании средства профилирования, но результаты могут оказаться далекими от результатов на реальном устройстве.)

Для запуска сеанса профилирования я щелкаю Launch Application. Как и при работе с Marketplace Test Kit, я стараюсь «бродить» по своему приложению так, как это делал бы пользователь, и обязательно минимум один раз замораживаю приложение и возвращаюсь в него. Для выхода из приложения я нажимаю кнопку Back — это предпочтительный метод завершения программы для получения наиболее точных результатов, хотя вы также можете закончить сеанс профилирования через Stop Profiling в утилите Performance Analysis. Средство профилирования некоторое время анализирует результаты и отображает их на странице в виде графика (рис. 6). Мои результаты очень интересны.

Рис. 6. Результаты теста Performance Analysis

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

Теперь я перезапускаю утилиту Performance Analysis с выбранным анализом памяти, и он подтверждает проблему растущего потребления памяти.

Поиск причин и устранение проблемы

Для отслеживания проблем с использованием средства профилирования выделите проблемные области на графике и прочтите инструкции в разделе Observation Summary.

Получив результаты профилирования выполнения, я щелкаю и перемещаю мышь, чтобы выделить ту часть графика, которая показывает всплеск нагрузки на процессор. После этого раздел Performance Warning немедленно обновляется описанием интересующей вас проблемы (рис. 7).

Рис. 7. Раздел Performance Warning с описанием высокой степени использования процессора UI-потоком

Согласно Observation Summary, приложение интенсивно использует процессор для выполнения функций в UI-потоке. Это определенно могло бы привести к замедлению времени запуска и низкой производительности в целом, но я не уверена, что этот фактор играет значимую роль в проблеме с памятью. Чем хороша утилита для профилирования, так это тем, что она дает мне некоторые инструкции, которым я и последую. Я выбираю CPU Usage, а затем Functions. Таблица результатов обновляется, и я сортирую результаты по столбцу Inclusive Samples (%). Вызовы функций в моем приложении отображаются синим цветом с полными именами, включающими пространство имен (MemoryLeak очень подозрительно в данном случае), имена класса и метода. Кроме того, вызовы функций являются активными ссылками на методы в моем коде. Эти результаты показаны на рис. 8.

Рис. 8. Утилита Performance Analysis показывает методы, которые могут вызывать проблемы

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

Я щелкаю ссылку для просмотра метода FlowerPage.OnNavigatedTo. Этот метод создает список объектов Flower и загружает битовую карту для каждого такого объекта методом LoadBitmap. Ниже показан типичный вызов метода LoadBitmap в моем коде:

bitmap = LoadBitmap("/MemoryLeak;component/Images/tulip.jpg");

и метод LoadBitmap, который загружает этот ресурс:

private BitmapImage LoadBitmap(string urlString)
{
  var streaminfo = App.GetResourceStream(new Uri(urlString, UriKind.Relative));
  BitmapImage bitmap = new BitmapImage();
  bitmap.SetSource(streaminfo.Stream);
  return bitmap;
}

Когда пользователь переходит на страницу, я извлекаю название цветка, выбранного на основной странице, по URI навигации и загружаю изображение того же цветка в FlowerPage.

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

Если Observation Summary не дает достаточно информации для решения проблем в вашем приложении, вы должны проверить MSDN и поискать в Интернете подходящее руководство. Вот некоторые из полезных ресурсов:

• «Performance Considerations in Applications for Windows Phone» (в разделе «Media») (wpdev.ms/utCq6h);
• «Performance Techniques for Windows Phone» (wpdev.ms/perfTech);
• блог группы Silverlight for Windows Phone Performance (wpdev.ms/slmperf);
• «Analyzing and Improving Windows Phone Application Performance» (видеоролик от MIX11) (wpdev.ms/mixwpperf);
• «Expert Lessons: Top Tips for Building a Successful Windows Phone Application» (видеоролик от MIX11) (wpdev.ms/mixwptoptips).

Я стала исследовать ресурсы по приложениям для Phone и нашла нечто важное. Согласно разделу «Media» в статье MSDN Library «Performance Considerations in Applications for Windows Phone», я должна указывать свои файлы изображений как контент, а не ресурсы, потому что Phone оптимизирован под использование файлов. Когда медийный файл компилируется как ресурс, контент копируется в файл перед использованием, что уменьшает производительность.

Я сменила действие сборки для своих файлов изображений на Content и внесла соответствующее небольшое изменение в код. В методе LoadBitmap я указываю UriSource для BitmapImage вместо вызова SetSource:

private BitmapImage LoadBitmap(string urlString)
{
  BitmapImage bitmap = new BitmapImage();
  bitmap.UriSource = new Uri(urlString, UriKind.Relative);
  return bitmap;
}

А при вызове LoadBitmap я передаю относительный URL каждой битовой карты (растрового изображения):

bitmap = LoadBitmap("/Images/tulip.jpg");

Повторный запуск Marketplace Test Kit и утилиты Performance Analysis

Устранив все проблемы, выявленные в Marketplace Test Kit и утилитой Performance Analysis, можете заново воспользоваться этим инструментарием.

IЯ перекомпилировала свое приложение, снова запустила Marketplace Test Kit и даже не сразу поверила разнице в результатах (рис. 9). Приложение теперь проходит все четыре теста. Время запуска невелико, по крайней мере не выходит за допустимые рамки.

Рис. 9. Результаты изменения обработки изображений позволили пройти все четыре теста Marketplace

Наконец, я запустила средство профилирования выполнения. И увидела большую разницу в результатах (рис. 10).

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

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

Рис. 11. Данный всплеск нагрузки на процессор не приводит к появлению Performance Warning

С облегчением увидев, что средство профилирования не находит никаких проблем с производительностью, я могу передать свое приложение в Market¬place. Теперь у меня есть уверенность в том, что его примут и что я смогу продолжить совершенствование этой программы и при необходимости передавать обновления.

Следуйте этой схеме

В этой статье я описала, как выявить и исправить проблемы в приложении-примере Windows Phone с помощью Marketplace Test Kit и утилиты Performance Analysis. Эти инструменты интегрированы в Visual Studio и устанавливаются вместе с Windows Phone SDK. Marketplace Test Kit помогает определить, отвечает ли ваше приложение требованиям сертификации. Утилита Performance Analysis позволяет анализировать проблемы с использованием памяти и процессора. Прежде чем отправлять свои приложения в Marketplace, рекомендую придерживаться схемы, аналогичной показанной в этой статье.

1. Используйте продемонстрированный инструментарий, в том числе все наборы тестов из Marketplace Test Kit.
2. Выявите и устраните все проблемы.
3. Повторно протестируйте приложения для проверки исправлений.

Если вы последуете этой схеме, вы заблаговременно обнаружите проблемы и быстрее создадите свои приложения. Кроме того, это поможет добиться принятия ваших приложений в Marketplace с первой попытки.