Разработчикам: Проверьте будущее ваших Windows Phone приложений

Как убедиться, что приложение созданное для предыдущих версий Windows Phone будет также хорошо работать на Windows Phone 8?
Участвуете ли вы или нет в программе SDK Preview, о которой вчера написал Тод Брикс, вот несколько советов для проверки приложений и подготовки их к следующей версии Windows Phone. Вот три аспекта этого вопроса, которых я буду касаться:
Совместимость: хотя почти всё отличается, наша платформа приложений поддерживает высокую степень обратной совместимости. Таким образом, с точки зрения API платформы как правило не нужно ничего делать — ваше приложение просто будет продолжать работать как и прежде без каких-либо изменений. Но это становится менее однозначным, если вы делаете что-то необычное или не поддерживаемое в вашем приложении (подробности ниже).
Версионная устойчивость: Вы не можете предсказать будущее, поэтому сама фраза «проверьте будущее» немного вводит в заблуждение. Однако, когда будущее наступит, вам всё равно придётся с этим столкнуться: как вы убедитесь, что ваше приложение работает корректно на нескольких версиях платформы, которая поддерживает растущий набор функциональности?
Устойчивость относительно оборудования: В-третьих, Windows Phone 8 вводит поддержку более широкого круга устройств. Это означает, что есть дополнительные аппаратные особенности и более широкие возможности, не являющиеся дополнительным функционалом. Умный разработчик будет учитывать это, делая гибким своё приложение, обрабатывая условия, в которых некоторый функционал недоступен или не актуальны.

Изменения API
Чтобы почувствовать как API может измениться между версиями платформы, давайте рассмотрим изменения от версии 7.0 к 7.1. Они описаны здесь. Большинство изменений были в сторону расширения — то есть новые API-интерфейсы были добавлены, так что это не имеют никакого влияния на нарушение работы существующих приложений. Небольшое количество изменений, которые не были в сторону расширения, обычно подпадают под категорию «улучшение согласованности с общей поверхностью API». То есть были исправлены аномалии, и это всегда происходит в крайнем случае.
Вы можете ожидать это также и в будущем: существующая поверхность API перейдёт в мир Windows Phone 8, несоответсвия будут приведены в соответствие с этой поверхностью, и поверхность будет расширена для поддержки множества возможностей на новой платформе.

Версионная устойчивость
Как вы справляетесь с различием версий? И как вы обнаружите различия между версиями? Одним из методов динамического исследования API является использование рефлекшена среды (рефлекшн (reflection) — возможность, которая позволяет с объектом сделать некоторые действия: получить полную информацию по методам, полям, свойствам, помимо получения списка дает полное описание по их семантике и дает возможность вызвать, изменить любую из этих частей. К сожалению, не нашёл подходящего перевода термина на русском языке) во время выполнения, а не на этапе компиляции. Это проблематичная техника: она может быть использована для повышения версионной устойчивости, но она может быть использована для обхода публичного API (тем самым снижая версионную устойчивость).
В общем, использование рефлекшена не рекомендуется в Windows Phone приложениях. Публичные поверхности платформы приложений были тщательно разработаны, чтобы обеспечить ваше приложение максимальной функциональностью последовательным способом. Если вы обходите эти тщательно построенные поверхности с помощью рефлекшена, можно легко заблудиться в областях, которые не поддерживаются или могут быть изменены в более поздних версиях. Например, рефлекшен можно использовать для доступа к закрытым членам, и обычно это плохая идея. Единственный случай, когда рефлекшн может быть полезен для лёгкого сценария, где вы проверите работаете ли вы на версии платформы, которая имеет возможности, которые вам нужны.
Например, в версии платформы 7.0 класс SystemTray имеет только одно свойство IsVisible, в версии 7.1 добавлены четыре новых свойства. Таким образом, вы можете запросить BackgroundColor, и если вы работаете на версии платформы, которая поддерживает это свойство, то вы можете получить (и/или установить) его значение. Это разумное использование рефлекшена для хорошей версионной устойчивости, потому что она ограничена задокументированными публичными членами, например:

Обфускация
Чтобы защитить свою интеллектуальную собственность, вы могли бы рассмотреть обфускацию кода, например свободно доступный Dotfuscator Windows Phone Edition от фирмы PreEmptive. Единственная загвоздка состоит в том, что фреймворк Silverlight широко использует рефлекшен за кулисами — это делает трудным для обфускатора правильный анализ сборки для выяснения какой уровень обфускации является безопасным.
Слишком глубокая обфускация может привести к ошибке во время выполнения. Просто потому, что если ваша обфускация кода работает на одной версии платформы, то это не означает, что тот же обфусцированный код будет также работать на другой версии. Для версионной устойчивости, таким образом, вы должны выбрать консервативные методы обфускации. В частности, как правило, следует избегать возможности оптимизации кода в обфускаторах, которые удаляют неиспользуемый код и данные, объединяют строки, объединяют сборки и т.д.

Архитектурная развязка
Традиционная техника реализации версионной стойкости — это оптимизация развязки между компонентами в вашем приложении. Это не делает конкретное приложение версионностойким. Это скорее способствует созданию нескольких версий вашего приложения для разных вариаций платформы, где вы просто заменяете различные отдельные компоненты/сборки соответствующими для данного варианта.
Для различных версий Windows Phone во многом это не нужно — напомним, что платформа приложений сама выступает версионно стойкой обёрткой над различными основными особенностями платформы. Мы сделали тяжелую работу за вас! Этот подход будет более полезен в сценариях, в которых вы хотите сосредоточиться на Windows Phone 8 и Windows 8 с тождественным приложением. Но я далеко забежал вперёд, я буду больше говорить об этом, когда будет выпущен Windows Phone 8 SDK.

Вариативность платформы
Первый релиз Windows Phone был очень ограничен аппаратной спецификацией. Это означает, что разработчикам было накладно сосредоточиться на одной платформе. Так как рынок Windows Phone расширился, то есть спектр аппаратных конфигураций, которых требуют эти новые рынки.
Поэтому набор аппаратных характеристик очень гибкий — больше возможностей становится не обязательными. Это уже относится к версии 7.1, касательно таких возможностей как компас, акселерометр, гироскоп и камера. Умный разработчик уже знает как построить код с условиями, порверяющими наличие или конфигурацию аппаратных возможностей через свойства IsSupported или IsXXXSupported, например:

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

Вариативность памяти
Пункт 5.2.5 технических требований для сертификации приложений предупреждает, что «приложение не должно использовать более 90 Мб RAM, за исключением устройств, которые имеют более 256 Мб памяти». Отметим, что не указано сколько памяти вы можете использовать на устройстве, которое имеет более 256 Мб оперативной памяти. По сути, вы гарантированно имеете 90 Мб оперативной памяти и можете использовать больше на некоторых устройствах, но не факт.
Суть в том, что вы должны сделать всё, чтобы ограничить ваше приложение для возможности запуска, используя 90 Мб оперативной памяти. Если вы сделаете так, то приложение будет иметь максимально широкий целевой рынок (то есть все устройства Windows Phone известные миру). Если вы не сделаете это, то вы выбираете путь, который исключает приложение из некоторой части этого рынка. Даже если вы не исключаете приложение с этой доли рынка явно, то оно может так плохо вести себя на устройствах с малым количеством памяти, что пользователи скорее всего его будут удалять и писать плохие отзывы о нём.
Таким образом, в то время как ориентированность на 90 Мб рассматривается некоторыми только как руководство, любое такое руководство может стать критическим по мере расширения спектра устройств. В конкретных случаях нехватки памяти вы можете пойти на крайние меры, сделав так, чтобы оно не устанавливалось на устройства с недостаточным объемом памяти. Это задокументировано здесь.
Если вы не хотите ограничивать свой рынок, вместо этого можно адаптировать функциональные возможности приложения для уменьшенного объёма оперативной памяти. Вы можете использовать технику TryGetValue, если доступно DeviceExtendedProperties.ApplicationWorkingSetLimit. TryGetValue определен в интерфейсе IDictionary, и вы обычно используете его в открытой коллекции типов, таких как IsolatedStorageSettings или NavigationContext.QueryString. Однако эта методика была взята в классе DeviceExtendedProperties специально для поддержки функций, зависящих от версии. ApplicationWorkingSetLimit говорит о том работаете ли вы на 7.1 или на 7.1.1. Если возврашённое значение меньше 90 Мб, то вы знаете, что работаете на устройстве с низким объёмом памяти и соответственно можете адаптировать свой функционал.
Если ApplicationWorkingSetLimit не найден, то вы не работаете на 7.1.1, что означает отсутствие файла подкачки, что в свою очередь означает, что в свою очередь означает, что для приложения рабочий предел такой же, как установленный предел. Вы можете получить установленный предел из свойства из DeviceStatus.ApplicationMemoryUsageLimit.

Подробнее об этой технике можно посмотреть здесь. Свойство ApplicationMemoryUsageLimit из класса DeviceStatus сообщает вам о максимальном объёме памяти, которое может быть выделено вашему приложению. Разность вычитания ApplicationCurrentMemoryUsage из ApplicationMemoryUsageLimit говорит вам, сколько еще места у вас есть, чтобы его можно было использовать. Итак, для обеспечения устойчивости в мире, в котором некоторые устройства имеют больше памяти, чем другие, вы можете сделать динамическую проверку, и адаптировать поведение приложения соответственно — так же, как вы делаете с дополнительным оборудованием.
В итоге: мы рассмотрели лёгкие сценарии, не используйте опрометчиво рефлекшн, будьте консервативны с обфускацией, тестируйте для опционального оборудования и функционала переключаемого пользователем, обратите пристальное внимание на руководящие принципы по использованию памяти.

Оригинал статьи: http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/09/12/future-proofing-your-apps.aspx
Перевод: Сергей Урусов

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

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