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

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

■ Объекты Bitmap. Часто возникают ситуации, в которых в качестве временного хранилища для изображения или части изображения, создаваемых вашим приложением, удобно использовать объект Bitmap. Если вашему приложению требуется пространство для рисования, то в этом нет ничего необычного; единственное, чего следует избегать — так это создания и уничтожения многих битовых изображений в циклах рисования. Обычно гораздо лучше иметь одно рабочее пространство, многократно используемое в качестве общего ресурса, чем нести дополнительные затраты, связанные с непрерывным созданием и уничтожением временных изображений. Размер такой временной памяти должен быть равен размеру наибольшего временного изображения, которое может понадобиться вашим процедурам (но не более того). Если временную память необходимо очищать, прежде чем использовать ее для рисования, то это можно сделать легко и быстро при помощи вызова Graphics.Clear. Кроме того, как продемонстрировано в приведенном выше примере кода, часто используемые растровые изображения имеет смысл загружать и кэшировать в памяти. Следите за тем, чтобы в каждый момент времени загружался только один экземпляр растрового изображения. Загрузка нескольких экземпляров идентичных изображений приведет к напрасному расходованию больших объемов памяти. 

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

■ Объекты Font, Brush, Pen, ImageAttribute. Распространенной ошибкой разработчиков, причины которой вполне объяснимы, является их чрезмерное увлечение управлением временем жизни ресурсов на микроуровне, не сопровождающееся глубоким анализом их использования на макроуровне. В процессе создания графического изображения вам может потребоваться пройти, скажем, через 30 отдельных этапов, в ходе которых рисуются линии, закрашиваются эллипсы, создается текст и копируются битовые образы. Выполнение каждой из этих операций требует использования некоторой комбинации перьев, кистей, шрифтов, то есть объектов Pen, Brush, Font, а если в дело включаются еще и маски прозрачности, то и объектов ImageAttribute. В случае мобильных устройств ситуация усугубляется тем, что в .NET Compact Framework, в отличие от .NET Framework, статические версии базовых кистей и перьев не предусмотрены. Так, в версии NET Framework, ориентированной на настольные компьютеры, существуют, например, объекты System.Drawing.Pens.Blue и System.Drawing.Brushes.DarkOrange, но в NET Compact Framework эти объекты приходится распределять. Решение этой проблемы заключается в создании собственного глобального набора объектов Pen и Brush, который вы будете использовать для нужд рисования во всем приложении. Вы должны тщательно просмотреть все циклы рисования в приложении, обращая особое внимание на случаи повторного создания идентичных ресурсов и избавляясь от подобной избыточности в коде. Если в вашем приложении непрерывно выполняются операции рисования, то такие объекты, как шрифты, перья, кисти и маски прозрачности, должны либо однажды распределяться в цикле рисования, либо глобально кэшироваться. 

■ Типы, которые преобразуются (или, как еще говорят, "'упаковываются") в объекты. Наиболее распространенным типом значений, используемым в графических кодах, является структура System.Drawing.Rectangle. Обычно работа с типами, соответствующими значениям, отличается высокой эффективностью, поскольку их можно размещать в стеке (а не в глобальном пуле свободной памяти, или куче, как объекты). В то же время, значения также могут рассматриваться как объекты и размещаться в массивах или коллекциях или передаваться всюду, где допускается использование объектного типа. Тщательно следите за тем, чтобы не происходило неявное постоянное распределение и освобождение памяти, обусловленное "упаковкой" значений в объекты и их обратной "распаковкой".

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

Резюме

От того, что вы напишете код, обеспечивающий отличную реакцию пользовательского интерфейса, алгоритмы вашего приложения работать быстрее не станут. Это никоим образом не ускорит победный марш разработки приложения "до полного завершения". Более того, код приложения может даже усложниться. Единственная причина, по которой следует заботиться о высокой реактивности интерфейса и стремиться к высокой производительности его кода, заключается в том, чтобы создать для пользователя более комфортные условия, но разве ради этого не стоит потрудиться? Если вы хотите, чтобы пользователь поставил самую высокую оценку вашему приложению, вы не должны жалеть времени на доводку и отшлифовку таких вещей, как способность интерфейса к отклику. Как и в случае других аспектов производительности, выполнение этой работы нельзя откладывать до завершающих этапов процесса разработки. В конце разработки вы еще смогли бы добавить что-то наподобие курсоров ожидания в тех точках, где приложение может тормозиться, но это все равно, что красиво покрасить фасад плохо построенного дома — это лучше, чем вообще ничего, но, в сущности, не так уж и много. Никогда не забывайте о необходимости обеспечения высокой интерактивности пользовательского интерфейса и всегда в явном виде включайте это требование в качестве критерия прохождения каждой контрольной точки разработки. Лучше всего решать подобные проблемы сразу же после их выявления, пока они не успели накрепко зацементироваться в структуру приложения.

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

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

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

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

Работая с графическим кодом, вы должны хорошо представлять себе систематическую картину того, каким образом в приложении осуществляется визуализация изображений. При этом очень важно "не оказаться крохобором в мелочах, бездумно транжирящим крупные суммы" в обращении с ресурсами. Если имеются такие объекты Bitmap, Graphics, Pen, Brush, Font или ImageAttribute, которые будут использоваться во всех операциях рисования в приложении, то вы должны разработать систему, в задачи которой входит создание и кэширование указанных ресурсов. Применение предварительно создаваемых изображений сопряжено с дополнительным расходом ценной памяти, однако оно чрезвычайно ускоряет операции рисования; при разумном подходе это позволяет создавать приложения с привлекательным интерфейсом, сохраняющие высокую производительность. Исключайте случаи одновременной загрузки двух идентичных ресурсов — подобная расточительность никому не нужна.