Варіанти кроссплатформної розробки мобільних додатків

Мало хто зможе утриматися від бажання працювати менше, а отримувати більше. Це бажання, виконане в позитивному ключі, веде до прогресу. Однією із спроб досягти цього стала платформна розробка мобільних додатків.

Зі зростанням популярності смартфонів, планшетів, електронних книг і нетбуків мобільні платформи стають все більш актуальними — починаючи від адаптивної верстки сайту і закінчуючи повноцінним додатком.

Давайте подивимося, які варіанти кроссплатформної розробки існують і що вони пропонують нам як творцям. Бізнес постукає зі своїми бажаннями, а вибір того, на чому писати, часто доводиться робити саме розробнику.

В кінці статті ви знайдете опис конкурсу, переможці якого зможуть пройти курс вивчення однієї з перерахованих нижче фреймворків.

Проблема архітектури в кроссплатформах

У світі кроссплатформы всі фреймворки приблизно однакові по своїй структурі. В основі всього — цільова платформа (iOS, Android, etc.), для якої ведеться розробка і шар абстракції, який обіцяють зробити швидко, дешево і красиво, а між ними міст, що з'єднує ці дві сутності. Шар абстракції здебільшого представлений зв'язкою з JS і CSS (частково або повністю).

У такої архітектури є типові проблеми.

Частково вони обумовлені тим, що шар абстракції, умовно кажучи, намагається всидіти на двох стільцях — з перемінним успіхом. Звідси і складності: на кожній окремо взятій платформі додаток відображається і веде себе по-різному. Іноді це не проблема, але бувають випадки, коли унікальний дизайн і поведінка на обох платформах є додатковим business value.

У приклад можна привести додаток Reflectly. Спочатку воно було написано на React Native, вперше вийшло на iOS, а пізніше була спроба вийти на платформу Android.

React Native Flutter

Запуск програми в Android підніс неприємний сюрприз. У результаті його повністю переписали на Flutter.

В даному випадку програма реалізує унікальний функціонал , що минає трохи в бік від списків і форм, дизайн теж є унікальним. Дізнатися подробиці цієї історії можна тут .

Асинхронність та продуктивність мосту, що з'єднує дві платформи. Все, що ви хочете від платформи (рендеринг, виклик нативних методів), вам спочатку потрібно сериализации в рядок, передати, по ту сторону десериализовать і тільки потім отримати очікуваний результат. Такі дії явно не збільшать продуктивність.

Працездатність і підтримка плагінів. Кроссплатформа не так поширена, як класичний фронтенд. Нерідко плагін випускається в Open Source, і практично відразу припиняється його підтримка, так як існуюча версія вирішує проблеми розробника, а за більше ніхто не буде платити. Ще гірше, коли припиняється не тільки підтримку, але і реагування на pull requests...

Міф про те, що будь-якого web-розробника можна швидко перекваліфікувати у мобільщика з допомогою «магічного фреймворку Х». Все виглядає схоже на Web — CSS + JS, на кроссплатформе — те ж саме. Повинно працювати. Але не враховується факт, що до наявних знань потрібно швидко додати розуміння як мінімум двох платформ (iOS і Android), з якими розробник раніше не стикався. Окремим бонусом йде набивання руки в специфічних питаннях, пов'язаних зі взаємодією всередині всього цього зоопарку.

З-за всіх цих нюансів кроссплатформенную розробку тролять ось так:

Почнемо знайомство з фреймворків, заснованих на WebView.

Cordova

Одним з перших кросплатформених фреймворків став Cordova (кол. PhoneGap). Перший реліз відбувся в 2009 році. Спочатку розроблявся компанією Nitobi, купленої Adobe. У результаті поглинання вихідний код PhoneGap був переданий Apache Foundation.

З офіційною архітектурної схеми видно, що основою візуалізації виступає звичайний WebView — то є звичайний браузер. Незважаючи на те що це найдавніший фреймворк, пропонує він лише джентльменський набір плагінів і зв'язки API для забезпечення їх взаємодії. Якогось специфічного набору інструментів у нього немає. Є перелік сервісів та бібліотек, який пропонується на головній сторінці, наприклад Onsen UI — UI-бібліотека.

Developer experience досить неоднозначний: фактично, як ти його собі організуєш, так і буде. Можна на jQuery все писати і оновлювати сторінку з F5, а можна зібрати собі затишний і звичний набір бібліотек і користуватися вже існуючими рішеннями для hot reload.

Дебаг відбувається в консолі браузера. Дебаг на пристрої — через зв'язок з Safari до WebView, запущеному на iOS.

Також є зручний механізм темплейту, який дозволяє генерувати проект з готових сторонніх бойлерплейтов. Наприклад, cordova-template-framework7-vue-webpack .

Ionic

На основі Cordova в 2013 році був випущений Ionic . З часом Cordova замінили Capacitor із збереженням сумісності API, щоб залишилася працездатною вся існуюча база компонентів.

Має свою базу UI-компонентів і дозволяє реалізовувати бізнес-логіку будь-фреймворку з могутньої трійки (до 4 версії була можливість використовувати тільки Angular). Є можливість оплатити ентерпрайз-підтримку. В іншому все сказане про Cordova відноситься і до Ionic. Дебаг в консолі браузера, хот-релоад від фреймворку, працює всередині WebView.

Наступними розглянемо фреймворки semi-native, які пропонують писати на суміші CSS + JS (React Native, NativeScript, Appcelerator) або .NET (Xamarin), а на виході отримувати додаток, практично не відрізняються від нативного.

Appcelerator найменш відомий (0 згадок у вакансії на DOU), використовує свій власний фреймворк Alloy . Існує також версія з підтримкою Angular , але вона все ще в беті, а рух в репозиторії зупинилося в 2108 році... Знати про нього можна, а вивчати практичного сенсу немає :)

Xamarin

Фреймворк з довгою історією. Спочатку розвивався окремо, пізніше був придбаний компанією «Майкрософт». Оскільки він «не на JS», то не дуже популярний.

На відміну від JS-фреймворків код на C# компілюється, і це дозволяє йому працювати трохи швидше. Також у нього є два варіанти архітектури.

Тут UI-шар розробляється окремо для обох платформ, а бізнес-логіка загальна. Цей варіант буде цікавий, якщо є бажання зробити максимально нативне додаток з точки зору UI (з урахуванням всіх гайдлайнов), а на дублюванні бізнес-логіки заощадити шляхом повторного використання існуючих напрацювань. В той же час вимагає наявності в команді розробників, здатних написати UI-частина для обох платформ окремо.

Xamarin Forms

Продовження розвитку Xamarin, але вже з покриттям UI, не вимагає написання окремо.

Доступні набори інструментів для розробки на будь-який смак. Є безкоштовна Visual Studio Community Edition і платна версія Visual Studio Professional по підписці за 45 $ в місяць.

Дебагер, хот-релоад (тільки для верстки), лейаут-эдитор — все є в наявності. Однак мова розробки і відносна дорожнеча інструментів розробки робить Xamarin малопоширених за межами екосистеми Microsoft.

NativeScript

Фреймворк випущений в 2014 році. На даний момент з коробки пропонується писати на Angular або Vue. За довгі роки розвитку накопичив достатньо великий арсенал інструментів розробника: готовий набір UI-компонентів, власну пісочницю , маркетплейс компонентів , додаток для швидкого запуску превью написаного коду на пристрої, додаток, де можна побачити наживо роботу компонентів. Для дебага можна використовувати або консоль браузера, або надається розробниками плагін для VS Code.

Має цікаву архітектуру — API платформи через рефлексію пробрасываются на бік JavaScript.

На практиці робота з API-платформи виглядає так , як ніби ви пишете, наприклад, на Java, тільки через призму JS. У повсякденному же роботі використовується набір вбудованих layout-компонентів і CSS-подібний синтаксис для розмальовки. При зміні стилів досить непогано працює hot reload.

На виході маємо бандл JS-коду, виконаний в JSCore (iOS) або V8 (Android) і працює через міст з платформою.

React Native

Перший реліз відбувся в 2015 році. Практично єдиний з кросплатформених фреймворків JS, який не дає нам вибору і пропонує тільки React як фреймворк для розробки. Його поява підтверджує, що React можна згодувати будь-движок для візуалізації віртуального будинку дерева. Перша імплементація цього підходу була результатом хакатона і в підсумку продовжила свій розвиток в Open Source. На даний момент дуже популярний не в останню чергу завдяки «Реакту» для Web.

Загальна архітектура дуже схожа на NativeScript, тільки міст на 100 метрів вище по річці. Нативні плагіни пишуться на стороні платформи, а через міст передаються лише параметри. У проміжку між JS і платформою знаходиться Yoga — багатоплатформовий движок, який реалізує flex-box layout на цільовій платформі.

Технічно React Native дуже схожий на те, що frontend-розробники звикли бачити на Web.

Фреймворк активно розвивається: релізи з'являються кожні 3-6 місяців. У версії 0.61.0 оновили механізм hot reload, який дозволяє працювати більш продуктивно. Не так давно була випущена версія 0.62.0, яка додала інтеграцію fbflipper з коробки. Сподіваюся, ця ініціатива отримає гідне продовження, так як досі арсенал інструментів розробника був схожий на клаптикову ковдру. Спочатку пропонується тільки консоль браузера, можна використовувати також react-native-debugger або reactotron , які дають додаткові інструменти при розробці (інспекція Redux, MobX, Apollo Cache).

З особливостей: іноді зустрічаються відмінності при відображенні в iOS і Android. У більшості випадків все добре, але перед завершенням розробки фічі варто перевіряти на обох платформах. Віджети, які надаються платформою, іноді сильно відрізняються . У разі перемикачів механіка і загальний принцип роботи однакові, у разі пикера відмінності кардинальні. Якщо потрібно подібна механіка, доводиться вдаватися до послуг модулів .

Останніми розглянемо фреймворки native-like. Відрізняє їх те, що вони зовсім не використовують вбудованих віджетів. Замість цього малюють все своїми силами. Одним з новачків в цій категорії є Flutter. У процесі підготовки статті я з подивом виявив, що з 2011 року на Python розвивається аналогічний фреймворк, який реалізує таку ж концепцію, — Kyvi . На жаль, але цього фреймворку не вистачає фінансування і ком'юніті. Наприклад, імплементація Material UI вже 3 роки не розвивається, а ініціатива була перехоплена нашим співвітчизником.

Flutter

Перший реліз відбувся в кінці 2018 року. Платформа досить молода, але вона активно розвивається: щоквартальні релізи, активний розвиток мови Dart , багатий інструментарій розробника, дивовижний hot reload, онлайн-редактор для анімації, спеціалізована CI/CD — все це було доступно з першого дня релізу версії 1.0.

Особливістю архітектури Flutter є те, що він сам малює кожен піксель, контролює жести і анімацію. Він не використовує ОЕМ-віджети, як це робить React Native. Замість цього команда Flutter створила два набору віджетів для основних мобільних платформ: Material для Android і Cupertino для iOS. Таким чином, вони заново відмалювали всі UI-компоненти з обох мобільних платформ, повністю повторивши їх поведінку. Безпосередньо з мобільною платформою (геолокація, звук, Bluetooth) взаємодія відбувається через Platform Channels.

Завдяки такій архітектурі заявлена підтримка «все що завгодно», в теорії. На практиці добре підтримуються iOS і Android. Активно розвивається Web. Фактично успіх на web-терені визначить подальшу популярність фреймворку у всьому світі. На даний момент є підтримка Web в бета-версії, і з кожним днем вона стає все краще. Однією з проблем є продуктивність. З прапором FLUTTER_WEB_USE_SKIA=true продуктивність істотно зростає. Більш детальний огляд Flutter доступний в моїй попередній статті .

Відносна «молодість» платформи і широкий перелік підтримуваних платформ, буває, підносить баги в несподіваних місцях. Завдяки швидко зростаючому ком'юніті на багато з них є ишьюс на GitHub, в яких часто можна знайти варіант вирішити проблеми.

Qt

З цим фреймворком мені ще не довелося щільно познайомитися. На всякий випадок я його встановив і запустив. Не без проблем — через бага, який благополучно пофиксили у версії 5.14.2. Відпишіться В коментарях, якщо у вас є досвід кроссплатформної мобільного розробки на Qt.

Тренди

Для повноти картини наведу тренди на Stack Overflow :

Вакансії (Djinni):

Муки вибору

Вибір конкретного рішення буде продиктований, швидше, не плюсами і мінусами фреймворку, а загальною картиною і цілями на проекті. Кроссплатформу можна назвати компромісом між створенням окремих команд розробки і отримання якісного результату. Також кроссплатформа підходить стартап-проектів. В обох випадках ви будете вибирати виходячи з того, що є в активі, а не заради перспективи отримання сферично ідеального продукту. Під активом мається на увазі існуючий продукт (код, який можна повторно використовувати), компетенції працівників, популярність фреймворку (наймання нових співробітників, розвиток фреймворку і плагінів).

Наприклад, якщо у вас десктоп-рішення .NET, ваш вибір, швидше за все, впаде на Xamarin, що дозволить ефективно заново використовувати наявні напрацювання та компетенції.

Якщо вам потрібно просте рішення, щоб поточний web-продукт підтримати мобільною платформою, вам підійдуть PWA або Ioinc (з дистрибуцією через магазини).

Якщо ви тільки за Angular або за React, а все інше — «фу-фу-фу», якщо немає часу або бажання розбиратися треба, а на додаток вчора, ви, швидше за все, зупиніть вибір на NativeScript в першому випадку або на React Native у другому.

Стартапам доведеться вибирати між React Native і Flutter з-за їх популярності і підтримки великими компаніями. Перший — це зрілий фреймворк з усталеними практиками розробки, багатством бібліотек і великим ком'юніті. Другий — молодий, швидкий і перспективний з багатим набором вбудованих UI-компонентів і крутим developer experience.

Початківцям розробникам або бажаючим спробувати щось нове варто звернути увагу на Flutter.

Конкурс

Телеграм-група ArtFlutter запускає проект для людей, які хочуть навчитися розробляти програми на Flutter. Суть проекту дуже проста: ви виконуєте завдання, яке зазначено в правилах , а ми даруємо курс, який ви зможете пройти в будь-який час. У зв'язку з карантином вільного часу у нас стало трішки більше (як мінімум економія часу на дорогу до офісу і назад), і найкраще витратити його на навчання та вдосконалення навичок.

ArtFlutter Meetup #1

21 травня 2020 в 18:00 ми проведемо перший митап, присвячений Flutter, на нашому YouTube-каналі .

Теми доповідей:

Підписуйтесь і стежте за оновленнями!

Опубліковано: 22/04/20 @ 10:00
Розділ Різне

Рекомендуємо:

По той бік огорожі: бізнес-аналітик про роботу в ролі продакт-оунера
«Потрібно давати людям грати. Ставити складні завдання. Платити за їх помилки». Олександр Конотопський — про завдання Ajax Systems, найм інженерів і українському продукті
Набір на 6 потік мого курсу SEO Шаолінь
C++ дайджест #26: StayAtHome та вивчай Machine Learning
Product Marketing дайджест #3: стратегія зростання в часи невизначеності, шлях з $0 до $1,3 M MRR