Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Рекомендуется разработать список стандартных рекомендаций, определяющих в общих чертах стиль программирования для ваших проектов. Это может быть выполнено либо в виде простейших аннотаций к файлу с примерами кода, демонстрирующими принимаемые при написании программ соглашения, либо в форме исчерпывающего сборника рекомендаций для проектировщиков. Степень детализации подобных рекомендаций зависит от возможностей и потребностей вашей организации. Если такие стандарты или рекомендации у вас отсутствуют, целесообразно затратить некоторые усилия на их составление. Начните с самого простого и позаимствуйте подходящие стандарты написания программ из существующих опубликованных руководств, предварительно убедившись в том, что они для вас подходят, и их будут применять все члены рабочей группы. Вашей наградой будет единый стиль программирования в рамках всего проекта.
Определите модель памяти для вашего приложения
Поскольку мобильные приложения выполняются в средах с ограниченными ресурсами памяти, полезно определить и поддерживать явную модель, описывающую способы использования памяти и осуществления управления ею в вашем приложении. В
■ Какие глобальные ресурсы будут кэшироваться в памяти? Одни объекты целесообразно кэшировать, тогда как хранить в памяти другие объекты было бы слишком расточительно. Трезво оцените, какие объекты к какой категории следует отнести.
■ Какой объем данных приложения будет загружаться в память в каждый момент времени? Большинству приложений приходится иметь дело с довольно крупными объемами данных, лишь часть которых должна быть загружена в память в каждый заданный момент времени.
■ При каких условиях возможно освобождение памяти от загруженных данных и ресурсов? Модели очистки памяти, позволяющие избавляться от данных и ресурсов, необходимость в которых в данный момент отсутствует, играют очень важную роль в процессах освобождения памяти, требуемой для сохранения других данных и ресурсов.
От вас, как от разработчика, зависит, будет ли осуществляться управление этими важными аспектами явным образом или же проблемы будут решаться по мере их возникновения, пока объем поглощаемой приложением памяти не превысит допустимые пределы. Соображения по этому поводу уже приводились в одной из предыдущих глав, когда мы обсуждали применение машин состояний для управления моделью памяти приложения. Если вы еще не читали этот материал, имеет смысл вернуться назад и просмотреть его. Эти же вопросы находятся в центре внимания следующей главы, посвященной рассмотрению методов управления памятью и производительностью.
Как можно чаще контролируйте показатели, характеризующие работу вашего приложения
Продумайте способы измерения важнейших показателей работы вашего приложения. Измерения — это ключ к получению информации, которая поможет вам находить оптимальные пути повышения производительности. При помощи соответствующих измерений вы можете оценивать быстродействие алгоритмов и скорость реакции пользовательского интерфейса. Можно также измерять показатели, характеризующие распределение памяти и ее использование различными объектами.
Анализируя проблемы производительности, подумайте над тем, какого типа данные будут наиболее полезными для этих целей и как их можно получить. Ниже приводится ряд рекомендаций по этому поводу, перечисленных в порядке уменьшения степени их важности:
1. Оснастите код средствами объективного контроля. Затратив лишь самые незначительные усилия, вы можете включить в код средства мониторинга, обеспечивающие получение объективных характеристик работы приложения. Этот процесс называют оснащением кода средствами контроля характеристик его функционирования. Получение достаточно большого объема информации о том, как работает код, создает хорошие предпосылки для его оптимизации. Хронометраж кода обычно не представляет особых затруднений; пример соответствующей программы приводится далее в этой главе. Сравнение эффективности различных алгоритмов на основании данных, полученных в результате измерения объективных характеристик выполнения кода, часто помогает значительно прояснить ситуацию.
2. Продумайте способы автоматического тестирования производительности приложения и записи соответствующих показателей в журнал. В тех случаях, когда это возможно, полезно организовать автоматическое тестирование кода с ведением журнала показателей производительности для ключевых сценариев. Наличие соответствующих средств контроля работы кода и генерация согласованной системы показателей, измеряемых и сохраняемых от сборки к сборке, окажет вам неоценимую помощь при выяснении причин снижения производительности, если таковое вдруг начнет наблюдаться. Имея возможность сравнивать значения показателей, характеризующих производительность различных версий разрабатываемого вами мобильного приложения при выполнении ключевых сценариев, вы сможете без труда фиксировать случаи ухудшения этих показателей. Выявление проблем производительности на ранних стадиях их возникновения позволит вам легко определить, какие именно изменения, внесенные в проект, послужили причиной ухудшения того или иного показателя.
3. Используйте показатели производительности алгоритмов, генерируемые средой выполнения, а также установленными на устройстве средствами мониторинга работы приложении. Некоторые среды выполнения управляемого кода обеспечивают возможность измерения показателей, характеризующих отдельные аспекты функционирования приложений. В частности, они позволяют определить, сколько времени выполняется тот или иной код, а также отслеживать распределение памяти для размещения объектов и выполнение операций сборки мусора. Информация такого рода может пригодиться вам для настройки алгоритмов и выявления случаев утечки памяти. Наилучшей стратегией при проведении подобного рода анализа является как можно более полная изоляция кода, поведение которого анализируется. Самые точные и реальные характеристики
4. Используйте показатели производительности алгоритмов, генерируемые средствами мониторинга, которые доступны в настольных компьютерах и серверах. Для сред выполнения, функционирующих на настольных компьютерах и серверах, разработаны потрясающие средства, предназначенные для мониторинга работы управляемого кода. В настоящее время средства этой категории пока значительно опережают аналогичные им инструментальные средства, разработанные для устройств; вероятно, в течение некоторого времени такая ситуация будет сохраняться. Частично это объясняется тем, что рынок настольных компьютеров и серверов существует дольше, а частично — тем фактом, что в средах выполнения, предназначенных для настольных компьютеров и серверов, для поддержки утилит мониторинга могут выделяться гораздо большие объемы памяти. Можно ожидать, что в ближайшее время среды выполнения, используемые на устройствах, а вместе с ними и соответствующие средства получения эксплуатационных характеристик программ, получат дальнейшее развитие, однако по-прежнему будут уступать своим аналогам, ориентированным на настольные компьютеры и серверы. Поставляемые для настольных компьютеров и серверов средства, позволяющие анализировать работу приложений, способны обеспечивать получение детальной картины того, на выполнение каких функций приходится основная доля процессорного времени, и какие участки кода могут тормозить выполнение программ. Кроме того, современные средства мониторинга работы кода часто интегрируются в стандартные среды разработки приложений, что значительно упрощает проведение указанного анализа. Запуск кода, изначально предназначенного для устройств, в среде настольного компьютера или сервера позволит вам получить представление о возможностях его выполнения на этих платформах и глубже разобраться в особенностях его поведения в условиях устройств. Примечание. Имейте в виду, что механизмы JIT-компиляции, обработка исключений и стратегии сборки мусора для настольных компьютеров, серверов и устройств могут существенно отличаться друг от друга. Возможности настольных компьютеров и серверов в отношении доступных объемов памяти значительно превышают возможности мобильных устройств, а для каждого типа микропроцессоров существуют свои области вычислений, в которых он превосходит другие типы. Результаты мониторинга работы приложения, полученные на настольном компьютере или сервере, могут дать вам много полезной информации, но некоторые из характеристик приложения при выполнении на устройстве могут измениться. Подобные различия будут становиться особенно заметными тогда, когда в коде интенсивно используются операции файлового ввода-вывода, выполняется обмен данными по сети или обрабатывается графика, поскольку производительность кода в этих случаях будет в значительной мере зависеть от используемого оборудования и операционной системы. Инструментальные средства мониторинга, используемые на настольных компьютерах и серверах, помогут вам развить свою интуицию и глубже разобраться в особенностях распределения памяти для объектов, но окончательные выводы вы должны делать только на основании результатов, полученных при выполнении приложения на устройствах.
5. Используйте данные относительно использования памяти, полученные с помощью средств операционной системы и средств мониторинга на основе собственного кода, предоставляемых устройством. Для получения данных хронометража, а также данных по использованию памяти приложением, характеризующихся повышенным разрешением, во многих случаях могут быть привлечены системные вызовы операционной системы, использующие собственный код. Кроме того, для получения статистических данных, характеризующих работу программы, можно привлекать инструментальные средства мониторинга, написанные с использованием собственных кодов. Если вы создаете компоненты или приложения на основе собственного кода, то эти именно эти данные и являются тем, что вам нужно; в этом случае вам остается только засучить рукава и приступить к измерениям. Если же вы пытаетесь получить информацию о производительности приложения, создаваемого на основе управляемого кода, то ситуация несколько осложняется. Если данные об использовании памяти системой или приложением получены средствами операционной системы, то необходимо учесть, что поведение управляемой среды в отношении использования памяти лишь в общих чертах коррелирует с поведением системы. Ввиду периодического выполнения таких операций, как сборка мусора, кривая использования памяти, вероятнее всего, будет иметь пилообразную форму, соответствующую постепенному накоплению неиспользуемых объектов в памяти и последующему периодическому освобождению памяти от них в результате работы сборщика мусора. Тем не менее, эта информация вам может пригодиться, если вы пытаетесь выяснить причины утечки памяти, происходящей на протяжении длительных промежутков времени. Кроме того, вы можете вызвать сборщик мусора еще до измерения объема используемой памяти, однако поступать так следует лишь в целях тестирования; вызовы сборщика мусора непосредственно в коде при обычном выполнении приложения почти всегда приводят к снижению производительности. Как бы то ни было, для получения информации о расходе памяти непосредственно из операционной системы могут потребоваться системные вызовы, использующие собственный код, с последующей коррекцией результатов. Если же вы можете получить необходимые вам данные из управляемой среды, то все делается намного проще.