Բջջային հավելվածների բազմպլատֆորմային մշակում: Միջպլատֆորմային զարգացում. կողմ, թե դեմ: Ցածր գործառնական ծախսեր

Թվում է, թե մենք ունենք միջպլատֆորմային զարգացում, որը հնարավորություն է տալիս ստեղծել ունիվերսալ հավելվածներ տարբեր հարթակների համար։ Ես դիմումն ավելի արագ գրեցի, անմիջապես թողարկեցի այն ամենուր՝ շահույթ: Իսկ հայրենի զարգացում պետք չէ։ Կամ դեռ անհրաժեշտ է: Զարգացման երկու մոտեցումների նրբությունների մասին բջջային հավելվածներհարցրինք մեր փորձագետներին.

«Բջջային ծրագրավորողը» լայն հասկացություն է: Մշակողը, որն իրականացնում է բջջային սարքերի մասեր օպերացիոն համակարգ, նաև բջջային ծրագրավորող է։ Եվ եթե նպատակը հենց այդպիսի ծրագրավորող դառնալն է, ապա պետք է սկսել C++, բջջային օպերացիոն համակարգ և սարքաշար սովորելուց։ շարժական սարքեր.

Եթե ​​դուք նկատի ունեք մաքսային բջջային հավելվածներ իրականացնող ծրագրավորող, ապա դուք պետք է սկսեք հայրենի մշակումից:

Ինչո՞ւ է սա այդպես։ Մայրենի մշակումը թույլ է տալիս ավելի լավ և խորը ուսումնասիրել կոնկրետ օպերացիոն համակարգերի (և դրանց համար նախատեսված հավելվածների) և շարժական սարքավորումների հնարավորությունները:

Օգտատիրոջ տեսակետից միանշանակ հաղթում է հայրենի զարգացումը։ Բնական հավելվածներն ավելի արագ են աշխատում, դրանց ինտերֆեյսը ավելի արձագանքող է և ավելի ծանոթ բջջային օպերացիոն համակարգի օգտատերերին, նրանք ավելի լավ են օգտագործում սարքի ապարատային հնարավորությունները, ավելի լավ են աշխատում անցանց ռեժիմում և ավելի քիչ խելագարված են:

Միջպլատֆորմի զարգացման սկզբնական գաղափարը ծրագրավորողների աշխատուժի ծախսերի կրճատումն է: Կարելի է հակիրճ արտահայտվել այսպես. «Կատարված է մեկ անգամ, աշխատում է ամեն ինչի վրա»: Գաղափարը լավն է ու ճիշտ (ծրագրավորողի տեսանկյունից), բայց կան որակի խնդիրներ։ Ցանկացած բազմակողմանիություն ի սկզբանե պայմանավորված է փոխզիջումով, և բջջային զարգացման ոլորտը բացառություն չէ:

Երբ ընտրում է մշակման տեսակը կոնկրետ առաջադրանքի համար, մշակողը պետք է գնահատի, թե որքանով է ընդունելի այս փոխզիջումը: Կան մի շարք առաջադրանքներ, որտեղ միջպլատֆորմի մշակման օգտագործումը միանգամայն արդարացված կլինի, օրինակ՝ թեստային նախագծերում, վեբկայքերի բջջային տարբերակներում, Unity 3D-ի նման շրջանակներ օգտագործող խաղերում:

Միևնույն ժամանակ, բջջային բիզնեսի խնդիրներ լուծող նախագծերի համար (մեծ բեռով, երկարաժամկետ զարգացմանն ուղղված անցանց ռեժիմին աջակցելու անհրաժեշտություն), հայրենի զարգացումը թվում է միակ օպտիմալը (և որոշ խնդիրների համար՝ միակ հնարավորը): ) տարբերակ.

Միևնույն ժամանակ, հայրենի զարգացման հիմնական թերությունները զարգացման ժամանակն են (ավելի շատ է պահանջվում) և բազմազան ռեսուրսների անհրաժեշտությունը (ծրագրավորման տարբեր մայրենի լեզուներով մշակողներ): Այս թերությունները մեղմելու եղանակներ կան. օրինակ՝ մշակելու համար օգտագործեք բջջային հավելվածների ինչ-որ պլատֆորմ (MEAP դաս), որը թույլ է տալիս ստեղծել բնիկ հավելվածներ:

Խթանել իջեցնել

, «ID - Management Technologies» ՏՏ ընկերության տեխնոլոգիական զարգացման գծով տնօրեն

Ցանկացած միջպլատֆորմային գրադարան կամ շրջանակ հիմնված է նույն բնիկ մեխանիզմների վրա, որոնց վրա ուղղակիորեն իրականացվում է հայրենի զարգացումը: Պարզապես միջպլատֆորմային լուծումների դեպքում աշխատանքային գործընթացները կառուցված են այնպես, որ «հարթեն անկյունները»՝ վերջնական լուծման միջերեսը որոշակի ընդհանուր հայտարարի հասցնելու առումով։

Որպես կանոն, ունիվերսալիզմը միշտ չէ, որ պատասխանն է աշխատող բջջային լուծում ստեղծելու խնդրին. մշակողը ավելի լավ է աշխատում, այնքան լավ է հասկանում տարբեր գործընթացների մեխանիզմները ներսից, ինչպես ասում են՝ «կապակի տակից»:

Նաև բավականին աշխատանքային մոդելԿլինի երկու մոտեցումների հիմնական տարրերի միաժամանակյա տիրապետում, նախնական փուլում նման ուսուցման առաջադրանքում անհնարին բան չկա. Օրինակ, նման սցենարը կարող է բավականին իրագործելի և խոստումնալից լինել. սկսել աշխատել միջպլատֆորմային պարադիգմում և միևնույն ժամանակ, ինքնուրույն կամ գործընկերների օգնությամբ ուսումնասիրել, թե ինչ հնարավորություններ կան ներկայիս լուծումներ մշակելու համար և ինչպես: դրանք կարող են կիրառվել գործնականում:

Այս դեպքում ավելի հեշտ է հասնել համապարփակ ըմբռնման, թե ինչպես է սկզբունքորեն աշխատում բջջային ծրագրավորման գործընթացը, որը կոչվում է «end-to-end»: Սա նաև օգտակար է, քանի որ ցանկացած, նույնիսկ ամենաառաջադեմ, ունիվերսալ պլատֆորմը իր հնարավորություններով զիջում է հայրենի հարթակին. ապարատային և շարժական ՕՀ արտադրողները հաճախ աշխատում են միասին և անընդհատ մեծացնում են վերջնական լուծումների հնարավորությունները՝ բջջային զարգացման հարթակների, հատկապես խաչաձև: - հարթակային լուծումները, անխուսափելիորեն հետ են մնում .

Շուկայում անընդհատ հայտնվում են նոր ապրանքներ շարժական սարքերի սեգմենտի մեջ, որոնցից ոմանք զգալիորեն առաջ են իրենց ժամանակից. վերցրեք Samsung-ը և նրա կողմից ճկվող էկրանով սարքի մշակումը. ակնհայտ է, որ արմատապես տարբեր ճակատի պատճառով , զարգացման գոյություն ունեցող հարթակները պատրաստ չեն նման բաների։

Այստեղ է, որ օգտակար է բնիկ հարթակների խորը գիտելիքները. միայն բջջային զարգացման խորը համակարգային իմացություն ունեցող ծրագրավորողը կարող է փոխհատուցել ապարատային և ՕՀ-ի բնական ետ մնալը: Միայն այդպիսի մասնագետը կկարողանա մեծացնել իր լուծման ֆունկցիոնալությունը նորագույն շարժական սարքերի համար՝ հիմնվելով ներկայումս հասանելի ոչ ամբողջովին զարգացած զարգացման հարթակների վրա:

Միջպլատֆորմային զարգացումը հիանալի է նախատիպերի համար, արագ փորձարկումգաղափարներ և այլն: Հենց որ խոսքը գնում է իսկապես հիմնարար արտադրանք ստեղծելու մասին, ծրագրավորողն անխուսափելիորեն գալիս է գործընթացի հիմնական տարրերի, այսինքն՝ հայրենի զարգացման խորը ուսումնասիրության անհրաժեշտության:

Խթանել իջեցնել

, GeekUniversity, GeekBrains կրթական պորտալի iOS-ի զարգացման ֆակուլտետի դեկան

Կարճ պատասխան․ եթե ծրագրավորման փորձ չունեք, ապա, իհարկե, պետք է ընտրել հայրենի մշակումը։ Կրոսպլատֆորմային զարգացումը լավ է այն մասնագետների համար, ովքեր հարակից ոլորտներից շարժվում են դեպի բջջային ծրագրավորում: Օրինակ, եթե դուք Frontend-ի ծրագրավորող եք՝ JavaScript-ի լավ իմացությամբ, օգտագործելով React Native շրջանակը (կառուցված է React շրջանակի վերևում), կարող եք արագ և առանց ցավի փորձել տիրապետել բջջային ծրագրավորմանը: Նմանապես, .NET ծրագրավորողի համար ավելի հեշտ կլինի տիրապետել Xamarin Framework-ին:

Կրոսպլատֆորմների մշակումը նույնպես շահավետ է հաճախորդի համար. ավելի հեշտ է գտնել մշակողների մեկ թիմ, որը, ընդհանուր մոդելի համաձայն, կմշակի հավելված միանգամից երկու հարթակների համար:

Առավելությունները ակնհայտ են, բայց որո՞նք են բազմահարթակ զարգացման թերությունները: Ենթադրվում է, որ որքան ավելի բարդ և նուրբ է բջջային հավելվածի ֆունկցիոնալությունը, այնքան ավելի դժվար է, եթե ոչ անհնար, այն իրականացնել միջպլատֆորմային գործիքների միջոցով. դա հաճախ գերազանցում է ունիվերսալ գործիքների բոլոր առավելությունները: Իմ փորձով կան մի քանի խոշոր ընկերություններ, որոնք իրենց կիրառման աճով ստիպված եղան հրաժարվել խաչմերուկից՝ հօգուտ հայրենի զարգացման։ Այսպիսով, փոքր նախագծերի և, հնարավոր է, ֆրիլանս առաջադրանքների համար ընդհանուր լուծումները բավարար են, իսկ մեծ նախագծերի համար ավելի հարմար են բնիկները։

Երկու ոլորտների պահանջարկը բավականին մեծ է, բայց հայրենի զարգացման համար որոշ չափով ավելի բարձր է. Ռուսաստանում hh.ru-ում Swift-ի խնդրանքով՝ 369 թափուր աշխատատեղ, Կոտլին՝ 397, React Native՝ 111, Flutter՝ 13 Xamarin՝ 18: Բայց վստահ եղեք: , լավ մասնագետ Ոչ մի ոլորտում աշխատանք չի մնա.

Խթանել իջեցնել

Սկզբից կարևոր է նշել, որ ցանկացած բջջային հավելված բաղկացած է մի քանի շերտերից.

• UI-ն այն է, ինչ տեսնում է օգտվողը;
• բիզնես տրամաբանությունն այն է, ինչի համար գրված է դիմումը;
• հարթակի այլ բաղադրիչներ - աշխատել ցանցի, տվյալների բազաների և համակարգի այլ բաղադրիչների հետ, որոնք օգտագործվում են բիզնես տրամաբանությամբ:

Կախված կոնկրետ կիրառությունից, այս շերտերի բաղադրիչների չափերը կարող են շատ տարբեր լինել: Օրինակ, վեբկայքում նորություններ կարդալու հավելվածը շատ տարբեր կլինի VPN հաճախորդից:

Զարգացումը ինքնին կարելի է բաժանել երեք տեսակի՝ բնիկ, լիովին խաչմերուկային և հիբրիդային:

Մայրենի զարգացում

Մայրենի զարգացման մեջ բոլոր երեք շերտերը գրվում են գործիքների նույն հավաքածուի միջոցով: Հետեւաբար, նրանք կարող են փոխազդել միմյանց հետ առանց լրացուցիչ բարդության:

Մայրենի զարգացման առավելությունները.

Հիբրիդային զարգացում

Զարգացման այս տեսակը համատեղում է նախորդ երկու մոտեցումները: Բիզնեսի տրամաբանական շերտը կառուցված է որպես «շարժական» բաղադրիչ, իսկ UI-ի և հարթակի ինտեգրումը ստեղծվում է ստանդարտ գործիքների միջոցով: Ընդհանուր տրամաբանությունը գրելու համար կան մի քանի լեզուներ՝ 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 հարթակ JVM-ի վրա կա Java կամ փաթաթան՝ Կոտլին: iOS-ի համար կարող եք օգտագործել Objective-C կամ դրա փաթաթան՝ Swift: Սրանք բոլորը OOP լեզուներ են, որոնք շատ բան են ժառանգել Smalltalk-ից և C-ից:

Կրոսպլատֆորմների զարգացման համար նրանք ներկայումս օգտագործում են Google-ի Flutter-ը, որի համար դուք պետք է իմանաք Dart-ը: Կամ React Native-ից Facebook-ից:

Սկսնակ բջջային ծրագրավորողի համար որոշիչ գործոնը, ամենայն հավանականությամբ, կլինի նրա անցյալի փորձը և լեզուների իմացությունը: Եթե ​​նրա գործիքակազմը հիմնված է Java-ի վրա, նա կկարողանա շատ ավելի արագ ուսումնասիրել բջջային զարգացման աշխարհը Android հարթակի միջոցով՝ օգտագործելով նույն Java-ն կամ Kotlin-ը:

Միևնույն ժամանակ, Objective-C-ը iOS-ի մշակման համար Smalltalk-ից շատ բան է վերցրել, ինչպես Java-ն, այնպես որ ցանկության դեպքում կարող եք ընտրություն կատարել հօգուտ iOS-ի։ Բայց արժե հաշվի առնել, որ Android-ի մշակումը կարող է իրականացվել Windows-ի կամ Linux-ի վրա, սակայն iOS-ը պահանջում է MacOS X: Բայց React-ի իմացությամբ JavaScript մշակողի համար React Native-ն ակնհայտորեն ամենաարագ ճանապարհն է: Ինչպես Dart-ի մշակողների համար, այնպես էլ ընտրությունը կլինի Flutter-ի օգտին։

Այն բանից հետո, երբ սկսնակ ծրագրավորողը պատկերացում կազմի, թե ինչ է բջջային զարգացումը և որոնք են ընտրված ուղու դրական և բացասական կողմերը, նա ինքնուրույն կորոշի՝ աշխատել մեկ մոտեցմամբ, թե լուծել խնդիրները՝ օգտագործելով միջպլատֆորմային լուծումներ:

Այս մոտեցումն ունի իր առավելությունները. միջպլատֆորմային մեթոդը հնարավորություն է տալիս մի փոքր ավելի արագ թողարկել նախագիծը արդյունավետ միջավայր՝ օգտագործելով ավելի քիչ ռեսուրսներ: Բացի այդ, այն ավելի հեշտ է պահպանել: Բայց դա նաև ակնհայտ թերություններ ունի ինչպես մշակողի, այնպես էլ օգտագործողի համար: Օրինակ, մշակողը կարիք չունի իմանալու բնիկ տեխնոլոգիաները, սակայն պետք է հաշվի առնել պլատֆորմի ուղեցույցները, քանի որ iOS-ի ուղեցույցների համաձայն գրված հավելվածը դժվարություններ կառաջացնի։ Android օգտագործողներև հակառակը։

Միջպլատֆորմային հավելվածները չեն կարող հասնել սարքի ինտեգրման նույն մակարդակին, ինչ բնիկները: Այսինքն, եթե հավելվածը սարքի հետ շփվելու մասին է, օրինակ՝ տեսախցիկի, օրացույցի կամ սարքի հաշվողական հզորության օգտագործման մասին, ապա դրան ավելի հեշտ է հասնել բնիկ մոտեցման միջոցով, և դա կլինի ավելի արագ և ավելի։ արդյունավետ.

Կրոսպլատֆորմային հավելված մշակելիս մասնագետները հաշվի են առնում շրջանակի հնարավորությունները, որը սահմանափակումներ է դնում։ Արժե նաև հաշվի առնել, որ հայրենական տեխնոլոգիաների կիրառմամբ արտադրանք մշակելու համար յուրաքանչյուր հարթակի համար անհրաժեշտ են մասնագետներ։

Եթե ​​դուք աշխատում եք որպես ֆրիլանսեր կամ նպատակ ունեք ծածկել առավելագույն թվով սարքեր նվազագույն ռեսուրսներով, կենտրոնացեք միջպլատֆորմային զարգացման վրա, եթե կենտրոնանում եք բջջային լուծումների վրա կամ աշխատում եք որպես առաջնային ծրագրավորող:

Որո՞նք են բջջային բնիկ և միջպլատֆորմային զարգացման հիմնական առավելություններն ու թերությունները: Բնական զարգացումն ինքնին թանկ է, քանի որ ընկերությունը պետք է ներդրումներ կատարի երկու թիմերում՝ iOS և Android: Համար պարզ հավելվածներ, Flutter / React Native-ի զարգացման արագությունն ավելի բարձր է։

Բայց պլյուսն այն է, որ ենթակառուցվածքն արդեն ձեւավորված է ու հասկանալի։ Դուք մուտք եք ստանում սարքի ցանկացած ռեսուրս և կարող եք զարգանալ տակ խելացի ժամացույց, մեքենաներ և այլն:

Cross-platform զարգացումը նույնպես հիանալի բան է: Բայց Ռուսաստանում ՏՏ աշխատաշուկայում այն ​​դեռ այնքան էլ զարգացած չէ։ Դուք կարող եք մատների վրա հաշվել խելացի մասնագետներին։ Շրջանակային ենթակառուցվածքը երիտասարդ է, բայց իրավիճակը աստիճանաբար փոխվում է դեպի լավը։ Այս զարգացումը հնարավորություն է տալիս գրել միանգամից մի քանի սարքերի համար։ Նույնիսկ եթե դուք գրում եք Flutter-ով, օրինակ, այն հեշտությամբ ինտեգրվում է հայրենի կոդի հետ:

Խթանել իջեցնել

Կրոսպլատֆորմների մշակումն ուղղված է արագ արդյունքների և բյուջեի զգալի խնայողությանը՝ մենք գրում ենք մեկ կոդ բոլոր սարքերի համար: Դրա կիրառման շրջանակը կա՛մ լուծում է ներքին օգտագործման համար, որտեղ ապրանքի օգտագործելիությունն այնքան էլ կարևոր չէ, և ֆունկցիոնալությունը գերիշխող դեր է խաղում, կա՛մ արագ «պիլոտային» նախագծի ստեղծում, երբ հաճախորդը պետք է ցույց տա սկզբունքը կամ հայտի գաղափարը։ Բացի այդ, եթե չկա ճշգրիտ պատկերացում սարքի մասին, թե որ օպերացիոն համակարգով կդիտվի ձեր նախատիպը, ելքը միջպլատֆորմային մշակումն է: Այնուամենայնիվ, դուք պետք է նախօրոք հասկանաք, որ բոլոր սարքերն ունեն տարբեր ճարտարապետություն, ուստի ֆիզիկապես գրեթե անհնար է բարձրորակ հավելված գործարկել միայն միջպլատֆորմային կոդով: Բարդ սցենարները կպահանջեն գրել հայրենի կոդը: Բացի այդ, իր հատուկ բնույթի պատճառով, միջպլատֆորմային մշակումը կրում է ծախսեր, որոնք թույլ չեն տալիս հավելվածին հնարավորինս արդյունավետ լինել: Սա հասկանալի է, ներս այս դեպքումմիջանկյալ միջպլատֆորմային ծածկագիրը պետք է թարգմանվի յուրաքանչյուր հարթակի համար, ինչն ավելի «ծանր» է դարձնում հավելվածը, քանի որ բացի ֆունկցիոնալ կոդից այն պարունակում է իր կատարողական միջավայրը:

Մեկ այլ կարծիք տվեք

Ամեն ինչ պարզ է, ցույց տվեք ձեր եզրակացությունները

Այսպիսով, զարգացման ո՞ր մոտեցումը պետք է որդեգրեք:

Ամեն ինչ կախված է առաջադրանքից: Եթե ​​Ձեզ անհրաժեշտ է գրել հավելվածի նախատիպ մի քանի հարթակների համար կամ բջջային տարբերակկայք, ապա կարող եք նայել դեպի խաչմերուկային հարթակներ: Նրանց օգնությամբ դուք, ամենայն հավանականությամբ, հավելված կգրեք ավելի արագ, քան հայրենի մշակման դեպքում, հատկապես, եթե աշխատում եք ձեր սովորական գործիքի նման շրջանակի վրա, ինչպիսին է React Native-ը:

Մյուս կողմից, միջպլատֆորմային հավելվածների բազմակողմանիությունը պետք է փոխհատուցվի ինչ-որ բանով: Ինչ-որ տեղ հայտնվում է «ոչ բնիկ» ինտերֆեյսի տարր, ինչ-որ տեղ համակարգի հետ փոխազդեցությունն ավելի վատ է, ինչ-որ տեղ աշխատանքի արագությունը նվազում է և այլն: Չնայած այն հանգամանքին, որ հայրենի զարգացումը պահանջում է ավելի շատ ռեսուրսներ, շատ ընկերություններ նախընտրում են դա, քանի որ արդյունքն ավելի շատ է: կայուն և բնիկ տեսք ունեցող արտադրանք:

Այս առումով, եթե դուք նոր եք սկսում բջջային զարգացում, ապա ավելի լավ կլիներ նախ հայրենի զարգացում անել։ Դրա մասին ավելի շատ տեղեկատվություն կարող եք գտնել ինտերնետում, ավելի խորը պատկերացում կունենաք հարթակի հնարավորությունների մասին և ձեզ չեն խանգարի միջպլատֆորմային զարգացման որոշ նրբերանգներ: Ավելին, եթե դուք որոշեք ապագայում զբաղվել միջպլատֆորմային մշակմամբ, ապա ստացած գիտելիքները ձեզ հաստատ չեն տուժի։

Հիշեցնում ենք, որ ձեր հարցը կարող եք ուղղել մասնագետներին, և մենք կհավաքենք դրա պատասխանները, եթե այն հետաքրքիր լինի։ Հարցեր, որոնք արդեն տրվել են, կարելի է գտնել խնդիրների ցանկում: Եթե ​​ցանկանում եք միանալ փորձագետների շարքին և պատասխան ուղարկել ձեր ընկերությունից կամ ինքներդ, ապա գրեք, մենք ձեզ կասենք, թե ինչպես դա անել:

Կրոսպլատֆորմների մշակումը թույլ է տալիս ստեղծել բջջային հավելված, որը միաժամանակ կգործի iOS-ում և Android-ում: Սա էժան այլընտրանք է յուրաքանչյուր օպերացիոն համակարգի համար առանձին հավելված ստեղծելու համար:

Միջպլատֆորմի զարգացման առանձնահատկությունները

Տարբեր հարթակների համար մեկ հավելված մշակելը լավ և վատ է միաժամանակ: Լավ է, քանի որ դա կարելի է անել ավելի արագ և էժան, քան մի քանի հավելված յուրաքանչյուր օպերացիոն համակարգի համար: Եվ դա վատ է, քանի որ փոխզիջումն ազդում է հավելվածի շահագործման վրա։

Նախագիծը սկսելուց առաջ պետք է հաշվի առնել հետևյալ հատկանիշները.

• Կրոսպլատֆորմային միջավայրում կոդը գրվում է մեկ անգամ. Հավելվածն այլ օպերացիոն համակարգի վրա աշխատելու համար կոդը թարգմանվում է ծրագրավորման այլ լեզվով։ Զարգացման վրա ծախսված ժամանակն ու գումարը 1,5 անգամ պակաս է։
• Հավելվածները կարող են ճիշտ չաշխատել:Կրոսպլատֆորմային մշակման ժամանակ անհնար է հաշվի առնել յուրաքանչյուր օպերացիոն համակարգի ճարտարապետության հետ աշխատելու բոլոր նրբությունները, ուստի հավելվածները կարող են ավելի դանդաղ աշխատել, քան հատուկ iOS-ի կամ Android-ի համար մշակվածները:
• Տարրերի ինտերֆեյսի և դիզայնի պահանջները տարբեր են օպերացիոն համակարգերի միջև:. Օրինակ, iOS-ը չունի Վերադառնալ կոճակ, ինչպես Android-ը: Միասնական դիզայն մշակելիս պետք է հաշվի առնել այս կետը՝ iOS-ում կոճակը կամ կմնա, բայց չի աշխատի, կամ պետք է ձեռքով կտրվի, ինչը նշանակում է լրացուցիչ աշխատանք կոդի հետ։

Մի հարթակից մյուսը տեղափոխելիս սխալների մեծ մասը կարող է լուծվել ձեռքով, սակայն անհնար է ամբողջությամբ լուծել «ոչ բնիկ» օպերացիոն համակարգին հարմարվելու խնդիրները:

Այսպիսով, միջպլատֆորմային զարգացումը վատ է:

Ոչ, միջպլատֆորմային զարգացումը լավ է, քանի դեռ դուք դրանից ավելին չեք պահանջում, քան դա կարող է տալ:

Այս տարբերակը կարող է ընտրվել հետևյալ դեպքերում.

• Ծածկեք բոլոր օպերացիոն համակարգերը սահմանափակ բյուջեով:Եթե ​​թիրախային լսարանը ակտիվորեն օգտվում է iOS-ից կամ Android-ից, կարող եք սկսել մեկ օպերացիոն համակարգի բնիկ հավելվածից: Եթե ​​առավելագույն ծածկույթը անմիջապես կարեւոր է, ապա ավելի լավ է ընտրել խաչաձեւ հարթակային տարբերակ:
• Ստուգեք տեղը. Եթե ​​կա խոստումնալից գաղափար, բայց վստահ չեք, որ այն կստացվի, զարգացման մեջ մեծ բյուջե անմիջապես ներդնելը ռիսկային է։ Իմաստ ունի սկսել միջպլատֆորմային զարգացումից, ուսումնասիրել օգտատերերի արձագանքները և դրա հիման վրա ռազմավարական որոշումներ կայացնել:
• Հավելվածը չի օգտագործում բարդ անիմացիաներ և չի կատարում հաշվարկներ։Այս գործողությունները լրջորեն բեռնում են սարքը, և միջպլատֆորմային հավելվածը օպտիմիզացված չէ որոշակի հարթակի ռեսուրսների լիարժեք օգտագործման համար:
• Հավելվածն օգտագործում է միայն սարքի հիմնական գործառույթները. Ցույց տալ տեղեկատվություն, վերբեռնել ֆայլեր, օգտագործել աշխարհագրական տեղաբաշխում, պատվիրել՝ խաչմերուկային հավելվածը կարող է կարգավորել այս ամենը: Սարքի հնարավորությունների ավելի խորը ինտեգրում է պահանջվում. դուք պետք է ընտրեք հայրենի մշակումը:
• Կորպորատիվ դիմում աշխատակիցների համար.Եթե ​​հավելվածը մշակված է ներքին նեղ խնդիրների համար, և մարդիկ դրա հետ կաշխատեն անձնական գաջեթների միջոցով, ապա լավագույն տարբերակը կլինի միջպլատֆորմային հավելվածը։

Չկա համընդհանուր պատասխան այն հարցին, թե արդյոք միջպլատֆորմային լուծումները կարող են օգտագործվել ձեր նախագծի համար: Լրացրեք ստորև ներկայացված ձևը. մենք կուսումնասիրենք ձեր նախագիծը և կընտրենք դրա իրականացման լավագույն տարբերակը:

Կրոսպլատֆորմային հավելվածներ՝ լինել, թե՞ չլինել: Հարցը հեշտ չէ, քանի որ յուրաքանչյուր բիզնես ունի իր նպատակներն ու պահանջները բջջային հավելվածների համար: Բայց այսօր մենք անպայման կպարզենք, թե որ զարգացումն է ճիշտ ձեզ համար:

Որո՞նք են միջպլատֆորմային հավելվածները:

Cross-platform հավելվածները այն հավելվածներն են, որոնք մշակվում են և այնուհետև աշխատում են ինչպես Android-ի, այնպես էլ iOS-ի վրա: Զարգացման էությունն այն է աղբյուր կոդըՀավելվածը թարգմանված է բնիկ, այսինքն՝ հասկանալի կոնկրետ շարժական սարքի համար: Արդյունքում ծրագիրը կարող է փոխազդել իր վրա տեղադրված օպերացիոն համակարգի հետ։

Հիշեցնենք՝ հայրենի հավելվածները, ի տարբերություն քրոսպլատֆորմայինների, գրված են կոնկրետ ՕՀ-ի համար։

Միջպլատֆորմային զարգացման դրական կողմերը

• երկարաձգում օգտագործողների բազանհավելվածի միաժամանակ մի քանի խանութներում հայտնվելու պատճառով.
• Մեկ աղբյուրի կոդը վերացնում է յուրաքանչյուր հարթակի համար մի քանի մշակողների վարձելու անհրաժեշտությունը.
• Կրոսպլատֆորմային հավելվածի կոդերի բազայի 75%-ը կարող է կրկին օգտագործվել՝ այն հարմարեցնելով նոր նախագծերի համար:

Խաչաձեւ պլատֆորմի զարգացման թերությունները

1. Բջջային սարքից մեծ կախվածություն

Cross-platform հավելվածները սովորաբար չեն աշխատում անցանց: Հետևաբար, նրանց հնարավորությունները մեծապես կախված են այն բանից, որ օգտագործողը ունի կայուն ինտերնետ կապ: Օպերացիոն համակարգի տարբերակը և սարքի մոդելը նույնպես կարևոր են: Կրոսպլատֆորմային հավելվածը գրեթե երաշխավորված է նվազեցնելու մեկ կամ երկու տարուց ավելի հին սարքի աշխատանքը: Մինչդեռ հայրենի հավելվածը կայուն կաշխատի նույնիսկ հնացած որոնվածով հնացած գաջեթի վրա: Այսպիսով, եթե դուք չեք ցանկանում, որ ձեր հաճախորդները կարդան զայրացած ակնարկներ այն մասին, թե ինչպես է ձեր հավելվածը վերջապես «ավարտել» ինչ-որ մեկի սմարթֆոնը, ընտրեք հայրենի մշակումը:

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. Ի՞նչ արդյունքների եք ձգտում:

Թվային ռազմավարությունը նպատակների ցանկ է, որոնց ձեր ընկերությունը կարող է հասնել թվային գործիքների միջոցով: Վերջինիս ընտրությունը մեծապես կախված է այն առավելություններից, որոնք դուք ցանկանում եք ստանալ ի վերջո։

Կտրեք գործընթացը գաղափարից արդյունք կետ առ կետ՝ հաշվի առնելով առկա բոլոր ռեսուրսները: Բացահայտումները կարող են լինել ամենաանսպասելին։

Օրինակ, դուք կարող եք պարզել, որ չափազանց ծախսատար է ձեր ռեսպոնսիվ կայքը, որը բեռնված է առանձնահատկություններով և ինտերակտիվ տարրերով, վերածել միջպլատֆորմային հավելվածի, ինչպիսին ի սկզբանե ցանկանում էիք: Կամ վերջապես համոզվեք, որ բջջային կայքը միշտ կորցնում է բջջային հավելվածը, ճիշտ այնպես, ինչպես միջպլատֆորմային զարգացումը կորցնում է հայրենի զարգացմանը: Եվ պատճառների թվում դուք կգտնեք դրանք, որոնք մենք նկարագրեցինք վերևում:

Եզրակացություն՝ միջպլատֆորմային հավելվածը ձեռնտու է միայն մեկ դեպքում՝ դուք ստեղծում եք հավելվածի ցուցադրական տարբերակը՝ սահմանափակ ժամանակով, գումարով և բարձր մասնագիտացված մասնագետներով: Մնացած բոլոր դեպքերում հայրենի հավելվածը ձեզ բազմապատիկ ավելի առավելություններ կտա, քանի որ դա որակապես տարբեր մակարդակի զարգացում է։

Բջջային հավելվածները դարձել են մեր կյանքի անփոփոխ ուղեկիցը: Նրանց օգնությամբ մենք կարող ենք ոչ միայն զվարճանալ և պարզեցնել մեր կյանքը, առցանց գնումներ կատարել կամ պատվիրել որոշակի ծառայություններ, այլ նաև խթանել մեր բիզնեսը, ավելացնել հաճախորդների բազան և, հետևաբար, ավելացնել շահույթը: Եվ եթե ոչ ոք չի կարող կասկածել իր բիզնեսի համար հավելված ստեղծելու անհրաժեշտության վրա, ապա որոշ դժվարություններ կարող են առաջանալ բջջային հավելվածի տեսակի ընտրության հարցում։

Բջջային սարքերի բոլոր ժամանակակից հավելվածները կարելի է բաժանել բնիկ և խաչմերուկային, և այս երկու խմբերից յուրաքանչյուրն ունի իր սեփականը. ուժեղ կողմերը, և դրա թերությունները։

Մայրենի հավելվածներն այն հավելվածներն են, որոնք մշակվել են հատուկ պլատֆորմի համար՝ համապատասխան ծրագրավորման լեզվով: Այսպիսով, Android-ի համար հավելված ստեղծելիս օգտագործվում է Java, իսկ iOS հավելվածների համար՝ Objective-c կամ Swift։ Նման նախագծեր ստեղծելիս մասնագետները հաշվի են առնում հարթակների բոլոր առանձնահատկությունները՝ հատուկ ուշադրություն դարձնելով UI/UX դիզայնին, օպերացիոն համակարգերի մշակողների պահանջներին/առաջարկություններին, ինչպես նաև բջջային արդյունաբերության վերջին միտումներին։ Մեկ մասնագետ չի կարողանա լիովին տիրապետել վերը նշված բոլոր լեզուներին, հետևաբար, տարբեր հարթակների համար մեկ մայրենի արտադրանք մշակելու համար անհրաժեշտ է միանալ տարբեր մշակողներ, և դրանք լրացուցիչ ծախսեր են, և զարգացման ժամանակը տպավորիչ կլինի: Բայց միևնույն ժամանակ հավելվածները «կհարմարեցվեն» կոնկրետ հարթակին, մուտք կունենան սարքի ներքին ռեսուրսներն ու գործառույթները և կաշխատեն հնարավորինս արդյունավետ։

Չնայած հայրենի մշակումների առավելությունների զգալի ցանկին, հաճախորդները միշտ չէ, որ ցանկանում են ժամանակ և գումար ծախսել դրանց զարգացման վրա՝ ստեղծման գործընթացում ներգրավելով մի քանի մասնագետների: Լավագույն տարբերակըՆման դեպքերում օգտագործվում է միջպլատֆորմային մշակում, որը թույլ է տալիս ստեղծել հավելվածներ ցանկացած հարթակի համար՝ օգտագործելով ստանդարտ վեբ տեխնոլոգիաներ։ Այս դեպքում մշակումը կարող է իրականացնել մեկ անձ՝ HTML5-ի, JavaScript-ի և CSS3-ի հետ աշխատելու անհրաժեշտ գիտելիքներով և փորձով։ Cross-platform զարգացումները կարող են կազմվել .apk ֆայլի Android-ի համար և .ipa ֆայլի IOS-ի համար: Այսպիսով, մեկ մշակման հիման վրա դուք կարող եք երկու հավելված ստանալ հայտնի օպերացիոն համակարգերի համար՝ դրա վրա ծախսելով ավելի քիչ ժամանակ և գումար։ Այնուամենայնիվ, նման զարգացումներն ունեն նաև իրենց թերությունները, ուստի խիստ նպատակահարմար է յուրաքանչյուր կոնկրետ դեպքի մոտենալ առանձին և ընտրել ամենահարմար տարբերակը՝ բնիկ կամ միջպլատֆորմային զարգացում:

Հավելվածի հաճախորդի և սերվերի մասեր

Շատ լուրջ հավելվածներ ունեն իրենց հաճախորդի մասը, որը հաճախ կոչվում է frontend, իսկ սերվերի մաս՝ backend: Frontend-ը պատասխանատու է այն ամենի համար, ինչ տեսնում եք ձեր բջջային սարքի էկրանին, այսինքն՝ հավելվածի ողջ տեսողական ներկայացումը, ներառյալ պատուհանների, մենյուների, կոճակների, սլաքների և այլ տարրերի դիզայնը, չափը և գտնվելու վայրը: Frontend-ը նաև պատասխանատու է հավելվածի պատասխանի համար օգտատերերի որոշակի գործողությունների համար, որոնք ուղղված են հավելվածի տարբեր բաժիններ տեղափոխվելուն, նոր մենյու կանչելուն և այլն:

Backend-ը հավելվածի սերվերի մասն է և գտնվում է հեռավոր սերվերի վրա, որը կարող է տեղակայվել ցանկացած վայրում և կառավարվել՝ օգտագործելով լայն տեսականի ծրագրային ապահովում. Հաճախորդի և սերվերի մասերի փոխհարաբերություններն իրականացվում են API-ի (Application Programming Interface) շնորհիվ: Այլ կերպ ասած, API-ն մի տեսակ միջնորդ է frontend-ի և backend-ի միջև, որը հաճախորդի կողմից հարցումները փոխանցում է սերվեր՝ վերադարձնելով օգտվողին անհրաժեշտ տվյալները:

Frontend-ի զարգացում

Հավելվածի հաճախորդի մասը չափազանց կարևոր է, քանի որ հենց դրանով կզբաղվի օգտատերը, և հավելվածի աշխատանքի մասին նրա ընդհանուր պատկերացումը կախված կլինի ճակատային մասի հարմարավետությունից: Այն կարող է մշակվել կամ ձեռքով, բայց դրա համար անհրաժեշտ է լավ հասկանալ HTML5, CSS3 և java-script, կամ օգտագործել այսպես կոչված շրջանակներ։ Առաջին դեպքում հաճախ օգտագործվում է Apache Cordova-ի զարգացման միջավայրը, որը նաև հայտնի է որպես PhoneGap: Օգտագործելով այս միջավայրը, դուք կարող եք ստեղծել հավելվածներ ցանկացած հարթակի համար՝ օգտագործելով վեբ տեխնոլոգիաները, որոնք Cordova-ն վերածում է կոդի, որը հասկանալի է կոնկրետ հարթակի համար: Cordova-ն գործնականում անսահմանափակ հնարավորություններ է բացում վեբ մշակողների համար, ովքեր պարտադիր չէ, որ սովորեն Objective-C կամ Swift, Java կամ Kotlin՝ հատուկ օպերացիոն համակարգերի համար հավելվածներ ստեղծելու համար:

Չնայած Cordova-ն չունի UI-ի և տրամաբանության սահմանափակումներ, շրջանակներն առաջարկում են պատրաստի ձևանմուշ լուծումներ: Մի կողմից, սա զգալիորեն արագացնում և հեշտացնում է զարգացման գործընթացը, քանի որ մասնագետը կարող է օգտագործել պատրաստի կոճակներ, ցուցակներ, մուտքագրման դաշտեր, քարտեր և այլ UI տարրեր: Մյուս կողմից, մասնագետը կարող է օգտագործել միայն այն գործիքներն ու տարրերը, որոնք առկա են ընտրված շրջանակում: Դրանցից ամենահայտնին Ionic-ն է, որը թույլ է տալիս ստեղծել քրոսպլատֆորմային հավելվածներ յուրաքանչյուր ճաշակի համար: Այս շրջանակն ունի ստանդարտ տարրերի մեծ ներկառուցված հավաքածու, որոնք տեսողականորեն ընդօրինակում են հայրենի հավելվածները, սակայն անհրաժեշտության դեպքում դրանց դիզայնը կարող է փոխվել: Միևնույն ժամանակ, մշակողը կարող է միացնել բազմաթիվ լրացուցիչ պլագիններ, որոնք ընդլայնում են իոնային շրջանակի հնարավորությունները, և այս շրջանակի վրա ստեղծված նախագիծը կարող է գործարկվել անմիջապես բրաուզերի պատուհանում և գնահատել, թե ինչպես է ստեղծված հավելվածը տեսք և աշխատել առանց անհրաժեշտության: օգտագործել էմուլյատոր կամ տեղադրել այն սմարթֆոնի վրա:

Backend-ի զարգացում

Մինչ հաճախորդի կողմը կառավարվում է դիզայներների և մշակողների կողմից՝ HTML, CSS, JS և Framework-ների իմացությամբ, հետին պլանը մշակվում է այլ պրոֆիլի ծրագրավորողների կողմից: Կարող է օգտագործվել սերվերների կազմաձևման համար տարբեր լեզուներովծրագրավորում և գործիքներ, գլխավորն այն է, որ պատշաճ կերպով կազմաձևեն դրանց աշխատանքը և հարաբերությունները հաճախորդի մասի հետ: Այստեղ անհրաժեշտ է օգտագործել տվյալների բազայի կառավարման համապատասխան համակարգեր։ Սա կարող է լինել ավանդական MySQL-ը, Redis-ը, PostgreSQL-ը կամ որևէ այլ տվյալների բազա (օրինակ՝ MongoDB), որը հարմար է կոնկրետ նախագծի իրականացման համար, և որում լավ տեղյակ է հետին պլանի մշակողը: Հավելվածի սերվերային կողմը ստեղծելու համար մշակողները կարող են օգտագործել PHP, NodeJS, C#, Ruby, Python, Java և այլ ծրագրավորման լեզուներ։

KitApp բջջային ստուդիայի մասնագետները մոտենում են ճակատային և հետին մասերի մշակմանը համապարփակ և հնարավորինս պատասխանատու կերպով: Մեր մշակողները ձեզ համար կստեղծեն ցանկացած բարդության միջպլատֆորմային հավելված և կկենտրոնացնեն հնարավորինս արագ և արդյունավետ: Կապվեք մեզ հետ, և մեր մասնագետները անհապաղ խորհուրդ կտան ձեզ ձեր բոլոր հարցերի վերաբերյալ:

Բջջային հավելվածների շուկան ավելի քան տասը տարեկան է, սակայն այն դեռ արագ զարգանում է։ Ընկերությունների կողմից պահանջարկը մշտապես աճում է և այն դեռ զգալիորեն գերազանցում է առաջարկը, ինչը հանգեցնում է զարգացման արժեքի մշտական ​​աճի: Այս գործընթացի ծախսերը նվազեցնելու լուծումներից մեկը միջպլատֆորմային զարգացումն է, երբ նույն կոդը օգտագործվում է բոլոր հարթակներում:

Անցյալ անգամ մենք անդրադարձանք միջպլատֆորմային բջջային հավելվածների մշակմանը, և դրանից հետո շատ բան է փոխվել: Ժամանակն է նորից խոսել մեթոդների ու գործիքների մասին։

Եկեք նախ նորից անցնենք տերմինաբանությանը:

Հարազատներ

Եթե ​​ծրագրավորողները, հավելված գրելու գործընթացում, օգտագործում են ծրագրավորման լեզուն, որն ընդունվել է կոնկրետ հարթակի համար, լինի դա Objective-C և Swift iOS-ի համար, թե նման հավելվածը կկոչվի մայրենի (անգլերեն մայրենիից՝ բնիկ, բնական):

Մայրենի հավելվածների առավելությունները.

• արագություն և ինտերֆեյսի արձագանք: Հավելվածը ակնթարթորեն արձագանքում է սեղմումներին, գործնականում չկան ուշացումներ անիմացիայի, ոլորման, ստացման և տվյալների ելքի մեջ.
• պարզ և հեշտ հասանելիություն սարքի գործառույթներին և սենսորներին: Մշակողի համար գեոլոկացիայի հետ աշխատելը, push ծանուցումները, ֆոտոխցիկի, ձայնի, արագացուցիչի և այլ սենսորների միջոցով լուսանկարելն ու տեսանյութը վերցնելը խնդիր չէ.
• սմարթֆոնի գործառույթների հետ խորը աշխատելու ունակություն: Ինչպես նախորդ պարբերությունում, այնպիսի բաներ, ինչպիսիք են անիմացիաները, բարդ ինտերֆեյսերի ստեղծումը և նեյրոնային ցանցերի գործարկումը անմիջապես սարքերի վրա, իրականացվում են, գուցե ոչ պարզապես, այլ կանխատեսելի.
• . Բնական հավելվածները սովորաբար գործում են «հարթակի» ինտերֆեյսի տարրերով. ընտրացանկերը, նավիգացիան, ձևաթղթերը և դիզայնի բոլոր այլ տարրերը վերցված են օպերացիոն համակարգից և, հետևաբար, ծանոթ և հասկանալի են օգտագործողին:

Կա միայն մեկ թերություն՝ զարգացման և աջակցության բարձր արժեքը, այդ թվում այն ​​պատճառով, որ դուք պետք է գրեք ձեր սեփական կոդը յուրաքանչյուր հարթակի համար:

Բջջային հավելվածների շուկայի աճի հետ մեկտեղ ծրագրավորողները դարձել են ոչ միայն թանկ, այլև շատ թանկ, և տեղական զարգացումն այն չէ, ինչ յուրաքանչյուր բիզնեսի սեփականատեր կարող է իրեն թույլ տալ: Բայց բջջային հավելված չմշակելը կարող է ձեզ ավելի թանկ արժենալ ապագայում: Live Typing-ը կարող է օգնել ձեզ գումար խնայել. նկարագրեք ձեր գաղափարը և նշեք մոտավոր բյուջեն, որը ցանկանում եք հանդիպել, ում:

Եվ ոչ հարազատները

Կրոսպլատֆորմային հավելվածները գրվում են միանգամից մի քանի հարթակների համար մեկ լեզվով, բացի մայրենիից: Ինչպես կարող է աշխատել նման կոդը տարբեր սարքեր? Այստեղ նույնպես երկու մոտեցում կա.

Առաջինն այն է, որ հայտը հրապարակման պատրաստման փուլում այն ​​փոխակերպվում է բնիկի՝ հատուկ հարթակի համար՝ օգտագործելով տրանսփայլեր։ Փաստորեն, մի միջպլատֆորմային ծրագրավորման լեզու «թարգմանվում» է մյուսի:

Երկրորդն այն է, որ ստացված ծածկագրին ավելացվում է որոշակի փաթաթան, որն արդեն սարքի վրա աշխատելով, թռիչքի ժամանակ զանգերը թարգմանում է ոչ մայրենի կոդից հայրենի համակարգի գործառույթների:

Ենթադրվում է, որ այս կոդի մեծ մասը կարող է փոխանցվել հարթակների միջև. ակնհայտ է, որ, օրինակ, գնումներ կատարելու, ապրանքները զամբյուղում պահելու, տաքսիի համար երթուղի հաշվարկելու, մեսենջերում հաղորդագրություն գրելու տրամաբանությունը չի փոխվում։ կախված նրանից, թե հաճախորդն ունի Android կամ iOS: Մենք պարզապես պետք է կատարելագործենք UI-ն և UX-ը պլատֆորմների համար, բայց այժմ, որոշակի սահմաններում, նույնիսկ դա կարելի է համատեղել, օրինակ՝ համբուրգերի մենյուն ակտիվորեն օգտագործվում է ինչպես Android-ում, այնպես էլ iOS-ում: Այսպիսով, նույնիսկ ինտերֆեյսի մեջ ուղղումներ կատարելը, որպեսզի հավելվածը համապատասխանի ցանկալի հարթակի ոգուն և տառին, ցանկության, մշակման պահանջվող արագության և որակի խնդիր է:

Առավելությունները:

• արժեքը և զարգացման արագությունը: Քանի որ շատ ավելի քիչ կոդ պետք է գրվի, աշխատանքի արժեքը կրճատվում է.
• ընկերության ներքին ռեսուրսներն օգտագործելու ունակությունը. Ինչպես ավելի ուշ ցույց կտանք, միջպլատֆորմային հավելվածների մշակումը հաճախ կարող է իրականացվել ձեր գործող ծրագրավորողների կողմից:

Թերություններ.

• ոչ բնիկ ինտերֆեյս կամ, առնվազն, յուրաքանչյուր հարթակի ինտերֆեյսի հետ առանձին աշխատելու անհրաժեշտություն: Յուրաքանչյուր համակարգ ունի իր պահանջները տարրերի նախագծման համար, և երբեմն դրանք միմյանց բացառող են: Սա պետք է հաշվի առնել մշակման ընթացքում.
• բարդ գործառույթների իրականացման խնդիրներ կամ հնարավոր խնդիրներաշխատել նույնիսկ պարզ պրոցեդուրաներով՝ հենց մշակման շրջանակների սխալների պատճառով: Խաչաձև պլատֆորմային միջավայրը միայն համակարգային զանգերին և ինտերֆեյսներին ուղղված հարցումները թարգմանում է համակարգին հասկանալի ձևաչափի, և, հետևաբար, այս փուլում ինչպես հասկանալու դժվարությունները, այնպես էլ սխալները կարող են առաջանալ հենց շրջանակում.
• աշխատանքի արագությունը. Քանի որ միջպլատֆորմային միջավայրը կոդի վրա «վերնաշինություն» է (ոչ միշտ, բայց որոշակի իրավիճակներում), այն ունի իր սեփական ուշացումներն ու դադարները՝ օգտագործողի գործողությունների մշակման և արդյունքների ցուցադրման հարցում: Սա հատկապես նկատելի էր մի քանի տարի առաջ սմարթֆոնների վրա, որոնք այսօրվա համեմատ ավելի ցածր հզորությամբ ունեին, սակայն այժմ, շարժական սարքերի աշխատանքի արդյունավետության բարձրացմամբ, դա արդեն կարելի է անտեսել:

Ինչպես տեսնում եք, այս երկու մեթոդները գործնականում են հայելային պատկերմիմյանց. որ հայրենի հավելվածների մշակումն ունի առավելություններ, միջպլատֆորմային հավելվածների մշակումն ունի թերություններ և հակառակը:

Հանրաճանաչ հարթակներ և գործիքներ միջպլատֆորմային բջջային զարգացման համար

Ինչպես վերևում գրեցինք, կա երկու մոտեցում՝ կոդի վերածում մայրենիի հավաքման փուլում կամ ավելացնելով որոշակի փաթաթան, որը թարգմանում է զանգերը դեպի համակարգ և դեպի համակարգ:

Cordova-ն և PWA-ն երկու գործիքներ են, որոնք աշխատում են հենց փաթաթման գաղափարախոսության մեջ:

Կորդովան և HTML5

Կրոսպլատֆորմային ծրագրավորման ամենատարածված ոլորտներից մեկը, որը հաճախ հանրաճանաչորեն կոչվում է PhoneGap: Փաստորեն, ստեղծվում է բջջային կայք, որը «փաթաթված» է հարթակի փոքր կոդով, որը համակարգից զանգեր է փոխանցում հավելված և հետ:

Բոլոր թերություններն ու առավելություններն այստեղ ավելի պարզ են արտահայտված, քան որևէ այլ տեղ։ Դուք կարող եք օգտագործել վեբ ծրագրավորողներին (HTML, CSS և JavaScript որպես հիմնական տեխնոլոգիաներ) և ստեղծել հավելվածի առաջին տարբերակը մեկ ամսում կամ նույնիսկ մի քանի շաբաթվա ընթացքում համեմատաբար քիչ գումարով: Այո, այն կդանդաղի շահագործման ընթացքում, միգուցե այն ամբողջովին ճշգրիտ աշխարհագրական տեղակայում չի ունենա, բայց այն կաշխատի բոլոր սարքերի վրա և թույլ կտա ձեզ նվազագույնը ստուգել հաճախորդների պահանջարկը շարժական սարքերի վրա:

Այս մոտեցման համար ստեղծվել են հսկայական թվով շրջանակներ, բայց դրանք բոլորն էլ ըստ էության նույն բանն են անում: Նրանց միջև տարբերությունն այն է, որ Cordova (PhoneGap) չի սահմանում սահմանափակումներ և ձևանմուշներ տրամաբանության և UI-ի վրա ձեր HTML5 նախագծի համար, և շրջանակները գործում են իրենց պատրաստի UI տարրերով, որոնք նմանակում են: շարժական հարթակներ, և դրա զարգացման տրամաբանությունը։ Այս մոտեցման օրինակ է. Ionic Framework - wrapper; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI - ինտերֆեյսի շրջանակներ:

PWA

Google-ի նորաձև տեխնոլոգիան նույն վեբ հավելվածներն են, սակայն որոշակի տեխնոլոգիաների կիրառման միջոցով (հիմնականում, այսպես կոչված, ծառայության աշխատողներ. ֆոնսցենարներ և Web App Manifest - վեբ հավելվածի նկարագրություն բջջային համակարգի համար հասկանալի ձևով) նրանք կարող են աշխատել որպես բնիկ առանց PhoneGap փաթաթման: Նրանք կարող են տեղադրվել հիմնական էկրանին՝ շրջանցելով հավելվածների խանութը, աշխատել անցանց, աշխատել push ծանուցումների և բնիկ գործառույթների հետ։

Խնդիրն այն է, որ ոչ բոլոր հարթակներն են նույնիսկ այժմ աջակցում այս «որոշ տեխնոլոգիաներին»: Սա առաջին հերթին վերաբերում է Apple-ին, որին, ըստ երևույթին, իսկապես դուր չի գալիս App Store-ը շրջանցող հավելվածները տարածելու հնարավորությունը:

Հաշվի առնելով HTML5 լուծումների բոլոր թերությունները, շատ ընկերություններ ստեղծել են գործիքներ, որոնք թույլ են տալիս գրել կոդը մեկ, ոչ մայրենի լեզվով, այնուհետև այն թարգմանվում է մայրենի: Սա սպանում է երկու թռչուն մեկ քարով. կա միայն մեկ կոդային հիմք, և հավելվածները հնարավորինս մոտ են հայրենին:

Քսամարին

Microsoft հարթակ. Ձեռնարկությունների զարգացման ստանդարտ ծրագրավորման լեզուն C# է, իսկ միջպլատֆորմային մշակման միջավայրը՝ Visual Studio: Արդյունքը տեղական հավելվածներ են iOS-ի, Android-ի և Windows-ի համար: Ճիշտ է, համեմատաբար մեծ չափերով:

React Native

Platform from - հավելվածները գրված են JavaScript-ով և օգտագործելով CSS-ի նմանվող ոճեր: Ինտերֆեյսը պարզվում է, որ բնիկ է, իսկ կոդը մեկնաբանվում է հարթակում, ինչը նրան տալիս է անհրաժեշտ ճկունություն։

Լինելով համեմատաբար երիտասարդ հարթակ՝ React Native-ը դեռ ակնհայտորեն (թեև ոչ աղետալիորեն) տառապում է զարգացման գործիքների և փաստաթղթերի պակասից:

Թրթռալ

Բնականաբար, Google-ի նման հսկան չէր կարող անտեսել Android և iOS հավելվածների միջպլատֆորմային մշակման թեման։ Flutter-ը, թեև ներկայումս միայն բետա տարբերակում է, այլ մոտեցում է ցուցաբերում React Native-ից և Xamarin-ից: Այն չի վերածում ելակետային կոդը հայրենի կոդի, որն իրականացվում է պլատֆորմի կողմից, այլ իրականում պատուհան է նկարում սմարթֆոնի էկրանին և ինքն է ներկայացնում բոլոր տարրերը: Օգտագործված լեզուն «գույքային» Dart-ն է, որը Google-ը ստեղծել է որպես JavaScript-ի բարելավված տարբերակ:

Սա ունի և՛ առավելություններ (օրինակ՝ արտաքինից նույնական ինտերֆեյսներ), և՛ թերություններ (օրինակ, ինտերֆեյսի վերագծագրումը պահանջում է որոշակի քանակությամբ հիշողություն և պրոցեսորի ժամանակ):

Պլատֆորմը զարգանում է արագ տեմպերով, և Google-ը մեծ ջանք ու գումար է ներդնում դրա վրա։ Բայց համեմատած Flutter-ի հետ, նույնիսկ React Native-ը շատ կայացած և տպավորիչ էկոհամակարգ է թվում:

Ինչ ընտրել

Ձեր գլուխը հավանաբար արդեն պտտվում է, բայց դուք դեռ գաղափար չունեք, թե ինչ ընտրել: Ներկայացնենք հարցերի պարզ ցանկ, որոնք կօգնեն ձեզ.

• Արդյո՞ք այն ինչ-որ կերպ պետք է աշխատի որևէ սարքի վրա: Ընտրեք HTMLորպես հիմք;
• Ունե՞ք բավարար միջոցներ, չե՞ք շտապում և ցանկանում եք ամենաբարձր որակի հավելված: Դուք ուղիղ ճանապարհ ունեք դեպի հայրենի զարգացում;
• Ունե՞ք «ներկառուցված» վեբ ծրագրավորող, թե՞ պարզապես ցանկանում եք արագ և հեշտությամբ փորձել բջջային հավելվածը գործողության մեջ: Այստեղ մենք կարող ենք խորհուրդ տալ Կորդովա / HTML կամ PWA;
• Ունե՞ք ձեր սեփական CRM համակարգ և C# մշակող, որն աջակցում է դրան: Վերցրեք այն Քսամարին;
• դուք «ուզում եք փորձել», բայց դուք պետք է ամեն ինչ գեղեցիկ և մոդայիկ դարձնեք: Նայիր հեռու React Native կամ Flutter.

Կարող եք նաև մյուս կողմից գնալ։ Նայեք ձեր հավելվածի ֆունկցիոնալությանը և գնացեք այնտեղից.

• պարզ այցեքարտի հավելված? Վերցրեք React Native կամ HTML5և դուք կստանաք երկու հարթակ նվազագույն գնով;
• Ունե՞ք բարձր տրաֆիկ ունեցող կայք և պետք է փորձարկեք ձեր ներկայությունը բջջային տարածքում: HTML5;
• բարդ հավելվածներ՝ հասանելիությամբ անհրաժեշտ գործառույթներըսարքեր? Native development, Xamarin, React Native.

Կրոսպլատֆորմային զարգացումը համադարման չէ

Ընտրելիս պետք է ելնել հանձնարարված առաջադրանքներից և առկա ռեսուրսներից: Կրոսպլատֆորմային զարգացումը լավ և հասկանալի ուղղություն է, բայց իր առավելություններով և թերություններով, որոնք պետք է հիշել նախքան նախագիծը սկսելը: Ավարտված միջպլատֆորմային հավելվածն ակնհայտորեն ավելի լավն է, քան չմշակված բնիկը: Դուք կարող եք արագ և էժան զարգացնել այն, վերբեռնել այն խանութում և պարզապես ստուգել օգտատերերի պահանջարկը՝ արդյոք որևէ մեկը փնտրում է ձեր հավելվածը, տեղադրում է այն, ինչ գործառույթներ է օգտագործում: Նման փորձի արդյունքների հիման վրա հնարավոր կլինի որոշել ձեր ընկերությունում շարժական ուղղության և դրանում ներդրումների ճակատագիրը։

Դեռևս կասկածներ և հարցեր ունե՞ք միջպլատֆորմային հավելվածների վերաբերյալ: Կարդացեք այն մասին, թե ինչպես մենք ստեղծեցինք հավելված քաղաքի մարզական հաստատություններից մեկին արագ բաժանորդագրություն ստանալու համար և փորձեք հավելվածը վճարելու բոլոր տեսակի ծառայությունների համար՝ բնակարանային և կոմունալ ծառայություններից մինչև առցանց խանութների պատվերներ: Ավելի լավ է գրանցվել անվճար խորհրդատվության համար՝ նշելով ձեր մոտավոր բյուջեն և համառոտ նկարագրությունգաղափարներ կամ կապվեք մեր մենեջեր Կատյայի հետ հեռախոսով