Шрифт:
Как уже отмечалось, описанная модель визуализации игры имеет много общего с процедурой рисования диаграмм. В данной игре вне цикла визуализации выполняется максимально возможный объем работы. Кроме того, при любой удобной возможности в ней используется предварительное создание изображений. В цикле визуализации выполняются лишь простые операции побитового копирования фонового изображения, а также рисуются несколько небольших спрайтов, частично прозрачных для фона, немного текста и несколько простых прямоугольников. Поскольку в игре не распределяется память и исключены напрасные траты процессорного времени внутри цикла визуализации, все это может происходить очень быстро.
Кэшируйте часто используемые ресурсы
При написании кода для обработки графики часто оказывается так, что приложению необходимо многократно использовать одни и те же ресурсы. К числу распространенных классов, допускающих повторное использование, относятся битовые изображения (Bitmap), перья (Pen), кисти (Brush) и шрифты (Font). Было бы слишком расточительно многократно загружать или создавать одни и те же ресурсы; на повторную загрузку ресурса из хранилища или его повторный запрос у операционной системы затрачивается дополнительное процессорное время. Не меньшим расточительством является и одновременная загрузка эквивалентных ресурсов в память; например, хранить в памяти несколько экземпляров одного и того же битового изображения — напрасная трата ресурсов, если вместо этого можно обойтись совместным использованием единственного экземпляра. Наконец, освобождение памяти, занимаемой ресурсами, также ложится бременем на систему и снижает ее производительность. Чтобы избежать подобного снижения производительности, иногда оказывается полезным применять в приложении глобальный диспетчер ресурсов, который берет на себя все заботы, связанные с загрузкой, кэшированием и удалением часто используемых ресурсов.
В листинге 11.11 представлен пример, демонстрирующий три подхода к загрузке и обслуживанию ресурсов в памяти.
■ Подход 1, основанный на принципе "открытия задвижки " (Litch-based approach). Любой код, которому требуется общий ресурс, обращается к статическому свойству класса GraphicsGlobals для получения его значения. Если ресурс уже загружен, он возвращается запросившему его объекту. Если ресурс еще не был загружен, то он создается, кэшируется и после этого возвращается пользователю. Такой подход обладает двумя преимуществами: 1) запрашивающий объект не должен заботиться ни о каком инициализирующем коде; в результате запроса всегда будет возвращен действительный ресурс, и 2) управляемый ресурс может быть освобожден, если приложение считает, что в течение некоторого времени в нем не будет надобности; при необходимости он будет заново создан в результате следующего запроса. Единственным недостатком такого подхода являются незначительные дополнительные накладные расходы, связанные с необходимостью вызова функции для доступа к свойству всякий раз, когда требуется ресурс; обычно этими накладными расходами можно пренебречь.
■ Подход 2, основанный на групповой обработке ресурсов (batch-based approach). Если некоторые ресурсы используются одинаковым образом и имеют сравнимые времена существования, то они могут быть инициализированы сразу все вместе. Код, в котором должны будут использоваться эти глобальные ресурсы, может непосредственно получить доступ к переменным, но предварительно он должен удостовериться в том, что они уже были инициализированы. Когда приложение перейдет в состояние, в котором эти ресурсы в течение некоторого времени использоваться не будут, эти ресурсы должны быть освобождены, и для них должен быть вызван метод Dispose.
■ Подход 3, основанный на использовании коллекций (collection-based approach). Если некоторые ресурсы всегда используются в виде группы, как, например, в случае битовых изображений, образующих анимационную последовательность, то имеет смысл загружать их вместе и возвращать в виде массива или коллекции ресурсов. Если загрузка ресурсов обходится слишком дорого или требует использования значительных объемов памяти, то может оказаться целесообразным хранить их экземпляры, кэшированные централизованным образом, чтобы исключить повторное создание одних и тех же ресурсов. Как и в рассмотренном выше случае, когда необходимость в этих ресурсах отпадает, их необходимо освобождать и вызывать для них метод Dispose, следуя предварительно намеченной стратегии