как уменьшить размер unity приложения

Уменьшение размера файла сборки Android в Unity

Размер сборки — важная характеристика мобильного приложения. Если приложение весит много, оно первым будет удалено при чистке. Также меньший размер может ускорить запуск, установку, скачивание.

Даже пустой проект в Unity весит очень много. Пустой проект под Android с настройками по умолчанию в Unity 2017.1 весит 21637 КБ. Однако его можно очень легко уменьшить до 11952\12412 КБ, указав платформу для компиляции (ARMv7 и x86 соответственно).

По аналогии с этим, можно еще попробовать еще немного уменьшить вес, выбрав Graphic API. Если выбрать OpenGLES2 вместо Auto Graphics API, можно сэкономить еще 236 КБ (11716 вместо 11952). Выгода незначительна и возможна потеря в производительности, так что этого делать я не рекомендую.

Теперь поговорим о содержимом проекта. Рассмотрим 2D игру с большим количеством спрайтов.
Есть вероятность, что многие спрайты будут симметричными по одной или нескольким осям.

Давайте проверим, есть ли автоматическое сжатие на этот случай: скомпилируем сцену с выставленным Sprite Renderer с одной текстурой, например, этой.

ARMv7 билд увеличился с 11952 КБ 12046 КБ, прибавка от пустого билда составляет 94 КБ.

Теперь подготовим половину текстуры:

Поставим два Sprite Renderer с одинаковой позицией, у правого выставим Flip X для отзеркаливания, в настройках Sprite Import Settings укажем Pivot Right для совмещения зеркальных половин. Должен получиться такой же круг как и был раньше. Скомпилируем, посмотрим размер: 12000 КБ, то есть прибавка почти в два раза меньше (48 КБ против 94). Если и есть какое то специальное сжатие, то по умолчанию оно неэффективно.

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

Найдем стандартный шейдер Unity для Sprite Renderer.

Начнем с того, что убедимся, что все работает. Создаем шейдер, копируем в него код, меняем название в коде на Sprites/HorizontalSymmetry. Теперь нужно создать материал и выбрать наш шейдер. Попробуем назначить на Sprite Renderer наш материал. Должен выглядеть как раньше.

Теперь разберем шейдер. Вся магия происходит тут:

Это функция, которая должна вернуть цвет пикселя в указанной точке. Нам даны позиция, текстура, цвет для смешения. Не стоит бояться fixed4: это просто тип данных с 4 float: r,g,b,a.

В первой строчке мы получаем цвет текстуры и после этого умножаем на некий цвет IN.color. Этот цвет — это параметр шейдера, его можно изменить в Sprite Renderer/Color.

Дальше идет домножение цвета на альфу. Связано это с тем, что прозрачность зависит не только от альфы, но и от значения rgb. Для лучшего понимания цветового пространства можно поэкспементировать:

Получаем прозрачную серую текстуру. При rgb = 1 и a = 0 будет непрозрачная белая, при rgb = 0 и a = 0 полностью прозрачная, rgb = 0 и a = 1 будет черным непрозрачным.

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

Эту задачу можно решить в лоб:

Если немного подумать, то можно сделать решение короче, красивей, быстрей:

В качестве упражнения предлагаю читателю решить эту задачу для вертикальной и двойной симметрии.

Иногда могут быть артефакты прозрачности, связанные с тем, что спрайт рисуется по умолчанию по определенному контуру (мешу). Лечится так: Sprite/Import Settings/Mesh type = Full Rect.

Этот способ уже теоретически способен сократить размер используемых текстур в 4 раза. Проверим, как поведет себя билд при четверти спрайта (используя шейдер двойной симметрии). Размер билда — 11978 КБ против 12000 (половина спрайта). Напомню, что пустой проект весил 11952 КБ. То есть, опять получилось уменьшение прибавки почти в два раза (в 3.6 от изначального круга без оптимизации).

Однако, это не предел. В моей игре использовалось большое количество шайб, обладающей радиальной симметрией. Это означает, что достаточно иметь всего одну полоску, для того чтобы задать весь круг! Причем, половинную полоску (радиус, не диаметр).

Теперь дело за шейдером. Наша задача — сделать из линии круг.

Можно поступить так: найти удаленность текущей точки от центра и использовать координату текстуры с позицией (1-distance*2, 0). Умножение на два происходит потому что максимальное расстояние от центра будет 0.5, не 1. Вычитаем из единицы потому что текстура подготовлена слева (край круга) направо (центр круга).

Примечание: так как тут вычисляется корень, шейдер будет работать медленнее чем полноценное круговое изображение

Создаем материал, поставим его в Sprite Renderer, поставим Sprite = line, смотрим. Изображение будет очень узким, так что нужно растянуть спрайт (выставить большое значение Trasnform.Scale.y). Должен получиться исходный круг\овал.

Проверим размер билда с новым шейдером и кругом из полоски: получилось 11957 КБ. То есть прибавка от пустого проекта составляет всего лишь 5 КБ, и это включая размер шейдера.

В итоге у нас получился удобный инструмент, с помощью которого в некоторых случаях можно значительно уменьшить размер билда. Он пригоден не только для Android, но и для любой платформы поддерживающей шейдеры.

Источник

Unity: Сборка под Android или «размер имеет значение»

В некоторых случаях необходимо работать над снижением размера сборки для Андроид. Например, установка тяжеловесных APK для пользователей мобильного интернета может влететь в копеечку. Превышение размера APK в 50 Мб в Google Play выливается в дополнительные трудности при аплоаде.

Мы разрабатывали под Андроид на Unity 2D-игру, которая изобилует картинками (большинство с областями прозрачности) и разнообразными звуками, и столкнулись с проблемой размера APK. Забегая вперед скажу, что решив ее и снизив вес в 1,5 раза, мы получили в 1,5 раза больше скачиваний. Заставляет задуматься, не правда ли?

Пытаясь побороть проблему приложений-тяжеловесов, мы обратились к замечательной документации от Unity. Выяснилось, что там данная тема обсуждается лишь вскользь. Упоминается, какие именно аспекты влияют на размер сборки и как воздействовать на эти аспекты, чтобы сделать APK меньше, а также приведено немного конкретики по поводу настроек импорта изображений.

Другую полезную информацию по данному вопросу в интернете мы практически не нашли. Потому провели небольшое исследование, результатами которого спешим с вами поделиться.

ИЗОБРАЖЕНИЯ

Уточним насчёт изображений. В нашей игре соблюдается принцип pixel-perfect. Все изображения без альфа-канала имеют плавный градиент. Остальные изображения с прозрачностью, а непрозрачные области тоже имеют плавный градиент.

Проанализируем, какой вклад в размер АРК вносят изображения в формате PNG и JPG.

Картинки в формате PNG

Далее мы сохранили первую картинку в Photoshop с настройками: Compression->None/Fast, Intrelaced: Yes. Получили файл размером 9000 Кбайт, однако в сборку он добавил те же 236 Кбайт.

Это подтверждает слова из документации, о том, что Unity перекодирует все ассеты во внутренний формат. Очевидно, он приблизительно соответствует формату PNG, сохранённому в фотошопе с настройками: Compression->Smallest/Slow, Intrelaced: No. И Unity перекодирует все PNG в этот формат, независимо от начального формата файла.

Картинки в формате JPG

Опыты однозначно показали, что изображения JPG вносят вклад в размер сборки пропорционально своему размеру. Пока не совсем понятно, как ведёт себя Unity в случае, если ассет находится в формате JPG. Мы сохранили ту же самую (первую) картику в JPG и получили очень маленький файл на файловой системе (75 Кбайт). Однако в сборке он занял непомерных 767 Кбайт (*).

Мы проводили эксперимент на большом количестве разных картинок, здесь я привожу лишь малую часть исследований. В других экспериментах нам наоборот удавалось снизить общий размер сборки конвертированием всех файлов из PNG в JPG.
Причин этого явления выявить пока не удалось.
Скорее всего, снова имеет место внутренний формат Unity, однако точные принципы взаимодействия колдовского механизма Unity с ассетами JPG выяснить пока не удалось.

Еще один способ работы с JPG будет описан ниже.

ЗВУКИ

Для звуков значение имеют две настройки импорта: Audio Format и ForceToMono.

Файлы в формате WAV занимают больше места в сборке, чем файлы в формате MP3 (вклад в размер сборки приблизительно равен размеру файла). Стерео WAV файл займёт меньше места, если выставить ForceToMono = true. Точно такого же эффекта можно достичь, если конвертировать файл в «моно» ещё до импорта (тогда ForceToMono не будет доступна в инспекторе).

Однако если для файла WAV установить настройку импорта AudioFormat = Compressed, то в сборке он займёт места столько же, сколько и соответствующий MP3 файл высшего качества (Audacity: variable bitrate, 220-260 kbps). То есть Unity самостоятельно кодирует звук в формат MP3.

Для файлов в одинаковом формате действует принцип прямо пропорционального вклада в размер сборки.

Остальные настройки импорта на размер сборки никак не влияют. Они влияют на количество места, занимаемое звуком в RAM.

А ТЕПЕРЬ О КОНКРЕТНЫХ ШАГАХ К НАШЕЙ ЦЕЛИ

Таким образом, совет: для снижения нагрузки на ОЗУ
* избегать больших областей прозрачности в изображениях;
* не формировать атласы с большими участками прозрачности, особенно в NGUI.

(Но это мы отвлеклись от основной темы.)

Несколько слов о dll

Документ приводит список обязательно включаемых в сборку dll и призывает минимизировать количество дополнительных dll (особенно тяжёлых). В частности, по возможности не использовать System.dll (добавляет к APK 2 Мбайт). Однако даже если мы будем избегать ссылок на методы из этой библиотеки, System.dll всё равно (по состоянию на Unity 4.5.5) включается в сборку, так как её подтягивает обязательная Mono.Security.dll. Потому, получается, что официальная документация Unity в этом месте не совсем релевантна.

А вот использования других (необязательных) dll желательно избегать во имя снижения размера сборки.

На сегодня у нас всё. Спасибо за внимание!

(Просьба рассматривать данный материал как более-менее систематизированные результаты исследования, а не как универсальное руководство к действию. Буду очень рад комментариям, замечаниям, конструктивной критике, возражениям, предложениям, дополнениям. И, конечно, несказанно рад буду узнать, какие приёмы применяют коллеги из других компаний для решения обсуждаемого вопроса.)

Источник

Фишки unity3d или unity3d по-русски

Весело и со вкусом рассматриваю фишки и нюансы разработки казуальных игр на платформе unity3d. Расскажу про разработку и издание игр и приложений под iOS на этой платформе

24 нояб. 2011 г.

Уменьшение (оптимизация) размера приложения в unity3d. Часть 2

А теперь давайте поговорим об оптимизации текстур и других вещах, помогающих сделать наш билд меньше (вернее упихать в заветные 20 метров). На официальной страничке unity3d описано несколько приемов как сэкономить размер приложения этими способами. Итак, предлагается следующее.
Оптимизация используемых текстур включает в себя в первую очередь использование сжатых форматов текстур там где только возможно. Если сжатие не уменьшит занимаемый размер, то можно попробовать уменьшить размер текстуры. Что в принципе логично: зачем вам текстура размеров 2048, если у вас экран 1024х768 и она занимает места не больше, чем экран?

Далее приведу таблицу соотношения размеров изображения в зависимости от типа сжатия (взято из того же источника):

iOS

Для iOS, как мы видим, выгоднее использовать PVRTC 2 bits с альфа-каналом или без (все зависит от типа вашей текстуры). Однако, искажения, которые могут присутствовать в данном типе сжатия могут кого-то не устроить, тогда следует перейти на другой тип сжатия. Выбор за вами, экспериментируйте.

Также можно оптимизировать меши и анимации. Сжатие может быть включено в настройках импорта меша (Mesh import settings).

Еще возможно уменьшить количество dll, включенных в ваш проект. Это я рассматривал в прошлой статье по оптимизации (см. оптимизация, часть 1).

Спасибо за внимание, если что-то непонятно или недосказано с вопросами и предложениями прошу в комментарии.

Источник

Оптимизация 2d-приложений для мобильных устройств в Unity3d

Возможно все!

Начну с того, что каждый раз, когда я приступаю к оптимизации, я поначалу не верю, что можно что-то еще оптимизировать, особенно если проект уже прошел несколько циклов оптимизации до этого. Но просмотр официальной документации 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. Вот что значит перечитывать;) Пройдясь по сцене, я обнаружил огромное количество таких объектов:

Еще несколько подсказок (взятых в том числе из документа Unity), как сократить количество Draw Calls:

Скачки производительности

Второй фактор, влияющий на производительность — так называемые скачки производительности. Порою в игре были «зависания» на 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 вручную — перед загрузкой сцены или непосредственно сразу после ее запуска. Это также поможет освободить дополнительную память для сцены, что иногда бывает критично. Соответствующий скачок производительности можно скрыть, например, экраном загрузки;)

Использование правил выше привело к устранению скачков производительности и намного более плавным геймплею и картинке.

Другие оптимизации

Далее привожу другие правила, которые могут помочь Вам. Большинством из них я сам пользовался на предыдущих этапах оптимизации.

Скрипты

Физика

Анимации

Система частиц

Другое

Уменьшение размера приложения

Для чего это может понадобиться? Раньше это делалось потому, что приложения размером Archives даже появилась специальная кнопочка Estimate Size:

1. Используйте правильный формат текстуры.
Это также позволит уменьшить объем используемой текстурной памяти, а соответственно и повысить производительность. Иногда достаточно использовать формат текстуры 16 bits, особенно если вся графика нарисована всего в нескольких цветах. Сравните:

Для монотонных текстур можно использовать только ее серую и альфа-компоненту и лепить из них готовый объект, используя специально написанный для этого шейдер и умножение на цвет:

Для задников и нечетких объектов можно использовать компрессию. Сейчас PVRTC-компрессия на iOS довольно продвинутая. Стоит помнить, что чем больше текстура — тем лучше ее качество после компрессии. На маленьких текстурах использование компрессии может быть неприемлемым.
Чтобы это все имело смысл, нужно разделять объекты на группы типа «задний фон», GUI, игровые объекты, о чем я уже писал. Тогда на каждый тип можно завести свой атлас и использовать различные настройки формата текстуры.

Источник

Уменьшение размера файла сборки

Лог редактора сразу после сборки

Лог помогает выявить ассеты, которые вы, возможно, пожелаете удалить или оптимизировать, но вам стоит учитывать следующее перед тем как начать работу:

Unity перекодирует импортированные ассеты в собственные внутренние форматы, поэтому выбор исходного формата ассета не имеет значения. Например, если у вас в проекте есть Photoshop текстура с множеством слоёв, они будут объединены, а сама текстура будет сжата перед сборкой проекта. Экспорт текстуры в виде PNG никак не повлияет на размер сборки, так что вам следует придерживаться форматов, наиболее удобных для вас при разработке.

Советы по уменьшению размера сборки

Текстуры

Если это не приведёт к уменьшению размера, попробуйте снизить качество текстур. Хитрость тут в том, что вам не нужно менять исходный контент. Просто выберите текстуру в окне Project и измените значение свойства Max Size (максимальный размер) в настройках импорта. Можно приблизить объект, на котором используется выбранная текстура, и подобрать значение Max Size так, чтобы вы не замечали ухудшения качества текстуры в окне Scene ( Scene View ).

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

В следующей таблице показано, как много места занимают разные форматы изображений, в байтах на пиксель:

Формула занимаемого на диске места такова: ширина * высота * bpp. Если вы используете мипмапы, тогда размер на диске будет примерно на треть больше, чем при обычном единичном изображении.

По умолчанию, Unity сжимает все текстуры при импорте. Для ускорения рабочего процесса в редакторе, вы можете отключить сжатие в настройках редактора (флажок Compress Assets on Import), но при этом текстуры всё равно будут сжиматься при сборке, независимо от этой настройки.

Меши и анимации

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

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

Учтите, что сжатие меша снижает только физических размер файлов, но не объём используемой памяти при выполнении программы. А вот снижение количества ключевых кадров в анимации (значение Keyframe reduction у свойства Anim. Compression в настройках импорта) уменьшает и физический размер файлов, и потребление памяти во время выполнения программы, потому рекомендуется всегда оставлять эту настройку включенной.

DLL файлы

По умолчанию, Unity включает в сборку только эти DLL файлы:

При работе над игрой рекомендуется избегать использования зависимостей из System.dll или System.Xml.dll. По умолчанию, Unity не включает эти библиотеки в к сборку проигрывателя, но если в своём коде вы используете их классы, библиотеки будут включены в сборку. Эти DLL файлы добавят к размеру сборки проигрывателя около одного мегабайта. Если в вашей игре требуется работа с XML, вы можете использовать библиотеки вида Mono.Xml.zip в качестве небольшой по размерам альтернативы системным библиотекам. Хоть большинство дженерик контейнеров содержится в mscorlib, но Stack<> и некоторые другие находятся в System.dll, так что постарайтесь избегать их использования по возможности.

Как вы можете видеть, Unity включает System.Xml.dll и System.dll, при сборке проигрывателя

Источник