Оптимизация 2d-приложений для мобильных устройств в Unity3d
Недавно наша студия завершила разработку большого обновления — Captain Antarctica: Endless Run — для устройств на iOs. Кропотливая работа над обновлением затронула производительность, которая оказалась очень низкой на слабых устройствах. Я боролся с этим целую неделю и добился как минимум 30 FPS, а также значительного сокращения размера приложения. Хочу рассказать, как я это сделал, ну и как делать не стоит.
Статья пригодится любым разработчикам на Unity (причем не только менеджерам проектов и техническим специалистам, но и просто программистам, художникам и дизайнерам), потому что она затрагивает как оптимизацию на Unity в целом, так и конкретно оптимизацию 2d-приложений для мобильных устройств. 
Возможно все!
Начну с того, что каждый раз, когда я приступаю к оптимизации, я поначалу не верю, что можно что-то еще оптимизировать, особенно если проект уже прошел несколько циклов оптимизации до этого. Но просмотр официальной документации Unity, тем на форумах, статей в Интернете наводит меня на мысль о новых возможных улучшениях. Таким образом я веду специальный список, в котором записаны основные идеи по тому, что можно оптимизировать в проекте на Unity, постоянно обновляю его и первым делом обращаюсь к нему, когда речь заходит об оптимизации. Этими идеями я хочу с Вами поделиться. Надеюсь, статья поможет Вам сделать Ваш проект намного более шустрым.
Сразу обозначу, что разработка велась на Unity 3.5.6, целевая платформа — устройства Apple от iPhone 3GS и новее.
Базовые правила
Для начала приведу несколько правил, которыми я пользуюсь при разработке и оптимизации.
1. Не оптимизируйте заранее.
Это золотое правило должно быть знакомо всем, кто когда-либо занимался оптимизацией. Вспомним правило 80/20: 80% пользы получается от 20% работы. 
Цифры довольно условны, но я имел ввиду вот что: наиболее вероятно, что большая часть оптимизаций, которые Вы собираетесь сделать на начальном этапе проекта, скорее всего вообще никак не повлияет на конечный проект в целом.
Однако, есть пара исключений из этого правила, которые особенно важны при разработке для мобильных устройств, потому что это правило больше подходит для PC-проектов. А PC намного производительнее мобильных платформ и менее ограничены в ресурсах. Так вот, исключения:
- Допустим, есть код, или конструкция, которую вы уже сейчас знаете, как написать лучше, с меньшей затратой по памяти/процессора и тд. Вы об этом знаете по своему опыту, потому что не раз оптимизировали компоненты подобного рода, и знаете, что это приводит к увеличению производительности. Так почему бы уже сейчас не написать ее правильно? Обычно такие вещи складываются в свод правил типа «как правильно писать код, и как писать не надо», и грамотный программист постоянно им пользуется во избежание ошибок в будущем. Нечто подобное имеет место для художников, дизайнеров и тд.
- Если есть действие, которое будет повторяться много раз, и с самого начала можно его оптимизировать, почему бы это не сделать сразу. Дальше все будет идти автоматом, и не нужно будет исправлять одну и ту же вещь несколько раз. Сюда относятся, например, вспомогательные скрипты, помогающие дизайнерам ускорить однообразную работу с группой объектов.
Что мне помогло решить проблему с производительностью?
Еще до прогона через профайлер было очевидно, что слабое место — в кол-ве Draw Calls. В среднем сцена выдавала порядка 70 DrawCalls, что для устройств уровня iPad1 и ниже является фатальным. Нормально для них — 30-40 Draw Calls. Посмотреть кол-во Draw Calls можно прямо в редакторе в окне Game->Stats:. 
Кол-во Draw Calls, показываемых в редакторе, совпадает с таковым на конечных устройствах. Профайлер это подтвердил. Вообще, очень полезно смотреть эту статистику, и не только программистам, но и дизайнерам, для нахождения «тугих» мест в игре.
В наших сценах плохо работало группирование нескольких Draw Calls для одного и того же материала в один Draw Call. Это называется Dynamic Batching. Я начал рыть на тему «как понизить кол-во Draw Calls и улучшить их группирование». Ниже перечислены основные правила, придерживаясь которых, можно получить приемлемое количество Draw Calls. Вот те, которые мне очень сильно помогли:
1. Использовать атласы для комбинирования нескольких текстур в одну большую.
На самом деле важнее даже, чтобы спрайты/модели использовали не то что бы одну общую текстуру, а скорее один общий материал. Именно в кол-ве различных материалов измеряется кол-во Draw Calls (в идеальном случае). Поэтому у нас в проекте используемые изображения всегда объединены в атласы, разбитые на категории: объекты, используемые на всех сценах, объекты GUI, задний фон и тд. Вот пример такого атласа: 
Такое разбиение так же будет полезно в будущем для применения к текстурам различных настроек. Но об этом позже.
2. Не стоит изменять Transform->Scale.
Объекты с измененным Scale попадают в отдельную категорию, увеличивающую кол-во Draw Calls. Я заметил это, когда еще раз проходился по документу Draw Call Batching. Вот что значит перечитывать;) Пройдясь по сцене, я обнаружил огромное количество таких объектов: 
- Оказалось, что дизайнеры уже давно увеличили некоторые часто используемые объекты в 1.2 раза через Scale прямо в прифабе объекта. В итоге, мы пришли к решению увеличить их размер прямо в текстуре. Это к тому же соблюдало условие пиксель-в-пиксель, что очень важно для 2d-игры.
- Были объекты, которые имели одно и то же изображение, но разный Scale. Для таких объектов был написан специальный скрипт, который переводил нужный Scale с Transform прямо на меш, используемый для спрайта, т.е. менял размер меша и оставлял Scale = (1, 1, 1).
- Также Scale часто использовался у нас для отражения объекта, например, Scale.x = -1 отражает объект слева направо. Все такие скейлы были заменены на соответствующие им повороты.
- Еще у некоторых объектов Scale был изменен в анимации, пару раз неоправданно. Не забывайте проверять анимации, часто изменения в них — неявные, и могут быть обнаружены только после запуска.
Еще несколько подсказок (взятых в том числе из документа Unity), как сократить количество Draw Calls:
- Статические объекты могут быть помечены как Static. Тогда будет использоваться Static Batching (только в Pro-версии), который тоже поможет сократить кол-во Draw Calls.
- Старайтесь использовать объекты с одним и тем же материалом на одном и том же расстоянии от камеры. Пример: у нас различия по расстоянию в 10 юнитов уже давали 1-2 дополнительных Draw Call. При этом какая-то особая закономерность выявлена не была, но я подозреваю, что есть связь между размерами камеры, размерами объектов, их расстоянием до камеры и количеством Draw Calls. Экспериментируйте!
- Старайтесь, чтобы объекты с разными материалами не перекрывали друг друга. Это тоже увеличивает кол-во Draw Call, особенно для полупрозрачных объектов.
- Многопроходные (multi-pass) шейдеры увеличивают количество Draw Call. У нас таких не было, но полезно будет учесть это в будущем.
- Каждая система частиц дает 1 Draw Call. (Имеется ввиду старая система частиц Unity 3.5.6, используемая нами по сей день. Как обстоят дела в Unity 4, я не знаю). Поэтому если на экране одновременно N систем частиц — это автоматически как минимум N Draw Calls. Обычно, одного и того же эффекта можно достигнуть разными способами, в том числе меньшим числом как систем частиц, так и частиц в системе. Часто видел, как начинающие дизайнеры эффектов используют огромное кол-во частиц (и огромный размер самих частиц), чтобы создать вау-эффект. При этом они не думают о производительности (особенно учитывая, что все это делается в редакторе на PC) и обычно достаточно меньшего количества частиц, чтобы достичь того же эффекта.
Скачки производительности
Второй фактор, влияющий на производительность — так называемые скачки производительности. Порою в игре были «зависания» на 0,5-1 секунду, что конечно же было неприемлемо и напрямую влияло на геймплей. Причем такое наблюдалось даже на самых последних устройствах.
И в этом случае помог профайлер! Вот список правил для уменьшения скачков производительности:
1. Старайтесь не использовать Instantiate(), особенно для сложных объектов.
Скачки производительности приходились в основном на вызовы Instantiate(), которые создавали новые объекты из прифабов, или клонировали существующие. Причем некоторые объекты были очень громоздкими, что и повлияло на время их создания. Вместо этого пришлось переписать систему так, чтобы объекты использовались заново. Т.е. состояние объекта после окончания использования (или перед использованием) приводилось к начальному. Это также помогло сократить объем используемой памяти (так как на новые объекты больше не нужно было новой памяти) и количество вызовов Destroy().
2. Минимизируйте количество вызовов Destroy().
Destroy (особенно для больших объектов) почти всегда приводит к манипуляциям с памятью. А это обычно плачевно сказывается на производительности. Это правило напрямую связано с правилом выше, ибо вызовы Instantiate()/Destroy() обычно связаны. Таким образом, использование объектов заново лишило необходимости уничтожать их.
3. Минимизируйте вызовы gameObject.SetActiveRecursively().
Для сложных объектов вызов может быть очень долгим, потому что он предполагает не просто активацию объектов и их компонентов, но в некоторых случаях и загрузку необходимых ресурсов.
4. Минимизируйте вызовы Object.Find().
Думаю, не стоит объяснять, что время этой операции зависит от кол-ва объектов на сцене. Сюда же относятся функции типа GetComponent().
5. Минимизируйте вызовы Resources.UnloadUnusedAssets() и GC.Collect().
Unity иногда сама прибегает к ним, если недостаточно памяти для загрузки нового ресурса или пришел запрос от ОС освободить неиспользуемую память. Таким образом, первые 2 правила автоматически сокращают кол-во таких вызовов. Лучшее место для вызова Resources.UnloadUnusedAssets вручную — перед загрузкой сцены или непосредственно сразу после ее запуска. Это также поможет освободить дополнительную память для сцены, что иногда бывает критично. Соответствующий скачок производительности можно скрыть, например, экраном загрузки;)
Использование правил выше привело к устранению скачков производительности и намного более плавным геймплею и картинке.
Другие оптимизации
Далее привожу другие правила, которые могут помочь Вам. Большинством из них я сам пользовался на предыдущих этапах оптимизации.
Скрипты
- Не используйте GetComponent<>() в Update, FixedUpdate и других подобных функциях. Вместо этого лучше кэшировать компонент в Awake() или Start(). Если объектов, использующих скрипт, очень много, такое кэширование может значительно сократить время работы скрипта.
- Кэшируйте встроенные компоненты типа transform, renderer и тд. Особенно если они используются в функциях типа Update(). Ибо каждый такой вызов делается через GetComponent(). См. правило выше. Это можно сделать, например, так:
- Используйте Vector2(3,4).sqrMagnitude вместо magnitude.
- Используйте Color32 и Mesh.colors32 вместо Color и Mesh.colors при доступе к цветам меша.
- Можно использовать OnBecameVisible/OnBecameInvisible для скриптов, которые могут быть отключены, когда камера больше не видит объект.
- Используйте встроенные массивы. Имеются ввиду массивы типа T[]. Они намного быстрее всех остальных коллекций.
- Отключите логи при работе приложения на устройстве. Обычно печать лога требует доступа к файловой системе, а если логов много, это может привести к печальным последствиям для производительности.
- Отключите исключения. Как следствие — старайтесь не использовать их в коде. Отключение исключений поможет сохранить до 30% производительности. Но не забывайте, что если ошибка произойдет, и она не сможет быть обработана исключением — это падение приложения на устройстве. Поэтому приходится выбирать — либо хорошее тестирование и прирост производительности, либо надежность, но производительность чуть хуже. В случае, когда производительность удовлетворяет, преимущество лучше отдать второму варианту.
Физика
- Чем меньше одновременно активных Rigidbody, тем лучше. Деактивируйте неиспользуемые.
- Сокращайте количество FixedUpdate в единицу времени. Fixed Time = 0.03333 гарантирует физику со скоростью 30 вычислений в секунду, что обычно очень неплохо. Даже 20 может быть приемлемым, что соответствует Fixed Time = 0.05.
- Минимизируйте использование Continuous или Dynamic collision detection. Они очень ресурсозатратны. Для 2d-игр они обычно не нужны.
Анимации
- Следите за количеством анимированных объектов на экране. Чем меньше — тем лучше.
- Вместо нескольких простых анимаций на сложном объекте, можно сделать одну сложную, делающую то же самое.
- Можно попытаться уменьшить Sample Rate у клипа. Особенно если анимаций очень много.
- Используйте Culling Type = Based On Renderers или Based On User Bounds. Тогда анимация будет проигрываться только тогда, когда объект виден на экране.
Если это, конечно, устраивает.
Система частиц
- Используйте Vertical Billboard вместо Billboardв Particle Renderer.
- Используйте на мобильных устройства шейдеры из Mobile->Particles. Это касается не только системы частиц.
- Используйте как можно меньше систем частиц и самих частиц в системе для достижения нужного эффекта.
- Для слабых систем можно отключить некоторые малозаметные или несущественные системы частиц. Что позволит сохранить несколько Draw Calls и поднять на них производительность в ущерб эффектности. Уверяю, зачастую приятнее получать удовольствие от процесса игры, нежели от мегакрутых эффектов.
- Не используйте OnGUI(). Каждый такой вызов — несколько дополнительных Draw Calls. Тоже самое относится к GUILayout. И вообще, поддержка GUI в Unity сделана очень плохо. У нас, например, своя система GUI, основанная на спрайтах. В Asset Store есть несколько других очень полезных плагинов для GUI.
- Размер текстуры, генерируемой для шрифта, можно уменьшить, добавив только используемые символы. В Font Settings установить Character = Custom Set, а в Custom Chars включить используемые символы:
- Можно попробовать использовать отдельные камеры для объектов сцены и GUI. Это позволит сделать GUI zoom-независимым, что освобождает от использования на нем Scale при увеличении/уменьшении. Иногда это может увеличить производительность.
Другое
- Отключить акселерометр, если он не используется. Можно также понизить частоту измерений в Player Settings.
- Можно ограничить максимальный FPS на старых устройствах. Например, установив его в: Application.targetFrameRate = 30 . Обычно это приводит к более гладкой картинке. Также, это уменьшает просадку аккумулятора, т.к. за то же время требуется меньше процессорной мощности. Вообще, на устройствах Apple FPS > 60 не имеет смысла, т.к. частота обновления экрана у них — 60.
- Иногда периодическая частая сборка мусора сглаживает производительность. Потому что сама система делает это редко и когда уже все совсем плохо, и может накопиться большое кол-во объектов для уничтожения, что приводит к скачку производительности. Если делать это чаще, объектов для уничтожения будет меньше, и освобождение памяти будет более гладким. С другой стороны, за все время работы сцены сборка мусора может и не понадобиться.
Уменьшение размера приложения
Для чего это может понадобиться? Раньше это делалось потому, что приложения размером <20Mb можно было загружать на iOS через 3g-сеть. Что в принципе должно увеличить кол-во закачек, хотя конкретной статистики я не видел. В связи с выпуском iPad3 приложения стали «жирнее», и порог был поднят до 50Mb. Не стоит также забывать, что после заливки приложения в AppStore оно будет увеличено в размере в среднем на 4Mb. Для проверки, сколько приложение будет весить после заливки в AppStore в xCode в Organizer->Archives даже появилась специальная кнопочка Estimate Size: 
1. Используйте правильный формат текстуры.
Это также позволит уменьшить объем используемой текстурной памяти, а соответственно и повысить производительность. Иногда достаточно использовать формат текстуры 16 bits, особенно если вся графика нарисована всего в нескольких цветах. Сравните: 
Для монотонных текстур можно использовать только ее серую и альфа-компоненту и лепить из них готовый объект, используя специально написанный для этого шейдер и умножение на цвет: 
Для задников и нечетких объектов можно использовать компрессию. Сейчас PVRTC-компрессия на iOS довольно продвинутая. Стоит помнить, что чем больше текстура — тем лучше ее качество после компрессии. На маленьких текстурах использование компрессии может быть неприемлемым.
Чтобы это все имело смысл, нужно разделять объекты на группы типа «задний фон», GUI, игровые объекты, о чем я уже писал. Тогда на каждый тип можно завести свой атлас и использовать различные настройки формата текстуры.
Гайд по оптимизации мобильных игр в Unity
Всем привет! Меня зовут Илья, я работаю разработчиком мобильных игр на Unity вот уже несколько лет и сегодня хотел бы поделиться небольшим чек-листом (или гайдом) по оптимизации мобильных игр для начинающих. В этой статье мы коснемся как графических, так и других аспектов оптимизации «на скорую руку» когда вам нужно быстро поднять FPS ваших мобильных игр.
По большей мере речь пойдет про оптимизацию 2D игр, чтобы их можно было запустить даже на кипятильнике.
Итак, с предисловием закончили. Поехали!
1) Постарайтесь использовать одну камеру на сцене. Чем больше камер вы используете, тем выше нагрузка на CPU.
2) Избегайте использования пост-обработки, это серьезно увеличивает нагрузку на GPU за счет того, что движку приходится обрабатывать повторно каждый кадр при отрисовке.
4) Используйте MSAA не выше 4X на любых мобильных платформах.
5) Используйте Forward-режим рендеринга без использования HDR, чтобы снизить нагрузку на GPU.
6) Выставьте необходимые Clear Flags на камере, чтобы указать, что нужно очищать при рендеренге каждый кадр.
7) При разработке 3D игр, также настройте допустимый Clipping Planes для ограничения области прорисовки дальних объектов.
1) Старайтесь использовать облегченные API, как Vulkan или Metal если это возможно. Для 2D игр достаточно OpenGL 2.
2) Используйте Occlusion Culling для выгрузки объектов вне поля зрения.
3) Используйте только запеченное освещение, тени и Reflection Probes (от них лучше отказаться вовсе). Не используйте ни в коем случае Realtime расчеты.
4) Старайтесь использовать Static и Dynamic Batching для ваших объектов для объединения геометрии.
5) Старайтесь не использовать процедурные системы частиц.
6) Старайтесь по минимуму использовать анимации. Где это возможно, анимируйте объекты через ваши скрипты или, к примеру через DOTween.
7) Установите значение флага «Realtime Pixel Lights» на 0, если это возможно.
8) Выключите Soft Particles.
9) Старайтесь использовать простые шейдера с минимальным количеством инструкций.
10) Избегайте сэмплинга в Reflection Probes.
11) Используйте общий материал для ваших объектов.
12) Используйте Gamma рендеринг вместо Linear.
13) Постарайтесь использовать URP-рендеринг вместо Legacy (Built-in).
14) Постарайтесь изучить и использовать ShaderVariants в вашем проекте., для уменьшения нагрузки на GPU.
15) При добавление/удалении шейдеров в проекте, держите актуальным список Always Inculded Shaders.
16) Иногда требуется разогреть видео-чип перед стартом игры, чтобы исключить микро-фризы при первой отрисовке объекта. Для этого вы можете прогревать их в процессе загрузки игры, инициализируя объекты на сцене Preload.
1) Используйте Sprite атласы для интерфейсов и объединения графики в единый спрайт. Таким образом ваши объекты будут занимать меньше памяти на GPU. Желательно использовать последнюю версию инструмента для работы с атласами.
2) Постарайтесь избегать прозрачности в спрайтах.
3) Включите «Optimize Game Objects» при импорте мешей с ригом.
4) Минимизируйте количество деревьев в анимации.
5) Уменьшите количество костей и вертексов для анимации.
6) Используйте уровни отрисовки (LOD) для дальних объектов (касаемо 3D графики).
7) Избегайте Multi-Pass шейдеров.
8) Попробуйте использовать стриминг текстур.
9) Настройте оптимальные параметры для компрессии текстур, 3D моделей, анимаций и другого контента. Если есть необходимость — настройте MIPMAPS для тяжелых объектов.
10) Отключите Read/Write в импорте ассетов, где это возможно.
11) Настройте предзагрузку шейдеров, которые необходимы в геймплее.
12) Отключите все анимационные контроллеры. Включайте их только при необходимости, поскольку даже пустые Animation Controller создают нагрузку на GPU.
13) Не воспроизводите вместе Unity-анимации и DOTween анимации.
1) Используйте Sprite атласы. Это важно!
2) Избегайте изменения на UI каждый кадр отрисовки. Лучше изучите как работают события и делайте изменения через слушатели.
3) По возможности откажитесь от Rich Text, автоматической подгонки размера текста. В идеале — лучше использовать TextMesh вместо Unity Text.
4) Не используйте автоматическую систему слоев в UI. Также постарайтесь сократить количество UI слоев до 2х.
5) Настройте материалы у вашего UI. Не используйте UI без материалов, желательно не использовать стандартные шейдера.
6) Старайтесь не использовать пустые и невидимые объекты с компонентами Image. Все они влияют на нагрузку GPU.
1) Включите Straming на длинных аудио-клипах.
2) Отключите предзагрузку аудио-файлов там, где она не нужна.
3) Настройте оптимальную компрессию аудио.
4) Ограничьте хранение ссылок на аудио в памяти.
5) Настройте Bufffer size на Best perfomance.
6) Отключите все Plugins для Audio. Уменьшите количество потоков в половину от стандартного значения.
7) При правильном использовании Mixer можно снизить нагрузку на CPU, разбив отдельные звуки как дорожки микшера.
1) Настройте Addressables вместо Asset Bundles. Обо всех преимуществах в экономии памяти вы можете почитать на сайте Unity.
2) Избегайте использования ресурсов из директории «Resources».
3) Уменьшите размер вашей сборки при помощи CDN и последующей загрузки с него ресурсов.
1) Не используйте бесконечные Coroutine-функции, старайтесь минимизировать их размер.
2) Используйте пулы объектов, вместо реинициализации и уничтожения объектов со сцены.
3) Используйте ваш менеджер управления состояниями. Старайтесь не использовать обновления состояния объектов через Update.
4) Старайтесь убрать все неиспользуемые ссылки в объектах. Старайтесь не использовать на глобальных объектах тяжелых ссылок.
5) Постарайтесь вручную контролировать Garbadge Collector.
6) Избегайте генеративных методов Garbadge Collector-а, таких как FindObjectsOfType.
7) Избегайте боксинга/анбоксинга в C#.
8) По возможности, старайтесь не хранить ссылки на все подряд в памяти. Для удобства, можете использовать Zenject для внедрения зависимостей.
9) Не используйте SpriteAtlas.GetSprite во избежание утечек памяти.
1) Оставьте только те Build Targets, которые вы хотите использовать.
2) Используйте IL2CPP вместо .Net компиляции при публикации вашего приложения.
3) Используйте GPU Skinning, если это возможно.
4) Не забудьте выставить флаг «static» у тех объектов на сцене, которые являются статичными.
5) В иерархии сцены, постарайтесь не использовать динамичные объекты с большим количеством дочерних или родительских объектов.
6) Включите Multithreaded rendering и Graphics Jobs в настройках проекта.
Соблюдая данный чек-лист вы сможете добиться значительного уменьшения Draw Calls, а также оптимизировать без лишних затрат ваш проект. Желательно задуматься об оптимизации вначале работы над вашим проектом, поскольку это может сэкономить вам нервы в дальнейшем.
Надеюсь, вы подчерпнули для себя что-то новое. И буду рад вашим дополнениям!
P.S. Если будет интерес, в следующих статьях могу подробнее рассказывать о каждом разделе с подробным объяснением и сравнениями.
1. Не используйте этот чеклист пока не сделали первую игру
2. Не используйте этот чеклист пока не понимаете что значит любой из этих пунктов
3. Не думайте об оптимизации, думайте о геймплее, когда ваша игра взорвет рынок — наймёте Илью Сергеича и он оптимизирует вам игру.
Если заранее об оптимизации хоть чуть чуть подумать то это может сыграть на руку. Тот же Google play больше шансов даст фичеринг для более оптимизированной игры.
большинство пунктов выполняются автоматически, реально полезные советы — про пулы и переход на LWRP
Который будет хранить тысячи лишних ссылок вместо вас (:
Ну на большом проекте все же это будет куда удобнее и для гейм дизайнеров и для разработчиков.
Тестировал производительность URP и он всегда был медленее чем Built-In рендеринг.
То же самое с Вулканом против OpenGL.
Хм, у меня обратная картина. Возможно стоит изучить старые устройства. Но для 2d графики opengl 2 будет эталон если не использовать какие то новороченные функции.
Делать анимации скриптами прожорливее ��
Нет, простые анимации лучше сделать кодом, а не при помощи системы анимаций Unity. Она более прожорливая
Верно. Анимация — это заранее заданный путь для движения монетки например. Он один раз в памяти прописался и спокойно выполняется по кругу, то есть один раз съест немного оперативки и совсем немного процессора будет жрать в процессе выполнения. Через скрипт анимация может жрать сильно больше оперативки и процессора, просто потому что каждый следующий кадр приходится про считывать куда поместится монетка например
Что за автоматическая система слоёв, поясните, пожалуйста.
Content size fitter в сочетании с другими элементами, например Vertical Layout Group
Тестировал на мид/лоу-енд девайсах. На топовом железе разницы не сильно видно.
У меня лично URP помог таки поднять FPS на 2D игре. Возможно суть не в самом URP, а в шейдерах
Где Jobs? Б-г послал вам 8-ядерники, а вы ими пренебрегаете.
Как минимум в 6ом пункте последнего абзаца ��
А это что значит?
Built in шейдера напичканы слишком разной всячиной которая по факту не нужна на 90% проектов.
Интересный кейс, надо будет разобрать. Возможно есть ряд gpu которые умеют с ним работать.
Очень познавательно, с удовольствием почитал бы более подробные материалы на эту тему!
16) Иногда требуется разогреть видео-чип перед стартом игры, чтобы исключить микро-фризы при первой отрисовке объекта.
На сковороде прогреть лол. Вот кому поможет этот совет? Речь идёт о компиляции шейдеров. Так и пишите это. Скомпилируйте все необходимые шейдеры заранее используя ShaderVariantCollection. Делать это нужно один раз при запуске игры. Если шейдеры уже скомпилированны, повторной компиляции не будет. Инициализовать объекты ради компиляции шейдеров не нужно.
Не только в шейдерах дело, в том то и дело. Есть ещё текстуры и прочее. Да, термин прогреть немного странный �� это больше касается динамики, в частности партиклы
Я, конечно, не гуру, но все же.
Работа с камерой:
1) Одну камеру использовать не всегда удобно и выгодно с точки зрения оптимизации. Часто можно одной камерой рисовать трехмерную сцену, а другой камерой рисовать меню например (да как угодно можно).
7) Лучше нормально лоды сделать и не выдумывать.
Работа с рендерингом:
4) Это не имеет смысла часто. Лучше бы расписали что это такое и зачем.
6) Анимации гораздо эффективнее работают зачастую, они позволяют заранее запомнить то, что должен высчитывать скрипт каждый кадр.
16) Тут прямо очень надо разъяснить.
Работа с ресурсами:
1) Это тоже далеко не всегда сработает, есть куча особенностей работы с атласами, часто они могут только навредить (например можно получить атлас, который начнет крашить айфоны из-за своих размеров).
2) А почему? Вот это было бы полезно расписать. Прозрачность не плохая сама по себе, она просто плохо сжимается.
13) Не вижу в этом ничего плохого.
Оптимизация кода:
1) В этом нет ничего плохого, часто через них выгоднее сделать логику даже. Лучше распишите почему считаете их неэффективными.
2) Часто это отнимает ценную оперативку т увеличивает нагрузку на процессор (нужно как-то управлять пулом)
6) В этом нет ничего плохого, если они выполняются не часто, при инициализации например
Настройка Player Settings:
2) Это имеет очень много подводных камней.
5) Почему этот пункт здесь?
6) При неумелом использовании это только навредит
По итогу я специально придираюсь, уж извините, но мне кажется, что многое в статье не поможет, а часто даже навредит, начинающим разработчикам
Практическое руководство по оптимизации для мобильных
Это руководство предназначено для новичков в мобильном геймдеве. Для тех, кто испытывает трудности при планировании и прототипировании новой мобильной игры (или портировании уже существующего проекта). Также этот раздел будет полезен в качестве справки для каждого, кто делает мобильные или браузерные игры (с целевой платформой — старые ПК или нетбуки).
Оптимизация вообще широкая тема, и то как вы ее сделаете, целиком зависит от вашей игры, поэтому данное руководство следует рассматривать как некое введение или ссылку, а не пошаговое руководство.
Мобильные устройства не созданы одинаковыми
Информация здесь предполагает аппаратное обеспечение на уровне чипсета Apple A4, который используется в оригинальных iPad, iPhone 3GS и третьем поколении iPod Touch. Из Android предполагается устройство подобное Nexus One, или большинства устройств, работающих на Android 2.3 Gingerbread. В основном, эти устройства были выпущены в начале 2010 года. Эти устройства старее, медленнее современных, но так как они составляют большую часть рынка, их также следует поддерживать.
Есть очень быстрые и очень медленные телефоны. Вычислительные мощности мобильных устройств растут с потрясающей скоростью. Для нового поколения мобильной GPU, быть в 5 раз быстрее своего предшественника — обычное дело. Скорость мобильных устройств уже сравнима со скоростью ПК.
Для обзора технических характеристик мобильных устройств от Apple, см. Hardware.
Если вы хотите разрабатывать под мобильные устройсва, которые станут известными в будущем, или эксклюзивные high end устройства прямо сейчас, вы можете это сделать. См. Мобильные устройства будущего.
Очень низкая производительность (например, iPhone 3G или первое и второе поколение iPod touches) требует особого внимания к оптимизации. В противном случае могут возникнуть проблемы когда покупатели, не обновившие устройства, будут покупать ваши приложения. Если же вы делаете бесплатное приложение, можно не беспокоится о поддержке старых устройств.
Оптимизацию не следует считать последней стадией разработки проекта
Британский ученый Майкл А. Джексон часто цитируется своими Правилами оптимизации программ:
_Первое правило оптимизации программы: не делаете ее. Второе правило оптимизации программы (только для экспертов!): не делайте ее пока что.
Он обосновал это тем, что учитывая рост скорости компьютеров, ваша программа будет достаточно быстрой. Кроме того, если вы попытаетесь слишком много оптимизировать, то сильно усложните код, ограничите себя и создадите много ошибок.
Однако, если вы разрабатываете мобильные игры, есть еще одно мнение: аппаратное обеспечение, представленное сейчас на рынке, сильно ограничено по сравнению с компьютерами, которые мы используем для работы. Поэтому высок риск того, что ваша ваша игра не будет работать на большинстве устройств и оптимизацию рекомендуют делать с самого начала разработки.
В данном руководстве мы постараемся указать ситуации, когда оптимизация сыграет большую роль в производительности, по сравнению с обратными ситуациями, когда оптимизация большого значения не имеет.
Оптимизация: Не только для программистов
Художникам тоже полезно знать ограничения платформы и методы, которые используются для того, чтобы их обойти. Зная это, они могут принимать креативные решения, которые в итоге сэкономят их труд.
- На художника ложится большая ответственность. Если дизайн игры предполагает атмосферность и освещение, их можно нарисовать в текстурах вместо запекания.
- Каждый раз, когда что-либо может быть запечено, художники могут готовить контент для выпекания, вместо рендеринга в реальном времени. Это позволяет им игнорировать технические ограничения и работать свободно.
Планируйте игру так, чтобы во время исполнения она работала “плавно”.
Эти две страницы детально описывают основные тенденции в игровой производительности и объясняют, как лучше спланировать оптимизацию своей игры или как интуитивно выявить места, нуждающиеся в оптимизации (в случае, если игра уже вышла в продакшн).
Профилируйте на ранней стадии и почаще
Профилирование важно, потому что оно поможет выяснить, какие оптимизации действительно приведут к большому приросту производительности, а какие являются пустой тратой вашего времени. Благодаря тому, что рендеринг обрабатывается на отдельном чипе (GPU), отрисовка одного кадра занимает в два раза меньше времени (только GPU, а не CPU + GPU). Это означает, что если CPU замедляет работу, оптимизация ваших шейдеров вообще не повысит частоту кадров, и если GPU замедляет работу, не помогут оптимизация физики и скриптов.
Часто бывает так, что разные части игры и разные ситуации работают по разному, так что одна часть игры может привести к 100 миллисекундным кадрам полностью из скрипта, а другая может привести в замедлению игры, потому что в данный момент что нибудь рендерится. Поэтому, если вы собираетесь оптимизировать свою игру, нужно по крайней мере выявить узкие места.
Внутренний Профайлер
Профайлер в Unity в основном используется при ориентации на iOS и Android. См. Руководство по профайлеру для основных инструкций по его использованию.
Внутренний Профайлер
Внутренний профайлер выкидывает текст каждые 30 кадров. Это поможет вам выяснить, какие аспекты вашей игры замедляют ее, будь то физика, скрипты, визуализация, но без множества деталей (например, только название скрипта или визуализации).
См. Встроенный Профайлер для подробной информации о том, как это работает и включается.