Привет, Хабр! Меня зовут Андрей Романенков, я работаю ведущим программистом в IntellectoKids. Мы создаем образовательные приложения для дошкольников.
Этой статьи могло бы не быть, ведь детские мобильные игры, как правило, имеют простую логику, не требуют сложного кода и могут функционировать без дополнительных усилий со стороны разработчиков.
Но есть одно но.
В определенный момент ваше простенькое приложение может превратиться в перспективный проект с десятками мини-игр внутри и еженедельными обновлениями. Собственно, это произошло с нами. И тут начинается самое интересное. Представьте, что геймдизайнеры постоянно добавляют в игры новые уровни, художники — новые текстуры, а локализаторы — локализацию на волапюк. Репозиторий растет, приложение «раздувается». Как результат — увеличивается время скачивания. А это уже может повлиять на популярность продукта и на его продвижение.
Как решить проблему? За четыре года мы наработали опыт, не претендующий на абсолютность или даже оригинальность, но которым я хочу поделиться. Возможно, вам будет полезно.
Саб-модульность, многорепозиторность, подход к общему коду
Всего у IntellectoKids 4 приложения. Поскольку сервисы у них идентичны (например, логика работы с сервером, аналитика, покупки) и много одинакового кода, мы выделили общий функционал в отдельный репозиторий, который каждый конкретный проект подключает через git submodules. Выскажу довольно очевидную мысль, что когда ваши проекты с общим кодом множатся, код нужно скорее выделить в единую библиотеку. Вроде бы все это понимают, но часто откладывают на потом, а чем дальше вы откладываете, тем тяжелее будет процесс слияния.Помимо выделения репозитория для общих сервисов, мы создали также другой общий репозиторий для более базовой библиотеки утилит и вспомогательных классов.Второй вариант подключения дополнительного функционала появился у нас с добавлением Package Manager в Unity. Так можно делать, когда ваша библиотека устоялась и если вам необходимо подключить какую-то стороннюю библиотеку с репозитория как package.Когда проект длится давно, а количество контента увеличивается с каждым днем, то из-за раздувшейся истории и обилия больших файлов рано или поздно вы столкнетесь с проблемой размера репозитория. У нас текущий репозиторий перевалил за 10Гб (сейчас 14 Гб), с чем справляются не все хостинги (большая часть из них ограничивает размеры хранилища).В борьбе за производительность нам помогают чистка истории и использование git lfs, а также внимательное отношение к размеру и формату импортируемых в проект ассетов. Например, импортирование mp3 и ogg файлов вместо wav; и отсекание слишком больших текстур.
Локализация, в том числе на RTL-языки
Наши приложения локализованы более чем на 40 языков, включая RTL языки (предполагающие чтение справа налево). Система локализации самописная, но в целом она похожа на типовые решения из Asset Store (такие, как I2 Localization). В Google-таблицах хранятся ключи и значения. Есть базовая таблица для всех игр, и дополнительные таблицы для каждой конкретной игры. Каждая таблица в Google-документах скриптами собирается из других вспомогательных таблиц, которые редактируют локализаторы.
На клиенте наши скрипты MonoBehaviour «выцепляют» нужные значения и выставляют их в TextMesh Pro компоненты. Клиент может обновлять таблицы как в режиме редактора, так и рантайма. У клиента таблицы хранятся в csv формате, и в память грузится только нужный язык, так как количество ключей для каждого языка превышает уже пять сотен!
Для поддержки арабского языка и иврита мы реализовали ряд компонентов, осуществляющие превращение верстки под “обычные” языки: отражение, переставление якорей, смена последовательности элементов к группе, а также компонент для полной поддержки возможностей по форматирования текста в TextMeshPro.
Поскольку наши приложения — детские, они содержат очень много локализаций озвучки (поскольку дошкольники часто не умеют читать). Так как в разных языках голосовая озвучка персонажей отличается, мы используем анализ звуковой дорожки для синхронизации анимации рта персонажа с речью.
Бандловость: 2 подхода. Эволюция в работе с бандлами
По мере развития проекта (добавления новых уровней и другого контента, увеличения количества локализаций) постоянно рос общий размер содержимого. С самого начала нам было понятно, что необходимо использовать бандлы, иначе размер клиента был бы огромен и сейчас составлял бы 3 Гб. Да, не Modern Warfare, но всё же для еженедельной скачки это неприемлемо.
В какой-то момент мы, правда, провели эксперимент с выпуском таких больших релизов (тогда размер был примерно под 2 Гб), но это сразу заметно отразилось на общей статистике приложения. Сейчас у нас зашиты в билд только небольшие бандлы, необходимые для ускорения старта. В нашем основном приложении IntellectoKids Classroom & Learning Games — больше тысячи бандлов общим размером 2.5 Гб. Может показаться, что это слишком много, но если умножить количество встроенных игр на количество языков, и добавить к этому, что у каждой игры есть множество уровней с насыщенным контентом, то всё сразу станет понятно.
Из-за особенности геймплея каждая игра имеет свои нюансы объединения ресурсов в бандлы. Где-то можно поместить все локализованные фразы в один бандл, так как их общий размер мал, а где-то необходимо разделить и поместить каждый язык в отдельный бандл. В каких-то играх несколько уровней объединены в один бандл, а в других должен быть бандл у каждого уровня. При формировании бандлов мы создаём manifest файл, описывающий имена и хэши бандлов. Загрузчик при обновлении версии качает этот manifest и проверяет, какие бандлы нужно закачать заново, а какие удалить.
Изначально игра поддерживала фоновую загрузку бандлов во время игры, но позже мы отказались от такого подхода, так как он таил в себе много скрытых проблем (сценарии обновления бандла во время использования его игрой, баги Unity в выгрузке бандлов и т.п.). Сейчас мы перешли на более классический вариант, когда игроку в нужные моменты показывается экран загрузки бандлов.
Самый «маленький большой нюанс» нашего проекта, — это, безусловно, релиз и деплой более чем тысячибандлов. На первоначальном этапе, когда бандлов было меньше, мы размещали их в Google репозитории и даже использовали веб-интерфейс Chrome для их загрузки, но довольно быстро перешли на собственный билдер-загрузчик, выполненный в виде инструментария в Unity. Он позволяет загрузить нужные бандлы, задать версионность билда и настроить другую рутину.
Первоначально бандлы лежали в Google Cloud Storage, затем мы перешли на Amazon Web Services. Основная статья затрат у бандлов — это скачивание. С переходом на AWS и CloudFront нам удалось оптимизировать издержки. Хоть это, а также переход на новый API с доработкой инструментов деплоя занял некоторое время, но оно того стоило.
Переход на новые версии Unity
За прошедшие четыре года разработки мы многократно обновляли версии Unity. В целом мы стремимся делать это часто, но ведем разработку только в LTS версиях из-за их большей стабильности.
Если вы «растите» приложение, будьте готовы, что требования к нему будут довольно часто меняться. Нам много раз приходилось перерабатывать фреймворки аналитики (один Facebook включался и выключался больше пяти раз).
(Чтобы подчеркнуть всю глубину глубин этой ситуации я хотел вставить картинку описывающую определённую эмоцию, но не нашёл подходящей картинки человека схватившегося за голову или попу.)
Ваша архитектура изначально, скорее всего, не будет настолько гибкой, но всё же постарайтесь продумать ее так , чтобы она была готова к подобным изменением. Сделайте сервисную модель, разбейте на модули.
Что можно добавить к сказанному в статье?
Пожалуй, стоит понимать, что ваш проект всегда будет далек от того идеала, который вы себе намечтали. Но это не значит, что нужно откладывать очевидные улучшения архитектуры. Особенно в условиях, когда требования к функционалу приложения постоянно меняются. Ведь неделька на рефакторинг может сэкономить вам месяцы мучительной разработки, но помните, что "Real artists ship" — и если ваш рефакторинг слишком большой, а бизнес не стоит на месте, то и рефакторинг может подождать. Тут дам совет, особенно скромным программистам: более четко доносить до менеджмента такие критичные вещи, чтобы ваш технический долг не рос.
