Как вы уменьшали количество мусора при инициализации Spine-анимаций?

Снижение объёма мусора при инициализации Spine-анимаций

• Проанализировал работу Spine runtime и источники нагрузки на GC
• Кэшировал объекты (Skeleton, AnimationState), чтобы использовать их повторно
• Применял пул объектов для сокращения числа аллокаций
• Сократил создание временных векторов, массивов во время каждого обновления
• Заранее инициализировал ресурсы (атласы, скелеты) до запуска runtime
• Оптимизировал циклы обновления: убрал ненужные конвертации и промежуточные объекты
• Для поиска "горячих точек" использовал профилирование памяти (Unity Profiler, Instruments)
• В результате уменьшилась частота срабатывания GC, а FPS стал выше

Такой подход устраняет непредсказуемые выделения памяти и повышает производительность при запуске Spine-анимаций.

Развёрнутый ответ

Основной ответ

Чтобы сократить количество мусора при инициализации Spine-анимаций, я применял несколько методов, связанных с уменьшением аллокаций и повторным использованием данных. При загрузке Spine-анимаций создаётся много объектов: например, данные скелета (skeleton), keyframes и временные структуры, необходимые для промежуточных вычислений. Контроль объёма мусора особенно важен для стабильной работы на мобильных устройствах и в проектах с высоким фреймрейтом.

Основные приёмы

• Для повторного использования skeleton, attachments и временных буферов применял object pooling. Это заметно уменьшало нагрузку на сборщик мусора, в частности при повторной инициализации и переключении анимаций.
• Анимации и skeleton-данные инициализировал заранее, в фоновом потоке, например во время загрузки уровня. Благодаря этому во время игрового процесса не возникали "подвисания", связанные с крупными аллокациями в критической секции рендеринга.
• В методах обновления Spine переработал создание временных объектов: новые массивы и структуры заменил заранее выделенными буферами, которые можно использовать повторно. В операциях интерполяции keyframe часть аллокаций также удавалось устранить за счёт локального кеширования.

Практический пример

В проектах на Unity 2019+ со Spine Runtime версии 4.x я кэшировал skeleton data и собирал анимации при запуске сцены, а не при каждом включении анимационного объекта. Чтобы сократить число вызовов GC, использовал собственный пул объектов и контролировал, чтобы логика обновления не создавала лишние временные GC-объекты, такие как List или новые классы. Это помогало сохранять стабильный FPS и уменьшать пиковую нагрузку на GC, особенно на Android-устройствах с ограниченной производительностью.