AS3 большая неисправность производительности игры со временем

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

см. Класс пула объектов

Похоже, вам нужно профилировать свое приложение, чтобы увидеть, что происходит.

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

Профилирование кода ActionScript-3

Возможно, вы захотите проверить, можете ли вы просто запускать некоторые более мелкие части в течение определенного периода времени, и посмотреть, не заметите ли вы замедление.

Вы можете захотеть юнит протестируйте свое приложение, чтобы вы могли быстро запускать различные части в поисках утечек памяти. Одна структура: http://asunit.org/ , а другая: http://opensource.adobe.com/wiki/display/flexunit/

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

Вы используете слишком много памяти? Или ваш процессор слишком загружен?

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

Похоже, что вы ограничиваете скорость процессора, а не памяти. Вы должны очень постараться, чтобы ограничить память для Flash-приложения.

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

1) Строгое управление прослушивателями событий для всего ], особенно слушателей мыши. У вас есть слушатели событий $ texas на всех ваших спрайтовых объектах? Это могло быть проблемой.

2) Доступ к массивам с использованием int или uint вместо Number. Это огромно, и это одна из тех захолустных уловок Adobe. Доступ к объекту массива с помощью int и uint происходит намного быстрее, чем Number, и если вы выполняете много итераций (а это похоже на то, что вы делаете), это может сэкономить драгоценные миллисекунды на выполнении вашего кадра.

3) В том же духе, что и # 2 , отслеживайте свои математические операции и типы, которые вы используете для определенных операций. Самое медленное, что вы можете сделать в математических операциях для AS3, - это повторяющееся приведение (передача целых чисел в функцию, возвращающую число) или выполнение базовых операций, таких как сложение и вычитание числа вместо целого.

Самое замечательное в наличии wtfhuge Программа, подобная этой во Flash, заключается в том, что даже незначительное изменение оптимизации может существенно повлиять на производительность. Однажды я играл с движком трассировки лучей в AS3, где я объявил одну дополнительную переменную, и это убило мой FPS с 30 до 23.

Самое замечательное в наличии такой wtfhuge-программы во Flash заключается в том, что даже незначительное изменение оптимизации может существенно повлиять на производительность. Однажды я играл с движком трассировки лучей в AS3, где я объявил одну дополнительную переменную, и это убило мой FPS с 30 до 23.

Самое замечательное в наличии такой wtfhuge-программы во Flash заключается в том, что даже незначительное изменение оптимизации может существенно повлиять на производительность. Однажды я играл с движком трассировки лучей в AS3, где я объявил одну дополнительную переменную, и это убило мой FPS с 30 до 23.

У Flash есть довольно печально известная проблема (многие считают это ошибкой), которая вызывает прослушиватели событий для таймеров и ENTER_FRAME , чтобы не собирать мусор, даже если на них нет ссылок. Таким образом, даже несмотря на то, что использование событий со слабыми ссылками является хорошей практикой, вы все равно должны удалить все прослушиватели событий, когда они больше не нужны.

• Избегайте анонимных методов - замените их методами уровня класса.
• Используйте слабую ссылку в addEventListener и / или убедитесь, что вы удалили всех слушателей объекта, прежде чем удалять его с помощью removeChild
• Убедитесь, что вы удалили все спрайты, а не просто позволили им улететь за пределы экрана. Также, если возможно, повторно используйте спрайты вместо создания новых.