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

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

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

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

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

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

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

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

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

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

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

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

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

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

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