Проекты для юнити андроид

Как собрать проект 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 и iOS с помощью Gitlab CI

В этой статье хочу рассказать о подходе к сборке Unity-проектов на android и ios через Gitlab на собственных сборщиках с macOS.

Я работаю в небольшой gamedev компании, и задача автоматизации сборки появилась из-за следующих проблем:

• 5 распределенных команд должны собирать проекты из любой точки мира
• должны поддерживаться разные версии юнити
• сборщик должен обеспечивать как минимум 5 сборок в неделю от каждой команды
• сертификаты должны храниться централизованно, а не у разработчиков
• собранные билды должны быть доступны по ссылке в любой точке мира
• проекты должны проверяться на наличие обязательных библиотек (рекламные sdk и коды, локализация, сохранения)
• конфигурирование сборки для команд должно производиться в одном месте

Для решения этих проблем уже созданы готовые решения: Unity Cloud Build, TeamCity, Jenkins, Gitlab CI, Bitbucket Pipelines.

Первый из них, хоть и подготовлен для сборки Unity-проектов, но не позволяет автоматизировать работу с сертификатами, и для каждого проекта их приходится заводить вручную. TeamCity и Jenkins требуют настройки проекта в админках (это немного усложняет конфигурирование для разработчиков), установку дополнительного программного обеспечения на отдельный сервер и его поддержку. В итоге, самыми простыми и быстрыми в реализации остались два варианта — Gitlab и Bitbucket.
На момент решения проблемы Bitbucket Pipelines еще не анонсировали, поэтому было принято решение использовать Gitlab.

Для реализации подхода выполнены следующие шаги:

• Настройка проекта
• Настройка раннера
• Создание скриптов сборки

1. Настройка проекта

Проекты, которые собираются на сборщике мы храним на Gitlab. Бесплатная версия сервиса никак не ограничивает сами репозитории и их количество.
Для каждого проекта включается раннер (сервис, выполняющий команды от gitlab-сервера), работающий на маке.
Конфигурация для сборщика лежит в корне проекта в виде .gitlab-ci.yml файла. В нем описывается id приложения, требуемый signing identity (keystore для android и имя аккаунта для ios), требуемая версия Unity, ветка, режим запуска: ручной или автоматический и команда, которая запускает сборку (при необходимости, gitlab поддерживает гораздо больше параметров, документация).

2. Настройка раннера

Gitlab CI работает с общими (shared) и собственными раннерами (документация). Бесплатная версия ограничивает число часов использования shared раннеров, но позволяет безлимитно использовать собственные раннеры. Shared раннеры запускаются на linux, поэтому на них iOS приложения собирать не получится (но Unity запустить получится, на хабре была статья об этом). Из-за этого пришлось поднимать раннеры на собственных маках. В приведенном выше примере раннер запускает скрипт buildAndroid.sh или buildIOS.sh (в зависимости от ветки), в котором описаны подготовительные шаги, запуск Unity и уведомление о результате сборки.
Процесс настройки раннера хорошо описан в документации и сводится к запуску gitlab-runner install и gitlab-runner start .
После этого на мак устанавливаются необходимые версии Unity.

3. Создание скриптов сборки

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

• проверяем корректность id проекта, наличие сертификатов для нужного signing identity
• определяем пути до SDK, Java
• создаем в проекте C# класс с методом для запуска сборки
• проверяем наличие необходимой версии Unity и запускаем сборку. Если нет, то пытаемся собрать на версии по умолчанию
• Проверяем наличие apk или Xcode проекта, и если их нет — сигнализируем об ошибке в Slack
• для iOS: собираем Xcode проект
• загружаем артефакты (apk, ipa) на сервер (например, Amazon S3)
• сигнализируем об успешной сборке в Slack и отправляем ссылку на скачивание артефактов

Особенность сборки Unity проекта в том, что Unity в batch режиме позволяет выполнить только статический метод класса, имеющегося в проекте. Поэтому скрипт сборки “подкидывает” в проект класс с методами для запуска сборки:

Метод Environment.GetEnvironmentVariable получает значение environment переменных, которые предварительно были указаны в bash-скриптах.

Пример скрипта сборки для Android

Пример скрипта сборки для iOS
Сборка проектов осуществляется в два шага: формирование Xcode проекта из Unity и сборка Xcode проекта. Разработчики не могут напрямую влиять на Xcode проект, что вносит ограничения: нельзя напрямую изменять настройки проекта, информацию о сборке.
Также, особенность сборки на iOS в том, что тестовые устройства должны быть зарегистрированы в provisioning профиле приложения. А чтобы собрать Xcode проект, нужно до сборки создать сертификат, provisioning профиль и id приложения в developer консоли Apple.
Для автоматизации этого процесса используется fastlane. Этот инструмент создает и синхронизирует сертификаты, профили и позволяет загружать билды и мета-информацию в itunes connect.

При сборке Unity проектов без доступа к Xcode есть нюансы:

• в Unity перед сборкой проекта нужно указать TeamId, который есть в консоли разработчика — это делается через PlayerSettings.iOS.appleDeveloperTeamID
• в postprocess скрипте проекта необходимо выполнить предварительную обработку Xcode проекта: настроить info.plist, build settings
  Релизная и Ad-Hoc сборка также имеют разные скрипты, отличающиеся формированием результата: релизная грузит архив в itunes connect, а ad-hoc грузит ipa, создает манифест и страницу для скачивания over the air, ссылка на которую рассылается всем заинтересованным лицам.

Как с этой системой работают другие

Интерфейс просмотра логов сборки:

Результаты

Таким образом, получившаяся система является простой в использовании, позволяет добавлять проверки и валидации со стороны сервера (code style, тесты), при этом менеджеры видят ссылки на сборки в Slack и нет проблем со сборкой на iOS.

Из минусов — необходима ее поддержка для добавления новых версий Unity, signing identity и обеспечения работоспособности маков.

На текущий момент у нас работают два раннера (около двух лет), через систему прошло более 4000 сборок. Скорость сборки зависит от характеристик раннера и количества ассетов в проекте, ведь они импортируются каждый раз заново и она варьируется в пределах 3 — 30 минут для Android и 10 — 60 для iOS.

Источник

Профилируем 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 это никак нельзя.

Источник