Ознакомительная версия.
int i = 0;
for (int j = 0; j < 100; j++) {
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
a[i++] = 25;
}
В приведенном примере вы сократили число повторений цикла на порядок (с 1000 до 100), но вы загрузили процессор операцией инкрементирования внутри цикла. В целом, приведенный код работает быстрее исходного, однако не ждите чудес. Раскрытие циклов может быть полезным в ряде случаев, но я не советую вам ставить этот метод оптимизации на первое место. Такой метод следует применять в играх, в которых важна каждая миллисекунда производительности.
Сжатие и затенение кода
Когда ваша игра готова к распространению, для сокращения объема кода можно использовать автоматическое средство. Я говорю об инструментах сжатия и затенения кода, которые сжимают код Java-программы и переименовывают переменные, чтобы усложнить процесс восстановления кода. Даже самый тщательно оптимизированный код наверняка будет содержать несколько неиспользуемых пакетов, классов, методов и переменных – именно для этого и нужна программа сжатия кода (shrinker). Программа затенения кода (obfuscator) предназначена не для повышения эффективности кода, а для его защиты и копирования.
Большинство программ сжатия и затенения кода объединены в один инструмент. Например, открытый инструмент ProGuard, служит как для сжатия, так и для затенения кода. Эту программу можно загрузить с адреса http://proguard.sourcesafe.net/. Такие инструменты, как ProGuard вырезают комментарии из кода и неиспользуемый код, а также переименовывают идентификаторы, используя более короткие криптографические имена. В результате получается класс, который на 20–50 % меньше и более защищенный по сравнению с исходным.
Анализ кода мобильной игры
Программисты часто говорят, что 90 % времени выполнения игры тратится на выполнение 10 % игрового кода. Это означает, что лишь малая часть кода действительно отвечает за выполнение игры. Вам необходимо сосредоточить внимание лишь на 10 % кода. Вы можете направить усилия по оптимизации на небольшой фрагмент программы, тогда вероятность создания эффективного мидлета значительно возрастает.
Принципиальная трудность для большинства разработчиков мобильных игр при начале оптимизации заключается не в использовании приемов оптимизации, а в поиске тех 10 % кода, которые будут выполняться 90 % времени. Выявление малой части кода, определяющей быстродействие мобильной игры, – это самая сложная грань процесса оптимизации. К счастью, для решения этого вопроса можно использовать специальный инструмент.
Анализатор (profiler) – это инструмент, которой анализирует программу во время ее выполнения и сообщает, сколько процессорного времени и циклов заняло выполнение определенной части программы. Вы можете изучить данные, собранные анализатором и определить, какая часть вашей программы выполняется чаще всего. Эта информация может указать, где следует приложить усилия и провести оптимизацию, используя приемы и методы, описанные в этой главе.
Пакет J2ME Wireless Toolkit поставляется с анализатором Java, который достаточно прост в использовании. Для начала запустите приложение Preferences (Настройки) стандартной установки J2ME Wireless Toolkit. Перейдите на вкладку Monitor (Монитор), и вы увидите окно как на рис. 17.3.
Рис. 17.3. Вкладка Monitor приложения Preferences позволяет включить анализ мидлетов
Единственное отличие между окном, представленным на рисунке, и окном на экране вашего компьютера может заключаться в том, что у вас, вероятно, не поставлена галочка в окошке метки Enable Profiling (Включить анализ). Поставьте галочку, чтобы разрешить анализ мидлетов. Когда вы щелкнете по кнопке OK, анализатор Java готов, он запустится в следующий раз, когда вы будете использовать эмулятор J2ME.
Следующий шаг – это запустить игру в эмуляторе, например, Henway, разработанную в главе 7. По окончании работы эмулятора приложение анализатора автоматически запускается и показывает вам результаты анализа игры. На рис. 17.4 показан результат анализа игры Henway, проведенный на моем компьютере.
Рис. 17.4. Анализатор J2ME Wireless Toolkit предоставляет детальную информацию о том, в каком месте игрового кода самые большие затраты времени и ресурсов процессора...
Совет Разработчику
Перед тем как использовать анализатор, убедитесь, что вы не применяли к мидлету затенитель кода. Иначе применение анализатора станет бессмысленным.
Задача анализатора Java – подсказать вам, какие части Java-программы потребляют больше всего процессорного времени. Он выводит список всех вызовов в вашем мидлете и показывает, сколько времени было потрачено в каждом из них. Список вызовов, или, как его еще называют, «граф вызовов», представлен в левой панели в виде дерева. Каждый узел-потомок соответствует вызовам соответствующего метода из другого метода, представленного узлом-родителем. Это позволяет точно определить, на что же уходит время.
Колонки в правой панели окна анализатора (рис. 17.4) важны для интерпретации полученных данных:
► Name – полное имя метода
► Count – сколько всего раз вызывался метод
► Cycles – время, потраченное на выполнение данного метода (в тактах ЦП)
► %Cycles – процентная доля времени, потраченного на выполнение данного метода, от общего времени работы программы
► Cycles with Children – время выполнения данного метода и всех вызывавшихся из него (а тактах ЦП)
► %Cycles with Children – процентная доля времени в предыдущей колонке от общего времени работы программы.
Если щелкнуть по любому заголовку, то список отсортируется по соответствующей колонке. Чтобы освоиться с анализатором, взгляните на список методов в правой панели (рис. 17.4). Если сложить процентные доли всех методов, то в сумме всегда получится 100 %. Это понятно, ведь анализатор показывает, как общее время работы программы делится между отдельными методами. Если щелкнуть по знаку «+» слева от имени метода, то соответствующий узел раскроется, и вы увидите как время, проведенное в данном методе, распределяется между вложенными вызовами методов. Так, на рис. 17.4 мы видим, что метод HCanvas.run() потребляет 98 % времени ЦП. А на рис. 17.5 показано, как распределено это время между вложенными вызовами.
Рис. 17.5. Раскрытие узла метода в левой панели анализатора показывает, какие методы вызываются из него
Ага, вот это уже интереснее – выясняется, что в HCanvas.draw() тратится 25 % времени, а в HCanvas.update() – свыше 72 %. Вряд ли это это повергнет вас в шок, но тем не менее анализатор показал, что при работе игры Henway примерно три четверти времени процессор тратит в методе HCanvas.update(). Имея такую информацию, вы сможете понять, куда направить усилия по оптимизации.
...
Совет Разработчику
Анализатор Java не предназначен для моделирования выполнения кода на конкретном телефоне, поэтому очень может статься, что на одних телефонах программа будет вести себя иначе, чем на других. Иными словами, оптимизация, сотворившая чудо в эмуляторе, может не дать столь же ощутимого эффекта при работе на конкретном телефоне. Поэтому так важно тестировать любую проведенную оптимизацию не только в эмуляторе, но и на реальных устройствах.
Помните, что в большинстве случаев анализатор указывает непосредственно на фрагмент кода, который следует оптимизировать. Но даже в этом случае вы должны вникнуть в суть происходящего и вычислить, какие методы занимают большую часть процессорного времени. Затем к выделенному фрагменту кода следует применить методы оптимизации, описанные выше.
Отслеживание загрузки памяти игрой
Кроме анализа кода J2ME, Wireless Toolkit также содержит инструмент отслеживания памяти, который полезно использовать для мониторинга объемов используемой памяти. Монитор памяти можно найти в том же самом приложении Preferences, которое используется для включения анализатора. На рис. 17.6 показано окошко метки Enable Memory Monitor (Включить монитор памяти), в котором поставлена галочка.
Рис. 17.6. Вкладка Monitor приложения Preferences позволяет включить монитор памяти в эмуляторе J2ME
В отличие от анализа, информация которого доступна по окончании работы мидлета, мониторинг памяти осуществляется во время работы. Когда вы включаете монитор памяти и запускаете эмулятор, на экране появляется окно монитора (рис. 17.7), которое начинает отслеживать использование памяти.
Рис. 17.7. Монитор памяти показывает след использованной памяти, который и говорит об использовании игровым мидлетом ресурсов телефона
По умолчанию монитор памяти открывается на вкладке Graph, которая отображает след использования памяти запущенного мидлета. График отражает текущий объем занятой мидлетом памяти. Точное значение можно узнать в стоке статуса, расположенной в нижней части окна. Играя, интересно наблюдать за увеличениями и уменьшениями объема используемой памяти. Вы можете эмулировать запуск сборщика мусора, для чего щелкните по кнопке Run GC, расположенной в верхней части монитора памяти.
Другая вкладка в мониторе памяти – это вкладка Objects (Объекты), которая отображает информацию об объектах в памяти. На рис. 17.8 показаны данные о памяти для игры Henway.
Ознакомительная версия.
