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

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

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

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

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

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

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

Заключительные замечания и рекомендации

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

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

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

■ Не бойтесь помещать в кэш-память часто используемые ресурсы. Вы должны поставить перед собой задачу поддерживать объем постоянно используемой памяти приложения на как можно более низком уровне, но только не за счет отбрасывания полезных объектов. Если вам приходится то и дело заново создавать и уничтожать одни и те же критические объекты, то лучше кэшировать их, чтобы избежать этого напрасного перелопачивания памяти. Подумайте о создании класса диспетчера ресурсов, ответственного за распределение, кэширование, освобождение и передачу ресурсов остальным частям приложения. Этот класс может отделить задачу диспетчеризации ресурсов от их размещения в памяти и уничтожения. Предусмотрев один центральный диспетчер ресурсов, вы можете настроить его в соответствии с запросами приложения в его различных состояниях, тем самым избавив остальную часть кода от каких бы то ни было забот о стратегиях распределения и освобождения ресурсов. 

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

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

■ Осмотрительно выбирайте размеры применяемых вами растровых изображений. В наши дни размеры обычных цифровых изображений значительно превышают те, которые еще допустимы при выводе изображений на экраны мобильных устройств. При больших размерах изображений вы будете напрасно терять время на их пересылку по сети, место, необходимое для их хранения на устройстве, и память, занимаемую ими при загрузке. Лишние 0,5 Мбайт данных изображения, загруженных в память, эквивалентны сотням или даже тысячам других удерживаемых в памяти элементов, не являющихся изображениями; 500 Кбайт пикселей по занимаемому объему равносильны 500000 целочисленных элементов данных. При любом удобном случае прежде, чем загружать изображение, уменьшайте его размеры, сообразуясь с возможностями экрана целевого устройства. Если это сделать невозможно или в память должны загружаться изображения с высоким разрешением, подумайте, нельзя ли сразу же создать в памяти копии этих изображений с низким разрешением, после чего уничтожить их объемистый в отношении используемой памяти оригинал, чтобы за приложением не было закреплено большое количество лишней памяти. 

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

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