Опыт использования Kotlin Multiplatform Mobile (KMM) в 9GAG

Мы очень рады видеть, что Kotlin Multiplatform Mobile (KMM) переходит в стадию бета-тестирования и Google опубликовал экспериментальные библиотеки Jetpack для KMM. Приятно видеть, что Google поддерживает платформу и портирует библиотеки Jetpack на KMM. Я считаю, что KMM станет будущим мобильной разработки, если будет поддерживаться все больше и больше фреймворков или библиотек.

React Native

9GAG тестировал различные кроссплатформенные решения, но ни одно из них не было полностью запущено в продакшен. Мы пытались переписать все приложение на React Native в 2016 году, поначалу все шло хорошо, но по мере того, как мы добавляли все больше и больше функций, производительность приложения продолжала ухудшаться, а размер приложения продолжал увеличиваться. Кроме того, по мере того, как мы добавляли все больше и больше библиотек, мы попадали в ад зависимостей.

Мы отказались от всего этого проекта и вернулись к нативной разработке.

Flutter

В 2020 году Flutter набирал обороты. Мы попробовали Flutter в стороннем проекте. На мой взгляд, Flutter имеет гораздо лучшую производительность, чем React Native, а Material Theming выглядит неплохо. С точки зрения размера, приложение выглядит вполне прилично благодаря поддержке пакетов приложений.

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

KMM

Прокрутим часы до 2021 года. Мы узнали, что Jetbrains разрабатывает свое мультиплатформенное решение: Kotlin Multiplatform Mobile. Я был немного скептичен в самом начале, это было похоже на Xamarin и все еще в альфа-версии, что вряд ли могло быть хорошим решением. Один из моих коллег предложил попробовать, так как в то время нам нужно было разработать побочную функцию.

Почему КММ

Мы все еще ищем способы согласовать поведение приложения на обеих платформах. Проблема, которая у нас была с React Native и Flutter, заключается в том, что если проект терпит неудачу, весь код, который написан, уходит в помойку и становится ненужным, и это то, почему  я относился ко всему скептически в самом начале. Однако, после секундного размышления, я согласился попробовать KMM.

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

Так началось наше путешествие.

Как

Конечная цель: существующее приложение для iOS и Android использует KMM в качестве логического слоя. Я считаю, что это лучше подходит для большинства случаев для многих из нас — вместо создания совершенно нового приложения на KMM. Цель кажется большой, но есть несколько советов, как начать с малого. Этот доклад с Droidcon NYC 2022 говорит почти о том же, что мы сделали!

Для начала давайте рассмотрим общую структуру проекта 9GAG:

• :ninegag-shared-lib — служит в качестве проекта-оболочки, не содержит кода внутри, но используется для экспорта XCFramwork (NineGagKmm) для iOS.
• :ninegag-shared-app — код KMM, который содержит бизнес-логику, константы приложения и т.д.
• :core — еще один проект KMM, но содержит некоторые низкоуровневые вещи, такие как некоторый класс util, методы шифрования пароля/подписи, которые могут быть повторно использованы другими проектами в будущем.

Проект Android может просто вызвать implementation project(«:ninegag-shared-lib»), чтобы включить весь код KMM, как обычно

Проект iOS будет включать бинарный файл XCFramwork, созданный из проекта :ninegag-shared-lib.

Шаг 1. Начните с Android

Излишне говорить, что Kotlin — язык Android. И первое логичное решение — начать с существующего приложения для Android. Настройте проект KMM, чтобы ваше существующее приложение для Android могло включать его в качестве зависимости. Это должно быть первым легким шагом.

Это один маленький шаг для человека, но гигантский скачок для человечества. — Нил Армстронг

Шаг 2: Делаем проект KMM компилируемым на iOS

Следующим шагом будет включение проекта KMM в существующий проект iOS.

Нам потребовалось некоторое время, чтобы изучить структуру проекта. Существующий образец проекта не подходил для нашего варианта использования. Наконец мы нашли статью о том, как использовать библиотеку KMM на iOS. Идея проста: мы относимся к логике, написанной на KMM, как к библиотеке, и тогда и Android, и iOS могут просто включать эту библиотеку, как и все прочие.

Ура! Для меня, как для Android-разработчика, это была самая сложная часть, поскольку у меня не было знаний об iOS-разработке, и мне было нужно время, чтобы научиться. Более того, мне пришлось общаться с товарищами по iOS-команде, чтобы понять структуру их проекта, как запустить приложение в Xcode и т.д.

Шаг 3. Начните с констант

Как только шаг 2 будет выполнен, вы можете подумать о том, что делать дальше при совместном использовании кода. Внедрение или перенос констант отслеживания в ваш KMM-проект , вероятно, будет одним из самых простых действий, которые вы можете сделать. Почему? Нет логики кода, нет необходимости включать сторонние библиотеки, только константы. Они могут быть легко использованы в iOS и позволяют iOS-разработчикам понять, что такое KMM. :D

В то время, когда мы внедряли KMM, мы работали над побочной функцией и включили множество библиотек, связанных с KMM, в нашу кодовую базу. Например, Ktor для вызова API, SQLDelight для кеширования данных в базе данных, мультиплатформенные настройки для хранилища KV и так далее.

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

Шаг 4: Начните перенос ваших общих утилит на KMM

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

Шаг 5. Попробуйте написать или перенести бизнес-логику в KMM

Теперь вы должны быть более уверены в KMM. Вы можете начать переносить бизнес-логику или писать новую с помощью KMM, изучая некоторые асинхронные вещи с корутинами!

По моему опыту, это самая сложная часть из-за времени, затраченного на реализацию, поскольку были ошибки, которые приводили к сбою iOS-приложения с версией Kotlin, которую мы тогда использовали (1.6.x).

Дальше

Как только вы начали использовать KMM, я думаю, стоит больше делиться кодом, чтобы проект KMM служил единым источником правды. Вот несколько идей для вас:

• Сеть, API — Ktor
• База данных — SQLDelight
• Совместное использование ресурсов (Строковые ресурсы, Локализация, Цветовая схема) — moko-resources
• Шифрование/дешифрование — Krypto

Вот список библиотек KMM, которые вы можете проверить: https://github.com/terrakok/kmm-awesome.

Проблемы — настройка проекта

Конечно, при интеграции KMM возникло множество проблем. Вот список вопросов, которые мне показались сложными:

На стороне iOS

• Что такое Podfile?
• Как связаны библиотеки?
• Как работают их зависимости?
• Как работает Cocoapods?
• Что такое XCFramework
• И так далее — а iOS-разработчики не знакомы с Gradle.

При установке KMM в Gralde

• Как настроить скрипт Gradle для создания фреймворка, пригодного к использованию в iOS?

Проблемы — разработка

• Нет знакомства со Swift
• Вызов корутин в iOS
• Странные имена переменных в iOS (например, Kotlinx_coroutines_coreCoroutineDispatcher)
• Автодополнение в Xcode показывает множество несвязанных переменных

Проблемы — рабочие процессы

Как и в прошлом, команды Android и iOS имеют разные наборы рабочих процессов, например, в создании PR, именовании веток, сообщениях коммитов, подтверждении CI и так далее. Интеграция KMM также создает инициативу по согласованию наших рабочих процессов, чтобы мы могли объединить и выстроить две команды в одну (конечная цель).

Заключение

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