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

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

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

Прежде чем перейти к вопросам оптимизации 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-программировании, и мидлеты не являются исключением. Один из способов минимизировать затраты памяти на объекты – повторно использовать их. При этом отпадает необходимость создавать объекты заново. Конечно, такой подход можно применить только в случае, если необходимо использовать объект одного типа несколько раз, но вы будете удивлены, насколько часто такой метод применим при разработке мидлетов.

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

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

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

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

Минимизация сетевых данных

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