Az okostelefonok továbbra is egyre több helyet foglalnak el a nap alatt, nem csak a macskafotók és xxx videók fogyasztásának eszközeként, hanem munkaeszközként is. Ezért a mobilfejlesztés iránti igény növekszik. Általánosan elfogadott, hogy az Objective-C/Swift az iOS-hez és a Java/Kotlin Androidhoz igaz és menő. Kétségtelen, igaz és klassz, de sok olyan valós forgatókönyv létezik, amelyekben a többplatformos keretrendszerek használata előnyösebb a natív eszközökhöz képest.

Egyes fejlesztők azt várják, hogy a platformok közötti keretrendszer minden életproblémáját megoldja, míg mások ellenségesen érzékelik őket. Mindkét "harcos tábornak" megvannak a maga tévhitjei, amelyeket a működés és a működés félreértése okoz. Ez olajat önt a tűzre, hiszen technikai érvek helyett érzelmeket használnak.

A fejlesztők, különösen a kezdők körében is sok mítosz kering a platformok közötti mobil keretrendszerekkel kapcsolatban. Cikkünkben a legnépszerűbbeket elemezzük. De először nézzük meg a mobilfejlesztést egy olyan vállalkozás szemével, amely pénzt ad minden informatikai blackjackért.

Miért van szükségünk többplatformos eszközökre?

Történelmileg mindig is verseny volt a számítógépes piacon, és minden gyártó biztosította az optimális úgynevezett natív (natív) eszközkészletet operációs rendszereik és eszközeik alkalmazásainak fejlesztéséhez.

Natív eszközök = az ökoszisztéma tulajdonosa biztosítja.

A „betlehem” minden egyéb jele MÁSODLAGOS – az alkalmazások viselkedése és interfésze, az operációs rendszer funkcióihoz való hozzáférés, a teljesítmény és így tovább.

Ezenkívül szinte mindig kiderült, hogy a natív eszközök nem csak a fejlesztési nyelvek, az elfogadott konvenciók és az architektúrák szintjén nem kompatibilisek egymással, hanem az operációs rendszerrel és a könyvtárakkal való munkavégzés mechanizmusainak szintjén is. Ennek eredményeként ugyanazon algoritmusok és interfészek megvalósításához több környezetre, különböző programozási nyelveken kellett egy alkalmazást írni, majd azt „platformonként egy parancs” alapon karbantartani. Ugyanakkor az alkalmazások képességei és megjelenése különböző platformokon ah majdnem mindig 90%-ban azonos. Az érdeklődés kedvéért hasonlítsa össze kedvenc programjainak megvalósítását iOS és Android rendszeren.

Második fontos pont- a szükséges tudás és tapasztalat rendelkezésre állása a csapaton belül: ha nem, akkor időbe telik a tanulás.

Mindkét probléma megoldására már régóta megjelentek a piacon a többplatformos fejlesztőeszközök (nem csak a mobilokon), amelyek a következőket kínálják:

  • maximalizálja a közös kódbázist egyetlen programozási nyelvben, hogy a termék könnyebben fejleszthető és karbantartható legyen;
  • a meglévő kompetenciák és szakemberek felhasználása az alkalmazások új platformokon való megvalósításához.

Mivel manapság nagyon sok programozási nyelv (és környezet) létezik (és olyan szakemberek, akik ismerik ezeket a nyelveket), elég sok eszköz áll rendelkezésre a platformok közötti fejlesztéshez. Példaként a területünkön népszerűre fogunk összpontosítani PhoneGap, Xamarin, React Native és Qt.


Most mítoszokról beszélhetünk.

Mítosz 1. Varázslat

A legelterjedtebb mítosz, amely a kezdő fejlesztők elméjét űzi, a szuperalgoritmusokba vetett hit (és az azokat létrehozó szuperprogramozók), amelyek varázslatos módon változtatják a platformok közötti alkalmazásokat natív alkalmazásokká. Valami a "JavaScript kód konvertálása Swift-re, majd egy Swift-alkalmazás lefordítása" témájú. Ezt a mítoszt maguk a többplatformos eszközök fejlesztői táplálják, és ennek eredményeként „natív alkalmazások” létrehozását ígérik. És nem arról van szó, hogy valaki ravasz itt, hanem a gazdag képzelőerő és az alapvető mechanizmusok megértésének hiánya készteti a fejlesztőket olykor sámánisztikus trükkökre.

A többplatformos megoldások alapelve a kód két részre osztása:



A „bennszülött” világ és a „platformok közötti” világ összekapcsolásához speciális híd, ő határozza meg a platformközi keretrendszerek lehetőségeit és korlátait.

Híd használatakor a teljesítmény mindig csökken az adatok „világok” közötti konvertálásával, valamint API-hívások és könyvtárak konvertálásával.

Tehát minden platformközi alkalmazásnak rendelkeznie kell natív résszel, különben az operációs rendszer egyszerűen nem fogja tudni futtatni őket. Tehát nézzük meg közelebbről, milyen rendszer API-kat és mechanizmusokat biztosít maguk az iOS, az Android és a Windows. Térjünk át a következő mítoszra.

2. mítosz. Nem őshonos!

Tehát az alkalmazásnak van egy többplatformos része, amely virtuális környezetben él, és a keretrendszer infrastruktúráján és a hídon keresztül kommunikál az operációs rendszerrel.

Minden operációs rendszer: iOS, Android és Windows UWP – hozzáférést biztosít a következő alrendszerekhez (rendszer API-k készletei):

  • A WebView (az alkalmazásba ágyazott webböngésző) a PhoneGap alapú hibrid alkalmazásokban használatos, és de facto helyi webhely futtatókörnyezetként működik;
  • A React Native és társaik JavaScript-motorokat használnak a JS-kód gyors végrehajtására és a Native és a JS közötti adatcserére;
  • Az OpenGL ES-t (vagy DirectX-et) Qt/QML vagy hasonló alapú játékmotorokban és alkalmazásokban használják a felület megjelenítésére;
  • A felhasználói felület alrendszere felelős az alkalmazás natív felhasználói felületéért, amely a React Native és a Xamarin esetében releváns.


A többplatformos alkalmazások natív résszel és ugyanazzal a teljes hozzáféréssel rendelkeznek a rendszer API-khoz, mint a "natív" alkalmazásokhoz. A különbség az, hogy a rendszermetódushívás a hídon és a keretrendszeren keresztül megy keresztül:

webnézet- az alkalmazás a webböngészőjében él, hasonlóan egy egyoldalas weboldalhoz. Nincs hozzáférés a natív vezérlőkhöz (gombok, listák stb.), minden HTML/CSS/JavaScript alapú. Másrészt egy webfejlesztő úgy érzi magát, mint egy kacsa a vizet.

JavaScript motorok viszonylag nemrégiben vált népszerűvé, mivel egy hasonló mechanizmust csak a 7.0-s verzióban adtak hozzá az iOS-hez. A funkciók közül érdemes megfontolni a JavaScript és a Native környezetek között átvitt összetett adatszerkezetek JSON-ba való sorba rendezésének szükségességét. Ha röviden leírunk egy ilyen megoldásosztályt, akkor a JavaScript környezetben a natív alkalmazást vezérlő JS kód kerül végrehajtásra.

OpenGL ES és DirectX alacsony szintű alrendszerek, és a játékok és például a Qt/QML felhasználói felületének megrajzolására szolgálnak. Vagyis az OpenGL / DirectX használatakor a fejlesztők maguk rajzolnak vezérlőket és animációkat, amelyek csak a natívhoz hasonlóak lehetnek. Másrészt ez egy alacsony szintű, nagyon nagy teljesítményű alrendszer, ezért használják a cross-platform játékmotorokban is.

Minden platformközi alkalmazásnak van natív része, és ezért potenciálisan ugyanaz a teljes hozzáférés a rendszer API-khoz, mint a "natív" alkalmazásokhoz. Ezenkívül a többplatformos alkalmazásokat "natív" eszközök építik és csomagolják "natív" telepítőcsomagokba. A kulcskérdés az, hogy hogyan szerveződik meg a többplatformos rész és a natív rész közötti interakció. Például egy WebView-n belül vagy az Open GL ES / DirectX használatával nincs mód teljesen natív megjelenésű felhasználói felület létrehozására, de teljes hozzáférés áll rendelkezésre a GPS-hez, a Push értesítésekhez és egyéb funkciókhoz. A JavaScript vagy a C# kód pedig teljesen szabadon irányíthatja a natív alkalmazást és annak viselkedését, teljesen natív megjelenést biztosítva.

Összefoglalva - igen, a használt fejlesztői eszközöket tekintve "nem őshonos" (nem Apple, Google). De egy alkalmazás lehet teljesen natív a rendszer API-khoz való hozzáférés szempontjából, és teljesen natív megjelenést és érzetet biztosít. És továbblépünk a következő mítoszhoz.

3. mítosz. Mankó a mankón

Itt azt kell érteni, hogy a natív API-k alapból nem számítanak mankónak (bár itt is vannak eltérő vélemények), így minden felháborodás a platformok közötti részre irányul. Nyilvánvaló, hogy a végrehajtási környezetet (például WebView, JavaScript motor vagy Mono) is nehéz mankónak nevezni - kiforrott, kiforrott megoldások nagy múlttal.

Úgy tűnik, hogy a mankó az, ahogy a keresztplatformos rész integrálódik a natív részhez. A különböző keretrendszerek működésének jobb megértése érdekében a PhoneGap, a Xamarin, a Qt és a React Native példáját fogjuk használni, hogy megvizsgáljuk azokat az operációs rendszer-mechanizmusokat, amelyek a platformok közötti és a natív részek összekapcsolására szolgálnak.

Kezdjük a PhoneGap-pal. Az alábbiakban egy ezen a keretrendszeren alapuló alkalmazás legfelső szintű architektúrája látható.



A PhoneGap alkalmazás valójában egy natív alkalmazás, amely a WebView-t jeleníti meg az egyetlen UI-vezérlőként. Rajta keresztül megy végbe a natív résszel való interakció. Az iOS, Android és Windows UWP összes szabványos WebView támogatja a natív kezelők hozzáadását a JS-tulajdonságokhoz és -metódusokhoz. Ugyanakkor a JS-kód elszigetelt környezetben él, és nem tud semmit a natív részről - egyszerűen előhívja a szükséges JS-metódusokat, vagy megváltoztatja a szükséges JS-tulajdonságokat. Minden benne van a szabványos web DOM-ban, amely egyszerűen hozzáadja a natív megvalósításhoz kapcsolódó új elemeket.



Amikor React Native-en hoz létre alkalmazásokat, a fejlesztőnek szinte mindig a natív részt Objective-C-ben, Java-ban vagy C #-ben kell megvalósítania, maga a natív alkalmazás kezelése pedig JavaScript-ből származik. Valójában a JavaScript motor egy WebView elem, amely külön is elérhető. Az interakció ugyanazon a JS-hídon megy keresztül, mint a PhoneGap esetében. A React Native-ban azonban a JS-kód nem a webes DOM-fát, hanem a natív alkalmazást kezeli.

Kérjük, vegye figyelembe, hogy az iOS korlátai miatt (nincs mód a JIT megvalósítására) a JavaScript kódot menet közben értelmezi, és nem fordítja le. Általában ez nem befolyásolja jelentősen a teljesítményt valódi alkalmazások de érdemes emlékezni rá.

Most vegyük fontolóra a klasszikus Xamarin.iOS-t és a Xamarin.Android-t, mivel a Xamarin.Forms (a Windows UWP-t támogató) ezek kiegészítője.



A Xamarin a Mono könyvtárat használja a cél operációs rendszerrel való interakcióhoz, amely lehetővé teszi a natív kód meghívását a P/Invoke mechanizmus segítségével. Az iOS/Android natív API-kkal való kommunikációra is szolgál. Ez azt jelenti, hogy a C#-ban a burkolókat minden nyilvános natív API-metódushoz hozzák létre, amelyek viszont rendszer API-kat hívnak meg. Így az összes rendszer API elérhető egy Xamarin alkalmazásból.

És végül nézzük a Qt-t, mivel sok kérdés merül fel ezzel kapcsolatban a tapasztalt fejlesztők részéről.



A Qt egy "önmagában lévő dolog", ennek vannak előnyei és korlátai is. A Qt-könyvtárak egyszerűen csatlakoznak az összes operációs rendszeren megtalálható C++ rendszer API-khoz. A felhasználói felület megrajzolásához alacsony szintű mechanizmusokat használnak, de saját grafikus motort, amely támogatja a natív stílust. Ugyanakkor Androidon egy speciális hídon (JNI bridge) keresztül kell elérni a Java API-t, Windows UWP esetén pedig az Open GL ES to DirectX híváskonvertálót, mivel az Open GL UWP-hez nem érhető el.

Összefoglalva: minden platformon átívelő keretrendszer az operációs rendszerek szabványos natív képességeit használja, kiforrott, tapasztalt csapatok és a nyílt forráskódú közösség hozta létre IT iparági óriások támogatásával. És végül itt az ideje a legerősebb érvnek.

4. mítosz. Lassan

Egy fontos ütőkártya, amelyet az emberek szívesen használnak a platformok közötti keretrendszerekkel kapcsolatos vitákban, az alacsony teljesítmény. Ismét attól függően, hogy mivel kell összehasonlítani, és melyik papagájt kell számolni.

Emlékezzünk vissza, hogy a többplatformos alkalmazások egyik jellemzője a két világ párhuzamos létezése, amelyeket egy híd köt össze:

  • PhoneGap: HTML/JS és natív Java / Objective-C / C#;
  • React Native: JS és natív Java / Objective-C / C#;
  • Xamarin: Mono és natív Java / Objective-C;
  • Qt: C++ és natív Java/Objective-C.

Így a teljesítmény összehasonlításakor figyelembe kell venni a munka sebességét:

  • keresztplatformos rész;
  • natív rész;
  • híd.

Ha például beírja a keresőmotorba, hogy reagál a natív vagy a gyors teljesítményre, sok különböző tesztet láthat, és sok közülük megjegyzi, hogy a teljesítmény meredeken csökken a híd aktív használatakor, beleértve a felhasználói felület aktív manipulálását a többplatformos kódból. A Xamarin esetében a helyzet ugyanúgy néz ki - a cross-platform rész nagyon gyors és adatfeldolgozásban összehasonlítható a natív részével, azonban híd használatakor a teljesítmény csökkenhet. A Qt általában C++ szinten működik, ami önmagában is gyors. Ha a PhoneGap alapú megoldásokat tekintjük, akkor itt a teljesítmény nagymértékben függ a WebView-tól, de mégsem szabad aktívan megváltoztatni a felhasználói felületet a JavaScript kódban, vagy tudományos számításokat végezni.

Lassan? Igen, a teljesítmény csökkenhet az operációs rendszerrel való hídon keresztüli nem megfelelő interakció miatt. Maguk a platformok közötti világok azonban ugyanolyan gyorsak, mint a natív világok.

A mobil alkalmazások életünk nélkülözhetetlen kísérőivé váltak. Segítségükkel nemcsak jól érezhetjük magunkat és leegyszerűsíthetjük életünket, vásárolhatunk vagy rendelhetünk meg bizonyos szolgáltatásokat az interneten, hanem népszerűsíthetjük vállalkozásunkat, növelhetjük vevőkörünket, és ezzel megsokszorozhatjuk a profitot. És ha senki sem kételkedhet abban, hogy alkalmazást kell készítenie vállalkozása számára, akkor a mobilalkalmazás típusának kiválasztásával nehézségek adódhatnak.

Összes modern alkalmazások a mobileszközökhöz natív és több platformra osztható, és e két csoport mindegyikének megvan a maga sajátja erősségeit valamint annak hiányosságait.

A natív alkalmazások kifejezetten egy adott platformra, a megfelelő programozási nyelven kifejlesztett alkalmazások. Tehát az Android-alkalmazások létrehozásakor a Java-t, az IOS-alkalmazásokhoz pedig az Objective-c-t vagy a Swift-et használják. Az ilyen projektek létrehozásakor a szakemberek figyelembe veszik a platformok összes jellemzőjét, különös figyelmet fordítva az UI / UX tervezésére, az operációs rendszer fejlesztői követelményeire / ajánlásaira, valamint a mobilipar legújabb trendjeire. Egy szakember nem tudja teljesen elsajátítani az összes fenti nyelvet, ezért egy natív termék fejlesztéséhez különböző platformokhoz különböző fejlesztőket kell összekapcsolni, és ez többletköltséget jelent, és a fejlesztési idő lenyűgöző lesz. Ugyanakkor az alkalmazások egy adott platformra „élesednek”, hozzáférnek az eszköz belső erőforrásaihoz és funkcióihoz, és a lehető leghatékonyabban működnek.

A natív fejlesztés előnyeinek számottevő listája ellenére az ügyfelek nem mindig akarnak időt és pénzt költeni fejlesztésükre, több mestert bekapcsolva a létrehozási folyamatba. Ilyen esetekben a legjobb megoldás a többplatformos fejlesztés, amely lehetővé teszi, hogy bármilyen platformra hozzon létre alkalmazásokat szabványos webes technológiák használatával. Ebben az esetben a fejlesztést egy olyan személy végezheti, aki rendelkezik szükséges ismereteketés tapasztalat HTML5, JavaScript és CSS3. A platformok közötti fejlesztések Android esetén .apk, IOS rendszeren pedig .ipa fájlba fordíthatók. Így egy fejlesztés alapján két alkalmazást is kaphatunk a népszerű operációs rendszerekhez, kevesebb időt és pénzt költve rá. Az ilyen fejlesztéseknek azonban megvannak a hátrányai is, ezért nagyon kívánatos minden egyes esetet egyedileg megközelíteni, és kiválasztani a legmegfelelőbb lehetőséget - natív vagy cross-platform fejlesztést.

Az alkalmazás kliens és szerver részei

A legtöbb komoly alkalmazásnak megvan a saját kliens oldala, amelyet gyakran frontendnek neveznek, és egy szerveroldal, a háttér. A frontend felelős azért, amit a mobileszköze képernyőjén lát, vagyis az alkalmazás teljes vizuális megjelenítéséért, beleértve az ablakok, menük, gombok, nyilak és egyéb elemek kialakítását, méretét és elhelyezkedését. Ezenkívül a frontend felelős azért, hogy az alkalmazás reagáljon bizonyos felhasználói műveletekre, amelyek célja az alkalmazás különböző részeire való költözés, új menük előhívása és így tovább.

A háttér az alkalmazás szerver része, és egy távoli kiszolgálón található, amely bárhol elhelyezhető, és sokféle eszközzel vezérelhető. szoftver eszközök. A kliens és a szerver részek közötti kapcsolat az API-n (alkalmazásprogramozási felület) keresztül valósul meg. Vagyis az API egyfajta közvetítő a frontend és a backend között, amely a kliens oldalról küldi el a kéréseket a szerver felé, visszaküldve a felhasználó számára szükséges adatokat.

Frontend fejlesztés

Az alkalmazás kliens része rendkívül fontos, mivel a felhasználó maga foglalkozik vele, és az alkalmazásról alkotott általános elképzelése a frontend kényelmétől függ. Manuálisan is fejleszthető, de ehhez jól kell ismerni a HTML5-öt, a CSS3-at és a java-scriptet, illetve úgynevezett keretrendszerek segítségével. Az első esetben gyakran az Apache Cordova fejlesztői környezetet használják, amelyet PhoneGap néven is ismernek. Ezzel a keretrendszerrel bármilyen platformra készíthet alkalmazásokat webes technológiák segítségével, amelyeket a Cordova egy adott platform számára érthető kóddá alakít át. A Cordova gyakorlatilag korlátlan lehetőségeket nyit meg azoknak a webfejlesztőknek, akiknek nem kell megtanulniuk az Objective-C-t vagy a Swiftet, a Java-t vagy a Kotlint ahhoz, hogy alkalmazásokat hozzanak létre bizonyos operációs rendszerekhez.

Míg a Cordova nem szab határokat a felhasználói felület és a logika terén, a keretrendszerek kész sablonmegoldásokat kínálnak. Ez egyrészt jelentősen felgyorsítja és leegyszerűsíti a fejlesztési folyamatot, hiszen a szakember használhat kész gombokat, listákat, beviteli mezőket, kártyákat és egyéb UI-elemeket. Ezzel szemben a szakember csak azokat az eszközöket, elemeket használhatja fejlesztésre, amelyek a kiválasztott keretrendszerben rendelkezésre állnak. Közülük a legnépszerűbb az Ionic, amely lehetővé teszi, hogy platformokon átívelő alkalmazásokat készítsen minden ízléshez. Ez a keret nagy beépített gyűjteménnyel rendelkezik szabványos elemek, amelyek vizuálisan utánozzák a natív alkalmazásokat, de szükség esetén a kialakításuk módosítható. Ugyanakkor a fejlesztő számos további bővítményt csatlakoztathat, amelyek bővítik az ionos keretrendszer képességeit, és az ezen a keretrendszeren létrehozott projekt közvetlenül a böngészőablakban elindítható, és kiértékelheti, hogyan fog kinézni és működni. alkalmazás készül emulátor vagy okostelefonra történő telepítés nélkül.

Háttérfejlesztés

Míg a HTML-t, CSS-t, JS-t és keretrendszereket ismerő tervezők és fejlesztők a kliens oldalon, addig a háttérben más profilú programozók dolgoznak. A szerverek konfigurálásához különböző programozási nyelvek és eszközök használhatók, a lényeg az, hogy megfelelően konfigurálják a munkájukat és az ügyfélrésszel való interakciót. Itt kell használni megfelelő rendszerek adatbázis-kezelés (adatbázisok). Ez lehet hagyományos MySQL, Redis, PostgreSQL, vagy bármilyen más adatbázis (például MongoDB), amely alkalmas egy adott projekt megvalósítására, és amelyben a háttérfejlesztő jól jártas. A fejlesztők PHP, NodeJS, C#, Ruby, Python, Java és más programozási nyelveket használhatnak az alkalmazás szerveroldalának létrehozásához.

A KitApp mobilstúdió szakemberei átfogóan és maximálisan felelősségteljesen közelítik meg a frontend és a backend részek fejlesztésének kérdését. Fejlesztőink a lehető leggyorsabban és leghatékonyabban létrehoznak Önnek egy platformfüggetlen alkalmazást bármilyen bonyolultságú és irányú! Forduljon hozzánk, és szakembereink azonnal tanácsot adnak minden kérdésében!

Platformokon átívelő alkalmazások – lenni vagy nem lenni? A kérdés nem könnyű, hiszen minden vállalkozásnak megvannak a maga céljai és követelményei a mobilalkalmazásokkal szemben. De ma biztosan kitaláljuk, melyik fejlesztés a megfelelő az Ön számára.

Mik azok a platformok közötti alkalmazások?

A többplatformos alkalmazások olyan alkalmazások, amelyeket egyszerre fejlesztenek ki, majd futnak Androidon és iOS-en is. A fejlődés lényege az forrás Az alkalmazás natív nyelvre van lefordítva, azaz egy adott mobileszköz számára érthető. Ennek eredményeként a program kölcsönhatásba léphet a rá telepített operációs rendszerrel.

Emlékezzünk vissza, hogy a natív alkalmazások, a többplatformos alkalmazásoktól eltérően, egy adott operációs rendszerhez vannak írva.

A platformok közötti fejlesztés előnyei

  • felhasználói bázis bővülése az alkalmazás egyidejű megjelenése miatt több üzletben;
  • az egyetlen forráskód megóvja attól, hogy több fejlesztőt kelljen felvennie minden platformhoz;
  • A többplatformos alkalmazások kódbázisának 75%-a újrafelhasználható, új projektekhez igazítva.

A platformok közötti fejlesztés hátrányai

1. Nagy függőség a mobileszköztől

A többplatformos alkalmazások általában nem működnek offline állapotban. Ezért képességeik nagymértékben függenek attól, hogy a felhasználónak van-e stabil internetkapcsolata. Változat operációs rendszerés a készülék modellje is fontos. Egy többplatformos alkalmazás szinte garantáltan rontja az egy-két évnél régebbi eszközök teljesítményét. Míg a natív alkalmazás stabilan fog működni még egy elavult firmware-rel rendelkező ősi modulon is. Tehát ha nem szeretné, hogy ügyfelei dühös véleményeket olvassanak arról, hogy az alkalmazás végül „kifejtette” valaki okostelefonját, válassza a natív fejlesztést.

2. Barátságtalan felhasználói felület

A felhasználók annyira rabjai megjelenésés kütyük funkcionalitását, hogy maximális válaszkészséget várnak el a rájuk telepített alkalmazásoktól. Biztosak akarnak lenni abban, hogy minden gomb a megfelelő helyen van, az oldal a számukra optimális sebességgel gördül, és minden intézkedést azonnali reakció követ. A platformok közötti alkalmazások általában nehezen illeszthetők az eszközhöz, és nem büszkélkedhetnek nagy sebességű teljesítménnyel.

A probléma az, hogy nincsenek irányelvek a platformok közötti fejlesztéshez - fejlesztési szabványok az operációs rendszer alkotóitól. Ezért az „Androidra” készült, többplatformos alkalmazás nem lesz kényelmes az iOS-felhasználók számára, és fordítva. Természetesen minden platformhoz külön dizájnt is készíthet, de a munkaerőköltség szempontjából ez egyenlő lesz két különböző alkalmazás létrehozásával, igaz, ugyanazon a nyelven.

3. Küzdelem a felsőbbrendűségért a fejlesztési eszközök között

A többplatformos fejlesztési megoldások piacán a verseny napról napra kiéleződik. Eddig a React Native és a Xamarin a legnépszerűbb a fejlesztők körében, de például a Vue Native jócskán megelőzheti őket. Ebben az esetben a verseny ex-vezetői elveszítik a legfontosabb előnyt - a működési kód támogatását. És ez bármilyen platformközi eszközzel megtörténhet.

A natív fejlődés nem fél egy ilyen problémától. Az új eszközök bevezetése fokozatos, és több programozási nyelv ismerete, ami egy szűk szakember számára kötelező, lehetővé teszi, hogy minden újítással gyorsan megbirkózzon. Ráadásul az egyes operációs rendszerek körül hatalmas szakmai közösségek alakulnak ki, aminek eredményeként a felmerülő nehézségeket úgy oldják meg, hogy a fórumokon keresnek hasonló problémát, ahol több ezer ember kész javaslatot és segítséget adni a megoldásban.

Melyik alkalmazás a megfelelő az Ön vállalkozásának?

Mielőtt válaszolna erre a kérdésre, rendkívül fontos elemezni a vállalkozását. Fogyasztói szegmensek, az idő- és pénzforrások értéke, az alkalmazások felhasználói eszközökkel való integrálásának kívánt mélysége, valamint egyértelműen meghatározott hosszú távú célok – a minimum, amelytől a választása függ. De megkönnyítjük a dolgunkat, ha már most válaszol a vonatkozó kérdésekre.

1. Mit használ a közönség?

Ha tudja, hogy ügyfelei között az iOS és Android felhasználók számának aránya megközelíti az 50/50-et, válassza a natív fejlesztést. Ez megmutatja, hogy egyformán tiszteletben tartja minden ügyfele igényeit, függetlenül azok jövedelmi szintjétől.

A mobileszköz-választás és a fizetőképességi szint közötti összefüggést az App Annie ismét megerősítette. A mobilalkalmazások letöltési és eladási számának vizsgálata eredményeként A Google Playés Alkalmazásbolt 2018 első negyedévében kiderült, hogy az Android okostelefonok felhasználói 135%-kal több alkalmazást töltöttek le, mint az iOS áruház látogatói. Az App Store ugyanakkor 85%-kal több bevételt hozott tulajdonosainak, mint a Google Play.

A sikerhez vezető út nyilvánvaló: játssz egyszerre két pályán. Pontosabban két üzlet. Csak számolja ki, hogy az alkalmazás melyikben jelenjen meg először. Természetesen, ha az egyidejű kiadás nem része a digitális stratégiának).

2. Mennyi fejlesztési ideje van?

A projekt pénzügyi költségei a kérdésre adott választól függenek. Az tény, hogy a fejlesztésre fordított idő szempontjából a cross-platform alkalmazás csak jövedelmezőbb megoldásnak tűnik. Valójában a platformokhoz való adaptálása majdnem annyi ideig tart, mint két natív alkalmazás létrehozása, mivel a fejlesztőknek további kódrészleteket kell írniuk a problémás területekhez.

Egy natív alkalmazásnál biztosan nem lesznek ilyen problémák, ami nagyon fontos a hibákkal és hibákkal szemben rendkívül érzékeny közönség megtartásához. A Compuware statisztikái szerint a felhasználók 79%-a kész újraindítani az alkalmazást, ha az első indításkor nem működött megfelelően, de csak 16%-uk vállalja, hogy újabb esélyt ad neki. A többi valószínűleg csak eltávolítja a programot.

3. A készülék milyen funkcióit tervezi használni?

Már beszéltünk arról, hogy csak a natív alkalmazások képesek gyorsan és minőségromlás nélkül reprodukálni a nehéz grafikákat. De ez technikai előnyök az őshonos fejlődés nem korlátozott. Vegyük például a Facebook alkalmazást. Az Androidra és iOS-re különálló verziók kiadásának köszönhetően gördülékenyebbé vált a görgetés, csökkentek a képbetöltési idők, és minden gyorsítótár probléma megoldódott.


Sőt, a natív alkalmazások közvetlen hozzáféréssel rendelkeznek az összes eszközszolgáltatáshoz, így információkat kaphat a felhasználó tartózkodási helyéről vagy névjegyzékéről. A többplatformos alkalmazásoknak speciális natív bővítményeket kell használniuk, ami negatívan befolyásolja az adatátviteli sebességet és a túlterhelést RAM eszközöket.

4. Milyen eredményeket keres?

A digitális stratégia olyan célok listája, amelyeket vállalata digitális eszközökkel elérhet. Az utóbbi választása nagymértékben attól függ, hogy milyen előnyöket szeretne elérni.


Bontsa fel a folyamatot ötletről eredményre pontról pontra, figyelembe véve az összes rendelkezésre álló erőforrást. A felfedezések a legváratlanabbak lehetnek.

Előfordulhat például, hogy a sok funkciót és interaktív elemet tartalmazó reszponzív webhely többplatformos alkalmazássá való lefordítása, ahogy eredetileg szerette volna, túl költséges feladat. Vagy végül győződjön meg arról, hogy a mobilwebhelyek mindig veszítenek egy mobilalkalmazással szemben – akárcsak a platformok közötti fejlesztés a natíval szemben. És az okok között keresse meg azokat, amelyekről fentebb beszéltünk.

Következtetés: egy többplatformos alkalmazás csak egy esetben előnyös - létrehozza az alkalmazás demóverzióját, korlátozott az idő, a pénz és a szűk profilú szakemberek. Minden más esetben egy natív alkalmazás többszörösen több előnnyel jár, hiszen ez egy minőségileg eltérő fejlettségi szint.

Úgy tűnik, hogy itt többplatformos fejlesztésről van szó, amely lehetővé teszi univerzális alkalmazások létrehozását különböző platformokra. Gyorsabban írtam a kérelmet, azonnal kiadtam mindenhol - profit! És nincs szükség natív fejlesztésre. Vagy még mindig szükség van rá? Szakértőinket a mobilalkalmazás-fejlesztés mindkét megközelítésének árnyalatairól kérdeztük.

A „mobilfejlesztő” tág fogalom. Az a fejlesztő, aki a mobil operációs rendszer részeit implementálja, egyben mobilfejlesztő is. Ha pedig az a cél, hogy ilyen fejlesztővé válj, akkor általában a C ++, a mobil operációs rendszer és a mobileszközök hardverének megtanulásával kell kezdeni.

Ha a custom implementáló fejlesztőre gondolsz mobil alkalmazások, akkor a natív fejlesztéssel kell kezdeni.

Miert van az? A natív fejlesztés lehetővé teszi az adott operációs rendszerek (és az azokhoz való alkalmazások) és a mobil hardverek képességeinek jobb és mélyebb felfedezését.

A felhasználó szempontjából mindenképpen a natív fejlesztés nyer. A natív alkalmazások gyorsabban működnek, felületük reszponzívabb és ismerősebb az adott mobil operációs rendszer felhasználói számára, jobban kihasználják az eszközök hardveres képességeit, jobban működnek offline, és kevésbé „hibásak”.

A platformok közötti fejlesztés eredeti ötlete a fejlesztő munkaerőköltségének csökkentése. Röviden a következőképpen fejezhető ki: „Egyszer megcsináltam, bármire bevált.” Az ötlet jó és helyes (a fejlesztő szemszögéből), de a minőséggel kapcsolatban vannak kérdések. A sokoldalúság kezdettől fogva kompromisszumokkal jár, és ez alól a mobilfejlesztés sem kivétel.

Egy adott feladat fejlesztési típusának kiválasztásakor a fejlesztőnek értékelnie kell, hogy ez a kompromisszum elfogadható-e. Számos olyan feladat van, ahol a cross-platform fejlesztés alkalmazása igencsak indokolt lenne, például tesztprojektekben, oldalak mobil verzióiban, olyan keretrendszert használó játékokban, mint a Unity 3D.

Ugyanakkor a mobil üzleti problémákat megoldó projekteknél (nagy terhelés mellett az offline mód támogatásának szükségessége, hosszú távú fejlesztést célozva) a natív fejlesztést tekintik az egyetlen optimálisnak (és bizonyos feladatoknál az egyetlen lehetségesnek). ) választási lehetőség.

Ugyanakkor a natív fejlesztés fő hátrányai a fejlesztési idő (többet vesz igénybe) és a változatos erőforrásigény (különböző natív programozási nyelveken fejlesztők). Vannak módok ezeknek a hiányosságoknak a mérséklésére – például valamilyen mobilalkalmazás-platform (MEAP osztály) használata a fejlesztéshez, amely lehetővé teszi natív alkalmazások létrehozását.

Frissítés Downgrade

, Az "ID - Management Technologies" IT cég technológiai fejlesztési igazgatója

Bármely platformközi könyvtár vagy keretrendszer ugyanazokon a natív mechanizmusokon alapul, amelyek közvetlenül megvalósítják a natív fejlesztést. Csupán arról van szó, hogy a többplatformos megoldások esetében a munkafolyamatokat úgy építik fel, hogy „kisimítsák a sarkokat” abból a szempontból, hogy a végső megoldás felületét egy bizonyos közös nevezőre hozzák.

Általános szabály, hogy az univerzalizmus nem mindig ad választ egy működő mobil megoldás létrehozásának feladatára: a fejlesztő annál jobban dolgozik, annál mélyebben ismeri az eszköz mechanizmusait. különféle folyamatok belülről, ahogy mondják, "a motorháztető alól".

Szintén teljesen működőképes modell lenne a két megközelítés alapelemeinek egyidejű elsajátítása, egy ilyen tanulási feladatban már a kezdeti szakaszban nincs lehetetlen. Például egy ilyen forgatókönyv elég megvalósíthatónak és ígéretesnek bizonyulhat: kezdj el egy többplatformos paradigmában dolgozni, és ezzel párhuzamosan önállóan vagy kollégák segítségével tanulmányozd, milyen natív lehetőségek vannak a jelenlegi megoldások fejlesztésére, és hogyan alkalmazni a gyakorlatban.

Ebben az esetben könnyebb elérni a mobilfejlesztési folyamat elvi működésének átfogó megértését, amelyet végponttól végpontig hívnak. Ez azért is hasznos, mert minden, még a legfejlettebb univerzális platform is lemarad a natívtól: a hardver- és a mobil operációs rendszer gyártói gyakran együttműködnek, és folyamatosan növelik a végső megoldások képességeit - a mobilfejlesztői platformok képességeit, különösen a cross-platform megoldásokat. , elkerülhetetlenül lemaradnak .

Folyamatosan jelennek meg a piacon új termékek a mobilszegmensben, némelyik jóval megelőzi korát – vegyük a Samsungot és az összecsukható képernyős készülék fejlesztését: nyilvánvaló, hogy a radikálisan eltérő front-end miatt , a meglévő fejlesztői platformok nem állnak készen az ilyesmire.

Itt segít a natív platformok mély ismerete: csak a mobilfejlesztés, azaz a natív platformok mély, rendszerszintű tudásával rendelkező fejlesztő tudja kompenzálni a hardver és az operációs rendszer mögötti természetes lemaradást. Csak egy ilyen szakember tudja majd a legújabb mobileszközökre szánt megoldásának funkcionalitását növelni a jelenleg elérhető, nem egészen fejlett fejlesztői platformokon.

A platformok közötti fejlesztés kiválóan alkalmas prototípusok készítésére, ötletek gyors tesztelésére stb. Amint valóban alapvető termékek létrehozásáról van szó, a fejlesztőnek elkerülhetetlenül felmerül az igénye, hogy alaposan tanulmányozza a folyamat alapelemeit, vagyis a natív fejlesztést.

Frissítés Downgrade

, A GeekUniversity iOS Fejlesztési Karának dékánja, a GeekBrains oktatási portál

Rövid válasz: ha nincs programozási tapasztalat, akkor természetesen a natív fejlesztést kell választani. A platformok közötti fejlesztés azoknak a szakembereknek jó, akik a kapcsolódó területekről a mobilfejlesztés felé mozdulnak el. Például, ha Ön egy front-end fejlesztő, aki jól ismeri a JavaScriptet, akkor a React Native keretrendszer segítségével (a React keretrendszeren alapul) gyorsan és fájdalommentesen próbálhatja elsajátítani a mobilfejlesztést. Hasonlóképpen, a .NET fejlesztők könnyebben elsajátítják a Xamarin keretrendszert.

A platformok közötti fejlesztés az ügyfél számára is előnyös - könnyebben talál egy fejlesztői csapatot, akik egy közös mintát követve egyszerre két platformra fejlesztenek alkalmazást.

Az előnyök nyilvánvalóak, de mik a hátrányai a többplatformos fejlesztésnek?! Úgy gondolják, hogy minél összetettebb és finomabb a funkcionalitás egy mobilalkalmazásban, annál nehezebb, ha nem lehetetlen megvalósítani a többplatformos eszközökkel – ez gyakran felülmúlja az univerzális eszközök minden előnyét. Tapasztalataim szerint több olyan nagyvállalat is van, amely alkalmazásának növekedésével kénytelen volt felhagyni a keresztplatformokkal a natív fejlesztés érdekében. Így kis projektekhez és esetleg szabadúszó feladatokhoz az általános megoldások is elegendőek, a nagy projektekhez pedig a natív megoldások jobban megfelelnek.

A kereslet mindkét területen meglehetősen nagy, de a natív fejlesztésre valamivel magasabb: Swift kérésére a hh.ru oldalon Oroszországban - 369 üres, Kotlin - 397, React Native - 111, Flutter - 13 Xamarin - 18. De pihenj biztos, jó szakember a Nem lesz munka semmilyen területen.

Frissítés Downgrade

Először is fontos megjegyezni, hogy minden mobilalkalmazás több rétegből áll:

  • UI – amit a felhasználó lát;
  • üzleti logika – mire írták az alkalmazást;
  • egyéb platform-összetevők – az üzleti logika által használt hálózattal, adatbázisokkal és egyéb rendszerelemekkel való együttműködés.

Az adott alkalmazástól függően ezeken a rétegeken a komponensek mérete nagyon eltérő lehet. Például egy webhely hírolvasó alkalmazása nagyon különbözik egy VPN-klienstől.

Maga a fejlesztés három típusra osztható: natív, teljesen cross-platform és hibrid.

őshonos fejlődés

A natív fejlesztés során mindhárom réteget ugyanazzal az eszközkészlettel írják. Ezért minden további bonyolultság nélkül kölcsönhatásba léphetnek egymással.

A natív fejlesztés előnyei:

Hibrid fejlesztés

Ez a fajta fejlesztés a két korábbi megközelítést ötvözi. Az üzleti logikai réteg „hordozható” komponensként épül fel, a felhasználói felület és a platform integrációja pedig szabványos eszközökkel jön létre. Számos nyelv létezik az általános logika írására: C/C++ (érett és erőteljes), KotlinNative (nagyon aktívan fejlesztett) és JavaScript (legkevésbé gyakori).

Előnyök:

  • az erre legalkalmasabb komponensek natívak maradnak;
  • a közös logika egyszer jön létre.

Hibák:

  • ha egy közös összetevőt egy mobil csapat hoz létre, akkor más nyelven kell szakértelmet szerezni;
  • többplatformos komponensek integrálására van többletköltség.

Milyen típusú fejlesztéssel érdemes kezdeni?

A kérdés megválaszolásához meg kell értenie, milyen projekteket szeretne létrehozni. A kis projektek tisztán többplatformosak lehetnek, és ez teljes mértékben indokolt lesz. Itt azt tanácsolom, hogy nézze meg közelebbről a Fluttert.

De ma a natív fejlesztéssel kezdeném. Először is, a legtöbb projekt ma natívan jön létre. Ez azt jelenti, hogy több lehetősége lesz projektet/céget váltani. Másodszor, idővel át lehet térni a hibrid platformok közötti fejlesztésre. Ez lehetővé teszi, hogy fejlődjön a technikai kérdésekben.

Frissítés Downgrade

Véleményem szerint a legjobb a natíval kezdeni, majd ha nagyon akarod, elsajátítod egy vagy több platformfüggetlen eszközt. Kivételt jelenthet a játékok fejlesztése, mivel ezek főként Unityben íródnak, ez pedig egy cross-platform motor.

Ha a natív fejlesztés előnyeiről beszélünk, akkor ez egy programozó számára kevesebb akadályt és többféle munkaeszközt jelent. Több információforrással is rendelkezik majd, hogy megoldja az alkalmazáskészítés során felmerülő összetett problémákat – nem titok, hogy az interneten sokkal több tipp és trükk található a natív fejlesztéshez, mint a többplatformos fejlesztéshez.

A végfelhasználó számára a natív fejlesztés azt jelenti, hogy az alkalmazásnak ismerős, kiszámítható felületei és viselkedési mintái lesznek – feltéve, hogy az alkalmazás az összes útmutató szerint készült.

Egy többplatformos alkalmazás nem mindig sikerül maradéktalanul megfelelni mindkét platform útmutatóinak, és ez további nehézségeket okozhat a fejlesztő és a felhasználó számára. A legegyszerűbb példa- a "Vissza" gomb helyzete: Androidban szinte minden képernyőn jelen van, míg iOS-ben nincs. Ha e gomb nélkül készít többplatformos alkalmazást, néhány Android-felhasználó kellemetlen érzést tapasztalhat.

Érdemes megemlíteni a fejlesztési költségek különbségeit is. Ha a projekt egyszerű, akkor a többplatformos fejlesztés választása lehetővé teszi a költségvetés megtakarítását, mivel valójában nem külön termékeket fejleszt a különböző platformokhoz, hanem egyet mindenkinek. De ha a projekt növekszik, akkor a mérleg más irányba billen, és a natív fejlesztés jövedelmezőbb lehet.

Ami az alkalmazások sebességét illeti, a többplatformos termékek lassabbak. Például a webes technológiára épülők rétegként böngészőt tartalmaznak, ami jelentősen lelassítja az alkalmazást.

Frissítés Downgrade

A többplatformos vagy natív megközelítés kiválasztása valójában két tényezőtől függ: az Ön által személyesen megvalósítani kívánt mobilfejlesztés természetétől, vagy azon munkáltatók kérésétől, akiknél szeretne dolgozni. Így például, ha megnézzük az Upwork-et (a projektekhez és feladatokhoz távoli szakemberek keresésének platformja), akkor egyértelmű ajánlatok túlsúlyát láthatjuk a Xamarin és a React Native irányába. Az előnyök itt nyilvánvalóak: olcsó, gyors, és lehetővé teszi a projektek végrehajtását minden platformon egyszerre. Ha azonban a nagy informatikai cégeket tekintjük házon belüli munkaerő-kereséssel, akkor jelentős hangsúlyt kap a natív fejlesztés, annak ellenére, hogy ez a típus több időt igényel és drágább is.

Cégünknél előnyben részesítjük és a natív fejlesztést választjuk, mert ez lehetővé teszi a tervezők és a fejlesztők számára, hogy gördülékenyebb, intuitívabb UX/UI-t hozzanak létre. Ezenkívül a natív fejlesztés rugalmasabb szabályozást tesz lehetővé a rendszerfunkciók felett.

Frissítés Downgrade

Ha mobilfejlesztő akarsz lenni, akkor a válasz kézenfekvő: bármelyik natív fejlesztői környezetet választanod kell, és az Objective-C/Swift-re kell támaszkodnod iOS-re vagy a Java/Kotlin-re Androidra. Ebben az esetben a rendszer minden funkciója az Ön szolgálatában áll, szinte minden árnyalatot irányíthat.

Ha csak olyan programot akarsz írni, ami telefonokon is működik, akkor nem sokat gondolkodhatsz, és választhatod, hogy miben van inkább a lelked, vagy miben van jelentős tapasztalatod: C ++, React Native, Xamarin vagy ötszázezer JS keretrendszerek többplatformos fejlesztéshez. Vagy akár továbbra is saját [reszponzív] webhelyeket készíthet.

Hogy őszinte legyek, meglehetősen szkeptikus vagyok a platformok közötti fejlesztés olyan különböző (és eltérő) platformokon, mint az Android és az iOS. Egyik eladó sem szereti a "rossz" fejlesztőket, akik egyszerre két széken próbálnak ülni. Mindenki igyekszik eszközökhöz és környezetekhez kötni a programozókat, és belátható időn belül nincs tendencia a konvergálásra. Mit mondjak, az Apple ebben a versenyben még az OpenGL-t is elhagyta, a Curl után a legtöbb könyvtárat keresztező platformot, de most megvan a saját Metaljuk, amely úgy tűnik, ugyanazt csinálja, csak jobban és más nyelven.

Másrészt a mobilfejlesztés nagyon gyakran két olyan alkalmazás létrehozása, amelyek egyformán néznek ki valamilyen hálózati szolgáltatásnál. A vásárlók nem mindig készek fizetni két teljesen megkülönböztethetetlennek tűnő termékért, így a platformok közötti fejlesztési technológiák iránt létezik, és valljuk be, meglehetősen nagy az igény. A programozók sem idegenkednek a spórolástól, különösen, ha mobilalkalmazást szeretnének eladni, nincs vágy a Swift / Kotlin megtanulására, de a JS / C # már karnyújtásnyira van.

Természetesen a platformok közötti fejlesztés sok nem nyilvánvaló árnyalatot hoz magával. Minden univerzális megoldás kénytelen homokvárat építeni: akár összetett, akár törékeny technológiai megoldások(mint a Xamarin), vagy mobilon JavaScript motorok mint a React Native. Ugyanakkor a platformgyártók nem is gondolnak arra, hogy támogassák valamelyik megoldást, és a natív SDK minden egyes frissítése nagy fejtörést okoz minden platformközi keretrendszernek. Nem is beszélve az olyan rendszerspecifikus funkciókról, mint a kamera elérése, kulcstartó vagy akár egy banális fotógaléria, amit mindenki igyekszik megkerülni kisebb-nagyobb sikerrel. Az univerzális utat választó fejlesztőket a keretük túszul ejti, és gyakran a jelentős megtakarítással kecsegtetett fejlesztés egy gereblye elleni harcba csap át.

Szintén gyakran a cross-platform megoldásokban szokás feláldozni azt, amit a felhasználói élmény (UX) kifejezéssel jelölnek: sok keretrendszer igyekszik mindkét rendszer számára a lehető legáltalánosabb vezérlőket használni, és ez a megoldás szinte mindig mindenki számára egyformán kényelmetlen. . Vagy lassíts. Vagy divatból. Vagy lemeríti az akkumulátort. Folytassa a listát maga.

Különböző platformokon átívelő alkalmazások állnak fenn, amelyek kerneljei alacsony szinten vannak megírva, a legelterjedtebb minden operációs rendszerben: olyan nyelveken, mint a C/C++. Ilyenkor az üzleti logikát kiszolgáló kódhasználatot szokás általánosítani, és platformonként külön írják meg a felületet. Ideális esetben elkerülhető az alkalmazás kritikus részének duplikálása, miközben megőrizhető az egyes platformokra jellemző felhasználói élmény. A való életben azonban a dolgok bonyolultabbak. A Dropbox például több egymást követő évben próbált élni egy alacsony szintű maggal, de végül sok okból feladta, és most elégedett a natív platformalkalmazásokkal. Az érdeklődőket a témával kapcsolatos érdekes cikkükre ajánlom.

Véleményem szerint a többplatformos keretrendszereken való megtakarítás mindig illuzórikus. Valószínűleg néhány triviális projektben, ahol az alkalmazás csak a fő webhely egy mobilra optimalizált verziója, az általános megközelítés működik. Más esetekben azt kockáztatja, hogy megismétli a Dropbox sorsát. Azt tanácsolom, hogy ha mobilfejlesztő szeretne lenni, fektessen be a platform tanulásába. Mindig megtérülnek, még akkor is, ha több platformon keresztüli projektben kell részt vennie.

Frissítés Downgrade

, Vezető szoftverfejlesztő, Accenture Tver Technology Center

A mobilalkalmazások piaca aktívan fejlődik, és ennek megfelelően bővül a fejlesztésükhöz szükséges technológiák készlete. Jó néhány eszközt használhatsz.

Az Android platformon történő natív fejlesztéshez Java vagy egy burkoló található a JVM felett - Kotlin. iOS esetén használhatja az Objective-C-t vagy egy burkolót - a Swiftet. Ezek mind olyan OOP nyelvek, amelyek sokat örököltek a Smalltalktól és a C-től.

A platformok közötti fejlesztéshez mostantól a Google Flutter-jét használják, amelyhez ismernie kell a Dartot. Vagy React Native a Facebookról.

Egy kezdő mobilfejlesztő számára valószínűleg korábbi tapasztalata és nyelvtudása lesz a meghatározó. Ha a Java az eszköztárának alapja, akkor az Android platformon keresztül sokkal gyorsabban, ugyanazt a Java vagy Kotlin segítségével tudja majd megtanulni a mobilfejlesztés világát.

Ugyanakkor az Objective-C iOS-fejlesztéshez sokat vett át a Smalltalktól, valamint a Java-tól, így ha akarod, választhatsz az iOS mellett. De ne feledje, hogy az Android fejlesztés történhet Windowson vagy Linuxon, de az iOS-hez MacOS X szükséges. A Reactot ismerő JavaScript-fejlesztők számára azonban nyilvánvalóan a React Native a leggyorsabb módja. Csakúgy, mint a Dart fejlesztői számára, a választás a Flutter javára fog válni.

Miután egy kezdő fejlesztő képet kap arról, milyen a mobilfejlesztés, mik a választott út előnyei és hátrányai, maga dönti el, hogy valamelyik megközelítéssel dolgozik-e, vagy a problémákat többplatformos megoldásokkal oldja meg.

Ennek a megközelítésnek megvannak a maga előnyei: a többplatformos módszer lehetővé teszi, hogy egy projektet valamivel gyorsabban, kevesebb erőforrás felhasználásával produktív környezetbe engedjenek át. Ráadásul könnyebben karbantartható. De nyilvánvaló hátrányai is vannak mind a fejlesztő, mind a felhasználó számára. Például egy fejlesztőnek nem kell ismernie a natív technológiákat, de a platform irányelveit figyelembe kell venni, hiszen egy iOS irányelvek szerint írt alkalmazás nehézségeket okoz az Android felhasználóknak, és fordítva.

A többplatformos alkalmazások nem tudják elérni ugyanazt az eszközintegrációs szintet, mint a natív alkalmazások. Vagyis ha az alkalmazás egy eszközzel való interakcióról beszél, például kamerával, naptárral vagy használattal számítási teljesítmény eszközöket, natív megközelítéssel ezt könnyebb elérni, gyorsabb és termelékenyebb lesz.

A többplatformos alkalmazás fejlesztése során a szakemberek figyelembe veszik a keretrendszer képességeit, ami korlátozásokat támaszt. Érdemes megfontolni azt is, hogy egy termék natív technológiákon történő kifejlesztéséhez minden platformon szakemberre van szükség.

Ha szabadúszóként dolgozik, vagy az a cél, hogy a lehető legtöbb eszközt fedezze minimális forrásból, akkor összpontosítson a platformok közötti fejlesztésre, ha a mobil megoldások vagy front-end munka.

Melyek a mobil natív és a többplatformos fejlesztés fő előnyei és hátrányai? Maga a natív fejlesztés drága, mert a cégnek két csapatba – iOS-be és Androidba – kell beruháznia. Egyszerű alkalmazások esetén a Flutter / React Native fejlesztési sebesség gyorsabb.

De az a plusz, hogy az infrastruktúra már kialakult és érthető. Bármilyen eszközforráshoz hozzáférhet, és alatta fejleszthet okos óra, autók és egyebek.

A platformok közötti fejlesztés is klassz dolog. De még nem fejlett az oroszországi IT munkaerőpiacon. Értelmes szakemberek – számolj az ujjakon. A keretinfrastruktúra fiatal, de a helyzet fokozatosan javul. Ez a fejlesztés lehetővé teszi, hogy egyszerre több eszközre írjunk. Még ha például Flutterben ír is, könnyen integrálható a natív kóddal.

Frissítés Downgrade

A platformok közötti fejlesztés célja a gyors eredmény és a jelentős költségvetési megtakarítás – minden eszközhöz egy kódot írunk. Alkalmazási területei vagy a belső használatra szánt megoldás, ahol nem annyira fontos a termék használhatósága, és a funkcionalitás dominál, vagy egy gyors „pilot” projekt létrehozása, amikor a megrendelőnek meg kell mutatnia az elvet ill. a pályázat ötlete. Ezenkívül, ha nincs pontos megértés az eszközről, hogy a prototípusát melyik operációs rendszerrel fogják megnézni, akkor a platformok közötti fejlesztés a kiút. Azonban előre meg kell értenie, hogy minden eszköznek más az architektúrája, így fizikailag szinte lehetetlen jó minőségű alkalmazást végrehajtani egyetlen többplatformos kódon. Összetett forgatókönyvek esetén natív kódot kell írnia. Ráadásul a többplatformos fejlesztés sajátosságából adódóan olyan költségekkel jár, amelyek nem teszik lehetővé, hogy az alkalmazás a lehető leghatékonyabb legyen. Ez érthető is, ebben az esetben minden platformra le kell fordítani a közbenső cross-platform kódot, ami „nehezebbé” teszi az alkalmazást, mivel a funkcionális kódon kívül a végrehajtási környezetét is tartalmazza.

Mondj más véleményt

Minden világos, mutasd meg a következtetéseket

Tehát milyen fejlesztési megközelítést érdemes alkalmazni?

Minden a feladattól függ. Ha több platformra kell app prototípust írnia ill mobil verzió webhelyen áttekintheti a platformok közötti keretrendszereket. Valószínűleg gyorsabban írhat alkalmazásokat velük, mint a natív fejlesztéssel, különösen, ha a szokásos eszközéhez hasonló keretrendszeren dolgozik, mint például a React Native.

Másrészt a többplatformos alkalmazások egyetemességét valamilyen módon kompenzálni kell. Valahol egy „nem natív” interfész elem jelenik meg, hol rosszabb a rendszerrel való interakció, hol a munka sebessége lelassul stb. Annak ellenére, hogy a natív fejlesztés több erőforrást igényel, sok cég ezt preferálja, mert a kimeneten stabilabb és natívabb megjelenésű termék.

Ebben a tekintetben, ha most kezdi a mobilfejlesztést, akkor jobb, ha először natív fejlesztést végez. Ehhez több információt találhat az interneten, mélyebben megismerheti a platform képességeit, és nem zavarja a platformok közötti fejlesztés egyedi árnyalatai. Sőt, ha úgy döntesz, hogy a jövőben platformokon átívelő fejlesztést végzel, a megszerzett tudás biztosan nem zavarja majd.

Felhívjuk figyelmét, hogy kérdését felteheti a szakértőknek, mi pedig összegyűjtjük a választ, ha érdekesnek bizonyul. A már feltett kérdések a problémalistában találhatók. Ha szeretne csatlakozni a szakértők sorához, és választ szeretne küldeni cégétől vagy személyesen, akkor írjon a címre, elmondjuk, hogyan kell ezt megtenni.

A platformok közötti fejlesztés lehetővé teszi egy olyan mobilalkalmazás készítését, amely egyszerre működik iOS és Android környezetben. Ez egy költségvetési alternatívája annak, hogy minden operációs rendszerhez külön-külön hozzon létre alkalmazást.

A platformok közötti fejlesztés jellemzői

Egy alkalmazás fejlesztése különböző platformokra jó és rossz egyszerre. Nos, mert gyorsabban és olcsóbban is meg lehet csinálni, mint több alkalmazás minden operációs rendszerhez. Ez pedig rossz, mert a kompromisszum az alkalmazás működésében is megmutatkozik.

Ezeket a jellemzőket figyelembe kell venni a projekt megkezdése előtt:

  • Többplatformos környezetben a kód egyszer íródik. Ahhoz, hogy az alkalmazás más operációs rendszeren működjön, a kódot lefordítják egy másik programozási nyelvre. A fejlesztésre fordított idő és pénz másfélszer kevesebb.
  • Előfordulhat, hogy az alkalmazások nem működnek megfelelően. A platformok közötti fejlesztés során lehetetlen figyelembe venni az egyes operációs rendszerek architektúrájával való munka minden árnyalatát, így az alkalmazások lassabban futhatnak, mint a kifejezetten iOS-re vagy Androidra tervezett alkalmazások.
  • Az elemek interfész- és tervezési követelményei operációs rendszerenként eltérőek.. Például iOS-en nincs vissza gomb, mint az Androidon. Az egységes dizájn kialakításánál ezt a szempontot kell figyelembe venni: iOS-ben a gomb vagy megmarad, de nem fog működni, vagy manuálisan kell kivágni, ez pedig további munka a kóddal.

Az egyik platformról a másikra való áttérés legtöbb hibát manuálisan javítanak ki, de lehetetlen teljesen megoldani a „nem natív” operációs rendszerhez való alkalmazkodás problémáit.

Tehát a platformok közötti fejlesztés rossz?

Nem, a platformok közötti fejlesztés mindaddig rendben van, amíg nem követel többet tőle, mint amennyit adni tud.

Ez az opció a következő esetekben választható:

  • Lefed minden operációs rendszert korlátozott költségvetéssel. Ha egy a célközönség ha aktívabban használja az iOS vagy az Android rendszert, egy operációs rendszerhez natív alkalmazással kezdheti. Ha azonnal fontos a maximális lefedettség, akkor jobb a többplatformos opciót választani.
  • Ellenőrizze a rést. Ha van egy ígéretes ötlet, de nem biztos, hogy működik, akkor kockázatos azonnal nagy költségvetést fektetni a fejlesztésbe. Érdemes a platformok közötti fejlesztéssel kezdeni, tanulmányozni a felhasználói reakciókat és ez alapján meghozni a stratégiai döntéseket.
  • Az alkalmazás nem használ összetett animációt és nem végez számításokat. Ezek a műveletek komolyan terhelik az eszközt, és a többplatformos alkalmazás nincs optimalizálva egy adott platform erőforrásainak teljes kihasználására.
  • Az alkalmazás csak az eszköz alapvető funkcióit használja. Információk megjelenítése, fájlok feltöltése, földrajzi helymeghatározás használata, rendelés leadása – mindezt egy többplatformos alkalmazás képes kezelni. Az eszköz képességeinek mélyebb integrálására van szükség – a natív fejlesztést kell választania.
  • Vállalati alkalmazás alkalmazottak számára. Ha az alkalmazást szűk belső feladatokra fejlesztik, és az emberek személyes kütyükön keresztül dolgoznak vele, akkor a többplatformos alkalmazás a legjobb megoldás.

Nincs univerzális válasz arra a kérdésre, hogy lehetséges-e cross-platform megoldásokat használni projektjéhez. Töltse ki az alábbi űrlapot: megvizsgáljuk projektjét, és kiválasztjuk a legmegfelelőbb lehetőséget a megvalósításhoz.