Название кликбейтное, привлекает внимание, но не совсем правдивое. Flutter, конечно же, нужен.
Привет! Меня зовут Егор Федяев, я мобильный разработчик финтеха в Яндекс Про. В статье расскажу, почему важен и Flutter, и натив, а также поделюсь примерами, как мы используем натив в кроссплатформенном приложении Яндекс Про.
Почему нужен и Flutter, и натив
Начну с того, зачем нужен Flutter и в чем его преимущества для нас в Про.
- Flutter как технология активно развивается, популярность фреймворка растет.
- Разработка на Flutter чаще всего идет быстрее. Можно посчитать, сработает ли это для вашего проекта: подробно о формуле для расчет времени рассказал Сергей Кольцов на Яндекс Go Mobile Day&Night.
- Flutter объединяет две мобильных платформы и дает возможность писать под десктоп и веб на единой кодовой базе. Загвоздка только в том, что база не такая уж единая.
Мы провели исследование кодовой базы в Про, и оказалось, что 80% проекта действительно написана на Dart, то есть это база кода используется на двух платформах. Целых 80% неплохо, да?
При этом есть те самые 20% контрибьютов в натив. Мы не можем их просто взять и выкинуть, поэтому давайте разберемся, мало это или много.
Рассмотрим простой пример: у нас есть машина, в ней четыре колеса и трансмиссия, двигатель. Мы не можем взять и выкинуть какую-нибудь часть машины, иначе она не поедет. С нативом также: если избавиться от него в Яндекс Про, не останется ни карты, ни работы с камерой, ни работы со звуком.
Поэтому мы используем его в нескольких случаях:
- Работа с аппаратными функциями: Bluetooth, GPS, гироскопом, камерой и другими. Flutter — в первую очередь UI-фреймворк, который не умеет работать с аппаратными функциями напрямую. Для таких задач у нас есть нативный код и разработчики на Android и iOS, которые делают обработчики для аппаратных функций.
- Код уже написан на нативе: дешевле сделать плагин, чем переписывать на Flutter. Бывает уже написанный код, который не хочется просто брать и выбрасывать. И если есть нативная SDK, то гораздо лучше взять и обернуть её во Flutter-плагин. Таких кейсов у нас достаточно много, потому что Яндекс делает много внутренних и внешний проектов, в первую очередь, на нативе.
У нас есть несколько нативных плагинов, с которыми активно работаем:
- Карты и геолокация — база Яндекс Про. Если вы сидите на заднем сиденье такси и смотрите на экран таксиста, то первое, что вы видите — карта, основанная на SDK Яндекс Карт.
- Подключение к постаматам и датчикам. Этот кейс связан с работой курьеров. Например, курьеры Яндекс Маркета используют постаматы, к которым подключаются по Bluetooth.
- Обработка жестов, камеры, считыватели QR-кодов, видео- и аудиопроигрыватели, а также нативные SDK.
Так как я работаю в финтехе, дальше расскажу подробнее, как мы используем натив в Яндекс Банке.
Кейс: Яндекс Банк для водителей
Яндекс Банк — привычный всем банк, только не в отдельном мобильном приложении, а в Яндекс Про. В нём есть много плюсов: моментальные выплаты, бонусы, кешбэк. Самое удобное — сервис встроен в приложение, не нужно скачивать и авторизовываться отдельно.
Для бизнеса Банк — важный и приоритетный проект, потому что так мы развиваем финтех Яндекса и делаем водителей, а следовательно, и пассажиров, счастливее.
Банк выглядит так: экран дашборда, экран кешбэка и экран пластиковой карты. Особенность сервиса в том, что в нём только один экран с дашбордом, написанным на Flutter, всё остальное — это BankSDK, который мы открываем, используя уже готовые решения.
Если у вас есть карта Плюса и приложение, экраны могут быть знакомы, потому что они используются не только в Про. Нам не пришлось всё писать заново: мы просто взяли и обернули нативные плагины.
Работает всё достаточно просто: есть банк-фича, в в нее интегрируется банковский плагин, который является просто оберткой для BankSDK iOS и BankSDK на Android.
Что мы берем из нативного SDK?
- Показываем готовые сценарии из нескольких экранов. Через SDK создаем UI-сценарий — один или несколько экранов, которые мы можем показывать из нашего Flutter-приложения. Например, экран кешбэка, экран пластиковой карты.
- Обрабатываем часть бизнес-логики. Всё, что происходит при нажатии на кнопки Получить или Кешбэк за сентябрь, открывается нативом.
- Открываем диплинки.
- Получаем пуши с помощью EventChannel.
Расскажу подробнее о сложности и процессе создания и масштабирования таких фичей:
- Сценарии и диплинки — первый уровень сложности. Для разработки пишем плагин-wrapper для BankSDK — в этой задаче вам не нужны особые знания натива. Нужно базово пройтись по синтаксису Swift или Kotlin и понять, как открывать экраны. Далее либо берем на стороне Dart MethodChannel и добавляем методы открытия экранов и обработку диплинков, либо на стороне натива создаем экран с помощью фабрики и открываем его.
- Возможность скрыть информацию (не только SDK) — второй уровень сложности. Мы используем другие функциональности девайса, в том числе гироскоп. В этом случае нужно уметь разбираться в API гироскопа и понимать, как работает CMMotionManager на iOS и SensorManager на Android. Далее с помощью EventChannel нужно обрабатывать эти события — а события у нас приходят в виде матрицы переворота экрана — чтобы на стороне Flutter скрывать информацию, которую водитель хочет скрыть.
Зачем нужна фича: многие водители не хотят, чтобы пассажиры видели их баланс или транзакции. Это достаточно приватная информация, и водитель может либо встряхнуть телефон, либо нажать кнопку и скрыть ее. - Карточки водителей из Яндекс Про в Яндекс Go — третий уровень сложности. Это максимальный натив и полный переход в нативную разработку. В Яндекс Про мы сделали карточки для водителей, перешли в Яндекс Go и поняли, что они работают не так, как мы ожидали. Обратились к команде разработки Яндекс Go и предложили внедрить фичу прямо в суперапп, чтобы сделать оптимальный UX. Договорились, а дальше наши ребята, которые работают с нативом, пришли и дописали под новый API карту из Яндекс Про внутри Яндекс Go.
Этот кейс — пример, как в нашей экосистеме могут происходить обмены ресурсами и как наши компетенции в нативе помогли улучшить пользовательский опыт не только в Яндекс Про.
Все примеры основаны на нашей работе над Яндекс Банком. Это только одна фича, в экосистеме их намного больше, и у большинства из них так или иначе есть либо какие-то аппаратные функции, либо SDK, которые под ними используются.
Например, Заправки — полностью готовая SDK на iOS и Android, которую мы оборачиваем и показываем внутри модалки. В Маркете есть подключение по Bluetooth к постаматам для курьеров и сканеры QR-кодов. В Еде используется подключение к биконам в ресторанах, то есть неким Bluetooth-станциям. Когда курьер заходит в ресторан, ему сразу приходят пуши о статусе заказа, а ресторан узнает, что курьер уже пришел.
Все эти фичи нельзя сделать без натива, поэтому возвращаемся к идее, что в достаточно больших проектах для стопроцентной реализации требований бизнеса нужны разработчики, которые могут писать и на Flutter, и на iOS, и на Android.
Навыки разработчиков в нативе
Мы провели в нашей команде небольшое исследование на 50 человек и узнали, кто пришел из какой платформы и какие знания пригодились в работе. Как оказалось, большинству Android-разработчиков и всем iOS-разработчикам пригодились знания своей платформы, их применяли и писали фичи конкретно с использованием этих технологий. Здесь стоит обратить внимание, что Android-разработчики чаще приходят во Flutter, чем iOS-специалисты.
В результате мы решили, что идеальный кроссплатформенный разработчик должен хорошо знать Flutter и одну из платформ, при этом уметь писать и понимать код как на iOS, так и на Android.
И тогда уже можно, чтобы он и код без багов писал, и всегда в сроки успевал, и драконов побеждал... В общем делал всё, что попросит продакт-менеджер. Такого почти не бывает, а если бывает, то стоит очень дорого. Так что если вы это можете — вы сильно повышаете свою ценность на рынке.
Вернемся к уровням сложности: не все команды могут позволить себе набрать идеальных кроссплатформенных разработчиков в вакууме. При этом часто во время проектирования приложения можно оценить его сложность, понять, сколько фичей используют аппаратные функции девайса, сколько используется SDK, и решить, какой разработчик нужен проекту.
- Если используется по минимуму, можно поставить нулевую сложность.
- Если вы хотите подключить виджеты или используете SDK, которые уже готовы на iOS или Android, нужно написать плагин-wrapper, понадобятся базовые знания натива — первый уровень.
- Если нужно сверстать экраны на iOS или на Android, нужен разработчик с хорошим опытом работы на платформе — второй уровень.
- Если большая часть приложения написана на iOS или Android, нужно подключать хорошего нативщика — третий, самый сложный уровень.
Далее делюсь матрицей навыков, которые нужны разработчикам для каждого уровня сложности — сохраняйте себе и тренируйтесь.
Какие навыки должны быть у разработчика
| Базовые | Продвинутые | Эксперт |
|---|---|---|
| Синтаксис, кодстайл | Верстка | Build & Release |
| Управление зависимостями (SPM + Cocoapods/Gradle) | Архитектурные паттерны (MVC, MVVM, MVI, MVP) | Новый фреймворки: Swift UI / Jetpack Compose |
| Асинхронка и многопоточность | Тестирование | Java/Objective-C |
| App Lifecycle | Persistance | Способность построить архитектуру проекта с нуля |
| IDE, DevTools (Xcode, Android Studio) | Best Practices | Advanced DevTools, profiling |
Подытожим материалы этой статьи: с одной стороны, команде всегда нужно понимать, сколько нативного функционала у вас будет, и уметь оценивать, как сложно будет имплементировать натив в ваше приложение. Далее в зависимости от этого нужно искать разработчиков с подходящими скиллами.
Финальный совет для разработчиков: если вы обладаете хотя бы базовыми навыками в iOS и Android, это сильно увеличивает вашу ценность на рынке. Поэтому изучайте обе платформы — так вы точно будете востребованы и сможете решать сто процентов задач для бизнеса.