Мультиплатформенная Разработка — ДА/НЕТ?

10 января 2022

НАПИШИ ОДИН РАЗ — ЗАПУСКАЙ ГДЕ УГОДНО

 

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

 

 

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

 

  • Объем шаринга кодовой базы. Бывают кейсы, когда универсальное решение не работает, либо работает не так, как нужно и тогда приходится его кастомизировать под конкретную платформу. Это свойство можно выражать через проценты — например, в приложении 50% общего кода. Можно выражать через абстракции — например, сетевой слой (т.е. работа с API)  общий, а UI часть на каждой платформе своя.
  • Производительность. Тут вроде все очевидно.
  • Порог вхождения: прежде чем работать с новой технологией ее нужно изучить/освоить.
  • Легаси: слабо-обусловленный отказ от накопленных знаний и опыта. Бывает естественная необходимость в переходе на новую технологию, когда старая объективно проигрывает, но бывает и так, что переход обусловлен лишь тем, что в новых условиях, просто другая экосистема, другой технологический стек. Чем больше знаний становятся неактуальными, тем хуже.
  • Перспективы: вероятность того, что технология выстрелит, ее не перестанут развивать и поддерживать, наличие активного комьюнити. Для команды это еще и актуальность знаний и опыта, на изучение которых были потрачены усилия и ресурсы.

 

Рассмотрим решение от JetBrains: Kotlin Mobile Multiplatform для iOS и Android.

 

ШАРИНГ КОДОВОЙ БАЗЫ.

 

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

 

Обычно в общий код попадают такие штуки, как работа с сетью, бизнес логика. В нейтиве реализуют UI и какие-то специфичные для платформы API, например работа с камерой, биометрия, Google/Apple сервисы и т.д.

 

Чисто в теории, можно зашарить и намного больше — все зависит от того:

 

  • на каком этапе развития находится технология
  • понравилась ли она сообществу, что влияет на кол-во библиотек от сторонних разработчиков.

 

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

 

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

 

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

 

С производительностью все должно быть хорошо.

 

Если грубо и без подробностей, то общий код компилируется в нативный и подключается как библиотека.

 

 

ПОРОГ ВХОЖДЕНИЯ/ЛЕГАСИ/ПЕРСПЕКТИВЫ

 

 

1. Новые библиотеки для разработчиков.

 

Если речь идет про шаренный код, то библиотеки там свои, их нужно осваивать: какие-то могут быть похожи на «старые» и даваться легко, а другие могут сильно отличаться, в том числе концептуально.

 

2.  Возможно новый (дополнительный) язык для iOS разработчика (Kotlin).

 

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

 

 

Пример.

 

То, что на изображении в схемке, это все шаренный код, написанный на Kotlin. При этом в iOS части (оранжевая слева) уже есть доступ к iOS SDK (разные NS обджекты).

Таким образом, либо iOS разработчик изучает Kotlin, либо Android разработчик, знающий Kotlin, изучает iOS SDK.

 

3. Архитектура

 

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

 

4. Две IDE (среды разработки)

 

Время от времени может понадобится работать в обеих IDE (Android студия и XCode). То есть речь идет о дополительном времени, чтобы освоиться.

 

5. Рекомендации по железу от iOS разработчика (для Mac)

 

  • 512 GB SSD
  • 16 GB RAM
  • Девайс (iphone) – не обязателен (есть simulator)

Возможно хватило бы и 350-400 ГБ диска, но выбор между 256 и 512, а чего-то посредине нету. 256 слишком мало, рискованно для двух экосистем разработки.

Стоит упомянуть, что на Windows собрать бинарник для MacOS нельзя.

Девайс (iphone) – необязателен (есть simulator, который хоть и покрывает не все кейсы, но для базового функционала сгодится).

 

 

ПЕРСПЕКТИВЫ

 

Чисто субъективно, по инфоповодам и тому, как это выглядит со стороны: технология вроде бы приглянулась комьюнити. Активно развивается, погибать не собирается.

 

Список некоторых компаний, которые используют КММ. Наверное всем понятно, что они используют это в рамках экспериментов, а не как основную технологию для флагманских продуктов.

 

Автор: Арсен, наш Android разработчик 😎

Поделиться