Unity Developer ни в чем не виноват

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

По ходу своей карьеры - и официальной, и не очень - я не раз сталкивался с повторяющейся картиной. Команда просит помочь разобраться с производительностью: проект не выходит на целевые показатели производительности, сцена вроде несложная, но счётчик FPS грустно припадает к 15. Иногда руководители сообщают, что уже сменили одного-двух разработчиков, а ощутимых улучшений нет. Тестировщики фиксируют: главный поток загружен, GPU отдыхает. И логичным адресатом обратной связи снова становится программист.

Чаще всего это происходило в стартапах и небольших студиях, которые переходили от казуальных 2D-игр к чему-то более сложному в техническом плане - мидкорным 3D-проектам. Переход вроде бы естественный, но вместе с новой графикой приходят и новые требования к организации ресурсов.

Когда проект попадал ко мне, я почти всегда видел одно и то же. Код написан хорошо. Чаще лучше, чем у меня самого: чисто, структурировано, легко читается и расширяемый. Unity-разработчик сделал свою работу отлично.

Но почему тогда у других команд более сложные сцены работают плавно, а здесь - как будто через принтер играешь? Главное различие, которое я для себя отметил, - наличие в команде техартиста. Человека, который умеет разговаривать с движком и его инструментарием, понимает, как работают системы Unity в боевых условиях, и знает, где спрятаны те самые «галочки», способные превратить толковый проект в поток скриншотов.

Показательный случай был в одной компании. Я устраивался туда как Unity-разработчик, но довольно быстро - испытательный срок закончился за семь дней - стал по факту техартистом. Предыдущий специалист на этой позиции не справился с производительностью, хотя это была не совсем его зона ответственности. Первый же поверхностный разбор ассетов и их пересборка дали стабильные 30 FPS. А через три месяца более глубокой и спокойной работы над проектом мы уже спокойно показывали лок в 60 кадров на очень древних устройствах вроде Galaxy A8, что даже привело к перерисовке артбука под более красивую графику. Появился простор для расширения визуала.

Что именно влияло? Список простой и по большей части лежит в плоскости CPU:

- неправильно собранные ассеты; - слабый учёт статичных и динамических объектов; - большое количество скинмешей и аниматоров; - игнорирование пулов; - и даже безобидные на первый взгляд галочки в настройках билда.

Всё это вместе даёт нагрузку именно на процессор. Поэтому при поверхностной проверке в профайлере мы видим CPU под 100%, а GPU отдыхает - и идём ругать разработчика. Хотя по-хорошему стоит посмотреть на работу с движком в целом.

Есть простой способ быстрой самодиагностики. На этапе рантайма в редакторе Unity (берём платформу ARM) обращаем внимание на несколько вещей. Если показатели Batching уверенно выше 150, Saving by Batch около нуля, карты теней пустуют, а в билдовом профайлере скрипты показывают скромную активность, но при этом дикие прогрузы идут по физике и другим юнитевским модулям, - это хороший повод позвать техартиста и вместе спокойно пройтись по проекту.

Я надеюсь, что этот небольшой опыт окажется полезным командам, которые только начинают свой путь к релизу. Всем супер-графики и отличного FPS.