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

Някои разработчици очакват междуплатформените рамки да решат всичките им житейски проблеми, докато други ги възприемат враждебно. И двата "враждуващи лагера" имат свои собствени погрешни схващания, породени от неразбиране на това как и какво работи. Това налива масло в огъня, тъй като се използват емоции вместо технически аргументи.

Освен това сред разработчиците, особено начинаещите, има много митове относно мобилните рамки на различни платформи. В нашата статия ще анализираме най-популярните от тях. Но първо, нека погледнем мобилното развитие през очите на бизнес, който дава пари за целия ИТ блекджек.

Защо се нуждаем от инструменти за различни платформи?

В исторически план винаги е имало конкуренция на компютърния пазар и всеки производител е предоставил оптималния набор от така наречените собствени (родни) инструменти за разработване на приложения за своите операционни системи и устройства.

Родни инструменти = предоставени от собственика на екосистемата.

Всички останали признаци на "рождество" са ВТОРИЧНИ - поведението и интерфейса на приложенията, достъпът до функциите на ОС, производителността и т.н.

Освен това почти винаги се оказва, че нативните инструменти са несъвместими помежду си не само на ниво езици за разработка, приети конвенции и архитектури, но и на ниво механизми за работа с операционната система и библиотеките. В резултат на това, за да се приложат едни и същи алгоритми и интерфейси, беше необходимо да се напише приложение за няколко среди на различни езици за програмиране и след това да се поддържа на базата на „една команда на платформа“. В същото време възможностите и външният вид на приложенията на различни платформипочти винаги еднакви на 90%. За интерес сравнете изпълнението на любимите си програми за iOS и Android.

Второ важен момент- наличието на необходимите знания и опит в екипа: ако не са, тогава ще отнеме време за учене.

За да решат и двата проблема, на пазара отдавна се появиха инструменти за разработка на различни платформи (не само мобилни), които предлагат:

  • максимизиране на общата кодова база в един език за програмиране, така че продуктът да е по-лесен за разработване и поддръжка;
  • използване на съществуващи компетенции и специалисти за внедряване на приложения на нови платформи.

Тъй като сега има много езици за програмиране (и среди) (и специалисти, които владеят тези езици), има доста инструменти за разработка на различни платформи. Като пример ще се спрем на популярни в нашия район PhoneGap, Xamarin, React Native и Qt.


Сега можем да говорим за митове.

Мит 1. Магия

Най-разпространеният мит, който преследва умовете на амбициозните разработчици, е вярата в супералгоритмите (и суперпрограмистите, които са ги създали), които магически превръщат междуплатформените приложения в собствени. Нещо от рода на „конвертиране на JavaScript код в Swift и след това компилиране на Swift приложение“. Този мит се подхранва от самите разработчици на инструменти за различни платформи, обещавайки създаването на „родни приложения“ като резултат. И не че някой хитрува тук, но богатото въображение и липсата на разбиране на основните механизми понякога карат разработчиците да мислят за шамански трикове.

Основният принцип, залегнал в кросплатформените решения, е разделянето на кода на две части:



За да свържете "родния" свят и "междуплатформения" свят, е необходимо да използвате специален мост, той е този, който определя възможностите и ограниченията на междуплатформените рамки.

Когато използвате мост, производителността винаги се намалява чрез преобразуване на данни между „светове“, както и преобразуване на API извиквания и библиотеки.

Така че всички междуплатформени приложения трябва да имат собствена част, в противен случай операционната система просто няма да може да ги стартира. Така че нека да разгледаме по-отблизо какви системни API и механизми се предоставят от самите iOS, Android и Windows. Да преминем към следващия мит.

Мит 2. Не е роден!

И така, имаме междуплатформена част от приложението, която живее във виртуална среда и взаимодейства с операционната система чрез инфраструктурата на рамката и моста.

Всички операционни системи: iOS, Android и Windows UWP - предоставят достъп до следните подсистеми (набори от системни API):

  • WebView (уеб браузър, вграден в приложението) се използва в базирани на PhoneGap хибридни приложения и действа като де факто местно време за изпълнение на уебсайт;
  • JavaScript двигателите се използват в React Native и неговите колеги за бързо изпълнение на JS код и обмен на данни между Native и JS;
  • OpenGL ES (или DirectX) се използва в игрови двигатели и приложения, базирани на Qt/QML или подобни за изобразяване на интерфейса;
  • Подсистемата на потребителския интерфейс е отговорна за родния потребителски интерфейс на приложението, което е подходящо за React Native и Xamarin.


Приложенията за различни платформи имат собствена част и същия пълен достъп до системните API като "родните" приложения. Разликата е, че извикването на системния метод преминава през инфраструктурата на моста и рамката:

уеб изглед- приложението живее в своя уеб браузър, подобно на уебсайт с една страница. Няма достъп до естествени контроли (бутони, списъци и т.н.), всичко е базирано на HTML/CSS/JavaScript. От друга страна, един уеб разработчик ще се чувства като пате във вода.

JavaScript двигателистана популярен сравнително наскоро, тъй като подобен механизъм беше добавен към iOS само във версия 7.0. От функциите си струва да се вземе предвид необходимостта от сериализиране на сложни структури от данни, прехвърляни между JavaScript и Native среди в JSON. Ако опишем накратко такъв клас решения, тогава в средата на JavaScript се изпълнява JS кодът, който контролира родното приложение.

OpenGL ES и DirectXса подсистеми от ниско ниво и се използват за изчертаване на потребителския интерфейс в игри и, например, Qt/QML. Тоест, когато използват OpenGL / DirectX, разработчиците сами рисуват контроли и анимации, които могат да бъдат подобни само на родните. От друга страна, това е подсистема от ниско ниво с много висока производителност, поради което се използва и в кросплатформени двигатели за игри.

Всички междуплатформени приложения имат естествена част и следователно потенциално същия пълен достъп до системните API като „родните“. Освен това междуплатформените приложения се изграждат и пакетират от „родни“ инструменти в „родни“ инсталационни пакети. Ключовият въпрос е как е организирано взаимодействието между кросплатформената част и нативната част. Например, вътре в WebView или използвайки Open GL ES / DirectX, няма начин да създадете потребителски интерфейс с напълно оригинален вид и усещане, но има пълен достъп до GPS, Push известия и друга функционалност. И кодът на JavaScript или C# може доста свободно да контролира собственото приложение и неговото поведение, осигурявайки напълно оригинален вид и усещане.

За да обобщим - да, "non-native" от гледна точка на използваните инструменти за разработка (не от Apple, Google). Но едно приложение може да бъде напълно естествено по отношение на достъпа до системни API и да осигури напълно оригинален вид и усещане. И преминаваме към следващия мит.

Мит 3. Патерица на патерица

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

Изглежда, че патерицата е как кросплатформената част се интегрира с родната. За да разберем по-добре как работят различните рамки, ще използваме примера на PhoneGap, Xamarin, Qt и React Native, за да разгледаме онези механизми на операционната система, които се използват за свързване на междуплатформените и „родните“ части.

Ще започнем с PhoneGap. По-долу е архитектурата от най-високо ниво на приложение, базирано на тази рамка.



Приложението PhoneGap всъщност е естествено приложение, което показва 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. Това означава, че обвивките в C# се създават за всички публични местни API методи, които от своя страна извикват системни API. По този начин всички системни API могат да бъдат достъпни от Xamarin приложение.

И накрая, нека да разгледаме Qt, тъй като има много въпроси за него от опитни разработчици.



Qt е "нещо само по себе си", това има както плюсове, така и ограничения. Библиотеките на Qt просто се свързват със системните API на C++, намиращи се във всички операционни системи. За изчертаване на потребителския интерфейс се използват механизми от ниско ниво, но собствен графичен двигател, който поддържа естествен стил. В същото време на Android трябва да получите достъп до Java API чрез специален мост (JNI мост), а за Windows UWP използвайте преобразувателя на повиквания Open GL ES към DirectX, тъй като Open GL не е наличен за UWP.

За да обобщим: всички междуплатформени рамки използват стандартните собствени възможности на операционните системи, зрели са, създадени са от опитни екипи и общността с отворен код с подкрепата на гиганти в ИТ индустрията. И накрая, дойде време за най-"силния" аргумент.

Мит 4. Бавно

Важен коз, който хората обичат да използват в спорове за междуплатформени рамки, е ниската производителност. Пак в зависимост от това с какво да сравняваме и в кои папагали да броим.

Спомнете си, че характеристика на кросплатформените приложения е паралелното съществуване на два свята, свързани с мост:

  • PhoneGap: HTML/JS и Native Java / Objective-C / C#;
  • React Native: JS и Native Java / Objective-C / C#;
  • Xamarin: Mono и Native Java / Objective-C;
  • Qt: C++ и Native Java/Objective-C.

По този начин, когато се сравнява производителността, е необходимо да се вземе предвид скоростта на работа:

  • крос-платформена част;
  • родна част;
  • мост.

Ако въведете в търсачка, например, реагирайте нативна срещу бърза производителност, можете да видите много различни тестове и много от тях отбелязват, че производителността спада рязко при активно използване на моста, включително активно манипулиране на потребителския интерфейс от междуплатформен код. За Xamarin ситуацията изглежда същата - крос-платформената част е много бърза и сравнима с естествената при обработка на данни, но при използване на мост производителността може да намалее. Qt обикновено работи на ниво C++, което само по себе си е бързо. Ако разгледаме решения, базирани на PhoneGap, тогава производителността ще зависи силно от WebView, но все пак не трябва активно да променяте потребителския интерфейс в JavaScript кода или да извършвате научни изчисления.

Бавно? Да, възможни са спадове в производителността поради неправилно взаимодействие с операционната система през моста. Самите междуплатформени светове обаче са също толкова бързи, колкото и местните.

Мобилните приложения се превърнаха в незаменим спътник в живота ни. С тяхна помощ можем не само да се забавляваме и да опростим живота си, да правим покупки или да поръчваме определени услуги онлайн, но и да популяризираме бизнеса си, да увеличим клиентската си база и следователно да умножим печалбите. И ако никой не може да се съмнява в необходимостта от създаване на приложение за своя бизнес, тогава с избора на типа мобилно приложение може да възникнат някои трудности.

всичко модерни приложенияза мобилни устройства могат да бъдат разделени на родни и кросплатформени, като всяка от тези две групи има и двете свои собствени силни страникакто и неговите недостатъци.

Родните приложения са приложения, разработени специално за конкретна платформа на съответния език за програмиране. Така че, когато създавате приложение за Android, се използва Java, а за IOS приложения - Objective-c или Swift. При създаването на такива проекти специалистите вземат предвид всички характеристики на платформите, като обръщат специално внимание на UI / UX дизайна, изискванията / препоръките на разработчиците на операционни системи, както и най-новите тенденции в мобилната индустрия. Един специалист няма да може да овладее напълно всички горепосочени езици, следователно, за да разработите един роден продукт за различни платформи, е необходимо да свържете различни разработчици и това е допълнителна цена и времето за разработка ще бъде впечатляващо. Но в същото време приложенията ще бъдат "заточени" за конкретна платформа, ще получат достъп до вътрешните ресурси и функции на устройството и ще работят възможно най-ефективно.

Въпреки значителния списък от предимства на родното развитие, клиентите не винаги искат да отделят време и пари за тяхното развитие, свързвайки няколко майстори в процеса на създаване. Най-добрият вариант в такива случаи е разработката на различни платформи, която ви позволява да създавате приложения за всяка платформа, използвайки стандартни уеб технологии. В този случай разработката може да се извърши от едно лице, което има необходими знанияи опит с HTML5, JavaScript и CSS3. Разработките на различни платформи могат да бъдат компилирани в .apk файл за Android и .ipa файл за IOS. По този начин, на базата на една разработка, можете да получите две приложения за популярни операционни системи, като харчите по-малко време и пари за това. Подобни разработки обаче имат и своите недостатъци, така че е много желателно да се подходи индивидуално към всеки конкретен случай и да се избере най-подходящият вариант - нативна или кросплатформена разработка.

Клиентска и сървърна част на приложението

Повечето сериозни приложения имат своя собствена клиентска страна, която често се нарича frontend, и сървърна страна, backend. Предният интерфейс е отговорен за това, което виждате на екрана на вашето мобилно устройство, тоест за цялото визуално представяне на приложението, включително дизайна, размера и местоположението на прозорци, менюта, бутони, стрелки и всякакви други елементи. Освен това интерфейсът е отговорен за реакцията на приложението към определени потребителски действия, насочени към преминаване към различни раздели на приложението, извикване на нови менюта и т.н.

Бекендът е сървърната част на приложението и се намира на отдалечен сървър, който може да бъде разположен навсякъде и да се контролира с помощта на голямо разнообразие от софтуерни инструменти. Връзката между клиентската и сървърната част се осъществява чрез API (интерфейс за програмиране на приложения). С други думи, API е вид посредник между фронтенда и бекенда, който предава заявки от страна на клиента към сървъра, връщайки данните, необходими на потребителя.

Frontend развитие

Клиентската част на приложението е изключително важна, тъй като самият потребител ще се справи с нея и общата му представа за приложението ще зависи от удобството на интерфейса. Може да се разработи както ръчно, но за това трябва да сте добре запознати с HTML5, CSS3 и java-script, така и с помощта на така наречените рамки. В първия случай често се използва средата за разработка Apache Cordova, която също е известна като PhoneGap. Използвайки тази рамка, можете да създавате приложения за всяка платформа, използвайки уеб технологии, които Cordova преобразува в код, който е разбираем за определена платформа. Cordova отваря практически неограничени възможности за уеб разработчици, които не трябва да учат Objective-C или Swift, Java или Kotlin, за да създават приложения за конкретни операционни системи.

Докато Cordova няма ограничения в потребителския интерфейс и логиката, рамките предлагат готови шаблонни решения. От една страна, това значително ускорява и опростява процеса на разработка, тъй като специалистът може да използва готови бутони, списъци, полета за въвеждане, карти и други UI елементи. От друга страна, специалистът може да използва за разработка само онези инструменти и елементи, които са налични в избраната рамка. Най-популярният от тях е Ionic, който ви позволява да създавате междуплатформени приложения за всеки вкус. Тази рамка има голяма вградена колекция стандартни елементи, които визуално имитират нативни приложения, но дизайнът им може да се променя при необходимост. В същото време разработчикът може да свърже много допълнителни плъгини, които разширяват възможностите на йонната рамка, а проектът, създаден на тази рамка, може да бъде стартиран директно в прозореца на браузъра и да оцени как ще изглежда и работи. създава се приложениебез нужда от емулатор или инсталация на смартфон.

Бекенд разработка

Докато дизайнери и разработчици с познания по HTML, CSS, JS и рамки са ангажирани от страна на клиента, програмисти от различен профил са ангажирани в бекенда. За да конфигурирате сървъри, можете да използвате различни езици и инструменти за програмиране, основното е да конфигурирате правилно тяхната работа и взаимодействие с клиентската част. Тук трябва да използвате подходящи системиуправление на бази данни (бази данни). Това може да бъде традиционен MySQL, Redis, PostgreSQL или всяка друга база данни (например MongoDB), която е подходяща за изпълнението на конкретен проект и в която задният разработчик е добре запознат. Разработчиците могат да използват PHP, NodeJS, C#, Ruby, Python, Java и други езици за програмиране, за да създадат сървърната страна на приложението.

Специалистите на мобилното студио KitApp подхождат към въпроса за разработването на фронтенд и бекенд части по цялостен и максимално отговорен начин. Нашите разработчици ще създадат за вас крос-платформено приложение с всякаква сложност и посока възможно най-бързо и ефективно! Свържете се с нас и нашите специалисти ще Ви консултират своевременно по всички Ваши въпроси!

Междуплатформени приложения – да бъде или да не бъде? Въпросът не е лесен, тъй като всеки бизнес има свои собствени цели и изисквания към мобилните приложения. Но днес определено ще разберем кое развитие е подходящо за вас.

Какво представляват междуплатформените приложения?

Приложенията за различни платформи са приложения, които се разработват и след това работят на 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.

Пътят към успеха е очевиден: играйте на две полета едновременно. По-точно два магазина. Просто изчислете в кое приложение трябва да се появи първо. Разбира се, ако едновременното пускане не е част от вашата цифрова стратегия).

2. Колко време за разработка имате?

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

С нативно приложение определено няма да има такива проблеми, което е много важно за задържане на аудитория, която е изключително нетолерантна към грешки и бъгове. Според статистиката на Compuware 79% от потребителите са готови да рестартират приложението, ако не е работило правилно при първото стартиране, но само 16% са съгласни да му дадат още един шанс. Останалите най-вероятно просто ще деинсталират програмата.

3. Какви функции на устройството планирате да използвате?

Вече говорихме за факта, че само родните приложения са в състояние да възпроизвеждат тежки графики бързо и без загуба на качество. Но това технически предимствародното развитие не е ограничено. Вземете приложението Facebook като пример. Благодарение на пускането на отделни версии за Android и iOS, превъртането стана по-плавно, времето за зареждане на изображения беше намалено и всички проблеми с кеша бяха решени.


Нещо повече, собствените приложения имат директен достъп до всички услуги на устройството, което ви позволява да получите информация за местоположението на потребителя или списъка с контакти. Приложенията за различни платформи трябва да използват специални нативни плъгини, което се отразява негативно на скоростта на пренос на данни и претоварвания RAMустройства.

4. Какви резултати търсите?

Дигиталната стратегия е списък от цели, които вашата компания може да постигне с помощта на цифрови инструменти. Изборът на последния до голяма степен зависи от ползите, които искате да получите в крайна сметка.


Разлагайте процеса от идея до резултат точка по точка, като вземете предвид всички налични ресурси. Откритията могат да бъдат най-неочаквани.

Например, може да откриете, че превеждането на вашия адаптивен сайт с много функции и интерактивни елементи в междуплатформено приложение, както първоначално сте възнамерявали, е твърде скъпа задача. Или най-накрая се уверете, че мобилният сайт винаги губи от мобилно приложение - точно както разработката на различни платформи губи от естественото. И сред причините намерете тези, за които говорихме по-горе.

Заключение: кросплатформеното приложение е полезно само в един случай - създавате демо версия на приложението, ограничени сте по отношение на време, пари и специалисти с тесен профил. Във всички останали случаи нативното приложение ще ви даде в пъти повече предимства, тъй като това е качествено различно ниво на развитие.

Изглежда, че тук имаме кросплатформено развитие, което прави възможно създаването на универсални приложения за различни платформи. Написах приложението по-бързо, веднага го пуснах навсякъде - печалба! И не е необходимо нативно развитие. Или все още е необходимо? Попитахме нашите експерти за нюансите на двата подхода за разработка на мобилни приложения.

„Мобилен разработчик“ е широко понятие. Разработчик, който внедрява части от мобилна операционна система, също е мобилен разработчик. И ако целта е да станете точно такъв разработчик, тогава трябва да започнете като цяло с изучаването на C ++, мобилна операционна система и хардуера на мобилните устройства.

Ако имате предвид разработчик, внедряващ персонализирани мобилни приложения, тогава трябва да започнете с естествена разработка.

Защо така? Естествената разработка ви позволява да изследвате по-добре и по-задълбочено възможностите на конкретни операционни системи (и приложения за тях) и мобилен хардуер.

От гледна точка на потребителя естествената разработка определено печели. Родните приложения работят по-бързо, интерфейсът им е по-отзивчив и познат на потребителите на определена мобилна операционна система, те използват по-добре хардуерните възможности на устройствата, работят по-добре офлайн и са по-малко „бъги“.

Първоначалната идея за разработка на различни платформи е да се намалят разходите за труд на разработчика. Накратко може да се изрази по следния начин: „Направих го веднъж, работи на всичко.“ Идеята е добра и правилна (от гледна точка на разработчика), но има проблеми с качеството. Всяка гъвкавост идва с компромис и мобилната разработка не е изключение.

Когато избира типа разработка за конкретна задача, разработчикът трябва да прецени дали този компромис е приемлив. Има редица задачи, при които използването на кросплатформена разработка би било напълно оправдано, например в тестови проекти, мобилни версии на сайтове, игри, използващи рамки като Unity 3D.

В същото време за проекти, които решават проблеми на мобилния бизнес (с голямо натоварване, необходимостта от поддръжка на офлайн режим, насочен към дългосрочно развитие), родното развитие се разглежда като единственото оптимално (и за някои задачи, единственото възможно ) опция.

В същото време основните недостатъци на родната разработка са времето за разработка (отнема повече) и необходимостта от разнообразни ресурси (разработчици на различни родни езици за програмиране). Има начини за смекчаване на тези недостатъци - например да се използва някаква платформа за мобилни приложения (клас MEAP) за разработка, която ви позволява да създавате собствени приложения.

Надграждане Понижаване

, Директор Технологично развитие на ИТ компания "ID - Мениджмънт Технолоджис"

Всяка междуплатформена библиотека или рамка се основава на едни и същи местни механизми, които директно прилагат естествена разработка. Просто в случай на междуплатформени решения, работните потоци са изградени по такъв начин, че да „изгладят ъглите“ по отношение на привеждането на интерфейса на крайното решение до определен общ знаменател.

По правило универсализмът не винаги е отговорът на задачата за създаване на работещо мобилно решение: разработчикът работи толкова по-добре, колкото по-дълбоко разбира механизмите на устройството различни процесиотвътре, както се казва, "под капака".

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

В този случай е по-лесно да се постигне цялостно разбиране за това как по принцип работи процесът на мобилна разработка, който се нарича от край до край. Това също е полезно, защото всяка, дори и най-напредналата, универсална платформа изостава от естествената в своите възможности: производителите на хардуер и мобилни операционни системи често работят заедно и постоянно увеличават възможностите на крайните решения - възможностите на платформите за мобилна разработка, особено междуплатформените решения , неизбежно изостават .

Нови продукти в мобилния сегмент се появяват на пазара през цялото време, някои от тях са далеч пред времето си - вземете Samsung и неговата разработка на устройство със сгъваем екран: очевидно е, че поради радикално различен преден край , съществуващите платформи за разработка не са готови за такива неща.

Това е мястото, където задълбочените познания за родните платформи ще помогнат: само разработчик със задълбочени, системни познания за мобилно развитие, тоест родните платформи, може да компенсира естественото изоставане спрямо хардуера и операционната система. Само такъв специалист ще може да увеличи функционалността на своето решение за най-новите мобилни устройства, базирани на не съвсем напреднали платформи за разработка, налични в момента.

Разработката между платформи е чудесна за създаване на прототипи, бързо тестване на идея и т.н. Веднага щом стане дума за създаване на наистина фундаментални продукти, разработчикът неизбежно стига до необходимостта от задълбочено изучаване на основните елементи на процеса, тоест нативната разработка.

Надграждане Понижаване

, Декан на факултета по разработка на iOS GeekUniversity, образователен портал GeekBrains

Кратък отговор: ако нямате опит в програмирането, тогава, разбира се, трябва да изберете родна разработка. Разработката на различни платформи е добра за професионалисти, които преминават от свързани области към мобилна разработка. Например, ако сте front-end разработчик с добри познания по JavaScript, използвайки React Native framework (базиран на React framework), можете бързо и безболезнено да се опитате да овладеете мобилното развитие. Подобно на .NET разработчика, ще бъде по-лесно да овладеете рамката Xamarin.

Разработката на различни платформи също е от полза за клиента - по-лесно е да се намери един екип от разработчици, който, следвайки общ модел, ще разработи приложение за две платформи наведнъж.

Предимствата са очевидни, но какви са недостатъците на мултиплатформената разработка?! Смята се, че колкото по-сложна и фина е функционалността в едно мобилно приложение, толкова по-трудно е, ако не и невъзможно, да се приложи с крос-платформени инструменти – това често превъзхожда всички предимства на универсалните инструменти. Според моя опит има няколко големи компании, които с разрастването на тяхното приложение са били принудени да се откажат от крос-платформата в полза на естественото развитие. По този начин за малки проекти и евентуално задачи на свободна практика са достатъчни общи решения, докато за големи проекти родните решения са по-подходящи.

Търсенето и за двете зони е доста голямо, но за родното развитие е малко по-високо: по искане на Swift на hh.ru в Русия - 369 свободни, Kotlin - 397, React Native - 111, Flutter - 13 Xamarin - 18. Но почивка уверен, добър специалист в Няма да има работа във всяка област.

Надграждане Понижаване

Като начало е важно да се отбележи, че всяко мобилно приложение се състои от няколко слоя:

  • UI - това, което потребителят вижда;
  • бизнес логика - за какво е написано приложението;
  • други компоненти на платформата - работа с мрежата, бази данни и други системни компоненти, които се използват от бизнес логиката.

В зависимост от конкретното приложение размерът на компонентите на тези слоеве може да варира значително. Например, приложението за четене на новини на уебсайт ще бъде много различно от VPN клиент.

Самата разработка може да бъде разделена на три вида: нативна, напълно кросплатформена и хибридна.

родно развитие

При собствената разработка и трите слоя са написани с помощта на един и същ набор от инструменти. Следователно те могат да взаимодействат помежду си без допълнителна сложност.

Ползи от местното развитие:

Хибридно развитие

Този тип развитие съчетава и двата предишни подхода. Слоят на бизнес логиката е изграден като "преносим" компонент, а потребителският интерфейс и интеграцията на платформата се създават с помощта на стандартни инструменти. Има няколко езика за писане на обща логика: C/C++ (зрял и мощен), KotlinNative (много активно разработен) и JavaScript (най-малко разпространен).

Предимства:

  • най-подходящите компоненти за това остават родни;
  • общата логика се създава веднъж.

недостатъци:

  • ако общ компонент ще бъде създаден от мобилен екип, тогава е необходимо да се получи експертен опит на друг език;
  • има допълнителни разходи за интегриране на междуплатформени компоненти.

С какъв тип развитие е най-добре да започнете?

За да отговорите на този въпрос, трябва да разберете какви проекти искате да създадете. Малките проекти могат да бъдат чисто междуплатформени и това ще бъде напълно оправдано. Тук бих ви посъветвал да разгледате по-отблизо Flutter.

Но днес бих започнал с родното развитие. Първо, повечето проекти днес се създават нативно. Това означава, че ще имате повече възможности за смяна на проекти/компании. Второ, с течение на времето ще бъде възможно да се премине към хибридно междуплатформено развитие. Това ще ви позволи да растете в техническите въпроси.

Надграждане Понижаване

По мое мнение е най-добре да започнете с натив и след това, ако наистина искате, овладейте един или повече кросплатформени инструменти. Изключение може да бъде разработването на игри, тъй като те са написани главно в Unity и това е крос-платформен двигател.

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

За крайния потребител родната разработка означава, че приложението ще има познати, предвидими интерфейси и модели на поведение - при условие, че приложението е написано според всички ръководства.

Едно кросплатформено приложение не винаги успява да се съобрази напълно с ръководствата на двете платформи и това може да създаде допълнителни затруднения за разработчика и потребителя. Най-простият пример- ситуацията с бутона "Назад": в Android присъства на почти всички екрани, докато в iOS го няма. Ако направите междуплатформено приложение без този бутон, някои потребители на Android може да изпитат дискомфорт.

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

Що се отнася до скоростта на приложенията, кросплатформените продукти са по-бавни. Например, тези, които са базирани на уеб технологии, имат браузър като слой, което значително забавя приложението.

Надграждане Понижаване

Изборът на междуплатформен или естествен подход всъщност зависи от два фактора: естеството на мобилното развитие, което вие лично искате да правите, или искането на работодателите, с които се интересувате да работите. Така например, ако разгледаме Upwork (платформа за намиране на отдалечени специалисти за проекти и задачи), можем да видим явен превес на офертите в посока на Xamarin и React Native. Предимствата тук са очевидни: това е евтино, бързо и ще ви позволи да изпълнявате проекти на всички платформи наведнъж. Въпреки това, ако вземем предвид големи ИТ компании с търсене на служители в къщата, тогава има значителен акцент върху местното развитие, въпреки факта, че този тип изисква повече време и е по-скъп.

В нашата компания ние даваме приоритет и избираме собствената разработка, защото тя позволява на дизайнерите и разработчиците да създават по-плавен, по-интуитивен UX/UI. Освен това естественото развитие дава по-гъвкав контрол върху системните функции.

Надграждане Понижаване

Ако искате да станете мобилен разработчик, тогава отговорът е очевиден: трябва да изберете някоя от естествените среди за разработка и да разчитате на Objective-C/Swift за iOS или Java/Kotlin за Android. В този случай всички функции на системата са на ваше разположение, можете да контролирате почти всеки нюанс.

Ако просто искате да напишете програма, която да работи и на телефони, тогава не можете да мислите много и да изберете към какво е повече душата ви или в какво имате забележителен опит: C ++, React Native, Xamarin или петстотин хиляди JS рамки за разработка на различни платформи. Или дори продължете да правите свои собствени [отзивчиви] уебсайтове.

Честно казано, аз съм доста скептичен относно самата идея за междуплатформено развитие на толкова различни (и различни) платформи като Android и iOS. Никой от продавачите не харесва "грешни" разработчици, които се опитват да седят на два стола едновременно. Всеки се опитва да обвърже програмистите с инструменти и среди и няма тенденция за сближаване в обозримо бъдеще. Какво мога да кажа, Apple в тази надпревара дори изоставиха OpenGL, най-многоплатформената от всички библиотеки след Curl, но сега те имат свой собствен Metal, който изглежда прави същото, само по-добре и на различен език.

От друга страна, много често мобилното развитие е създаването на две приложения, които изглеждат еднакви за някаква мрежова услуга. Клиентите не винаги са готови да платят за два продукта, които изглеждат напълно неразличими, така че търсенето на технологии за разработка на различни платформи съществува и, разбира се, е доста високо. Програмистите също не са склонни да спестят пари, особено ако искат да продадат мобилно приложение, няма желание да научат Swift / Kotlin, но JS / C # вече е на една ръка разстояние.

Разбира се, разработката на различни платформи носи със себе си много неочевидни нюанси. Всички универсални решения са принудени да строят замъци в пясъка: или разчитайки на сложни и крехки технологични решения(като Xamarin), или на мобилно устройство JavaScript двигателикато React Native. В същото време доставчиците на платформи дори не мислят да поддържат някое от решенията и всяка актуализация на родния SDK е голямо главоболие за всяка крос-платформена рамка. Да не говорим за такива специфични за системата функции като достъп до камерата, ключодържател или дори банална фотогалерия, която всеки се опитва да заобиколи с различна степен на успех. Разработчиците, които избират универсалния път, са заложници на тяхната рамка и често развитието, което обещаваше значителни спестявания, се превръща в битка срещу рейк.

Също така често в междуплатформените решения е обичайно да се жертва това, което се обозначава с термина потребителско изживяване (UX): много рамки се опитват да използват контроли, които са възможно най-общи за двете системи и почти винаги това решение е еднакво неудобно за всички . Или забави. Или демоде. Или изтощава батерията. Продължете списъка сами.

Междуплатформените приложения се отличават, чиито ядра са написани на ниско ниво, най-често срещаното за всички операционни системи: на езици като C/C++. В този случай е обичайно да се обобщава използването на код, който обслужва бизнес логиката, а интерфейсът се пише за всяка платформа поотделно. В идеалния случай може да се избегне дублирането на критична част от приложението, като същевременно се запази потребителското изживяване, което е специфично за всяка платформа. В реалния живот обаче нещата са по-сложни. Например Dropbox се опита да живее с ядро ​​от ниско ниво в продължение на няколко години подред, но в крайна сметка се отказа поради много причини и сега е доволен от собствените приложения на платформата. Препращам интересуващите се към тяхната любопитна статия по тази тема.

Според мен спестяването на междуплатформени рамки винаги е илюзорно. Вероятно в някои тривиални проекти, където приложението е просто версия на основния сайт, супер оптимизиран за мобилни устройства, обобщеният подход работи. В други случаи рискувате да повторите съдбата на Dropbox. Моят съвет е, ако искате да сте мобилен разработчик, инвестирайте в изучаването на платформата. Те винаги ще се отплатят, дори ако трябва да участвате в междуплатформен проект.

Надграждане Понижаване

, Старши софтуерен разработчик, Accenture Tver Technology Center

Пазарът на мобилни приложения се развива активно и наборът от технологии за тяхното разработване съответно нараства. Има доста инструменти, които можете да използвате.

За нативна разработка на платформата Android има Java или обвивка върху JVM - Kotlin. За iOS можете да използвате Objective-C или обвивка върху него - Swift. Това са всички ООП езици, които са наследили много от Smalltalk и C.

За разработка на различни платформи вече се използва Flutter от Google, за което ще трябва да познавате Dart. Или React Native от Facebook.

За начинаещ мобилен разработчик най-вероятно неговият минал опит и познания по езици ще бъдат определящият фактор. Ако Java е основата на неговия инструментариум, той ще може да научи света на мобилното развитие чрез платформата Android много по-бързо, използвайки същата Java или Kotlin.

В същото време Objective-C за разработка на iOS е взел много от Smalltalk, както и от Java, така че ако желаете, можете да направите избор в полза на iOS. Но имайте предвид, че разработката за Android може да се извърши на Windows или Linux, но iOS изисква MacOS X. Но за разработчик на JavaScript с познания за React, React Native очевидно е най-бързият начин. Точно както за разработчиците на Dart, изборът ще бъде в полза на Flutter.

След като начинаещият разработчик получи представа какво представлява мобилното развитие, какви са плюсовете и минусите на избрания път, той сам ще реши дали да работи с един подход или да решава проблеми с помощта на крос-платформени решения.

Този подход има своите предимства: крос-платформеният метод прави възможно пускането на проект в продуктивна среда малко по-бързо, като се използват по-малко ресурси. Освен това се поддържа по-лесно. Но има и очевидни недостатъци както за разработчика, така и за потребителя. Например, разработчикът не трябва да познава собствените технологии, но трябва да се вземат предвид насоките на платформата, тъй като приложение, написано според указанията на iOS, ще създаде затруднения за потребителите на Android и обратно.

Приложенията за различни платформи не могат да постигнат същото ниво на интеграция на устройството като родните приложения. Тоест, ако приложението говори за взаимодействие с устройство, като например камера, календар или използване изчислителна мощностустройства, е по-лесно да се постигне това с помощта на родния подход и ще бъде по-бързо и по-продуктивно.

При разработването на междуплатформено приложение специалистите вземат предвид възможностите на рамката, която налага ограничения. Също така си струва да се има предвид, че за да се разработи продукт на местни технологии, са необходими специалисти за всяка платформа.

Ако работите на свободна практика или имате цел да покриете максимален брой устройства с минимални средства, съсредоточете се върху разработката на различни платформи в случай на фокус върху мобилни решенияили предна работа.

Кои са основните предимства и недостатъци на мобилната нативна и междуплатформена разработка? Самата нативна разработка е скъпа, защото компанията трябва да инвестира в два екипа – iOS и Android. За прости приложения скоростта на разработка на Flutter / React Native е по-бърза.

Но плюсът е, че инфраструктурата вече е оформена и разбираема. Получавате достъп до всякакви ресурси на устройството и можете да се развивате под умен часовник, автомобили и др.

Разработката на различни платформи също е страхотно нещо. Но все още не е силно развит на ИТ пазара на труда в Русия. Разумни специалисти - броят се на пръсти. Рамковата инфраструктура е млада, но ситуацията постепенно се променя към по-добро. Тази разработка дава възможност да се пише за няколко устройства едновременно. Дори ако пишете на Flutter, например, той се интегрира лесно с нативния код.

Надграждане Понижаване

Разработката между платформи е насочена към бързи резултати и значителни икономии на бюджет - ние пишем един код за всички устройства. Неговите области на приложение са или решение за вътрешна употреба, където използваемостта на продукта не е толкова важна, а функционалността играе доминираща роля, или създаване на бърз "пилотен" проект, когато клиентът трябва да покаже принципа или идея за приложението. Освен това, ако няма точно разбиране на устройството с коя операционна система ще се гледа вашият прототип, тогава разработката на различни платформи е изходът. Трябва обаче да разберете предварително, че всички устройства имат различна архитектура, така че физически е почти невъзможно да се изпълни висококачествено приложение само на един междуплатформен код. В сложни сценарии ще трябва да напишете естествен код. Освен това, поради своята специфика, кросплатформеното развитие води до разходи, които не позволяват на приложението да бъде максимално ефективно. Това е разбираемо, в този случай междинният междуплатформен код трябва да бъде преведен за всяка от платформите, което прави приложението по-„тежко“ поради факта, че в допълнение към функционалния код съдържа неговата среда за изпълнение.

Дайте друго мнение

Всичко е ясно, покажете изводите

И така, какъв подход за развитие трябва да предприемете?

Всичко зависи от задачата. Ако трябва да напишете прототип на приложение за множество платформи или мобилна версиясайт, можете да погледнете към междуплатформени рамки. С тях е вероятно да напишете приложение по-бързо, отколкото с естествена разработка, особено ако работите върху рамка, подобна на обичайния ви инструмент, като React Native.

От друга страна, универсалността на крос-платформените приложения трябва да бъде компенсирана по някакъв начин. Някъде се появява „нероден“ интерфейсен елемент, някъде взаимодействието със системата е по-лошо, някъде скоростта на работа пада и т.н. Въпреки факта, че родната разработка изисква повече ресурси, много компании го предпочитат, защото на изхода е по-стабилен и естествено изглеждащ продукт.

В това отношение, ако тепърва започвате в мобилното развитие, тогава би било по-добре първо да направите естествено развитие. За него можете да намерите повече информация в интернет, ще получите по-задълбочено разбиране за възможностите на платформата и няма да бъдете обезпокоени от отделните нюанси на кросплатформената разработка. Освен това, ако решите да правите кросплатформена разработка в бъдеще, придобитите знания определено няма да ви попречат.

Напомняме ви, че можете да зададете въпроса си на експертите, а ние ще съберем отговори на него, ако се окаже интересен. Въпросите, които вече са зададени, могат да бъдат намерени в списъка с проблеми. Ако искате да се присъедините към редиците на експертите и да изпратите отговор от вашата компания или от вас лично, тогава пишете на , ние ще ви кажем как да го направите.

Разработката на различни платформи ви позволява да създадете мобилно приложение, което едновременно да функционира в iOS и Android среди. Това е бюджетна алтернатива на създаването на приложение за всяка операционна система поотделно.

Характеристики на кросплатформената разработка

Разработването на едно приложение за различни платформи е добро и лошо едновременно. Ами защото може да се направи по-бързо и по-евтино от няколко приложения за всяка операционна система. И това е лошо, защото компромисът се отразява в работата на приложението.

Тези характеристики трябва да се вземат предвид преди началото на проекта:

  • В междуплатформена среда кодът се пише веднъж. За да може приложението да работи на различна операционна система, кодът се превежда на друг език за програмиране. Времето и парите, изразходвани за разработка, са 1,5 пъти по-малко.
  • Приложенията може да не работят правилно.При разработката на различни платформи е невъзможно да се вземат предвид всички нюанси на работа с архитектурата на всяка операционна система, така че приложенията могат да работят по-бавно от тези, предназначени специално за iOS или Android.
  • Интерфейсът и изискванията за дизайн на елементите варират от операционна система до операционна система.. Например в iOS няма бутон за връщане назад, както в Android. При разработването на унифициран дизайн трябва да се вземе предвид тази точка: в iOS бутонът или ще остане, но няма да работи, или ще трябва да бъде изрязан ръчно и това е допълнителна работа с кода.

Повечето грешки при прехода от една платформа към друга се коригират ръчно, но е невъзможно напълно да се решат проблемите с адаптирането към „неродна“ операционна система.

Значи кросплатформеното развитие е лошо?

Не, кросплатформеното развитие е добре, стига да не изисквате от него повече, отколкото може да даде.

Тази опция може да бъде избрана в следните случаи:

  • Покрийте всички операционни системи с ограничен бюджет.Ако целевата аудиторияпо-активно използване на iOS или Android, можете да започнете с родно приложение за една операционна система. Ако максималното покритие е важно веднага, по-добре е да изберете опцията за различни платформи.
  • Проверете нишата. Ако има обещаваща идея, но няма сигурност, че ще проработи, е рисковано незабавно да инвестирате голям бюджет в развитие. Има смисъл да започнете с разработка на различни платформи, да проучите реакциите на потребителите и да вземете стратегически решения въз основа на това.
  • Приложението не използва сложна анимация и не извършва изчисления.Тези операции сериозно натоварват устройството и кросплатформеното приложение не е оптимизирано за пълноценно използване на ресурсите на определена платформа.
  • Приложението използва само основните функции на устройството. Показвайте информация, качвайте файлове, използвайте геолокация, направете поръчка - кросплатформено приложение може да се справи с всичко това. Необходима е по-дълбока интеграция на възможностите на устройството - ще трябва да изберете естествена разработка.
  • Корпоративно приложение за служители.Ако приложението е разработено за тесни вътрешни задачи и хората ще работят с него чрез лични джаджи, кросплатформено приложение ще бъде най-добрият вариант.

Няма универсален отговор на въпроса дали е възможно да използвате кросплатформени решения за вашия проект. Попълнете формата по-долу: ние ще проучим вашия проект и ще изберем най-добрия вариант за неговото изпълнение.