Сравнение подходов к разработке мобильных приложений

Почти всегда, при разработке приложения, перед заказчиком стоит вопрос выбора стека технологий. Разные компании расхваливают свои подходы, и выявить что подходит для того или иного типа проекта достаточно сложно. У нас накопился достаточный опыт в нативе, классическом webview и Ionic.Framework. Рассказываю плюсы и минусы каждого из подходов.

Генеральный директор Bright Mobile сравнивает разные стеки технологий при мобильной разработке.

Пара строк для понимания опыта в разработке:

  • Натив. У нашего ведущего программиста, в своё время была студия нативной разработки "Лаборатория Малаховского" в числе прочих, делали приложения для АвтоВаза и Банки.ру
  • Webview. Последние два года мы делали приложения на этой технологии, в т.ч. сделали готовое решение для маркетплейсов услуг "Сервис ПИ" и 12 клиентов выстроили продажи на этой системе.
  • Ionic. В конце прошлого года перешли на Ionic, запустив несколько ядер для проектов с идеей заказа услуг, доски объявлений, заказа товаров и мессенджера. На данный момент добились спроса в 3-4 обращения в день.

Принципиальные отличия подходов

Я как-то давно, в первых своих видео рассказывал о сравнении нативной разработки и гибридной. Ключевая разница в том, что в нативе грузится только динамический контент, а вёрстка экранов лежит на стороне клиента. В случае с webview-приложениями, экран - это некий контейнер, в нем ничего нет, а верстка генерируется и целиком грузится с сервера.

Обычно нативщики ругаются, что webview-приложение - это тормозное приложение, за счёт того, что нужно ждать пока сервер сгененрирует экран, а так же по сети грузится бОльший объём данных. Но, если это бизнес-приложение, где нет тяжёлых данных, мало картинок, то это терпимо, разница в загрузке 8Кб и 50Кб с учётом сегодняшнего распространения скоростного интернета для конечного пользователя незаметна. Само собой, что если речь о некой игре, или функционале, требовательным с точки зрения ресурсов телефона, то webview не применим.

Тем не менее, даже в бизнес-приложениях, бывают тяжёлые экраны, к примеру, ленты товаров в магазинах с актуализацией цены в момент загрузки, и классический webview загружает экран в 1-3 секунды. Для конечного пользователя не сильно принципиально, но владельцы приложений из-за этого нервничают.

В конце прошлого года мы переехали с webview на разработку на Ionic. Это точно такая же нативная разработка, но с плюшками в виде разработки одновременно под обе ОС. Т.е. идея экономии бюджета клиента на том, что разрабатывается сразу и Android и iOS осталась. При этом решился вопрос прогрузки экранов во время использования приложения. В случае Ionic, вся верстка уже лежит в приложении и рендерится при первой загрузке, а дальше, как в случае натива, подставляются просто маленькие данные, которые распределяются по той или иной вёрстке.

Сравнение натива и Ionic "на живую"

Какие выводы? Первый момент - это более долгая загрузка на старте за счёт загрузки вспомогательных модулей и рендера экрана, т.е. нативное приложение с нуля загружается из памяти в течение двух секунд, Ionic за 4 секунды, по сути, потеря в два раза.

Скорость запуска приложения на Ionic и в нативе

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

На примере ниже, за счёт оптимизации кода, у нас даже удалось сделать, чтобы Ionic, на доли секунды, прогрузил данные быстрее натива.

Открытие экрана у загруженного нативного приложения и написанного на Ionic

Выводы

Какие из этого всего можно сделать выводы? На чаше весов всегда со стороны натива главное преимущество – это быстрая загрузка при первом запуске, со стороны Ionic - работает, как натив, когда приложение уже запущенно и, соответственно, бюджет в два раза ниже. Здесь важно всегда ощущать, что важнее для вас: первую загрузку сделать за 2 секунды, а не за 4 или сэкономить в два раза бюджет. Соответственно, сроки точно так же снижаются в 2 раза.

Кому стоит обратить внимание на Ionic? Я бы рекомендовал этот подход для стартапов, которые делают MVP, первую, а то и вторую версию, а так же для бизнес-приложений, которым не требуется высокая производительность со стороны телефона.

Кому нужно, однозначно, делать натив? Это игры, приложения, которые ключевую ставку делают на сложную анимацию, а так же брендам, которые готовы заплатить в 2 раза больше из-за имиджевой составляющей.

Вместо заключения

В любом случае, не стоит забывать о том, что не исключён фактор "кривых рук". Можно сделать и нативное приложение, которое еле ворочается, можно и на Ionic сделать тормознее webview. Озаботившись этим вопросом мы написали своё ядро, которое позволяет junior-программисту не делать детских ошибок при разработке и сделать быстрое и качественное приложение на Ionic, но об этом уже в следующей статье.

0
13 комментариев
Написать комментарий...
Pavel Anpleenko

Отличная статья, жду продолжения)

Ответить
Развернуть ветку
Виталий Подольский

И что в ней отличного? Как недокодер ионик нативом называет? Бред глупой кобылы!

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

А если сравнить с React Native, Flutter?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

RN - по сути пишешь как натив, только на чистом JS, с экономией раза в полтора. Но грабли в кастомизации тех или иных стандартных функций. Зачастую, проще бросить и написать на чистом нативе.

Flutter - больше похож на Unity, где, по сути, всё рисуется, отсюда и производительность в 60 кадров в секунду. Однако, это нивилируется языком Dark, специалистов по которому днём с огнём не найдёшь, что отражается на цене.

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

Flutter, Dart - разработка Google, React Native - Facebook. Две огромные компании, огромное количество разработчкиков и документации (Flutter еще набирает оборот). Ionic кажется чем-то уже старым как Cordova, Appcelerator. Моё мнение, могу и ошибаться.

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

Только Dart, Dark - это что-то адское https://esolangs.org/wiki/Dark

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Спасибо, опечатался

Ответить
Развернуть ветку
Kirill Pankin
нивилируется языком Dark

Такая экспертная экспертность, что аж страшно.

Ответить
Развернуть ветку
Игорь Кравченко

Dart простой и удобный язык, в чем с ним проблемы? Любой нормальный программист за пару дней нормально изучит Dart для решения бизнесс задач. Специалистов по Flutter практически нет, но так это новейшая технология!

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Я и не спорю про технологию. Исторически сложилось, что у нас в команде большие знания html+js, поэтому переучить разработчиков на Angular CLA было экономически эффективнее, чем долго и упорно переучивать на Dart.

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

А что такое Angular CLA? Contributor License Agreement? Или вы о SPA (Single Page Application)?

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

удален

Ответить
Развернуть ветку
Виталий Подольский

Ахаха, только что эту дичь здесь обнаружил.  Итак, начнем по порядку:

У нашего ведущего программиста, в своё время была студия нативной разработки "Лаборатория Малаховского" в числе прочих, делали приложения для АвтоВаза и Банки.ру

Окей, гугл! Я гуглить умею... Так называемая студия "Лаборатория Малаховского" делала унылое говно на базе 1С. Где тут натив? 1С? Язык на русском, что вызывает кровотечение из глаз?

Какие из этого всего можно сделать выводы? На чаше весов всегда со стороны натива главное преимущество – это быстрая загрузка при первом запуске, со стороны Ionic - работает, как натив, когда приложение уже запущенно и, соответственно, бюджет в два раза ниже.

А какие тут можно сделать выводы? Рожденный пить, еба... не может! 1С, ионик, вебвью - все это унылое говно, к нативу отношения не имеет. Если не хватает массы мозга для понимания, что такое нативная разработка, то на пальцах могу объяснить, что нативная разработка - использование родного компилятора при сборке приложения, что можно сделать лишь при использовании родных языков. В гугл, это джава и с недавнего времени, котлин.  В айосе, это обжСи и свифт. 

Что дает нативная разработка? Да все, Карл! Это родная платформа, можно еб... ее и в хвост, и в гриву.

Стоимость? Тоже на воде вилами писано... Проект может стоить дешевле за счет экономии человеко-часов. Не приходится костыли изобретать, чтобы заставить функционал работать. Насколько я знаю, ты до сих пор не осилил ApplePay на своем говноионике?! И не осилишь! Вот тебе и ответ. А то он видосики с ютюба по загрузке экранчиков сравнивает. На кого это рассчитано? На совсем тупых и упоротых?

Ответить
Развернуть ветку
Читать все 13 комментариев
null