परिचय

काम के दौरान, मुझे बार-बार मोबाइल विकास के लिए उपयुक्त तकनीक के विकल्प से जूझना पड़ा। नीचे मैंने उपयोग किए गए दृष्टिकोण, फायदे और नुकसान के अनुसार मुख्य रूपरेखाओं को इकट्ठा करने और वर्गीकृत करने का प्रयास किया।

यदि मेरी कुछ जानकारी गलत है या पुरानी है - तो टिप्पणियों का स्वागत है।

क्रॉस-प्लेटफॉर्म विकास के सामान्य नुकसान

सीमित मंच समर्थन

किसी भी क्रॉस-प्लेटफ़ॉर्म की रूपरेखा देशी प्लेटफ़ॉर्म के ऊपर एक अमूर्त परत है और आपको केवल उन्हीं विशेषताओं तक पहुँचने की अनुमति देती है जो सीधे फ्रेमवर्क द्वारा समर्थित हैं।

ज्यादातर मामलों में, फ्रेमवर्क के लिए देशी प्लगइन्स लिखकर प्लेटफ़ॉर्म के लिए समर्थन का विस्तार करना संभव है, लेकिन कुछ मामलों में यह विकास को काफी जटिल कर सकता है। सनसनीखेज AirBnb लेख का एक ताजा उदाहरण रिएक्ट नेटिव है, जो फिलहाल 64-बिट एंड्रॉइड लाइब्रेरी के साथ बॉक्स से बाहर काम करना नहीं जानता है।

आपको यह भी ध्यान देने की आवश्यकता है कि मूल प्लगिन और एक नियम के रूप में क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन का मुख्य कोड, विभिन्न प्रक्रियाओं में निष्पादित किया जाता है और उनके बीच की बातचीत प्रदर्शन समस्याओं का कारण बन सकती है। सेंसर, या SQLite के साथ काम करने के लिए, यह आमतौर पर एक समस्या नहीं है, लेकिन अगर आप उपयोग करते हैं, तो कहें, OpenCV लाइब्रेरी को एक देशी प्लगइन के रूप में और इसके और मुख्य एप्लिकेशन के बीच एक वीडियो फेंकना शुरू करें, मंदी महत्वपूर्ण हो सकती है।

श्रम बाजार में सीमित आपूर्ति

सबसे पहले, डेवलपर्स की बहुत उपस्थिति फ्रेमवर्क की व्यापकता पर निर्भर करती है। रिएक्टिव नेटिव के तहत लोगों को ढूंढना देशी डेवलपर्स की तुलना में और भी आसान हो सकता है, लेकिन, उदाहरण के लिए, फ्लटर के साथ यह बहुत अधिक कठिन है।

इस कारक को कितना ध्यान रखना चाहिए यह कार्यों पर निर्भर करता है। अधिकांश स्टार्टअप इस पर ध्यान नहीं दे सकते हैं, क्योंकि एक नई तकनीक सीखने की संभावना है कि मौजूदा और संभावित कर्मचारियों के लिए एक बोनस है। दूसरी ओर, बड़े व्यवसाय श्रम बाजार को ध्यान में रखने के लिए मजबूर हैं।

जोखिम का समर्थन करें

यह माना जाता है कि क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क के लिए समर्थन करने की संभावना समाप्त हो जाएगी, मोबाइल ओएस के संबंध में उसी घटना की संभावना से बहुत अधिक है।

वास्तव में, सवाल काफी जटिल है। OS को फ्रेमवर्क की तरह ही बंद किया जा सकता है (विंडोज फोन का उदाहरण पूरी तरह से ताजा है)। इसके अलावा, मूल विकास के भीतर, कुछ प्रौद्योगिकियां भी बंद हो सकती हैं, और कभी-कभी क्रॉस-प्लेटफॉर्म फ्रेमवर्क पर कोड अधिक जीवित रहता है।

इसका एक उदाहरण गेम और मल्टीमीडिया के क्षेत्र में है - Apple अपने OS पर आराम करने के लिए OpenGL तकनीक भेजने जा रहा है और सभी ने जो देशी 3D एप्लिकेशन लिखे थे, उन्हें नए संस्करण जारी करने के लिए पूरी तरह से फिर से लिखना होगा। इसी समय, क्रॉस-प्लेटफॉर्म गेम इंजन (उदाहरण के लिए, एकता) का उपयोग करने वालों के लिए, अपडेट करने के लिए किसी भी अतिरिक्त प्रयासों की आवश्यकता नहीं होगी।

मुख्य दिशाएँ

हाइब्रिड डेवलपमेंट, HTML + जावास्क्रिप्ट

तकनीकी रूप से, हाइब्रिड-प्रकार के अनुप्रयोग एचटीएमएल पृष्ठ एक एम्बेडेड ब्राउज़र में प्रदर्शित होते हैं। सामान्य तौर पर, इस दृष्टिकोण के लिए फ्रेमवर्क की आवश्यकता नहीं होती है, लेकिन कॉर्डोवा प्लेटफ़ॉर्म सुविधाओं तक पहुंचने के लिए प्लगइन्स का एक सेट प्रदान करता है, यही वजह है कि वे आमतौर पर उपयोग किए जाते हैं।

मुख्य लाभ

न्यूनतम विकास लागत

हाइब्रिड दृष्टिकोण आपको न केवल डेवलपर्स के कौशल, बल्कि वेबसाइटों के लिए लिखे गए कोड का पुन: उपयोग करने की अनुमति देता है।

वेब तत्वों को एकीकृत करने की क्षमता

HTML / JS के लिए पुस्तकालयों की संख्या मूल अनुप्रयोगों के लिए पुस्तकालयों की संख्या से अधिक है। दिलचस्प में से, इसमें उदाहरण के लिए, Google Analytics या विज्ञापन नेटवर्क का विस्तृत चयन शामिल है।

कुंजी विपक्ष

कम उत्पादकता

आधुनिक जावास्क्रिप्ट स्वयं जेआईटी संकलन का उपयोग करता है, अच्छी तरह से अनुकूलित है और जल्दी से काम करता है, लेकिन डोम पेड़ पर आधारित इंटरफ़ेस का निर्माण एक बहुत ही कुशल प्रक्रिया नहीं है। आधुनिक जेएस फ्रेमवर्क का उपयोग अतिरिक्त स्तर का लोड प्रदान करता है। कमजोर फोन और / या इंटरैक्टिव तत्वों के सक्रिय उपयोग के साथ, यह एक समस्या हो सकती है।

"मूल भावना"

यह एक बल्कि अनौपचारिक, लेकिन बहुत महत्वपूर्ण बिंदु है। ब्राउज़र में साइट इशारों पर प्रतिक्रिया करती है और मोबाइल एप्लिकेशन की तुलना में थोड़ा अलग प्रदर्शित करती है। इस भावना का सबसे ध्यान देने वाला तत्व, दबाने पर 300ms की देरी, कॉर्डोवा तय करती है, लेकिन कई अन्य विवरण रहते हैं।

ब्राउज़र संगतता समस्या

Android के पुराने संस्करणों (संस्करण 5 से पहले) पर, WebView मंच का हिस्सा था और स्वचालित रूप से अपडेट नहीं हुआ। तदनुसार, इन उपकरणों पर हाइब्रिड अनुप्रयोगों में आधुनिक ब्राउज़र क्षमताओं का उपयोग करना संभव नहीं होगा।

नतीजतन, हाइब्रिड एप्लिकेशन या तो एंड्रॉइड के न्यूनतम संस्करण को सीमित करते हैं (इस समय लगभग 13% उपकरणों को पीछे छोड़ते हुए) या अनुप्रयोग कोड (क्रॉसवॉक प्रोजेक्ट) में वेबव्यू को शामिल करते हैं, जिससे कई मेगाबाइट्स का आकार दस गुना बढ़ जाता है।

भाग्य

जल्दी से वन-टाइम ऐप्स बनाएं। यदि पर्याप्त विकास बजट है, तो एक हाइब्रिड दृष्टिकोण आमतौर पर तिरस्कार है।

मूल ढाँचे

सभी प्रमुख हाइब्रिड फ्रेमवर्क का मूल कॉर्डोवा है, जो देशी प्लगइन्स तक पहुंच प्रदान करता है। फोनगैप कॉर्डोवा के शीर्ष पर निर्माण के लिए उपकरण प्रदान करता है, जबकि आयनिक एक ढांचा है और इसमें उपयोगकर्ता इंटरफेस के निर्माण के लिए घटकों का एक सेट है।

नेटिव यूआई, सामान्य कोड

यह ध्यान रखना महत्वपूर्ण है कि इस दृष्टिकोण के साथ, उपयोगकर्ता इंटरफ़ेस और व्यावसायिक तर्क को एक पुल के माध्यम से बातचीत करने वाली विभिन्न प्रक्रियाओं में निष्पादित किया जाता है। दृष्टिकोण के कई नुकसान इसके साथ जुड़े हुए हैं।

इस दृष्टिकोण में कई कार्यान्वयन विकल्प हैं।

निष्पादन योग्य कोड का वर्गीकरण

संकलित कोड

Xamarin C # भाषा का उपयोग करता है, इसे मूल प्लेटफ़ॉर्म कोड में संकलित करता है। सामान्य तौर पर, यह दृष्टिकोण एक काफी छोटा अनुप्रयोग आकार और एक उच्च गति प्रदान करता है।

JIT संकलन के साथ व्याख्या की गई भाषा

इस दृष्टिकोण में अधिकांश चौखटे व्यापारिक तर्क को संसाधित करने के लिए जावास्क्रिप्ट का उपयोग करते हैं।

इंटरफ़ेस विवरण विधि द्वारा वर्गीकरण

देशी उपकरण

ज़ामरीन न केवल देशी इंटरफ़ेस घटकों का उपयोग करता है, बल्कि प्रत्येक प्लेटफ़ॉर्म के लिए स्वीकृत प्रारूप में उनका वर्णन भी करता है।

यूनिवर्सल इंटरफ़ेस तत्व

ज़मारिन फॉर्म्स और ऐप्पेलरेटर अपने स्वयं के विगेट्स का उपयोग करते हैं, जो प्रत्येक प्लेटफ़ॉर्म के उपयुक्त इंटरफ़ेस घटकों में परिवर्तित होता है।

विभिन्न प्लेटफार्मों के लिए अलग इंटरफ़ेस, लेकिन एक आम दृष्टिकोण

प्रतिक्रियाशील मूल निवासी इंटरफ़ेस घटकों के आसपास रैपर का उपयोग करता है। तदनुसार, इंटरफ़ेस प्रत्येक प्लेटफ़ॉर्म के लिए अलग से वर्णित किया गया है, लेकिन विवरण विधि समान है।

मुख्य लाभ

पूरी तरह से देशी इंटरफ़ेस

सबसे पहले, आवेदन की उपस्थिति और "महसूस" पूरी तरह से देशी अनुप्रयोगों के साथ मेल खाती है।

दूसरे, यह अनुप्रयोगों में देशी इंटरफ़ेस पुस्तकालयों का उपयोग करने की अनुमति देता है। देशी विज्ञापनों (नेटिव विज्ञापन) का उपयोग करते हुए, मोबाइल एप्लिकेशन पर केंद्रित, अन्य तरीकों से काम नहीं होगा। सच है, इस दृष्टिकोण के लिए, प्रासंगिक पुस्तकालयों का सेट बहुत सीमित है। मैं केवल प्रतिक्रियाशील मूल में फेसबुक मूल निवासी विज्ञापन समर्थन के बारे में जानता हूं।

डेवलपर कौशल का पुन: उपयोग करने की क्षमता

इस समूह के कई ढांचे तैयार किए गए हैं ताकि अन्य क्षेत्रों के डेवलपर्स सीख सकें कि कम से कम लागत के साथ मोबाइल एप्लिकेशन कैसे बनाएं। प्रतिक्रिया के लिए, मूल प्रतिक्रिया है, Xamarin, .NET, आदि के लिए।

कुंजी विपक्ष

इंटरफ़ेस क्षमताओं की सीमा, या अलग विकास के लिए अतिरिक्त लागत

इस माइनस का प्रारूप इंटरफ़ेस के वर्णन के तरीके के अनुसार वर्गीकरण के आधार पर निर्भर करता है:

ज़ामरीन आपको प्लेटफार्मों की लगभग सभी विशेषताओं का उपयोग करने की अनुमति देता है, लेकिन आपको प्रत्येक प्लेटफ़ॉर्म के लिए इंटरफेस पर बहुत समय बिताना होगा। नतीजतन, श्रम लागत देशी विकास के साथ बहुत कम नहीं हैं।

ज़मारिन फॉर्म्स और ऐप्पेलरेटर आपको केवल एक बार इंटरफेस का वर्णन करने की अनुमति देते हैं, लेकिन वे मूल कार्यक्षमता के बहुत सीमित उप-समूह के साथ काम करते हैं (औपचारिक होने के लिए प्रत्येक प्लेटफ़ॉर्म की सुविधाओं के सेट के न्यूनतम चौराहे से अधिक नहीं)।

रिएक्ट नेटिव बीच में है, दोनों कमियों को मिलाकर, लेकिन कम स्पष्ट रूप में।
इंटरफ़ेस सहभागिता प्रदर्शन
यहाँ विभिन्न प्रक्रियाओं में इंटरफेस और व्यापार तर्क के निष्पादन का कारक है। जब उच्च गति पर एक पुल (उच्च आवृत्ति के साथ जटिल एनीमेशन) के माध्यम से बड़ी मात्रा में जानकारी का आदान-प्रदान करना आवश्यक होता है, तो इस दृष्टिकोण में कठिनाइयां पैदा हो सकती हैं।

स्मृति लीक

मेमोरी लीक किसी भी एप्लिकेशन में हो सकता है, लेकिन अधिकांश मानक स्थितियों को कचरा संग्राहकों द्वारा नियंत्रित किया जाता है।

एक देशी इंटरफ़ेस के साथ क्रॉस-प्लेटफ़ॉर्म अनुप्रयोगों के साथ समस्या फिर से है कि वे दो प्रक्रियाओं में चलते हैं जिसमें अलग-अलग कचरा कलेक्टर होते हैं। यदि व्यावसायिक तर्क ऑब्जेक्ट इंटरफ़ेस ऑब्जेक्ट को संदर्भित करता है, तो यह इंटरफ़ेस ऑब्जेक्ट कचरा नहीं है, क्योंकि पुल से इसकी एक कड़ी है। यदि इंटरफ़ेस ऑब्जेक्ट व्यावसायिक तर्क ऑब्जेक्ट पर वापस संदर्भित करता है, तो उन्हें कचरा नहीं माना जाएगा, भले ही उनके लिए अधिक संदर्भ न हों।

एक समस्या और इसके पैमाने पर मुठभेड़ की संभावना सीधे आवेदन पर निर्भर करती है। यदि इंटरफ़ेस से जुड़ी वस्तुओं को सक्रिय रूप से बनाया गया है और इसमें हटा दिया गया है (जैसे अंतहीन स्क्रॉलिंग में), तो एक रिसाव की संभावना बढ़ जाती है। यदि ये ऑब्जेक्ट बड़े हैं (उदाहरण के लिए, चित्र), तो रिसाव का प्रभाव बढ़ जाता है।

दरअसल, यह समस्या देशी प्लगइन्स के साथ काम करते समय भी मौजूद होती है, जिन्हें एक अलग प्रक्रिया में निष्पादित किया जाता है। लेकिन, ज्यादातर मामलों में, या तो बड़ी वस्तुओं का ऐसा कोई गहन हेरफेर नहीं होता है, या इंटरैक्शन क्रॉस-रेफरेंस के बिना एक सख्त प्रक्रियात्मक दृष्टिकोण में होता है।

भाग्य

पूरी तरह से देशी इंटरफ़ेस के साथ अनुप्रयोग, खासकर यदि संबंधित प्रौद्योगिकियों के विशेषज्ञ हैं।

मूल ढाँचे

मूल निवासी

इसमें फेसबुक का समर्थन है और सबसे लोकप्रिय रिएक्ट जेएस फ्रेमवर्क के दृष्टिकोण का उपयोग करता है, जिसके कारण यह बहुत लोकप्रिय है। AirBnb के रिएक्ट नेटिव के परित्याग पर हाल के एक लेख ने बहुत शोर मचाया, लेकिन अगर जोखिमों के बारे में पता किया जाए, तो यह एक बहुत प्रभावी समाधान हो सकता है।

Xamarin

मुख्य दृष्टिकोण के अलावा, इसमें Xamarin.Forms पुस्तकालय है, जो आपको कुशलतापूर्वक और क्रॉस-प्लेटफ़ॉर्म डिज़ाइन सरल इंटरफेस की अनुमति देता है। Microsoft द्वारा सक्रिय रूप से समर्थित। सर्वर पर ASP.NET के साथ काम करते समय, यह आपको सर्वर पर और मोबाइल एप्लिकेशन में सामान्य व्यावसायिक तर्क कक्षाओं के उपयोग के माध्यम से एक निश्चित मात्रा में काम करने की अनुमति देता है।

NativeScript

यह रिएक्टर नेटिव पर उन डेवलपरों के लिए बनाया गया है जो अन्य जेएस फ्रेमवर्क (कोणीय और Vue.js) के मालिक हैं। कम लोकप्रिय, लेकिन वास्तुकला में अधिक आधुनिक समाधानों की संख्या है।

नेटिव यूआई, सामान्य कोड

लगभग सभी गेम इंजन इस दृष्टिकोण का उपयोग करते हैं, लेकिन वे इस लेख के दायरे से परे हैं।

इस दृष्टिकोण का सिद्धांत यह है कि एप्लिकेशन अपने स्वयं के कोड और अपने स्वयं के यूजर इंटरफेस रेंडरिंग का उपयोग करता है।

मुख्य लाभ

उच्च प्रदर्शन इंटरफेस

वास्तव में, एक एप्लिकेशन जो अपने स्वयं के इंटरफ़ेस को स्वयं खींचता है, मूल इंटरफ़ेस में ओएस के समान संचालन करता है। सिद्धांत रूप में, यह और भी तेज हो सकता है, क्योंकि प्रक्रिया और कर्नेल के बीच कोई स्विचिंग नहीं है, लेकिन व्यवहार में, अन्य कारक किसी विशेष इंटरफ़ेस की रेंडरिंग गति को प्रभावित करते हैं, बहुत बड़ी भूमिका निभाते हैं।

"डिजाइन इंटरफेस"

मूल एप्लिकेशन तैयार-किए गए इंटरफ़ेस घटकों का उपयोग करते हैं और उनके साथ क्या किया जा सकता है, इसकी कुछ सीमाएं हैं। बदले में, अपने स्वयं के इंटरफ़ेस को आकर्षित करने वाले अनुप्रयोगों में इस तरह के प्रतिबंध नहीं होते हैं और व्यक्तिगत रूप से तैयार किए गए तत्वों को स्वतंत्र रूप से मिश्रण कर सकते हैं।

कुंजी विपक्ष

ये नुकसान केवल उन अनुप्रयोगों के लिए प्रासंगिक हैं जो मानक ओएस इंटरफ़ेस की नकल करते हैं। जैसा कि पहले ही उल्लेख किया गया है, डिजाइन इंटरफेस और गेम के लिए यह दृष्टिकोण इष्टतम है।

आवेदन का आकार

इस दृष्टिकोण वाले एप्लिकेशन सशर्त रूप से मानक वाले सभी इंटरफ़ेस तत्वों को प्रस्तुत करने के लिए कोड ले जाने के लिए मजबूर हैं। यह इंस्टॉलेशन के दौरान एप्लिकेशन के आकार और ऑपरेशन के दौरान RAM दोनों को प्रभावित करता है।

यदि प्रभावी ट्री शेकिंग (फ़्लटर के नवीनतम संस्करण के रूप में) द्वारा पहली समस्या को कम किया जा सकता है, तो ये एप्लिकेशन रैम द्वारा मूल रूप से अपनी मूल मेमोरी खो देते हैं। हालांकि, यह समस्या अन्य क्रॉस-प्लेटफॉर्म फ्रेमवर्क की विशेषता भी है।

देशी इंटरफ़ेस

डिफ़ॉल्ट रूप से, एप्लिकेशन सभी प्लेटफार्मों पर समान दिखता है, जो उपयोगकर्ताओं के लिए असुविधा पैदा कर सकता है। इन समस्याओं को हल करने के लिए थीम का उपयोग किया जाता है, लेकिन वे पूरी तरह से मूल एप्लिकेशन की भावना पैदा नहीं कर सकते हैं।

लेकिन एक बड़ा माइनस है - इस दृष्टिकोण के साथ, मूल अनुप्रयोगों के लिए बनाए गए तीसरे पक्ष के इंटरफ़ेस तत्वों का उपयोग करना सबसे कठिन है (पहले उल्लेख किए गए मूल निवासी विज्ञापन सहित)।

भाग्य

सार्वजनिक अनुप्रयोग, विशेष रूप से एक डिज़ाइन इंटरफ़ेस के साथ।

मूल ढाँचे

स्पंदन

Google द्वारा उनके भविष्य फ्यूशिया ओएस के लिए कोर क्रॉस-प्लेटफॉर्म डेवलपमेंट फ्रेमवर्क और इंटरफ़ेस के रूप में स्पंदन को बढ़ावा दिया जा रहा है। जबकि रूपरेखा बहुत युवा है (रिलीज पूर्वावलोकन चरण में) और बहुत आम नहीं है, यह जल्दी से लोकप्रियता प्राप्त कर रहा है। डार्ट भाषा का उपयोग करता है (मूल कोड में संकलन के साथ)।

इसमें युवाओं के सभी पेशेवरों और विपक्षों - एक अच्छी तरह से सोचा हुआ वास्तुकला, अपने पूर्ववर्तियों की गलतियों को ध्यान में रखते हुए, बल्कि एक सीमित पारिस्थितिक तंत्र है।

क्यूटी मोबाइल

यह डेस्कटॉप क्यूटी के डेवलपर्स के बीच लोकप्रिय है। जावास्क्रिप्ट का उपयोग विकास में किया जा सकता है। बड़ी कंपनियों के समर्थन के बिना बहुत लोकप्रिय नहीं है।

Kivy

एक और बहुत लोकप्रिय ढांचा नहीं है जो दिलचस्प है, मुख्य रूप से क्योंकि यह सूची का एकमात्र ढांचा है जो पायथन का उपयोग करता है। डेवलपर्स के लिए जो केवल इस भाषा से परिचित हैं (और सूचना प्रौद्योगिकी के कुछ क्षेत्रों में कई हैं), यह महत्वपूर्ण हो सकता है।

संबंधित सामग्री

ज़मरीन और इसी तरह के ढांचे में स्मृति पर
देशी अनुप्रयोगों, स्पंदन और प्रतिक्रिया मूल के प्रदर्शन की तुलना