Как работать с unity для android

Начало разработки под Android

Разработка игр для устройств с Android OS требует подхода, схожего с разработкой под iOS. С другой стороны, аппаратное обеспечение Android-устройств не подчиняется чётким стандартам, что заставляет решать вопросы, которые отсутствуют при работе с iOS. Также присутствуют различия между версиями Unity для Android и iOS.

Подготовка среды разработки для Android

Прежде чем вы сможете протестировать свои игры на устройстве, вам нужно будет подготовить среду разработки. В частности — скачать и установить Android SDK нужной платформы и добавить ваше устройство в систему (этот процесс отличается для Windows и Mac). Об этом подробно написано на сайте Android-разработчиков, а также дополнительную информацию может предоставлять производитель вашего устройства. Так как это достаточно сложный процесс, мы приготовили небольшую инструкцию которая поможет вам подготовить всё необходимое для разработки. Если вам понадобится больше информации, вы сможете получить её на портале Android-разработчиков.

Доступ к функциям Android

Unity предоставляет API для доступа к средствам ввода и настройкам Android. Доступные классы задокументированы на странице Написание кода для Android сборок.

Привязка C, C++ или Java кода к скриптам

Unity позволяет вызывать функции, написанные на C/C++, непосредственно из скриптов (Java-функции могут быть вызваны непрямым способом). Чтобы узнать как из Unity получать доступ к функциям из нативного кода, посетите страницу о сборке плагинов для Android.

Occlusion Culling (отсечение невидимой геометрии)

Unity предоставляет поддержку occlusion culling, что очень полезно при оптимизации для мобильных платформ. Больше информации можно найти на странице Occlusion culling.

Настройка начальной заставки

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

Решение проблем и сообщения об ошибках

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

Как Unity для Android отличается от версии для настольных компьютеров

JavaScript со строгой типизацией

Для улучшения производительности в Android-версии Unity динамическая типизация в JavaScript всегда отключена (как если бы к каждому скрипту автоматически применялась #pragma strict). Это важно помнить, если вы переносите на Android проект со старших платформ, и если вы столкнётесь с ошибками компиляции — проблему стоит искать в первую очередь в типизации. С такими ошибками обычно легко справиться, убедившись что типы всех переменных явно указаны или приведёны при инициализации.

ETC — рекомендуемый способ сжатия текстур

Хоть Unity Android и поддерживает DXT/PVRTC/ATC текстуры, Unity распакует текстуры в формат RGB(A) при выполнении, если эти методы сжатия на поддерживаются на конкретном устройстве. Это может серьёзно повлиять на производительность GPU отрисовки, потому рекомендуется использовать формат ETC. Он является фактическим стандартом для Android, и должен поддерживаться всеми современными устройствами. С другой стороны, ETC не поддерживает альфа-канал, и иногда 16-битные RGBA текстуры будут лучшим выбором по критериям качества, размера и скорости рендеринга там, где нужен альфа-канал.

Также возможно создать несколько дистрибутивов игры (apk-файлов) с разными форматами текстур, чтобы Android Market сам предоставлял для каждого устройства наиболее подходящий из дистрибутивов. За подробностями обратитесь к этой странице.

Проигрывание видео.

Видео текстуры (MovieTexture) не поддерживаются на Android, но программно доступно полноэкранное поточное проигрывание. Для дополнительной информации о поддерживаемых форматах файлов и API скриптинга, ознакомьтесь со страницой класса MovieTexture или со страницей поддерживаемых на Android форматах медиа.

Источник

Как собрать проект Unity для смартфона или планшета

Опишем процесс сборки проекта под платформу Android, которая поддерживается большинством смартфонов.

Для начала сборки необходимо открыть окно Build Settings из пункта меню File -> Build Settings… (или нажать комбинацию клавиш Ctrl + Shift + B):

Окно Build Settings

Шаг 1. Выбор платформы

В окне Build Settings выбрать платформу Android и нажать на кнопку Switch Platform:

Выбор платформы Android

Шаг 2. Проверить и отредактировать (если надо) настройки в в окне Project Settings, в разделе Player:

1) заполнить поля:

Company Name (писать по-английски и лучше без знаков препинания и пробелов),

Product Name (аналогично – по-английски и без специальных символов и пробелов),

Version (можно оставить значение по умолчанию, но если приложение собирается повторно, то значение надо менять на большее; тогда при установке новой версии приложения на смартфон существующее приложение обновится. Если это число оставить прежним, потребуется сначала удалить установленное ранее приложение).

2) задать изображение для иконки приложения, добавив его в Default Icon.

3) если необходимо, в разделе Resolution and Presentation можно зафиксировать ориентацию приложения: горизонтальное (Landscape) или вертикальное (Portrait):

Ориентация приложения

4) в разделе Other Settings проверить правильность сформированного идентификатора в поле Package Name:

com.Company.ProductName – здесь правильно должны быть записаны компоненты Company и ProductName. При их записи должны быть использованы ТОЛЬКО буквы латинского алфавита, БЕЗ специальных символов и пробелов.
Примечание: в Unity 2019 эти компоненты заполняются автоматически после заполнения полей Company Name и Product Name в самом начале окна Project Settings, в разделе Player (см. п.1).

Например, итоговая строка com.Company.ProductName может получить следующий вид:

Это минимальный набор настроек, которые стоит отредактировать. После этого окно Project Settings можно закрыть.

Шаг 3. Перечислить в окне Build Settings сцены, которые должны попасть в сборку (build) проекта:

Если сцена всего одна, и она открыта в редакторе, можно просто нажать на кнопку Add Open Scenes.

Дополнительные сцены можно перетащить мышью из нужной папки окна Project.

Если в окне Scenes in Build указана не та сцена, её можно выделить мышью и удалить, нажав на клавишу Delete на клавиатуре компьютера.

Шаг 4. Нажать на кнопку Build в правом нижнем углу окна Build Settings, указать папку и имя собираемого файла в формате .apk и нажать на кнопку Сохранить (Save):

Собранный файл .apk переписать на смартфон, открыть его на смартфоне и установить приложение. После этого можно начать тестировать свою мобильную игру или приложение на смартфоне.

Источник

Профилируем Unity проект с Android Studio

Требования

Для полноценного профилирования приложения вам потребуется телефон с Android 8 или новее (API 27). По опыту, профилирование с Android-ами более старых версий несёт больше приключений, чем пользы. По этой причине я рекомендую обзавестись полной линейкой Nexus устройств, так как они имеют старое железо и последние обновления Android-а.

Настройка Unity проекта

Для получения результата, вам придётся настроить Unity проект определённым образом.

Настройки в Build Settings

• В первую очередь, вы должны переключить Build System в “Gradle” и поставить галочку напротив “Export Project”. Таким образом мы получим готовый Android Studio проект, который мы и будем в дальнейшем профилировать. Профилирование готового APK тоже возможна, но более ограничена и требует больше подготовки
• Режим “Development Build” желательно выключить, так как таким образом получаемые тайминги в профайлере будут максимально близки к реальным

Настройки в Player Settings

• Установите Scripting Backend в IL2CPP. Если оставить Mono, то при нативном профилировании мы увидим много функций Mono, без информации как они соотносятся с C# кодом.
• Опция ‘C++ Compiler Configuration’ для Android ни на что не влияет (в Unity 2018.3). Можете поставить её в ‘Release’, возможно в будущих версиях Unity Android toolchain эта настройка будет влиять на настройки компилятора.
• Желательно ограничить ‘Target Architecture’ до ARMv7. Так вы сэкономите на времени компиляции и по опыту множество архитектур иногда вводит Android Studio в ступор.
• Также стоит установить ряд дополнительных настроек:
  • Install Location — ‘Prefer external’
  • Internet Access — ‘Require’
  • Write Permission — ‘External (SDCard)’

  Android Studio и другие профайлеры используют simpleperf для сбора статистики, и ему потребуется доступ к карте памяти для записи временных файлов.

Подготовка Gradle проекта

После того, как вы установили все настройки, соберите Unity проект. Вы должны получить папку с Gradle проектом.

Unity по умолчанию собирает проект из расчёта, что вы планируете собирать из него финальный APK. Потому вся отладочная информацию из него удалена, но к счастью её можно вернуть. Для этого вам нужно подменить libil2cpp.so и libunity.so на версии с отладочной информацией.

libil2cpp.so

libunity.so

Это файл, который содержит low-level часть Unity Player. Так как мы делаем Release сборку, то Unity положила вам в проект файл без отладочной информации. Вам нужно подменить libunity.so на файл с символами.

• Пойдите в папку, где у вас установлена Unity
• Перейдите в папку «\Data\PlaybackEngines\AndroidPlayer\Variations\il2cpp\Development\Libs\armeabi-v7a\»
• Возьмите от туда файл libunity.so, и замените файл в вашем проекте, который лежит в папке ‘\src\main\jniLibs\armeabi-v7a’

Профилирование

Теперь вы можете начать профилировать в Android Studio, достаточно нажать кнопку запуска профайлера.

Android Studio запустит приложение и начнётся сессия профилирования

По умолчанию, Android Studio показывается графики, но не производит сэмплирование данных. Для запуска процесса, вам нужно кликнуть на треке CPU, чтобы профайлер переключится на вид CPU. При этом сверху окна появится дропдаун и кнопка ‘Record’.

Выберите Sampled ‘Native’ (В Android Studio 3.3 — C/C++ Native), и нажмите кнопку ‘Record’.
Так как запись производится на диск устройства, по опыту лучше не записывать более 5-8 секунд, многие устройства будут фейлится и на меньшем кол-ве данных (список проверенных устройств смотрите в конце статьи).

Для получения результата нажмите ‘Stop’ и потом красный квадрат, чтобы прервать сессию. Сложно понять задумку авторов, но если вы не остановите запись полностью, то профайлер не всегда начинает анализ полученных данных и ваш отрезок с данным уедет в далёкие дали.

После этого остаётся только немного подождать, через 30-50 секунд профайлер выдаст вам результат. Если всё настроено верно, вы получите capture со всем именами функций

Известные особенности

Unity специфика

• Главный поток Unity называется UnityMain, но вы можете увидеть множество UnityMain при профилировании. Это пользовательские потоки, которые вы создаете внутри C# кода. По умолчанию они получают такое же имя. Главный поток Unity обычно легко отличить, так как он будет самый нагруженный.
• Графический поток называется UnityGfxWorkerW
• Потоки Unity Job системы называются Worker Thread
• К сожалению некоторые wait-функции, которые применяет Unity (futex-ы), Android Studio показывает и считает не как wait-time, а как активность.
• Когда вы будете смотреть call graph в Top Down view, вам придётся пройти через множество уровней Java-вызовом, к сожалению отфильтровать в Android Studio это никак нельзя.

Источник

Разработка мобильных игр на Unity. URP, 2D Animation и другие новомодные вещи на примере игры

Всем привет! Это снова Илья и сегодня мы поговорим о технической реализации мобильной игры в современных реалиях. Статья не претендует на уникальность, однако в ней вы можете найти для себя что-то полезное. А чтобы рассмотреть разработку на реальном проекте — мы возьмем реализацию нашей игры, которая на днях выходит в Soft-Launch.

Дисклеймер! Код в этой статье не проходил рефакторинг и носит лишь ознакомительный характер, чтобы поделиться идеями. И вообще, в целом, это smellscode.

Итак, запасаемся кофе, открываем Unity и погнали!

Базовая настройка проекта. URP и все-все-все.

Начнем с того, что мы работаем с URP (Universal Render Pipeline). Почему так? Потому что он проще в настройке и обладает более гибким контролем, чем стандартный рендер. Ну и добиться хорошей производительности на тапках исходя из этого — намного проще.

Стоит указать, что ниже пойдет речь о 2D игре. Для 3D игр подходы будут несколько отличаться, как и настройки.

Мы реализовали два уровня графики. Low Level — для деревянных смартфонов и High Level — для флагманов. Уровни графики подключаются при помощи Project Settings.

В нашем проекте стоят следующие настройки (для Quality уровней):

Настройки графики для пресета Low в Project Settings:

На что здесь следует обратить внимание:

Texture Quality — качество текстур. Для High — мы берем полный размер текстур, для Low — Четверть. Можно еще внести Middle пресет с дополнительным уровнем.

Resolution Scaling везде стоит 1 — мы берем это значение из URP Asset.

Все что связано с реалтаймом — отключаем.

Теперь перейдем к настройкам самих URP Asset. На что следует обратить внимание:

Для разных уровней качества можно установить Render Scale — тем самым снижая разрешение для отрисовки. Также незабываем про Dynamic / Static батчинг.

Adaptive Performance

Отличная штука для автоматической подгонки производительности мобильных игр (в частности для Samsung-устройств):

Другие полезные настройки:

Отключите 3D освещение, лайтмапы, тени и все что с этим связано.

Используйте для сборки IL2CPP — ускорьте работу вашего кода.

Используйте Color Space — Linear.

По-возможности подключите multithreaded rendering.

Игровой фреймворк

Едем дальше. URP и другие настройки проекта сделали. Теперь настало время поговорить о нашем ядре проекта. Что оно включает в себя?

Само ядро фреймворка включает в себя:

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

Базовые классы для интерфейсов (компоненты, базовые классы View).

Классы для работы с контентом, сетью, шифрованием и др.

Базовые классы для работы с логикой игры.

Базовые классы для персонажей и пр.

Утилитарные классы (Coroutine Provider, Unix Timestamp, Timed Event и пр.)

Зачем нужны менеджеры?

Они нужны нам для того, чтобы из контроллеров управлять состояниями и глобальными функциями (к примеру, аналитикой).

Хотя мы и используем внедрение зависимостей, менеджеры состояний реализованы в качестве синглтонов (атата по рукам, но нам норм) и могут быть (и по их назначению должны быть) инициализированы единожды. А дальше мы просто можем использовать их:

А уже сам менеджер распределяет, в какие системы аналитики, как и зачем мы отправляем эвент.

Базовые классы.

Здесь все просто. Они включают в себя базовую логику для наследования. К примеру, класс BaseView и его интерфейс:

А дальше мы можем использовать его, к примеру таким образом:

Классы для работы с контентом, сетью, шифрованием

Ну здесь все просто и очевидно. Вообще, у нас реализовано несколько классов:

1) Классы шифрования (Base64, MD5, AES и пр.)

2) FileReader — считывающий, записывающий файл, с учетом кодировки, шифрования и других параметров. Также он умеет сразу сериализовать / десериализовать объект в нужном формате и с нужным шифрованием.

3) Network-классы, которые позволяют удобно работать с HTTP-запросами, работать с бандлами / адрессаблс и др.

Классы для шифрования нужны, чтобы работать с сохранениями и передачей данных на сервер в безопасном формате (относительно безопасном, но от школьников уже спасет).

Утилитарные классы

Здесь у нас хранятся полезные штуки, вроде Unix Time конвертера, а также костыли (вроде Coroutine Provider-а).

Unix Time Converter:

Костыль Coroutine-Provider:

Логика сцен

Наша игра — это по своей сути интерактивная история с различными мини-играми (поиск предметов, простенькие бои, крафтинг, найди пару, а также большое количество головоломок).

Каждая сцена — содержит в себе основной Installer, который помимо различных View, подключает логические блоки — своеобразные куски механик:

Эти куски механик последовательно выполняются, отдавая события OnInitialize, OnProgress, OnComplete. Когда последний блок сыграет свой OnComplete — он завершит работу сцены (закончит уровень).

Зачем это сделано?

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

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

Блоки механик удобнее изменять, нежели огромный инсталлер с кучей разных контроллеров.

Работа с контентом

При работе с контентом, мы стараемся делать упор на оптимизацию. В игре содержится много UI, скелетные 2D анимации, липсинк и прочее. Вообще, контента достаточно много, не смотря на простоту игры.

Анимации в игре

Самый удобный для нас вариант — оказался из коробки. Мы используем систему для работы с костной анимацией от самой Unity:

Да, можно взять Spine, но у нас нет настолько большого количества анимаций, поэтому вариант от Unity — весьма оптимален.

Упаковка и сжатие

Все, что можно и нужно запихнуть в атласы — мы запихиваем в атласы и сжимаем. Это могут быть элементы UI, иконки и многое другое. Для упаковки атласов — используем стандартный Unity пакер из Package Manager (V1):

Локализация

Вся локализация базируется на JSON. Мы планируем отказаться от этого в ближайшее время, но пока что на время Soft-Launch этого хватает:

Работа с UI

При работе с UI мы разбиваем каждый View под отдельный Canvas. 99% всех анимаций работает на проверенном временем DOTween и отлично оптимизирован.

View инициализируются и обновляются по запросу через эвенты, которые внедряются в Level Installer, либо в отдельных блоках логики.

Что мы используем еще?

Salsa — для липсинка;

2D Lighting — для освещения. В большинстве сцен используется освещение по маске спрайта;

DOTween — для анимаций;

Итого

Работа с механиками получается достаточно гибкой за счет блоков логики. Мы изначально думали взять связку Zenject + UniRX, но решили отказаться от нагромождения большой системы. Да, мы сделали проще, но нам и не нужно всех возможностей этих огромных библиотек.

Источник