В последнее время многие разработчики приложений склонны соглашаться с тем, что Xamarin может считаться нативным инструментом разработки. В самом деле, существует мнение, что «все, что можно сделать в приложении iOS с использованием Objective-C или Swift, и все, что можно сделать в приложении Android с помощью Java, можно сделать и на языке C# при помощи Xamarin».
Тем не менее существует много подводных камней в соперничестве нативной платформы и платформы Xamarin. Итак, давайте сравним Xamarin с нативными инструментами разработки и разработкой гибридных платформ (Ionic, PhoneGap/Cordova).
Стек технологий: один стек, одна кодовая база (C#, .Net framework + нативные библиотеки)
Совместное использование кода: да, до 96% с использованием Xamarin.Forms
UI/UX (User Interface/User Expierence): возможна полная настройка UI для каждой платформы
Производительность: хорошая, близкая к родной
Возможности аппаратных средств: высокие. Xamrin использует платформо-зависимые API и поддерживает связь с нативными библиотеками
TTM (время выхода на рынок): c Xamarin.Forms TTM происходит быстро из-за ограниченной настройки и расширенного обмена кодами.
Стек технологий: разные стеки для каждой платформы
Совместное использование кода: нет, разные кодовые базы
UI/UX (User Interface/User Expierence): только платформо-зависимые UI
Производительность: отличная
Возможности аппаратных средств: высокие. Нативные инструменты имеют полную поддержку для возможностей системы OOTB
TTM (время выхода на рынок): Xamarin,iOS и Xamarin.Android требуют больше времени по мере того, как увеличивается количество пользовательского кода.
Стек технологий: один стек, одна кодовая база (JavaScript, HTML5, CCS)
Совместное использование кода: да, 100%
UI/UX (User Interface/User Expierence): общий UI для всех платформ (ограниченные возможности настройки)
Производительность: средняя — низкая
Возможности аппаратных средств: средние. Возможности могут быть доступны через сторонние API и плагины, хотя есть некоторые риски из-за низкого качества и ненадежности большинства из этих инструментов
TTM (время выхода на рынок): TTM для нативных приложений Android или iOS может быть таким же, что и для Xamarin.Forms или гибридных инструментов. Тем не менее создание приложений для множества платформ может потребовать от вас либо продлить время выхода на рынок, либо увеличить количество заинтересованных разработчиков
Благодаря единой кодовой базе и минимальной настройке, гибридные решения быстрей выходят на рынок. Эти инструменты используются даже для макетирования концептуальных проектов
Гибридные инструменты мобильной разработки развиваются довольно быстро, но им по-прежнему не хватает производительности и собственных возможностей, которые предлагает Xamarin. При этом затраты остаются сопоставимыми. Если рассматривать два подхода (гибридный и Xamarin), то самая популярная дилемма — это Xamarin против Ionic и Xamarin против React. Однако React Native теряет популярность из-за ряда ограничений в базовых технологиях (стек веб-технологий).
Тем не менее существует мобильный инструмент разработки на базе JavaScript, который превосходит гибридные решения, по крайней мере, с точки зрения UI. Речь идет о NativeScript. Этот кроссплатформенный фреймворк с открытым исходным кодом при поддержке Telerik и при помощи единой базы кода позволяет вам реализовывать нативный UI и подключаться к родным API для лучшего использования мобильных устройств. Его главное отличие заключается в том, что он использует разметку XML, которая компилируется не в веб-браузере HTML, а в нативных эквивалентах Android и iOS.
Этот подход заполняет пробелы между нативными и гибридными разработками, и его методы похожи на то, что делает Xamarin. Основное различие между этими двумя инструментами заключается в языке программирования. Поэтому сравнение Xamarin и NativeScript, должно стать предметом более подробных исследований.
В то же время обсуждения преимуществ и недостатков Xamarin и нативных разработок Android/iOS кажутся более сложными: оба варианта доказывают, что они ценны с точки зрения качества и производительности. Поэтому выбор обычно зависит от типа приложения, которое вы хотите создать.
При сравнении всех за и против нетрудно прийти к выводу, что перечисленные недостатки могут нанести ущерб разработке. Большинство владельцев бизнеса выбирают платформу Xamarin, так как это сокращает время выхода на рынок (Time-To-Market) и инженерных затрат за счет совместного использования кода и использования единого стека технологий.
Основываясь на опыте нашей команды, можно заключить, что лучшим вариантом использования Xamarin является разработка мобильных приложений для бизнеса. Со стандартным интерфейсом, который охватывает 90% проектов, логическое ядро продукта можно легко сделать общим на всех платформах.
Источник: www.altexsoft.com/blog/mobile/the-good-and-the-bad-of-xamarin-mobile-development
Тем не менее существует много подводных камней в соперничестве нативной платформы и платформы Xamarin. Итак, давайте сравним Xamarin с нативными инструментами разработки и разработкой гибридных платформ (Ionic, PhoneGap/Cordova).
Xamarin
Стек технологий: один стек, одна кодовая база (C#, .Net framework + нативные библиотеки)
Совместное использование кода: да, до 96% с использованием Xamarin.Forms
UI/UX (User Interface/User Expierence): возможна полная настройка UI для каждой платформы
Производительность: хорошая, близкая к родной
Возможности аппаратных средств: высокие. Xamrin использует платформо-зависимые API и поддерживает связь с нативными библиотеками
TTM (время выхода на рынок): c Xamarin.Forms TTM происходит быстро из-за ограниченной настройки и расширенного обмена кодами.
Нативный
Стек технологий: разные стеки для каждой платформы
Совместное использование кода: нет, разные кодовые базы
UI/UX (User Interface/User Expierence): только платформо-зависимые UI
Производительность: отличная
Возможности аппаратных средств: высокие. Нативные инструменты имеют полную поддержку для возможностей системы OOTB
TTM (время выхода на рынок): Xamarin,iOS и Xamarin.Android требуют больше времени по мере того, как увеличивается количество пользовательского кода.
Гибридный
Стек технологий: один стек, одна кодовая база (JavaScript, HTML5, CCS)
Совместное использование кода: да, 100%
UI/UX (User Interface/User Expierence): общий UI для всех платформ (ограниченные возможности настройки)
Производительность: средняя — низкая
Возможности аппаратных средств: средние. Возможности могут быть доступны через сторонние API и плагины, хотя есть некоторые риски из-за низкого качества и ненадежности большинства из этих инструментов
TTM (время выхода на рынок): TTM для нативных приложений Android или iOS может быть таким же, что и для Xamarin.Forms или гибридных инструментов. Тем не менее создание приложений для множества платформ может потребовать от вас либо продлить время выхода на рынок, либо увеличить количество заинтересованных разработчиков
Благодаря единой кодовой базе и минимальной настройке, гибридные решения быстрей выходят на рынок. Эти инструменты используются даже для макетирования концептуальных проектов
Есть ли альтернатива Xamarin сегодня?
Гибридные инструменты мобильной разработки развиваются довольно быстро, но им по-прежнему не хватает производительности и собственных возможностей, которые предлагает Xamarin. При этом затраты остаются сопоставимыми. Если рассматривать два подхода (гибридный и Xamarin), то самая популярная дилемма — это Xamarin против Ionic и Xamarin против React. Однако React Native теряет популярность из-за ряда ограничений в базовых технологиях (стек веб-технологий).
Тем не менее существует мобильный инструмент разработки на базе JavaScript, который превосходит гибридные решения, по крайней мере, с точки зрения UI. Речь идет о NativeScript. Этот кроссплатформенный фреймворк с открытым исходным кодом при поддержке Telerik и при помощи единой базы кода позволяет вам реализовывать нативный UI и подключаться к родным API для лучшего использования мобильных устройств. Его главное отличие заключается в том, что он использует разметку XML, которая компилируется не в веб-браузере HTML, а в нативных эквивалентах Android и iOS.
Этот подход заполняет пробелы между нативными и гибридными разработками, и его методы похожи на то, что делает Xamarin. Основное различие между этими двумя инструментами заключается в языке программирования. Поэтому сравнение Xamarin и NativeScript, должно стать предметом более подробных исследований.
В то же время обсуждения преимуществ и недостатков Xamarin и нативных разработок Android/iOS кажутся более сложными: оба варианта доказывают, что они ценны с точки зрения качества и производительности. Поэтому выбор обычно зависит от типа приложения, которое вы хотите создать.
Советы по использованию Xamarin
При сравнении всех за и против нетрудно прийти к выводу, что перечисленные недостатки могут нанести ущерб разработке. Большинство владельцев бизнеса выбирают платформу Xamarin, так как это сокращает время выхода на рынок (Time-To-Market) и инженерных затрат за счет совместного использования кода и использования единого стека технологий.
Основываясь на опыте нашей команды, можно заключить, что лучшим вариантом использования Xamarin является разработка мобильных приложений для бизнеса. Со стандартным интерфейсом, который охватывает 90% проектов, логическое ядро продукта можно легко сделать общим на всех платформах.
Источник: www.altexsoft.com/blog/mobile/the-good-and-the-bad-of-xamarin-mobile-development
Комментарии (34)
theaklair
30.11.2017 17:35Тем не менее существует мобильный инструмент разработки на базе JavaScript, который превосходит гибридные решения, по крайней мере, с точки зрения UI. Речь идет о NativeScript.
То есть React Native с нативным рендерером по-вашему гибридные решения не превосходит? :)
Или вы по какой-то причине относите React Native к гибридным решениям? Если так, то это не правда, ибо RN компилируется в нативные приложения.
andreyverbin
01.12.2017 00:04Все проблемы React Native можно видеть в новом Skype на iOS (на Android наверное тоже). Страдает RN такой же болезнью, что и Appcelerator Titanium когда-то. Весь JS работает в отдельном от UI потоке, что иногда хорошо, а иногда не очень.
RN считает, что DOM (иерархию view) никто кроме него не изменяет, потому что diff иначе сгенерировать невозможно. Но большая часть контролов об этом не знает и сами генерируют свои внутренности по своим алгоритмам. Например, UITableView вставляет/удаляет в иерархию view ячейки по мере скролинга, обрабатывает всякие свайпы изменяя ячейки и т.п. Решить эти проблемы можно только делая нативные контролы, которые заточены под React. По сути рождается слой костылей для адаптации нативных контролов под ожидания React.
Возможно RN когда-нибудь допилят, но пока я за Xamarin, так как он ближе к платформе.
akadone
А почему нет сравнения с основным конкурентом — Rad Studio? И старичком QT? Перечисленные в статье — не конкуренты, а параллельные технологии. А интересно сравнение с конкурентами.
И кстати как сейчас код C# трансформируется в например apk? Своя виртуальная машина, натив или?
F0iL
Своя VM, вместе с APK идет Mono Runtime и нужные BCL-либы:
developer.xamarin.com/guides/android/advanced_topics/application_package_sizes
developer.xamarin.com/guides/android/under_the_hood/architecture
uploadfor
RAD Studio с FMX-мутацией в геноме — это местами работает, и даже иногда можно получить что-то более-менее (если это «что-то» не сложнее простого списка, с которым, увы, даже после всех обновлений происходят глюки, что несколько смущает) работающее, а по факту в большинстве случаев самому смотреть на это и стыдно, и страшно. Про то, чтобы кому-то это показывать (и уж тем более давать/продавать) и речи нет, разве что исключительно ради глумления. Если, конечно, у программиста есть совесть, честь и чувства вкуса и собственного достоинства. Мнение вообще не в пику Delphi, просто из личного опыта.
И при этом всём, заметьте, ни слова про адскую ценовую политику…
akadone
Ручки бы кому-то поправить. У других всё работает. И работает без проблем. В т.ч. и сервисы.
F0iL
Последняя Starter-версия не смогла после установки собрать пустой проект с пустой формой — сборка валилась с какой-то невнятной ошибкой.
Да и вообще в Сети встречается очень много жалоб на нестабильность и глюки FMX-компонентов, так что, видимо, это не проблем рук комментатора выше.
akadone
Стартером не пользуюсь. Ничего сказать не могу. Архитекты начиная с XE2 работают нормально. Точнее косячки в IDE есть, но по сравнению с той-же андроид студио считай всё идеально.
Что же до не стабильности и глюков в FMX — это всё было до примерно XE6. Пользоваться в те времена ими было не просто. XE 8,10.x — вполне себе нормально работают.
P.S. Напомнить, что 2017 студия от MS вообще не ставится в половине случаев? И ничего, все воспринимают это как должное. А тут что-то криво встало, не разобравшись что начинаете хаить продукт. Как-то не серьёзно.
ad1Dima
F0iL
Аналогично, не сталкивался с подобными проблемами и ни от кого не слышал (хотя пользователей VS среди знакомых очень немало)
akadone
Начнём с того, что без триллиона обновлений её тупо нельзя поставить на 7. И без 2/3 из них на 8.1. ну и конечно х86/64 путаница в самом дистрибе. Даже на хабре писали. Так что в след за радом не плохо было бы её слить не умехам, которые не способны даже ПО поставить с помощью инсталлятора.
ad1Dima
1) по вашей ссылке 2015 студия
2) неумехам, которые винду не обновляют я бы тоже чего-нить пообломал.
akadone
В верхнем сообщении у меня опечатка. 2015 конечно. Хотя 17 не сильно лучше.
А винду ни кто не обновляет по своей воле. На безопасности это ни как не сказывается, а проблем из-за обновлений куча. Чего стоит только насильное обновление до 10, от которого не возможно отказаться, с последующей не работой важного оборудования. А так же постоянные BSOD, циклические перезагрузки и прочие ништяки.
F0iL
Ничего личного, но с такими заявлениями я бы вам дал ачивку «шутник года».
akadone
Ага. Сегодня новая плюха от последних обновлений iOS, вот если бы я был фанатиком яблок, фанатиком обновлений то как миниум денег на этом потерял. И вот зачем мне это?
uploadfor
А где можно посмотреть на этих «других», у которых «всё работает», если не секрет? А то я кого ни вижу на fire-monkey.ru и stackoverflow.com — все они постоянно на что-то жалуются, и и при этом никто ничем не хвастается. Либо стесняются, либо боятся, видимо. А если что-то и показывают, что сделали сами — так на это даже просто смотреть порой стыдно, не то что этим пользоваться :-/
akadone
Как бы примерчик бы не помешал. А то слишком голословно. Интересно посмотреть на реальные проблемы с FMX на версиях старше 8 студии.
uploadfor
Ссылки на места, где публично и вслух обсуждают настоящие проблемы и «примерчики» RAD Studio я дал выше — там материала на месяцы чтения, и без всякого «голословия».
А вот от вас, я так понимаю, ссылок на Google Play в подтверждение ваших же слов «У других всё работает. И работает без проблем» можно уже не ждать, да? Хотя, конечно, это был риторический вопрос: те, кто рьяно защищает RAD Studio, при вопросе о живых примерах, как показывает опыт (+ наш текущий диалог), обычно обходятся без ссылок на готовые продукты, и при повторном уточнении/напоминании про магазины мобильных приложений куда-то теряются :(
akadone
Иди смотри в гугле, мне лень. Классный ответ! На вышеперечисленных сайтах решаются рабочие моменты. И судя по количеству ответов решаются успешно.
Моих разработок в гугл плее нет, и пока не будет. У меня свой сервак обновлений. За остальными проектами я не слежу.
Ещё раз повторюсь: аналогов RAD Studio в текущий момент просто нет. Xamarin и Qt — это даже не смешно. У меня в текущем проекте на единой кодовой базе крутится сервер, и куча клиентов под win/android, работающие с периодически отваливающимся интернетом (курьеры например). Ни на чём больше это реализовать не возможно. На этом можно поставить точку.
Xamarin сейчас у майкрософта. Судя по тому, что они уничтожают всё, к чему прикасаются (скайп, нокия, манкрафт и т.д.) нужно 10 раз подумать, прежде чем связываться с этим.
uploadfor
Вот и поговорили. Впрочем, всё как всегда :)
F0iL
Это на религиозный фанатизм похоже, вот да. Причем, как ни странно, на хабре чаще всего этим страдают именно embarcadero-фанбои (наделать много восхваляющих заявлений без каких-либо пруфов и игнорируя контраргументы).
akadone
Итак примеров неработоспособности не будет.
Мне только одно не понятно. Вот эта Ваша религиозная упёртость из-за того, что студия дорогая, или язык сложный?
F0iL
Подозреваю, что у комментатора выше не религиозная упертость, а здравый смысл и реальный опыт. Вы, кстати, тоже не предоставили ни одного хоть какого-то пруфа что «у всех все без проблем работает».
Язык я бы сложным не назвал, но на том же stackoverflow, что интересно, Delphi по результатам опросов стабильно в тройке самых нелюбимых языков программирования у разработчиков.
akadone
А я и не собираюсь ничего доказывать. Меня эта среда разработки в целом устраивает. Далеко не полностью, но ещё раз повторюсь, что аналогов в моей ситуации нет. А прозвучало заявление, что delphi — гэ. Я попросил обосновать это заявление. Но в результате много пены у рта и ничего адекватного.
Зато там самый любимый это java/c# и прочая хрень, которая у конечных пользователей вызывает только отторжение. Ну не все готовы себе покупать i7 32Гб RAM и ssd на 320Gb. Особенно когда аналогичным приложениям написанным на нормальных языках хватает HDD и 1Gb RAM.
Так что тут палка о двух концах. У моего нынешнего заказчика в требованиях для отображения в его нынешней ERP системе данных из sql базы значится i3, и то это при высокой нагрузке безбожно тормозит. Причём отчасти нехватает сервера, отчасти этого i3(!). Просто для отображается нескольких табличек в хроме не хватает i3 на правильной мамке(!). Зато зуб даю — «программисты» написавшие эту систему были самые что ни на есть тру. Но как можно умудриться за 5 лет не смочь обеспечить во время пиковых нагрузок достаточную латентность обновления 5-6 таблиц и отображения этого на других филиалах — я ума не дам… Возможно всё дело в любимых языках программирования, а не в тех, что дадут нормальное юзабилити это потом. Ну то есть архитектуре…
Ну и в результате надо писать не на том, что проще, а на том, что работает. Не у всех денег ка у фейсбука на кучу распределённых серверов.
Ладно. За сим умолкаю. Я лишь хотел сравнения поделки от мелко-мягких с конкурентами, а не эту белиберду, что в статье. Этого не будет. А пустое в порожнее переливать не люблю.
ad1Dima
Rad Studio и Qt тоже параллельные, там свои рендеры UI.
akadone
Нет. Тут речь идёт о единой кодовой базе под все платформы которая может собираться в exe/apk/… работая как нативное приложение, но с полным доступом к api каждой платформы. Сейчас тут «царь горы» здесь многими ненавистный Rad Studio. У Qt куча заморочек с интерфейсом, у Xamarin — глюков. Больше аналоги мне не известны. Соответственно и сравнивать надо их между собой, а не с реактом, который банальный яваскрипт и винду не умеет.
ad1Dima
Положим не банальный, а тоже нативный рендер использует. ну и github.com/Microsoft/react-native-windows
Вы ещё 1С вспомните, там тоже можно кросс-платформенные мобилки делать. Думаю, среди разработчиков 1С, тоже популярный вариант.
akadone
В мире IT? Когда нужно сделать что-то кросс-платформенное, то сразу вспоминаются 2 варианта обеспечения UI: html или rad studio. Ну если мы говорим про большие, серьёзные проекты. Не зря embarcadero такие ценники на свои продукты выставляет. И люди покупают, так как аналогов нет. Вот мне и интересно появляется ли аналог, в лице Xamarin, или MS уничтожило очередной замечательный проект? Потому что по весне этого года что-то рабочее собрать под андроид было… ну скажем так — тяжело.
Это такой троллинг, или вы серьёзно это рассматриваете как что-то типа плюса данной технологии?
1C ничего не умеет по сути.
ad1Dima
Да, когда интерфейс приложения состоит из нативных контролов платформы это безусловный плюс.
а это троллинг или что?
F0iL
Подозреваю, что основные клиенты — это все-таки компании, имеющие большую легаси-кодовую базу в проектах на Delphi/C++ Builder, и теперь переводящие свои разработки на новые рельсы и другие платформы. Поэтому и покупают, потому что переписывать все с нуля выйдет дороже.
Невольно хочется процитировать ваш же комментарий выше про прямоту рук. У меня лично после того как RAD Studio Berlin зафейлил все еще на старте (см. выше), на разработку прототипа андроидового приложения с Xamarin с нуля и без начального опыта ушла пара вечеров — к самой технологии нареканий нет никаких, к IDE были нарекания, но проблемы решались простым гуглежом на Stackoverflow.
Diaskhan
Слушайте а может быть Вам и освятить RAD Studio и опыт разработки под мобилку и ваши проекты ???
Было бы Интересно, и никаких опять глупых холиваров !
ad1Dima
Мне? ОсвЯтить?
F0iL
Кстати да. Было бы чудесно увидеть статью про какой-нибудь реальный проект на этой технологии, с разбором юзкейсов, достоинств и недостатков.