Создание игр для мобильных телефонов - Майкл Моррисон

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

Совет Разработчику

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

Оптимизация размера

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

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

Совет Разработчику

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

Оптимизация по скорости

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

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

В копилку Игрока

Для сравнения, чтобы в игре была плавная анимация, необходимо, чтобы частота смены кадров лежала в диапазоне от 15 до 24 кадров в секунду. Чтобы вспомнить, что такое частота смены кадров, посмотрите главу 5.

Основные приемы оптимизации игр

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

Сокращение использования памяти

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

► по возможности избегать применения объектов;

► если вы все же используете объекты, попробуйте применить их повторно;

► удаляйте объекты по окончании работы с ними.

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

Избежание применения объектов

Это может показаться странным, однако в мидлетах по возможности следует избегать использования объектов. Память под объекты выделяется из памяти среды выполнения, а не из стека, как в случае обычными типами данных. Стандартные типы данных, известные как скаляры, – это такие типы языка Java, как int, long, boolean и char. Конечно в CLDC и MIDP API множество классов, да и сами мидлеты – это объекты, следовательно, есть нижняя граница того, насколько вы можете сократить применение объектов. Тем не менее сокращение использования объектов больше касается данных мидлета, которые в большинстве случаев могут храниться в переменных стандартных типов, а не в объектах.

Если вы изучите CLDC и MIDP API, вы обнаружите, что многие вспомогательные классы, используемые в J2SE API, здесь отсутствуют. Например, класс Rectangle в J2SE – это хранилище четырех целочисленных переменных (X, Y, ширина и высота), описывающих прямоугольник. Этот класс отсутствует в MIDP API, а в тех местах, где ранее использовались переменные такого типа, используется непосредственное указание каждой переменной. Четыре переменные целочисленного типа менее требовательны к памяти по сравнению с объектом, хранящим четыре целочисленные переменные, под который нужно выделять память и управлять ей. Следовательно, обратите внимание, что в CLDC и MIDP API объекты используются только тогда, когда это функционально необходимо. В других случаях используются стандартные типы данных.

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

Если используете объекты, то применяйте их повторно

Очевидно, что нельзя полностью избежать применения объектов в мобильных играх. Объекты играют очень важную роль в Java-программировании, и мидлеты не являются исключением. Один из способов минимизировать затраты памяти на объекты – повторно использовать их. При этом отпадает необходимость создавать объекты заново. Конечно, такой подход можно применить только в случае, если необходимо использовать объект одного типа несколько раз, но вы будете удивлены, насколько часто такой метод применим при разработке мидлетов.

Совет Разработчику

Хороший пример повторного использования объектов – это использование одного объекта класса Sprite вместо удаления и создания нового. Изменение объекта можно сравнить с удалением старого и созданием нового. Такой подход широко применялся в мидлете High Seas, разработанном в главах 12 и 13.

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

Удаление объектов

Говоря о повторном использовании и уборке мусора, следует упомянуть о последнем приеме оптимизации, связанном с удалением объектов из памяти. В традиционном программировании J2SE или J2EE вы создаете объекты по необходимости, а удаляются они сборщиком мусора Java, когда становятся ненужными. В J2ME все аналогично, но стандартный сборщик мусора – это не очень эффективное средство высвобождения памяти. Сборщик мусора запущен как низкоприоритетный фоновый поток, который определяет и удаляет неиспользуемые объекты. Объект является используемым до тех пор, пока он не выйдет за границы области видимости или не станет равным null.