Нативно чи ні? Чотири міфи про крос-платформну розробку. Розробка кросплатформових додатків для початківців Значить, кросплатформова розробка - це погано

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

Особливості кросплатформової розробки

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

Ці особливості треба враховувати до початку проекту:

У кросплатформовому середовищі код пишеться один раз. Щоб програма працювала в іншій операційній системі, код перекладається іншою мовою програмування. Витрати часу та грошей на розробку в 1,5 рази менші.
Можлива некоректна робота програм.У кросплатформовій розробці неможливо врахувати всі нюанси роботи з архітектурою кожної операційної системи, тому програми можуть працювати повільніше за ті, що розроблені спеціально для iOS або Android.
Інтерфейс та вимоги до дизайну елементів у різних операційних систем різняться. Наприклад, на iOS відсутня кнопка Back, як на Android. При розробці єдиного дизайну цей момент потрібно враховувати: в iOS кнопка або залишиться, але не працюватиме, або доведеться вирізати її вручну, а це додаткові роботи з кодом.

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

Значить, кросплатформова технологія – це погано?

Ні, кросплатформова технологія – це нормально, якщо не вимагати від неї більше, ніж вона може дати.

Цей варіант можна вибирати у таких випадках:

Охопити всі операційні системи за обмеженого бюджету.Якщо цільова аудиторія активніше користується iOS або Android, можна почати з програми для однієї операційної системи. Якщо максимальне охоплення важливе відразу, краще вибрати кроссплатформенний варіант.
Перевірити нішу. Якщо є перспективна ідея, але немає впевненості, що вона вистрілить, одразу вкладати великий бюджет у розробку ризиковано. Є сенс почати з кросплатформної розробки, вивчити реакцію користувачів та приймати стратегічні рішення на цій основі.
Програма не використовує складну анімацію і не веде розрахунки.Ці операції серйозно навантажують пристрій, а кросплатформна програма не оптимізована для повноцінного використання ресурсів тієї чи іншої платформи.
Додаток використовує лише основні функції пристрою. Показувати інформацію, завантажувати файли, використовувати геолокацію, оформляти замовлення - з усім цим кросплатформна програма впорається. Потрібна глибша інтеграція можливостей пристроїв – доведеться вибрати нативну розробку.
Корпоративний додаток для співробітників.Якщо програма розробляється для вузьких внутрішніх завдань і люди будуть працювати з ним через особисті гаджети, кросплатформна програма буде оптимальним варіантом.

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

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

Що таке кросплатформні програми?

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

Нагадаємо: нативні програми, на відміну від кросплатформових, пишуться під конкретну ОС.

Плюси кросплатформної розробки

розширення бази користувача за рахунок появи програми одночасно в декількох магазинах;
один вихідний код позбавляє вас необхідності наймати декількох розробників для кожної платформи;
75% кодової бази кросплатформної програми можна використовувати повторно, адаптуючи її для нових проектів.

Мінуси кросплатформової розробки

1. Велика залежність від мобільного пристрою

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

2. Недружелюбний інтерфейс користувача

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

Проблема в тому, що для кроссплатформенної розробки не буває гайдлайнів – стандартів розробки від творців ОС. Тому кросплатформна програма, зроблена «під Android», не буде зручною користувачеві iOS, і навпаки. Можна, звичайно, створити окремі дизайни для кожної платформи, але за обсягом трудовитрат це дорівнюватиме створенню двох різних додатків, хоч і однією мовою.

3. Боротьба за першість серед інструментів розробки

На ринку рішень для кроссплатформенной розробки конкуренція посилюється з кожним днем. Поки що найбільшою популярністю у розробників користуються React Native та Xamarin, але їх цілком може випередити, наприклад, Vue Native. У такому разі екс-лідери гонки втратять найважливішу перевагу – оперативну підтримку коду. І таке може статися з будь-яким кросплатформним інструментом.

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

Яка програма підійде вашому бізнесу?

Перед тим, як відповісти на це питання, дуже важливо проаналізувати свій бізнес. Споживчі сегменти, цінність тимчасових та грошових ресурсів, бажана глибина інтеграції програми з пристроями користувачів плюс чітко окреслені довгострокові цілі – той мінімум, від якого залежатиме ваш вибір. Але ми зробимо його простішим, якщо ви прямо зараз відповісте на відповідні питання.

1. Чим користується аудиторія?

Якщо ви знаєте, що співвідношення кількості користувачів iOS та Android серед ваших клієнтів є близьким до пропорції 50 на 50, вибирайте нативну розробку. Так ви покажете, що однаково поважаєте потреби всіх ваших клієнтів незалежно від рівня їхнього доходу.

Зв'язок між вибором мобільного пристрою та рівнем платоспроможності вкотре підтвердила компанія App Annie. В результаті дослідження кількості завантажень та обсягу продажів мобільних додатків у Google Play та App Store за перший квартал 2018 року з'ясувалося, що користувачі Android-смартфонів завантажили на 135% більше програм, ніж відвідувачі iOS-магазину. В той же час App Store приніс своїм власникам на 85% більше прибутку, ніж Google Play.

Шлях до успіху очевидний: грати на двох полях одразу. Точніше, на двох магазинах. Просто розрахуйте, в якому з них додаток має з'явитися першим. Звичайно, якщо одночасний реліз не є частиною вашої digital-стратегії).

2. Скільки у вас часу на розробку?

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

З нативним додатком таких проблем точно не буде, що дуже важливо для утримання аудиторії, яка вкрай не толерантна до помилок та багів. За статистикою компанії Compuware, 79% користувачів готові перезапустити додаток, якщо він некоректно запрацював під час першого запуску, але дати йому ще один шанс згодні лише 16%. Решта, швидше за все, просто видалять програму.

3. Які функції пристрою ви плануєте використовувати?

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

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

4. Яких результатів ви прагнете?

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

Розкладіть процес від ідеї до результату за пунктами з огляду на всі наявні ресурси. Відкриття можуть бути найнесподіванішими.

Наприклад, ви можете виявити, що перевести ваш адаптивний сайт з безліччю функцій та інтерактивними елементами в кросплатформну програму, як ви хотіли спочатку, - занадто затратне завдання. Або остаточно переконайтеся, що мобільний сайт завжди програє мобільному додатку – як кросплатформова розробка програє нативною. І серед причин виявите ті, про які ми розповіли вище.

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

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

Минулого разу ми стосувалися кросплатформової розробки мобільних додатків і з того часу багато що змінилося. Настав час поговорити про методи та інструменти знову.

Давайте спочатку пройдемося ще раз по термінології.

Рідні

Якщо розробники в процесі написання програми користуються прийнятою для конкретної платформи мовою програмування, чи то Objective-C і Swift для iOS, така програма буде називатися нативною (від англ. native - рідна, природна).

Переваги нативних додатків:

швидкість роботи та відгуку інтерфейсу. Додаток реагує на натискання миттєво, практично відсутні затримки в анімації, скролюванні, отриманні та виведенні даних;
зрозумілий і простий доступ до функцій та датчиків пристрою. Для розробника не є проблемою робота з геолокацією, пуш-повідомленнями, зйомкою фото та відео через камеру, звуком, акселерометром та іншими датчиками;
можливість поглибленої роботи із функціями смартфона. Як і в попередньому пункті, такі речі, як анімації, створення складних інтерфейсів і робота нейромереж прямо на пристроях реалізуються, можливо, і не просто, але прогнозовано;
. Нативні програми зазвичай оперують «платформними» елементами інтерфейсу: меню, навігація, форми та решта елементів дизайну беруться від операційної системи і тому звичні і зрозумілі користувачеві.

Нестача одна — дорожнеча розробки та підтримки, зокрема тому, що для кожної платформи треба писати свій код.

Зі зростанням ринку мобільних додатків розробники стали не просто дорогими, а дуже дорогими, і нативна розробка — це не те, що може дозволити собі кожен власник бізнесу. Але відмова від розробки мобільного додатка в майбутньому може обійтися вам дорожче. Лайв Тайпінг може допомогти вам заощадити - опишіть свою ідею і вкажіть приблизний бюджет, в який хочеться вкластися в .

І не рідні

Кросплатформні програми пишуться відразу для декількох платформ однією мовою, відмінною від нативної. Як такий код може працювати на різних пристроях? Тут також є два підходи.

Перший полягає в тому, що на етапі підготовки програми до публікації він перетворюється на нативний для певної платформи за допомогою транспілера. Фактично одна кросплатформова мова програмування «перекладається» на іншу.

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

Передбачається, що більша частина такого коду може переноситися між платформами - очевидно, що, наприклад, логіка здійснення покупок, збереження товару в кошик, прорахування маршруту для таксі, написання повідомлення в месенджер не змінюється залежно від того, Android у клієнта чи iOS. Потрібно лише доопрацювати UI та UX для платформ, але зараз, у певних межах, навіть це можна об'єднати – наприклад, меню-гамбургер активно використовується як на Android, так і на iOS. Так що навіть внесення виправлення до інтерфейсу для того, щоб додаток відповідав духу та букві потрібної платформи — питання бажання, необхідної швидкості та якості розробки.

Переваги:

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

Недоліки:

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

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

Що вибрати

У вас вже, напевно, пішла голова кругом, а розуміння що вибрати, так і не з'явилося. Давайте уявимо простий список питань, який вам допоможе:

має хоч якось працювати на будь-якому пристрої? Вибирайте HTMLяк основу;
у вас достатньо коштів, немає поспіху і ви хочете найякісніший додаток? Вам прямий шлях у нативну розробку;
у вас є «вбудований» веб-розробник чи ви просто хочете швидко і просто спробувати мобільний додаток у справі? Тут можна рекомендувати Cordova/HTML або PWA;
у вас є власна CRM-система і C#-розробник, що підтримує її? Беріть Xamarin;
ви "хочете спробувати", але треба зробити все красиво та модно? Дивіться убік React Native або Flutter.

Можна зайти з іншого боку. Подивіться на функціональність, яка вам знадобиться в додатку, і виходьте з цього:

просте додаток-візитка? Візьміть React Native або HTML5і ви отримаєте дві платформи за найменшу ціну;
Ви маєте сайт з великою відвідуваністю і вам потрібно протестувати гіпотезу присутності в мобільному просторі? HTML5;
складні програми з доступом до потрібних функцій пристроїв? Нативна розробка, Xamarin, React Native.

Кросплатформова технологія - не панацея

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

У вас залишилися сумніви та питання про кросплатформні програми? Почитайте про те, як ми створювали програму для швидкого отримання абонементу в один із спортивних закладів міста та спробуйте програму для оплати різноманітних видів послуг — від ЖКГ до замовлень в інтернет-магазинах. А краще запишіться на безкоштовну консультацію, із зазначенням зразкового бюджету та коротким описом ідеї або зв'яжіться з нашим менеджером Катею по телефону

Смартфони продовжують відвойовувати все більше місця під сонцем не тільки як інструмент споживання фотографій котиків та ххх-роликів, а й як робочий інструмент. Тому й попит на мобільну розробку зростає. Вважають, що тру і кул - це Objective-C/Swift для iOS і Java/Kotlin для Android. Безперечно, тру і кул, але існує велика кількість реальних сценаріїв, в яких використання крос-платформних фреймворків більш переважно в порівнянні з нативними інструментами.

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

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

Навіщо потрібні крос-платформні інструменти?

Історично на ринку комп'ютерів завжди була конкуренція, і кожен виробник надавав оптимальний набір про нативних (рідних) інструментів для розробки додатків під свої операційні системи та пристрої.

Нативні інструменти надаються власником екосистеми.

Всі інші ознаки «нативності» ВТОРИННІ - поведінка та інтерфейс додатків, доступ до можливостей ОС, продуктивність та інше.

До того ж, практично завжди виявлялося, що нативні інструменти несумісні один з одним не лише на рівні мов розробки, прийнятих угод та архітектур, а й на рівні механізмів роботи з операційною системою та бібліотеками. В результаті для реалізації тих самих алгоритмів та інтерфейсів вимагалося написати додаток для кількох середовищ різними мовами програмування, а потім його підтримувати з розрахунку «одна команда на платформу». При цьому можливості та зовнішній вигляд додатків на різних платформах практично завжди ідентичні на 90%. Порівняй заради інтересу реалізацію улюблених програм для iOS та Android.

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

Для того щоб вирішити ці проблеми, на ринку вже давно з'явилися інструменти крос-платформної розробки (не тільки mobile), що пропонують:

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

Так як мов програмування (і середовищ) зараз наплодилося дуже багато (і фахівців, які володіють цими мовами), то і інструментів для крос-платформної розробки існує велика кількість. Ми як приклад зупинимося на популярних у наших краях PhoneGap, Xamarin, React Native та Qt.

Тепер можна поговорити і про міфи.

Міф 1. Магія

Найчастіший міф, що хвилює уми початківців девелоперів, пов'язаний з вірою в надалгоритми (і надпрограмістів, які їх створили), які чарівним чином перетворюють крос-платформні додатки на нативні. Щось на кшталт «перетворення коду JavaScript на Swift і подальша компіляція вже Swift-додатку». Цей міф підігрівають і самі розробники крос-платформних інструментів, обіцяючи на виході створення нативних додатків. І не те щоб хтось тут лукавив, але багата фантазія та нерозуміння базових механізмів іноді наводять розробників на думки про шаманські прийоми.

Головний принцип, що лежить в основі крос-платформних рішень, - поділ коду на дві частини:

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

Для того щоб пов'язувати між собою світ «нативний» та світ «крос-платформний», необхідно використовувати спеціальний міст (bridge), Саме він і визначає можливості та обмеження крос-платформних фреймворків.

При використанні bridge продуктивність завжди знижується за рахунок перетворення даних між світами, а також конвертації викликів API і бібліотек.

Отже, всі крос-платформні програми повинні мати нативну частину, інакше операційна система просто не зможе їх запустити. Тому давай розглянемо докладніше, які системні API та механізми надаються самими iOS, Android та Windows. Переходимо до наступного міфу.

Міф 2. Ненативно!

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

Всі операційні системи: iOS, Android та Windows UWP – надають доступ до наступних підсистем (набори системних API):

WebView (вбудований у додаток веб-браузер) використовується в гібридних програмах на базі PhoneGap і фактично виступає середовищем виконання локального веб-сайту;
JavaScript-движки використовуються в React Native та аналогах для швидкого виконання JS-коду та обміну даними між Native та JS;
OpenGL ES (або DirectX) використовується в ігрових двигунах та додатках на Qt/QML або аналогах для відтворення інтерфейсу;
UI-підсистема відповідає за нативний інтерфейс програми, що актуально для React Native і Xamarin.

Крос-платформні програми мають нативну частину і такий самий повний доступ до системних API, що й «нативні» програми. Різниця в тому, що виклик системного методу йде через міст та інфраструктуру фреймворку:

WebView- Додаток живе у своєму веб-браузері за аналогією з односторінковим веб-сайтом. Немає доступу до нативних контролів (кнопки, списки та інше), все ґрунтується на HTML/CSS/JavaScript. З іншого боку, веб-розробник відчує себе як риба у воді.

JavaScript-движкистали популярні відносно недавно, тому що в iOS подібний механізм було додано лише у версії 7.0. З особливостей варто враховувати необхідність серіалізації в JSON складних структур даних, що передаються між середовищами JavaScript та Native. Якщо коротко описати подібний клас рішень, то JavaScript-середовищі виконується JS-код, керуючий нативним додатком.

OpenGL ES та DirectXє підсистемами низького рівня і використовуються для відтворення інтерфейсу користувача в іграх і, наприклад, Qt/QML. Тобто при використанні OpenGL/DirectX розробники самі малюють контроли та анімації, які можуть бути лише схожими на нативні. З іншого боку, це підсистема низького рівня з дуже високою продуктивністю, тому вона використовується і в крос-платформних ігрових двигунах.

Всі крос-платформні додатки мають нативну частину, а отже, потенційно такий самий повний доступ до системних API, що й «нативні». Також крос-платформні програми збираються та упаковуються «нативними» інструментами в «нативні» настановні пакети. Ключове питання - як організована взаємодія між крос-платформною частиною та нативною. Наприклад, всередині WebView або за допомогою Open GL ES/DirectX немає можливості створити інтерфейс користувача з повністю нативним look'n'feel, але при цьому є повний доступ до GPS, Push-повідомлень та іншої функціональності. А код на JavaScript або C# цілком вільно може керувати нативною програмою та її поведінкою, забезпечуючи повністю нативний look'n'feel.

Якщо резюмувати - так, «ненативно» з точки зору використовуваних інструментів розробки (не від Apple, Google). Але програма може бути повністю нативною з точки зору доступу до системних API і забезпечувати повністю нативний зовнішній вигляд і поведінку. А ми рухаємось до наступного міфу.

Міф 3. Милиця на милиці

Тут варто розуміти, що нативні API за замовчуванням милицями не вважаються (хоча і тут є різні думки), тому все обурення спрямоване на крос-платформну частину. Очевидно, що середовище (наприклад, WebView, JavaScript-движок або Mono) милицею теж назвати складно - дорослі зрілі рішення з тривалою історією.

Схоже, що милицею називають те, як крос-платформна частина інтегрується з нативною. Щоб краще зрозуміти, як працюють різні фреймворки, ми на прикладі PhoneGap, Xamarin, Qt і React Native розглянемо механізми операційних систем, які використовуються для зв'язування крос-платформної та «нативної» частин.

Почнемо ми з PhoneGap. Нижче представлена верхньорівнева архітектура програми на базі цього фреймворку.

Додаток на PhoneGap - це за фактом нативна програма, яка як єдиний UI-контроль відображає WebView. Саме через нього і йде взаємодія із нативною частиною. Всі стандартні WebView у iOS, Android та Windows UWP підтримують можливість додати свої нативні обробники для JS-властивостей та методів. При цьому JS-код живе у своєму ізольованому середовищі і нічого не знає про нативну частину - просто смикає потрібні JS-методи або змінює потрібні JS-властивості. Все всередині стандартного вебівського DOM, який просто додаються нові елементи, пов'язані з нативною реалізацією.

При створенні додатків на React Native розробнику практично завжди буде необхідно реалізовувати нативну частину на Objective-C, Java або C#, а управління нативним додатком буде йти з JavaScript. За фактом JavaScript-движок – це елемент WebView, який доступний окремо. Взаємодія йде через такий же JS-міст, як і у випадку з PhoneGap. Однак у React Native JS-код керує не веб-деревом DOM, а нативним додатком.

Необхідно враховувати, що через обмеження iOS (немає можливості реалізувати JIT) код JavaScript на льоту інтерпретується, а не компілюється. Загалом це особливо позначається на продуктивності у реальних додатках, але пам'ятати це варто.

Тепер розглянемо класичний Xamarin.iOS та Xamarin.Android, тому що Xamarin.Forms (підтримує Windows UWP) – це надбудова над ними.

Xamarin використовує бібліотеку Mono для взаємодії з цільовою операційною системою, яка дозволяє викликати нативний код за допомогою механізму P/Invoke. Він також задіяний і для спілкування з нативними API в iOS/Android. Тобто всім публічних нативних API-методів створюються обгортки на C#, які, своєю чергою, викликають системні API. Таким чином, з Xamarin-програми можна звертатися до всіх системних API.

І на завершення розглянемо Qt, оскільки про нього виникає багато запитань від досвідчених розробників.

Qt - "річ у собі", в цьому є і плюси, і обмеження. Бібліотеки Qt просто підключаються до системних API C++, які є в усіх операційних системах. Для відтворення інтерфейсу користувача використовуються механізми низького рівня, але свій графічний движок, що підтримує стилізацію «під нативку». При цьому на Android доводиться звертатися до Java API через спеціальний міст (JNI bridge), а для Windows UWP використовувати конвертер викликів Open GL ES у DirectX, оскільки Open GL недоступний для UWP.

Підіб'ємо підсумок: всі крос-платформні фреймворки використовують стандартні нативні можливості операційних систем, є зрілими, створюються досвідченими командами та спільнотою open source за підтримки гігантів IT-індустрії. І нарешті, настав час для найсильнішого аргументу.

Міф 4. Повільно

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

Нагадаємо, що особливість крос-платформних додатків полягає в паралельному існуванні двох світів, пов'язаних мостом:

PhoneGap: HTML/JS та Native Java/Objective-C/C#;
React Native: JS і Native Java/Objective-C/C#;
Xamarin: Mono та Native Java/Objective-C;
Qt: С++ та Native Java / Objective-C.

Таким чином, при порівнянні продуктивності треба враховувати швидкість роботи:

крос-платформної частини;
нативної частини;
мосту.

Якщо набрати в пошуковій системі, наприклад, react native vs swift performance, то можна подивитися безліч різних тестів, і в багатьох з них зазначається, що продуктивність різко падає при активному використанні моста, включаючи активне маніпулювання UI з крос-платформного коду. Для Xamarin ситуація виглядає так само - крос-платформна частина дуже швидка і порівнянна з нативною в обробці даних, проте при використанні моста може падати продуктивність. Qt взагалі працює лише на рівні С++, який швидкий сам собою. Якщо ж розглядати рішення на базі PhoneGap, то тут продуктивність сильно залежатиме від WebView, але все ж таки не слід активно змінювати UI в JavaScript-коді або проводити наукові обчислення.

Повільно? Так, можливі падіння продуктивності при невмілому взаємодії з операційною системою через міст. Проте власними силами крос-платформні світи такі ж швидкі, як і нативні.

Мобільні програми стали незмінним супутником нашого життя. З їхньою допомогою ми можемо не тільки розважатися та спрощувати своє життя, здійснювати покупки або замовляти ті чи інші послуги онлайн, але й просувати свій бізнес, збільшувати клієнтську базу, а отже, і множити прибуток. І якщо в необхідності створення програми для своєї справи сумнівів ні в кого виникнути не може, то з вибором типу mobile-app можуть з'явитися деякі складнощі.

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

Нативними є програми, розроблені безпосередньо під певну платформу відповідною мовою програмування. Так, під час створення програми під Android використовується Java, а IOS-додатків – Objective-c чи Swift. Під час створення таких проектів фахівці враховують усі особливості платформ, особливу увагу приділяючи UI/UX дизайну, вимогам/рекомендаціям розробників операційних систем, а також останнім тенденціям у mobile-індустрії. Один фахівець не зможе повною мірою володіти всіма зазначеними вище мовами, тому для розробки одного нативного продукту під різні платформи необхідно підключати різних розробників, а це додаткові витрати, та й час розробки буде значним. Але при цьому програми будуть «заточені» під певну платформу, отримають доступ до внутрішніх ресурсів та функцій пристрою та працюватимуть максимально ефективно.

Незважаючи на чималий список переваг нативних розробок, клієнти не завжди хочуть витрачати час та гроші на їх розробку, підключаючи до процесу створення кількох майстрів. Оптимальним варіантом у таких випадках є кроссплатформенна розробка, що дозволяє створювати програми під будь-які платформи з використанням стандартних web-технологій. При цьому розробкою може займатися одна людина, яка має необхідні знання та досвід роботи з HTML5, JavaScript і CSS3. Кросплатформові розробки можуть бути скомпільовані у файл.apk для Android та i.pa для IOS. Таким чином, на основі однієї розробки можна отримати дві програми під популярні операційні системи, витративши на це менше часу та грошей. Однак подібні розробки мають свої недоліки, тому до кожного конкретного випадку вкрай бажано підходити індивідуально і вибирати найбільш підходящий варіант - нативна або кросплатформова розробка.

Клієнтська та серверна частини програми

Більшість серйозних додатків має свою клієнтську частину, яку часто називають frontend, і серверну – backend. Фронтенд відповідає за те, що ви побачите на екрані свого мобільного пристрою, тобто все візуальне подання програми, включаючи дизайн, розміри та розташування вікон, меню, кнопок, стрілок та будь-яких інших елементів. Також фронтенд відповідає за реакцію програми на ті чи інші дії користувача, спрямовані на перехід у різні розділи АППА, виклик нових меню тощо.

Бекенд є серверною частиною програми і розташований на віддаленому сервері, який може знаходитися будь-де і управлятися за допомогою найрізноманітніших програмних засобів. Взаємозв'язок між клієнтською та серверною частиною здійснюється завдяки API (інтерфейсу для програмування додатків). Іншими словами, API – якийсь посередник між frontend та backend, який передає запити від клієнтської частини до сервера, повертаючи необхідні користувачеві дані.

Розробка фронтенду

Клієнтська частина програми вкрай важлива, оскільки саме з нею матиме справу сам користувач і від зручності frontend залежатиме його загальне уявлення про роботу АППА. Її можна розробляти як вручну, але для цього необхідно добре розумітися на HTML5, CSS3 і java-script, так і за допомогою так званих фреймворків. У першому випадку часто використовується середовище розробки Apache Cordova, яке також широко відоме під назвою PhoneGap. Використовуючи це середовище, можна створювати програми для будь-яких платформ застосовуючи web-технології, які Cordova перетворює на зрозумілий для конкретної платформи код. Cordova відкриває фактично необмежені можливості для web-розробників, яким зовсім не обов'язково вивчати Objective-C чи Swift, Java чи Kotlin для створення програм під певні операційні системи.

У той час, як Cordova не має обмежень у UI та логіці, фреймворки пропонують готові шаблонні рішення. З одного боку, це суттєво прискорює та спрощує процес розробки, оскільки фахівець може використовувати вже готові кнопки, списки, поля введення, картки та інші UI-елементи. З іншого боку, фахівець може використовувати для розробки лише інструменти та елементи, які доступні у вибраному фреймворку. Найпопулярнішим з них вважається Ionic, що дозволяє створювати кросплатформні програми на будь-який смак. У цьому фреймворку є велика вбудована колекція стандартних елементів, які візуально імітують нативні програми, але їх дизайн у разі потреби можна змінити. При цьому розробник може підключати безліч додаткових плагінів, що розширюють можливості ionic framework, причому створений на цьому фреймворку проект можна запускати прямо у вікні браузера і оцінювати, як виглядатиме і працюватиме створювана програма без необхідності використання емулятора або установки на смартфон.

Розробка бекенда

У той час, як клієнтською частиною займаються дизайнери та розробники, які мають знання в HTML, CSS, JS та фреймворках, бекендом займаються програмісти іншого профілю. Для налаштування серверів можуть використовуватися різні мови програмування та інструменти, головне належним чином налаштувати їх роботу та взаємозв'язок з клієнтською частиною. Тут потрібно використовувати відповідні системи управління БД (базами даних). Це може бути традиційний MySQL, Redis, PostgreSQL або будь-яка інша БД (наприклад, MongoDB), яка підходить для реалізації конкретного проекту і в якій розробник бекенд добре розбирається. Для створення серверної частини програми розробники можуть використовувати PHP, NodeJS, C#, Ruby, Python, Java та інші програми.

Фахівці mobile-студії KitApp підходять до питання розробки frontend та backend частин комплексно та максимально відповідально. Наші розробники створять для вас кросплатформовий додаток будь-якої складності та спрямованості максимально швидко та якісно! Зв'яжіться з нами, і наші фахівці оперативно проконсультують вас з усіх питань!