Перед тем, как приступить к созданию мобильного приложения, стоит задуматься о выборе технического подхода к процессу: нативной или кроссплатформенной будет разработка?
В качестве короткого ликбеза поясняем: под нативной разработкой специалисты подразумевают использование оригинальных языков программирования и инструментов мобильной ОС. При кроссплатформенной разработке на вооружение берутся специализированные инструменты, при помощи которых можно создавать приложения, работающие в нескольких мобильных операционных системах сразу.
Оба подхода требуют определённых наборов инструментов, максимально подходящих для написания кода, проектирования интерфейса, отладки, мониторинга всех процессов и сборки окончательной версии приложения.
И оба этих подхода имеют свои преимущества и недостатки как для пользователей, так и для разработчиков. Разобраться начинающим программистам во всех плюсах/минусах нативной и кроссплатформенной разработки помогают специалисты НandsApp.
Михаил Овчинников, (Технический директор студии мобильной разработки Hands App)
Замечательный английский программист Джоел Спольски в своём мега-популярном блоге «Джоэл о программном обеспечении» (Joel on Software) как-то вывел «закон дырявых абстракций». Его суть заключается в следующем: теоретически абстракции должны изолировать нас от более низкого уровня, но в некоторых случаях они всё же настолько сложны, что нужно вникать в особенности реализации и на низком уровне.
Этот принцип относится и к кроссплатформенным фреймворкам. Обычно они абстрагируют разработчиков от особенностей написания кода под отдельную платформу. Однако, как только вопрос касается производительности или реализации специфического функционала под платформу, так сэкономленное при разработке время съедается на решении этих проблем.
Разумеется, есть области, где применение кроссплатформенных технологий полностью оправдано. Прежде всего разработка игр: к примеру, движок Unity — это хороший вариант для большинства разработчиков. Многие маркетологи, имея лишь базовые знания HTML/CSS/JS, успешно используют Ionic для тестирования своих гипотез без привлечения отдела разработки. Многие стартапы выбирают Flutter для того, чтобы быстро сделать минимально жизнеспособную версию продукта (MVP), доказав тем самым на практике конкурентоспособность своего детища.
Не нужно забывать и о том, что подходы при разработке приложения можно комбинировать. Например, отрабатывать критичные к производительности экраны (лента новостей в социальной сети) на нативных технологиях, а второстепенные (экран профиля, экран настроек) — на кроссплатформенных.
Если смотреть с точки зрения карьерного старта программиста, то делать ставку на кроссплатформенную разработку довольно рискованно: у крупных компаний пока мало вакансий такого рода, и вряд ли эта ситуация сильно изменится в будущем. У крупных компаний уже написаны огромные кодовые базы на нативных технологиях, которые нужно кому-то поддерживать. Поэтому если есть мечта — работать в одном из ИТ-гигантов, — то лучше выбрать ту платформу, которая больше нравится и заняться её углубленным изучением.
Никита Красавин, …(ведущий iOS разработчик студии мобильной разработки Hands App)
Давайте для начала разберёмся в деталях: что такое нативная разработка, что из себя представляет кроссплатформа, и чем они отличаются.
Нативная разработка — это процесс воплощения мобильного приложения с использованием официальных средств, предоставляемых разработчиками системы, для которой пишется приложение. Она направлена на одну конкретную мобильную систему. Например, Apple предоставляет интегрированную среду разработки XCode для нативной разработки приложений под iOS. И нельзя написать с помощью XCode приложение для Android. Всё очень просто: один код — одна система.
Кроссплатформенная разработка — это способ создания приложения с возможностью адаптации под несколько систем. По аналогии: один код — много систем.
Несмотря на то, что кроссплатформенные средства позволяют сильно экономить время, нативная разработка в среде программистов более популярна. По нескольким причинам, давайте рассмотрим основные.
1. У мобильных систем iOS и Android есть существенные различия, которые вызывают сложности при кроссплатформенной разработке. Это касается в первую очередь элементов интерфейса. Именно поэтому написать один универсальный код иногда гораздо сложнее, чем сделать это нативно.
2. Нативные среды максимально оптимизированы для работы со своей системой. Кроссплатформенным инструментам же приходится проксировать вызовы системных методов. В результате падают показатели быстродействия, и поэтому кроссплатформенные приложения чаще крашатся, дольше думают и тормозят.
3. Поддерживать кроссплатформенный код гораздо сложнее, чем нативный. Обновление систем приводит к частому обновлению программных интерфейсов, что требует больше рабочего времени программиста (если сравнивать с работой по обновлению кода нативного приложения).
4. При разработке нативного приложения программист почти всегда находит ответ на интересующий его вопрос по коду от коллег или использет сторонние библиотеки для конкретной задачи. В кроссплатформенном мире комьюнити меньше: часто приходится решать возникшую проблему самостоятельно. Собственно этот пункт относится к сфере популяризации нативной разработки: чем больше сторонников — тем больше комьюнити. А значит и работа над конкретной задачей упрощается.
Таким образом, преимущество скорости кроссплатформенной разработки нивелируется рядом прочих негативных факторов.
Подведём итоги: кроссплатформа удобна при написании простого приложения, в котором мало экранов и много общих элементов для разных платформ. Идеальная задача для кроссплатформы — разработка мобильной игры.
Для приложений с уникальными интерфейсами и сложной бизнес-логикой больше подходит нативный способ разработки.
Программистам-новичкам однозначно лучше начинать с нативной разработки хотя бы потому, что большое комьюнити всегда поможет сориентироваться в возникшей проблеме и даст наводку на ту информацию, которая поможет в каждом конкретном случае.
_________________________
Лялин Виталий
Руководитель направления маркетинга в студии мобильной разработки Hands App
Судя по «обильным» комментариям ваш материал явно не для VC :)
Но, вам «повезло», что вы «нарвались» на коллегу по цеху, который может предположить, что у вас еще мало опыта использования фреймворков в мобильной разработке, чтобы писать такие статьи.
«Многие маркетологи, имея лишь базовые знания HTML/CSS/JS, успешно используют Ionic» -
действительно, Ionic, Cordova, Xamarin и другие фреймворки можно использовать для простых задач (аля WebView), чтобы быстро решить проблему в ущерб производительности.
Но, причем тут: «Многие стартапы выбирают Flutter для того, чтобы быстро сделать минимально жизнеспособную версию продукта (MVP), доказав тем самым на практике конкурентоспособность своего детища.» или «Поддерживать кроссплатформенный код гораздо сложнее, чем нативный.»
Многие стартапы хотят использовать Flutter, но стоимость работы специалистов Flutter/Dart им не по карману, и они вынуждены довольствоваться тем, что могут себе позволить: Ionic, Cordova, Xamarin.
Flutter – это лучшее, что появилось в мобильной разработке за все время ее существования! Ко всему, может случиться так, что это будет единственно подходящий инструмент для разработки приложений под новую Fuchsia (операционная система, разрабатываемая компанией Google, взамен Android).
Конечно, использовать только Flutter не получится. Flutter – это только интерфейсы, многие системные и нестандартные методы остаются в нативе. Чтобы разрабатывать на Flutter нужно знать все: Flutter/Dart + xCode/Swift + Android/Java - именно поэтому специалисты Flutter «дороже» других.
Если у вашей студии есть возможность разработать более-менее серьезное приложение для iOS и Android платформ в нативе, а затем, перевести на Flutter, далее, сравнить скорость работы интерфейсов, то вы сразу поймете, почему Flutter – это действительно «новая эра» в разработке визуальных частей мобильного приложения!
Например, на Android устройствах нативный код работает через Java-машину и поэтому интерфейсы тормозят, а Flutter работает напрямую с операционной системой и ее графическим ускорителем – все интерфейсы просто летают!
П.С. Мой контакт в приложении-мессенджере, которое изначально было разработано в нативе для iOS и Android платформ, а затем полностью переписано на Flutter: https://help-signal.com/@admin – мне есть с чем сравнивать. А у вашей студии есть такой опыт и примеры?
Flutter на всех платформах - это эмуляция нативного интерфейса. Спорный подход. Производительность на iOS едва ли будет выше. На андроиде - не знаю, возможно. Но поведение интерфейсов может отличаться от нативного.
Кстати - React native почему то не упоминается. Зря. Популярный вариант
Для меня это не спорный подход, а пройденный этап. Я с нуля создал приложение в нативе, затем переписал его на Flutter. Ссылка выше. На iOS прирост производительности незначительный, но он есть, а на Android – существенный!
Немного не понимаю причин прироста производительности. Вместо нативных виджетов, за отрисовку которых отвечает операционная система, flutter сам рисует весь интерфейс. Недостаток очевиден: если flutter вовремя на новинки операционки не реагирует - значит нового в приложении не будет. Например, ночная тема. Например, системный размер шрифта.
Думаю «прирост производительности» в вашем понимании - это изменение таймингов анимации при эмуляции. Как вы его измеряли? Fps при работе смотрели на разных устройствах?
Я много уже много раз написал, как я это сделал! Я не поленился 3 раза написать с нуля мобильное приложение в 3-х вариантах: 2 натива (iOS и Android) + Flutter. Ссылка на Flutter-приложение выше. Тестировал на 50+ моделях Android. Flutter работает с графическим ускорителем, а если его отключить, то получаем стандартно-тормознутую версию натива под Android! С iOS устройствами прироста производительности почти нет, есть только «сложности» у модераторов Apple – у них нет доступа к вашему исходному коду. Понимаете?
—-
«Например, ночная тема. Например, системный размер шрифта.» - все это есть, можете проверить :) ссылка выше :)