Программирование мобильных устройств на платформе .NET Compact Framework - Иво Салмре

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

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

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

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

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

Находящиеся в памяти битовые образы и сохраненные изображения — это та арена, на которой графика и пользовательский интерфейс взаимодействуют между собой. Сохраненные изображения часто удобно использовать в приложении либо в качестве части пользовательского интерфейса, либо в качестве данных. При использовании изображений очень важно контролировать их размеры, чтобы в целом они соответствовали характерным размерам интерфейса; изображения, размеры которых больше необходимых, требуют больших объемов памяти для хранения и используют значительно больше системной памяти в процессе загрузки. Вы должны отдельно исследовать вопрос о том, какой формат хранения изображений следует использовать, чтобы он был наиболее оптимальным для интересующей вас задачи. Для фотографических изображений самым употребительным форматом является JPG, тогда как для изображений, полученных методами компьютерной графики, — формат PNG.

Графический код — это код, с помощью которого приложение может создавать рисунки. Эта возможность используется для представления нестандартных красочных изображений пользователям, а также для реализации высокоинтерактивных нестандартных элементов управления пользовательского интерфейса. Часто для интеграции графического кода в пользовательский интерфейс имеется несколько возможностей, начиная с простейших (например, отображение рисунков на элементах управления PictureBox), и заканчивая самыми сложными (например, создание нестандартных элементов управления). Выбор оптимальной модели встраивания графики в приложение имеет столь же важное значение, что и рассматривавшийся нами ранее выбор наиболее подходящего уровня абстракции API-интерфейсов; всегда старайтесь использовать самую простую из возможных моделей.

Существуют отличные способы оптимизации программных кодов, предназначенных для рисования графики. Чтобы разглядеть эти возможности в своем коде, вы должны придерживаться целостного подхода к рассмотрению задач рисования, возникающих в вашем мобильном приложении. Графический код часто состоит из множества мелких шагов, объединенных в цепочки или выполняющихся в циклах. Чтобы добиться максимальной производительности при работе с графикой, вы должны пытаться находить в процессе проектирования приложения: 1) области, для которых графическую работу можно выполнить заблаговременно, например, заранее готовя отдельные части нужных изображений, или 2) способы, позволяющие свести к минимуму количество операций, размещающих в памяти объекты или системные ресурсы. Если обычные перья, кисти, пиктограммы или иные ресурсы используются более одного раза, их следует создавать и сохранять в кэш-памяти

Старайтесь постоянно информировать пользователя о ходе выполнения приложения

Игнорируя проблемы производительности, вы накликаете на себя беду. Закрывать глаза на проблемы производительности, которые могут возникать в вашем приложении, и не замечать их — это самый верный способ создания самому себе трудностей в процессе дальнейшей разработки. Лучше всего разрешать проблемы производительности сразу же, как только они возникли, и именно в этот момент их легче всего диагностировать. В еще большей степени, чем приложения для настольных компьютеров, мобильные приложения можно рассматривать как состоящие из ряда способных блокировать друг друга взаимосвязанных систем, которые должны совместно использовать одни и те же системные ресурсы. Поскольку в случае мобильных устройств пул доступной памяти имеет гораздо меньший объем, а понятия свопинга редко используемых областей памяти в дисковый файл подкачки для них не существует, любой лишний элемент может стать причиной возникновения крупномасштабных проблем в рамках всего приложения..Так, хранение крупных растровых изображений в памяти непосредственно уменьшает ресурсы, которые можно было бы использовать для хранения дерева XML-данных или скомпилированного кода функции. Случаи, когда приложение исчерпывает всю доступную память, диагностировать легко. Установить источник проблем гораздо сложнее, если в приложении нехватка памяти нарастает постепенно, все чаще и чаще активизируя сборщик мусора, чтобы поддерживать приложение в работоспособном состоянии.

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

Очень важно, чтобы в тех случаях, когда проблемы производительности уже проявились, вы не пытались расширять возможности мобильного приложения и добавлять в него новый код, питая ложные надежды на то, что в будущем у вас еще будет время заняться этими проблемами. Добавлять новые средства и код в приложение следует лишь тогда, когда вы располагаете резервами производительности для поддержки этих средств. Если вы чувствуете, что "уткнулись в глухую стену", то прежде, чем вводить в приложение дополнительные элементы, потребляющие ресурсы, попытайтесь сделать состояние приложения более экономичным и свести к минимуму алгоритмическую чехарду с созданием и уничтожением объектов. Дополнительные резервы производительности — это та валюта, которой вы сможете расплачиваться за новые возможности; если у вас есть долги, то сначала рассчитайтесь с ними и лишь после этого позволяйте себе дальнейшие траты.