Оптимизация текстурных атласов для мобильных игр

Мы часто видим проекты, где текстурные атласы настроены по умолчанию. Результат — 40–100 МБ лишней памяти и разрушенный batching. В одном из проектов казуальной игры UI-атлас в RGBA32 занимал 64 МБ только на одной сцене. После нашей оптимизации — 8 МБ. В этой статье мы расскажем, как правильно оптимизировать текстурные атласы для мобильных игр.

Почему атласы — узкое место мобильной оптимизации?

Sprite Atlas в Unity — инструмент понятный, но его неправильная настройка стабильно прибавляет десятки мегабайт к памяти приложения и убивает batching. Типичная ошибка: разработчик включил Sprite Atlas, сложил все UI-спрайты в один атлас, доволен — Draw Calls упали с 80 до 12. Но забыл включить Include in Build в настройках. В итоге атлас генерируется в Edit Mode, но в Release-билде каждый спрайт загружается отдельной текстурой.

Другая история: атлас настроен правильно, batching работает, но размер 2048×2048 RGBA32 — это 16 МБ только на одну текстуру без mipmaps. На устройстве с 2 ГБ RAM суммарный UI-атлас из 4 листов съедает 64 МБ. При переключении языков — все 4 листа в памяти одновременно.

Какой формат сжатия выбрать для атласов?

Это самая недооценённая часть оптимизации. Разработчики часто оставляют RGBA32 или RGBA16 для всех текстур, не задумываясь.

ASTC — стандарт для современных мобильных устройств. Поддерживает блочное сжатие с настраиваемым качеством: ASTC 4×4 даёт высокое качество при 8 bpp, ASTC 8×8 — приемлемое качество при 2 bpp. Для атласов UI используем ASTC 4×4 или 6×6. Для фоновых текстур без мелких деталей — ASTC 8×8. По сравнению с RGBA32, ASTC 6×6 уменьшает размер в 6 раз при почти незаметной потере качества.

ETC2 — fallback для устройств без поддержки ASTC. Поддерживает альфа-канал. Для старых проектов с низким уровнем API всё ещё актуален.

PVRTC — форматы для iOS (PowerVR GPU). Требует текстур квадратной формы со стороной в степень двойки. Если атлас 1024×512 — PVRTC применить нельзя без изменения размера.

Официальная документация Unity по форматам сжатия

Реальный кейс: казуальная игра-пазл, Android+iOS. UI-атласы занимали 128 МБ в памяти (RGBA32, 4 листа 2048×2048). После переключения на ASTC 6×6 для iOS и ETC2 для Android: 128 МБ → 22 МБ. Качество на экране телефона — неотличимо. Время загрузки UI-сцены снизилось с 1,8 с до 0,4 с (в 4,5 раза быстрее).

Сравнение форматов сжатия:

Стратегия разбиения атласов

Не все спрайты в один атлас — это путь к проблемам. Правильная стратегия:

По сцене/экрану. Спрайты, которые используются только в меню — в атлас menu_atlas. Спрайты геймплея — в gameplay_atlas. Общие элементы (кнопки, рамки, иконки) — в common_atlas. Это позволяет выгружать неиспользуемые атласы при смене сцены.

По частоте использования. Hotpath-спрайты (HP-бар, прицел, таймер) всегда в памяти → core_hud_atlas. Редкие экраны (настройки, магазин) — выгружаются через Addressables при закрытии.

Ограничение размера листа. 2048×2048 — максимум для мобильных. Часть устройств не поддерживает 4096×4096 для сжатых форматов. В Sprite Atlas Settings устанавливаем Max Texture Size = 2048.

Дубликаты. Unity Addressables Analyze → Check Duplicate Bundle Dependencies обнаруживает спрайты, попавшие в несколько атласов. Типичная причина: shared-спрайт (иконка валюты) использован и в меню, и в геймплее без явного указания атласа.

Почему mipmaps вредны для UI?

Для UI-атласов mipmaps отключаем. UI рендерится в Screen Space, объекты не удаляются от камеры — mipmaps бесполезны и увеличивают размер текстуры на 33%. В Texture Import Settings: Generate Mipmaps = false.

Для игровых текстур (3D-объекты, задний план в 2D с масштабированием) — mipmaps обязательны. Без них aliasing и завышенный texture fetch bandwidth.

Пошаговая настройка атласа для мобильной игры

1. Импортируйте спрайты с настройками: Max Size = 2048, Compression = ASTC 6×6 (или ETC2 для fallback), Generate Mipmaps = false.
2. Создайте Sprite Atlas (V2): Assets → Create → Sprite Atlas.
3. В Inspector: Type = Master, Include in Build = true, Allow Rotation = true, Tight Packing = true, Padding = 4.
4. Добавьте спрайты в Objects for Packing.
5. Разделите по сценам: создайте отдельные атласы для menu, gameplay, common.
6. Для управления памятью используйте Addressables: отметьте атласы как Addressable и выгружайте при смене сцены.
7. Проверьте дубликаты через Addressables Analyze.

Процесс работы над оптимизацией

1. Аналитика. Собираем профили памяти и draw calls на целевых устройствах. Используем Unity Profiler, RenderDoc, GameAnalytics.
2. Аудит атласов. Оцениваем текущую стратегию, форматы, размеры, дубликаты.
3. Проектирование. Разрабатываем новую архитектуру атласов с разбивкой по сценам и частоте использования.
4. Реализация. Перенастраиваем атласы, сжимаем текстуры, интегрируем Addressables.
5. Тестирование. Проверяем память, производительность, качество на устройствах с 2 ГБ RAM и ниже.
6. Деплой. Фиксируем настройки в Version Control, документируем workflow.

Что входит в работу

• Аудит текущих атласов с отчётом по памяти, draw calls и рекомендациями.
• Разработка стратегии разбиения под целевую платформу.
• Настройка сжатия (ASTC, ETC2, PVRTC) с контролем качества.
• Интеграция Addressables для выгрузки атласов.
• Документация по поддержке атласов в проекте.
• Обучение команды работе с новой системой.
• Пост-релизная поддержка в течение месяца.

Мы гарантируем качество: наш опыт — более 10 проектов с оптимизацией под мобильные устройства. Оценим ваш проект бесплатно — свяжитесь для аудита. Закажите оптимизацию атласов и получите до 80% экономии памяти без потери качества.