{"id":14289,"url":"\/distributions\/14289\/click?bit=1&hash=892464fe46102746d8d05914a41d0a54b0756f476a912469a2c12e8168d8a933","title":"\u041e\u0434\u0438\u043d \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u043b \u043f\u0440\u043e\u0434\u0430\u0436\u0438 \u043d\u0430 5%, \u0430 \u0441\u0440\u0435\u0434\u043d\u0438\u0439 \u0447\u0435\u043a \u2014 \u043d\u0430 20%","buttonText":"","imageUuid":""}

KMP vs Flutter: 4 сценария, когда нужно сделать ставку на Kotlin Multiplatform, а не Flutter

Привет, это Максим Павлов— управляющий партнёр KTS. Мы создаём IT-продукты для бизнеса.

Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах. В статье — о том, чем Kotlin Multiplatform отличается от Flutter и в каких случаях он переигрывает и уничтожает Flutter.

При переходе от нативной разработки к кроссплатформенной многие выбирают Flutter, мы выбрали KMP. Я поспрашивал у нашего руководителя мобильной разработки Максима Мялкина, почему мы выбрали его, а не попсовый Flutter — делюсь результатами.

Максим Мялкин 
Руководитель мобильной разработки KTS

Kotlin Multiplatform (KMP) — раньше был известен еще как Kotlin Multiplatform Mobile‎ (KMM).

Кратко про KMP

KMP — это технология, которая помогает разработчикам переиспользовать общий код на языке Kotlin в обеих версиях мобильного приложения: для iOS и Android. KMP разработали в компании Jetbrains, которая сделала язык Kotlin — основной язык разработки приложений под Android.

Приложение на Kotlin Multiplatform состоит из трех частей:

  • общего кода, который описывает логику сразу для двух платформ,
  • кода интерфейс под iOS,
  • кода интерфейс под Android.

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

У вас будет интерфейс (отдельно под Android, отдельно под iOS), причем довольно простой: два поля ввода, кнопка «далее» и место для ввода кода из SMS.

При этом, за таким простым интерфейсом будет скрываться и своя логика: таймер, который отсчитывает время отправки кода, правила, по которым его нужно отправлять — это будет общий код, одинаковый и для iOS, и для Android.

Кратко про Flutter

Flutter — это более популярный кроссплатформенный фреймворк.

Главная особенность Flutter заключается в использовании одной кодовой базы на языке Dart вместо нескольких для Android и iOS платформ.

То есть, тогда как KMP фокусируется на бизнес-логике и позволяет использовать нативные инструменты каждой платформы для создания пользовательского интерфейса, Flutter предоставляет собственную систему виджетов для создания UI, которая позволяет создавать единый пользовательский интерфейс для всех платформ.

4 сценария, когда вам подойдет KMP

Выбор Flutter может быть предпочтительным, если вам нужно разработать приложение в короткие сроки и вы готовы мириться с ограничениями по дизайну. Согласно данным Surf, разработка на Flutter экономит до 40% времени по сравнению с нативной, тогда как у KMP этот показатель у нас в KTS варьируется между 20-25%.

Однако есть ситуации, когда стоит сделать выбор в пользу KMP.

#1. Вы не хотите долго искать разработчиков

Для работы на Flutter требуется знание языка программирования Dart. Разработчиков на Flutter тяжело найти на рынке — по данным того же hh.ru, сейчас их всего 1877 человек в России. Вы, конечно, можете нанять обычных Android- и iOS-разработчиков, но тогда надо будет потратить время на их переучивание. Без этого они и строчки не напишут.

Для работы на KMP не нужны «специальные» разработчики. KMP требует знание языка Kotlin, а значит вам подойдёт любой Android-разработчик: их, в настоящее время, по данным hh.ru, на рынке более 29 тысяч человек.

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

#2. Вам в приложении нужно использование блютуса, приём звонков и другие нативные фичи

Поскольку Flutter работает с языком Dart, то для настройки интеграции с нативными фичами — звонками или блютусом — придётся разрабатывать бриджи. Это механизмы, которые обеспечивают связь между нативным кодом, который сможет работать с этими фичами, и кроссплатформенным кодом на Dart.

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

Как это реализуется на практике, можно посмотреть в нашем разборе мобильного приложения для управляющей компании застройщика Мангазея. Там мы написали приложение на KMP и без труда подключили в приложение модуль, который поставляет производитель домофонов.

#3. Вам важна нативность интерфейса

Flutter обеспечивает высокую скорость разработки, но в нём больше ограничений, которые накладываются на реализацию интерфейса. В KMP меньше ограничений, но создание интерфейсов занимает больше времени.

Да, конечно, во Flutter можно постараться и создать нативно выглядящий интерфейс под каждую платформу, а в KMP — использовать compose multiplatform, который позволяет делать единый интерфейс для обеих платформ. Но это скорее исключения из общепринятых подходов.

Вывод: если вам важен максимально нативный интерфейс для пользователей платформы или вы стремитесь сделать премиальный продукт, то выбирайте KMP.

#4. Вам важен плавный переход с нативного приложения

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

Также KMP — подходящий вариант, так как вам не нужно будет переписывать всё приложение с нуля, как того потребует Flutter.

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

Пример: у вас уже есть два нативных приложения. Вы можете встроить новые экраны, которые написаны на KMP, в старые приложения без необходимости переписывать весь апп. Следовательно, вам не нужно инвестировать много времени в переезд на KMP.

Кто и почему использует КМР

Сейчас KMP используют Avito, Google, Netflix и Тинькофф. Число компаний, которые его используют, растет с каждым годом.

Мы в KTS выбрали КМР по 3 критериям:

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

Если совсем коротко

Flutter — это решение для быстрого запуска небольшого продукта в том случае, если вы готовы мириться с ограничениями готовых компонентов.

Однако если у вас:

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

то лучше использовать KMP, позволяющий создать максимально привычный интерфейс.

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

0
89 комментариев
Написать комментарий...
Alexander

За 20 лет в ИТ могу сказать что трудозатраты на разработку UI всегда недооценивают и в общем объеме проекта они и съедают огромное количество человеко-часов и в основой части проекта и в последующем развитии и исправлении дефектов. А то что называют весомым словосочетанием "бизнес-логика" обычно делается относительно легко и в предсказуемые сроки в общем-то на любом языке. И я сейчас не только про простенькие приложения, но и про суровые Enterprise системы для большого бизнеса.

Поэтому необходимость дважды пилить UI считаю серьезным недостатком KMP.

Однако, спасибо за обзор, это очень полезно знать.

Ответить
Развернуть ветку
Максим Мялкин

Под “бизнес-логикой” люди часто понимают разное. И в KMP действительно можно выносить в кроссплатформу разные части, по потребности. В статье мы не стали раскрывать что именно туда входит, тк не хотели закапываться в технику, но кратко опишу тут.
Кто-то в KMP выносит только логику работы с данными, а кто-то всю логику: презентационную, доменную, логику работы с источниками данных. Более детально можно посмотреть в опросе от JB (https://blog.jetbrains.com/kotlin/2021/10/multiplatform-survey-q1-q2-2021/). В наших проектах мы идем по второму пути, и поэтому из KMP-части прилетает только UiState, который нужно отрисовать на UI на платформах и передать из платформ в KMP событие от пользователя. Так получается достичь большего переиспользования.

Ответить
Развернуть ветку
Alexander

Спасибо за подробности!
Я именно про UI:
- хотим чтобы тут выпадающий список с фильтром был потому что в нем 10000 позиций
- чтобы здесь колонки можно было менять местами а тут ячейки объединять как в экселе
- чтобы здесь окошко было не модальное а выплывало снизу и пропадало
- чтобы тут диаграмма была с подписями не сверху а прямо на столбиках
- и таких over9000 требований в любой Enterprise-системе
И это все сжирает огромное количество ресурсов разработки. Часто гораздо больше чем например программная логика расчёта премий и бонусов для 10 000 сотрудников.

Ответить
Развернуть ветку
Максим Павлов
Автор

Насчёт выпадающего списка с фильтром и вылезания снизу оповещения с исчещанием - это решается хорошо и стандартными компонентами, второй в андроиде называется toast на сколько я помню

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

Ну и с доработками всяких диаграмм тоже проблем нет и такой перенос хоть в двух интерфейсах, хоть в одном занимает минимум времени, но да, при нативных интерфейсах в любом случае нужно будет сделать 2 раза

Ответить
Развернуть ветку
86 комментариев
Раскрывать всегда