👴🏾 🎫 👈🏻 स्पंदन क्यों जीत रहा है? 🚒 🤸🏻 👶🏿

पिछले साल, मैं वैसे भी आईओएस और एंड्रॉइड के लिए फ़्लटर ऐप लिख रहा हूं। इससे पहले, मुझे ज़मरीन के साथ 5 साल का अनुभव था। यह एक अद्भुत 5 साल रहा है। ज़मारिन के लिए धन्यवाद और इस ढांचे के लिए मेरा प्यार, मैं, सिद्धांत रूप में, डेवलपर्स के शिविर में चला गया, इस उपकरण ने मुझे बहुत पैसा, ज्ञान अर्जित करने और अद्भुत सहयोगियों को खोजने में मदद की। तो अब मैं स्पंदन पर क्यों लिख रहा हूं? संक्षिप्त उत्तर, क्योंकि स्पंदन प्लेटफॉर्म के विकास की सभी जरूरतों को शामिल करता है।

इतिहास का हिस्सा

मुझे गलत होने पर सही करें, लेकिन सामान्य रूप से 2009 में मोबाइल विकास के लिए कई मायने में महत्वपूर्ण था और विशेष रूप से क्रॉस-प्लेटफॉर्म विकास। 2009 में, iPhone 3gs जारी किया गया, जिसने आपको AppStore से तृतीय-पक्ष एप्लिकेशन चलाने की अनुमति दी। पहली बार यह अवसर आईफोन 3 जी में एक साल पहले आया था, लेकिन 3 जी वास्तव में बड़े पैमाने पर "लोकप्रिय" आईफोन बन गया है। फिर से, एक साल पहले, सितंबर 2008 में, एंड्रॉइड को जनता के लिए पेश किया गया था और 2009 में कई फोन निर्माता अपने नए फोन मॉडल के लिए एंड्रॉइड की कोशिश करने लगे। वसंत 2009 में, नितोबी ने फोनगैप पेश किया, जो एचटीएमएल 5, सीएसएस और जेएस पर आधारित क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन बनाने का एक नया ढांचा है। उसी वर्ष, सितंबर मेंज़िमियान ने मोनोटोच जारी किया, जिसने आपको मोनो और सी # का उपयोग करके आईओएस एप्लिकेशन लिखने की अनुमति दी। उसी 2009 में, दिसंबर में, रोवियो एंटरटेनमेंट ने आईओएस के लिए एक गेम जारी किया और, एक पल के लिए, मैमो, जिसने कई तरह से मोबाइल गेम उद्योग की शुरुआत को चिह्नित किया - एंग्री बर्ड्स। यहाँ अंतिम उदाहरण आकस्मिक नहीं है।

पहला क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क "लोगों के लिए" फोनगैप (क्यूटी डेवलपर्स, पत्थर नहीं फेंकना) माना जा सकता है। यह एक अद्भुत और बहुत स्पष्ट विचार था - वेब को मोबाइल विकास की दुनिया में लाने के लिए। 2009 तक, वेब की क्षमताओं ने पहले ही ब्राउज़र ( हेल्लो नोड.जेएस) से आगे बढ़ना शुरू कर दिया था , जबकि जेएस में वेब एप्लिकेशन लिखना बहुत सीधा था। दूसरा, कोई कम महत्वपूर्ण बिंदु यूआई का प्रतिपादन नहीं है। जिस तरह से प्रतिपादन होता है वह ब्राउज़र इंजन के साथ निहित होता है और ये सभी इंजन कमोबेश HTML, CSS और DOM के लिए W3C मानकों का पालन करते हैं। किसी भी वेब डेवलपर ने जो साइट बनाई है, उसे उम्मीद है कि उसकी साइट ~~लगभग~~ दिखाई देगीकिसी भी ब्राउज़र में समान, किसी भी प्लेटफ़ॉर्म पर। यह, मेरी राय में, एक खुले मंच के रूप में वेब का सबसे महत्वपूर्ण पहलू है। मुझे प्रत्येक प्लेटफ़ॉर्म के लिए यूआई ड्राइंग के लिए एक नई भाषा / रूपरेखा क्यों सीखनी चाहिए, अगर लंबे समय तक विभिन्न ब्राउज़रों के लिए यूआई मॉडलिंग के लिए एक मानक है।

उसके बाद, कॉर्डोवा ने फोनगैप से और इओनिक से अलग किया। ऐसा लगता है कि यह एक आदर्श ढांचा है, लेकिन इसमें 2 बिंदु थे: प्रदर्शन और ओएस एकीकरण। मुख्य लक्ष्यों में से एक या, यदि आप चाहते हैं, तो क्रॉस-प्लेटफ़ॉर्म समाधानों पर लिखे गए एप्लिकेशन बेंचमार्क उनके "नेटिविटी" थे। उन। आदर्श रूप से, 100% उपयोगकर्ताओं को यह विचार करना चाहिए कि आपका क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन मूल है। और इसका मतलब है कि यह मूल की तरह दिखना चाहिए, मूल की तरह काम करना चाहिए और ओएस के साथ सभी संभव एकीकरण हैं। शुरुआत में, फोनगैप के लिए ये सभी बिंदु अप्राप्य थे, 10 साल पहले के स्मार्टफोन की क्षमता 60 एफपीएस यूआई प्रतिपादन के लिए पर्याप्त नहीं थी, ओएस के साथ एकीकरण न्यूनतम था। अब आयोनिक पर काफी कुछ अनुप्रयोग हैं जो मूल लोगों से अलग करना मुश्किल है, लेकिन एक मूल आवेदन की नकल करना अभी भी एक काम है।और ऐसा नहीं दिया गया। आइए संक्षेप में थोड़ा बताएं। वेब एप्लिकेशन या iOS और Android पर हाइब्रिड एप्लिकेशन लिखना संभव और सुविधाजनक है। यह सुविधाजनक है क्योंकि UI रेंडरिंग तंत्र पूरी तरह से WebView प्लेटफॉर्म पर है, इसके अलावा प्रोग्रामर की एक पहले से ही प्रशिक्षित परत है जो वेब में अच्छी तरह से वाकिफ हैं।हालांकि, हाइब्रिड अनुप्रयोगों में, प्रदर्शन और ओएस एकीकरण लंगड़ा हो सकता है।

PhoneGap के रूप में, 2009 में मोनोऑट लॉन्च किया गया था, जिसे बाद में Xamarin.iOS नाम दिया गया था। इसके अलावा, उसी वर्ष, टाइटेनियम को जारी किया गया, जिसने बदले में जावास्क्रिप्ट पर iOS एप्लिकेशन लिखने की अनुमति दी। सबसे पहले, टाइटेनियम ने फोनगैप के समान ही प्रतिमान में काम किया - वेब व्यू पर निर्भर। लेकिन फिर उन्होंने ज़ामरीन दृष्टिकोण अपनाया। यह दृष्टिकोण क्या है? इसे बीच में कुछ के रूप में देखा जा सकता है। Xamarin / Titanium / React.Native का दृष्टिकोण यह है कि अपने / अपने मौजूदा UI रेंडर को बनाने / माइग्रेट करने के बजाय, फ्रेमवर्क मौजूदा, मूल के साथ एकीकृत करता है।

एचटीएमएल में एक फॉर्म ड्राइंग करने के बजाय, ज़ामरीन ने इसके लिए एक मूल यूआई तत्व (UITextField, TextEdit, आदि) को कॉल किया। वास्तव में, पहिया को क्यों मजबूत करना है? सभी आवश्यक यूआई तत्व देशी एसडीके और रनटाइम्स में मौजूद हैं, आपको बस अपने वीएम (मोनो, वी 8, आदि) से उनके साथ संवाद करने का तरीका सीखने की जरूरत है। उसी समय, जैसा कि आपने पहले ही अनुमान लगाया था, आप अपने पसंदीदा सी #, जेएस, टीएस, एफ #, कोटलिन, आदि का उपयोग कर सकते हैं, और उसी समय कोड जो यूआई के साथ सीधे बातचीत नहीं करता है वह 100% क्रॉस-प्लेटफॉर्म है। आप और भी आगे बढ़ सकते हैं। एक ही UITextField और TextEdit वैचारिक रूप से समान इकाइयां हैं, उनके पास कुछ समान गुण और इंटरैक्शन इंटरफेस हैं, और इसलिए, आप एक सार प्रविष्टि (हैलो Xamarin.Forms) बना सकते हैं और केवल इसके लिए काम कर सकते हैं, दुर्लभ के लिए ( ~~बहुत~~ कम ~~नहीं)~~) मंच यूआई तत्व के लिए नीचे जा रहा अपवाद। मैं यह उल्लेख नहीं करता कि यदि आपका vm यूआई के साथ मूल रूप से काम कर सकता है, तो संभव है कि आपका vm किसी भी प्लेटफ़ॉर्म API को कॉल कर सकता है। यह एकदम सही विकल्प की तरह लगता है। देशी UI, मूल प्रदर्शन (React.Native में हाय ब्रिज), 100% OS एकीकरण। क्या यह वास्तव में सही है? सबसे अधिक संभावना है - नहीं, और समस्या यह है कि वास्तव में ये समाधान क्रॉस-प्लेटफॉर्म विकास की समस्या को हल नहीं करते हैं - एक एकल यूआई। वे उसे भटकाते हैं। मैं एक बार लिखना चाहता हूं, हर जगह दौड़ता हूं। यह सभी प्रकार के कार्यक्रमों और समस्याओं के लिए सबसे अच्छा आदर्श वाक्य से दूर है, लेकिन यह यूआई के साथ अच्छी तरह से फिट बैठता है। मैं प्लेटफ़ॉर्म की परवाह किए बिना सभी के लिए यूआई लिखना चाहता हूं। एक वेब डेवलपर खुद को HTML और सीएसएस का उपयोग करने की अनुमति क्यों दे सकता है एक साइट लिखने के लिए जिसे उसी तरह सफारी पर iOS और क्रोम पर एंड्रॉइड पर प्रदर्शित किया जा सकता है, लेकिन कोई मूल डेवलपर नहीं?

वास्तव में, प्रोग्रामर ने लंबे समय तक आईओएस और एंड्रॉइड के लिए एक सामान्य कोड बेस के साथ एक उच्च-प्रदर्शन यूआई लिखा है। इन प्रोग्रामर को गेम डेवलपर कहा जाता है। एंग्री बर्ड्स को Cocos2d-x इंजन, कप हेड ऑन यूनिटी, और फोर्टनाइट पर अवास्तविक इंजन पर लिखा गया था। यदि गेम इंजन आपके फोन पर लुभावने दृश्य दिखाने में सक्षम हैं, तो चिकनी एनीमेशन वाले बटन और सूचियां निश्चित रूप से सक्षम होंगी। तो क्यों कोई उन्हें इस नस में उपयोग नहीं करता है? इसका उत्तर सरल और सामान्य है, वे इसके लिए अभिप्रेत नहीं हैं। जब आप गेम को खोलते हैं, तो यह पूरी तरह से फ्लैशलाइट तक होता है कि यूआई एक देशी की तरह कितना दिखता है, आपको लगभग कभी भी जियोलोकेशन, पुश-बटन, एक वीडियो कैमरा, आदि के साथ बातचीत करने की आवश्यकता नहीं है। जब आप खेलते हैं, तो आप अपनी छोटी सी दुनिया में एक अलग जीवन जीते हैं जो आपके UIViewController / गतिविधि में कैनवास के माध्यम से प्रदान किया जाता है। इसलियेगेम इंजन का OS के साथ अपेक्षाकृत खराब एकीकरण है , इसलिए देशी UI शीर्ष इंजन की नकल करते हुए कोई (या मैंने नहीं देखा है) है।

सबटोटल

एक आदर्श क्रॉस-प्लेटफॉर्म फ्रेमवर्क के लिए, हमें आवश्यकता है:

देशी UI मानचित्रण
मूल UI प्रदर्शन
किसी भी ओएस एपीआई को कॉल करने की 100% क्षमता, जैसे कि यह एक मूल अनुप्रयोग था

अब आप सोचते हैं कि मैं फ़्लटर के तहत असफल होना शुरू कर दूंगा, लेकिन मैं पहले से ही गुस्से में टिप्पणी सुनता हूं: "क्यूटी कहां है!" वह यह सब कर सकता है! ” दरअसल, क्यूटी एक डिग्री या किसी अन्य के लिए इन मानदंडों को फिट करता है। हालांकि मुझे उनमें से सबसे पहले संदेह है। लेकिन Qt की मुख्य समस्या देशी UI लिखने में कठिनाई नहीं है, मुख्य समस्या C ++ है। तब मैं पहले से ही अपने चेहरे को लेबर-एनकोडर के थूक से मिटा रहा था। पेशेवरों anabolic स्टेरॉयड पर एक स्विस चाकू है, पेशेवरों पर आप सब कुछ कर सकते हैं। लेकिन मैं, एक फ्रंटेंड डेवलपर के रूप में, इस सब की ज़रूरत नहीं है। मुझे एक सरल और समझने योग्य भाषा की आवश्यकता है जो UI और I / O के साथ काम करती है। तो, ऊपर हमारे तीन बिंदुओं को जोड़ा गया था:

जानने के लिए आसान और काफी अभिव्यंजक भाषा
रैंडाइम जो सामने वाले विकास प्रतिमान में अच्छी तरह से फिट बैठता है

खैर, अब जब हमने मोबाइल एप्लिकेशन विकसित करने के लिए एक अच्छे क्रॉस-प्लेटफ़ॉर्म टूल के कुछ मेट्रिक्स पर प्रकाश डाला है, तो हम उनमें से प्रत्येक पर जा सकते हैं और देख सकते हैं कि इसे फ़्लटर में कैसे लागू किया जाता है।

देशी UI मानचित्रण

जैसा कि हमने पहले पाया, क्रॉस-प्लेटफॉर्म फ्रेमवर्क में यूआई के साथ काम करने के दो विपरीत दृष्टिकोण हैं। यह प्रत्येक प्लेटफ़ॉर्म पर WebView या देशी UI तत्व कॉल का उपयोग करते हुए UI रेंडर है। प्रत्येक दृष्टिकोण के फायदे और नुकसान हैं। लेकिन वे डेवलपर जरूरतों की पूरी श्रृंखला को कवर नहीं करते हैं: मूल UI + देशी प्रदर्शन से अप्रभेद्य देखो। स्पंदन इन सभी जरूरतों को एक सिर के साथ कवर करता है। स्पंदन टीम ने ढांचे में "देशी" तत्वों को बनाने के लिए संसाधनों की एक निश्चित राशि खर्च की। स्पंदन में सभी विगेट्स तीन बड़ी श्रेणियों में विभाजित हैं:

यदि आप कपर्टिनो सेक्शन में जाते हैं, तो आप देखेंगे कि ये विजेट देशी आईओएस तत्वों से अप्रभेद्य हैं। एक डेवलपर के रूप में जो थोड़ी देर के लिए स्पंदन का उपयोग कर रहा है, मैं पुष्टि कर सकता हूं कि वे अप्रभेद्य हैं। यदि आप CupertinoDatePicker का उपयोग करते हैं, उदाहरण के लिए, स्क्रॉल करते समय आप अपने iPhone पर Taptic / Haptic इंजन से ठीक वैसी ही अच्छी प्रतिक्रिया महसूस करेंगे, जैसे कि यह मूल एप्लिकेशन का एक मूल तत्व था। मैं और अधिक कहूंगा, समय-समय पर मैं अपने iPhone पर साइट realtor.com के आवेदन को खोलता हूं और हाल ही में जब तक मुझे पता नहीं था कि यह फ्लटर में लिखा गया था (या कुछ और नहीं देशी)।

स्पंदन न केवल आपको 2 प्लेटफार्मों के लिए "देशी" विगेट्स का उपयोग करने की अनुमति देता है, बल्कि अपना खुद का भी निर्माण करता है, और यह बहुत आसान है! पूरे प्रतिमान यह है कि सब कुछ विजेट काम करता है। आप थोड़े समय में आश्चर्यजनक रूप से जटिल UI तत्व और एनिमेशन बना सकते हैं। फ़्लटर में यूआई के साथ काम करने के दृष्टिकोण के आकर्षण और ज्ञान को हाल ही में हैबर पर इस लेख में वर्णित किया गया है , मैं पढ़ने की सलाह देता हूं। चूंकि यह सब एक एकल ग्राफिक्स इंजन पर काम करता है जो प्रत्येक प्लेटफ़ॉर्म के लिए सीधे यह सब प्रस्तुत करता है (हम इसके बारे में बाद में बात करेंगे), आप सुनिश्चित कर सकते हैं कि जैसा कि आपने योजना बनाई थी, सब कुछ प्रदर्शित होगा।

एक और सुंदर अद्भुत बिंदु। स्पंदन आईओएस 8 और एंड्रॉइड एपीआई v16 के साथ शुरू होने वाले प्लेटफार्मों का समर्थन करता है। UI रेंडरिंग परिप्रेक्ष्य से, स्पंदन वास्तव में कोई फर्क नहीं पड़ता कि कौन से API एक विशेष प्लेटफॉर्म पर उपलब्ध हैं। उन्हें कैनवस और ग्राफिक्स सबसिस्टम के साथ कुछ प्रकार की बातचीत के साथ काम करने का अवसर मिलेगा। और इसका मतलब है कि हम एंड्रॉइड से नवीनतम यूआई तत्वों को आकर्षित कर सकते हैं, उदाहरण के लिए, 8 साल की उम्र के फोन पर। निश्चित रूप से सबसे पुराने समर्थित प्लेटफार्मों पर इस दृष्टिकोण के प्रदर्शन का सवाल है, लेकिन यह एक और सवाल है।

मूल UI प्रदर्शन

जैसा कि आप देख सकते हैं, यूआई प्रतिपादन के लिए फ़्लटर का दृष्टिकोण आयोनिक जैसे हाइब्रिड ऐप के करीब है। हमारे पास सभी प्लेटफार्मों पर यूआई प्रदान करने के लिए एक एकल इंजन है, यह स्काई ग्राफिक्स लाइब्रेरी है। Google ने 2005 में स्किआ को एक उत्पाद के रूप में खरीदा और इसे एक ओपन सोर्स प्रोजेक्ट में बदल दिया। यह कम से कम सुझाव देता है कि यह एक काफी परिपक्व उत्पाद है। कुछ Skia प्रदर्शन विशेषताएं:

ग्राफिक तत्वों और अन्य डेटा प्रकारों के लिए कॉपी-ऑन-राइट
विखंडन को कम करने के लिए जहां भी संभव हो स्टैक मेमोरी का उपयोग करना
बेहतर सुरक्षा के लिए थ्रेड-सेफ्टी

मैंने समान पुस्तकालयों (देखें काहिरा ) की तुलना में स्किया प्रदर्शन परीक्षणों को पक्का नहीं किया है , लेकिन कुछ परीक्षण कुछ विशिष्ट स्थितियों को छोड़कर औसतन 50% प्रदर्शन लाभ दिखाते हैं। हां, यह विशेष रूप से महत्वपूर्ण नहीं है, क्योंकि ये परीक्षण डेस्कटॉप पर OpenGL के उपयोग पर आधारित हैं, और ...

Skia कई GPU बैकएंड के साथ बातचीत कर सकता है। चूँकि हाल ही मेंIOS पर समय, संस्करण 11 के बाद से, स्पंदन डिफ़ॉल्ट रूप से बैकएंड जीपीयू के रूप में धातु का उपयोग करता है। Android पर, एपीआई 24 के साथ शुरू - वल्कन। नीचे दिए गए संस्करणों के लिए - ओपनजीएल। यह सब हमें उत्पादकता में एक स्पष्ट लाभ देता है। अन्य "हार्डवेयर" प्लेटफार्मों पर, जैसा कि मैं इसे समझता हूं, स्किआ / फ्लटर ओपनजीएल का उपयोग करता है, जो सिद्धांत रूप में हमें पर्याप्त ग्राफिक्स के प्रदर्शन के साथ आवेदन लिखने से नहीं रोकता है।

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

अंत में, C # प्रोग्रामर SkiaSharp का उपयोग अपेक्षाकृत लंबे समय से कर रहे हैं - मोनो / नेट x के लिए Skia पर एक आवरण। और Xamarin समुदाय कस्टम यूआई तत्वों को आकर्षित करने के लिए इस दायित्व का उपयोग करता है और यह एक बहुत ही लोकप्रिय पुस्तकालय है। अगर यह जीत नहीं है, तो मुझे नहीं पता कि यह क्या है।

किसी भी एपीआई ओएस को कॉल करने की 100% क्षमता

स्पंदन में "बाहर" दुनिया के साथ बातचीत के 2 सिद्धांत हैं:

प्लेटफ़ॉर्म चैनल आपको एक संदेश प्रणाली के माध्यम से मूल रनटाइम / एपीआई के साथ बातचीत करने की अनुमति देता है। वास्तुकला की दृष्टि से, इसे इस प्रकार देखा जा सकता है। नेत्रहीन, स्पंदन सिर्फ एक कैनवस है, जो आपके मूल एप्लिकेशन की एकमात्र गतिविधि / UIViewController में पूर्ण स्क्रीन तक फैला हुआ है। यह बिल्कुल उसी तरह का दृष्टिकोण है जो मैं गेम डेवलपर्स (गेम इंजन) का उपयोग करता हूं। उन। आप अपने एप्लिकेशन का iOS / Android प्रोजेक्ट खोल सकते हैं और Swift / Kotlin / आदि में कोई अन्य कार्यक्षमता जोड़ सकते हैं। समस्या यह है कि देशी रनटाइम और डार्ट वीएम को एक दूसरे के बारे में कुछ भी पता नहीं होगा (इस तथ्य के अलावा कि देशी रनटाइम को पता चल जाएगा कि आवेदन में कैनवस है और वहां कुछ प्रदर्शित होता है)। इसके अलावा, यदि आप, उदाहरण के लिए, अपने Android प्रोजेक्ट की MainActivity.kt फ़ाइल खोलें, तो आपको कुछ इस तरह दिखाई देगा:

class MainActivity: FlutterActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    GeneratedPluginRegistrant.registerWith(this)
  }
}

क्या आपने देखा है कि आपकी गतिविधि FlutterActivity से विरासत में मिली है? यह हमें Flutter / DartVM को सीधे संदेश भेजने के लिए तंत्र को कॉन्फ़िगर करने का अवसर देता है। ऐसा करने के लिए, हम ओवरराइड करने के लिए जरूरत configureFlutterEngine विधिऔर यह अतुल्यकालिक संदेश भेजने के लिए निर्धारित विधि का नाम और चैनल का नाम निर्धारित करेगा। सब। यह हमें किसी भी मूल कोड को लिखने और किसी भी मूल एपीआई को कॉल करना संभव बनाता है! इसी समय, पहले से ही बड़ी संख्या में प्लगइन्स (पैकेज) हैं जो आपको मूल कोड लिखने से बचाते हैं, आप केवल डार्ट का उपयोग कर सकते हैं। यह सिर्फ अद्भुत है! आप किसी भी प्लेटफ़ॉर्म के लिए अलग-अलग यूआई लिखते हैं और यूआई, आई / ओ के साथ काम करने के लिए डार्टमएम का उपयोग करते हैं और सिर्फ एक कंप्यूटिंग घटक के रूप में, उन प्लगइन्स का उपयोग करते हैं जो देशी सुविधाओं को लागू करते हैं और जो सभी कार्यक्षमता का 99% कवर करते हैं। और अगर यह पर्याप्त नहीं है, तो आप मूल रूप से लिखते हैं और संदेश तंत्र के माध्यम से संवाद करते हैं। कहानी।

दूसरा तंत्र एक विदेशी फ़ंक्शन इंटरफ़ेस या एफएफआई है। यह अन्य भाषाओं के साथ पुनरावृत्ति तंत्र के लिए एक काफी सामान्य शब्द है, मुख्य रूप से सी। .Net दुनिया में, इस तंत्र को P / Invoke कहा जाता है, JVM के लिए यह JNI है। संक्षेप में, यह C / C ++ / आदि में लिखे गए पुस्तकालयों के साथ बातचीत करने की क्षमता है। .Net फ्रेमवर्क के समय, उदाहरण के लिए, C # में कोई सॉफ्टवेयर नहीं लिखा गया था और सॉफ्टवेयर का विशाल बहुमत C / C ++ में लिखा गया था, इसलिए इन पुस्तकालयों के साथ काम करने के लिए एक तंत्र की आवश्यकता थी। यही बात जेवीएम, पायथन पर भी लागू होती है। एफएफआई एक तरह से या अन्य सभी क्रॉस-प्लेटफॉर्म मोबाइल फ्रेमवर्क में उपयोग किया जाता है। अभी हाल ही में, DartVM ने C और JavaScript के साथ व्यवधान के लिए FFI का समर्थन करना भी शुरू कर दिया है! हालांकि यह सुविधा एक बीटा शाखा में है, लेकिन पहले से ही उपयोग के लिए उपलब्ध है (अपने जोखिम और जोखिम पर)।

जैसा कि आप देख सकते हैं, फ़्लटर और डार्टमएम देशी प्लेटफार्मों पर 100% संभावनाओं को कवर करते हैं, और इससे भी अधिक।

जानने के लिए आसान और काफी अभिव्यंजक भाषा

मैं ईमानदारी से मानता हूं, जबकि मेरे लिए डार्ट दुनिया की सबसे अच्छी भाषा नहीं है। कोई सख्त प्रकार की प्रणाली नहीं है, कोई कार्यात्मक बन्स नहीं हैं, जैसे कि पैटर्न मिलान या अपरिवर्तनीयता विशेषताएं (जैसे वे जल्द ही वितरित किए जाएंगे, आदि)। प्रकार प्रणाली के बारे में, डार्ट को मूल रूप से "बिना एक ठेठ" भाषा के रूप में माना गया था, अलास्का जेएस, लेकिन एओटी संकलन के लिए सामान्य समर्थन के लिए टाइप प्रणाली को और अधिक सख्त लाने के लिए आवश्यक था, हालांकि पूरी तरह से नहीं, मैं कहूंगा। यह अभी भी मुझे तर्क के साथ विधि हस्ताक्षर के साथ काम करने की घोषणा करता है। ये सभी कोष्ठक, @requiredकिसी कारण से , क्रुद्ध हैं । लेकिन डार्ट बहुत आसानी से सीखी जाने वाली भाषा है। सिंटैक्स में, यह मेरे लिए जावा और जेएस के बीच एक क्रॉस है। डार्ट जेएस की तरह बहुत क्षमा करता है। सामान्य तौर पर, यह भाषा सीखने में काफी आसान है, मैंने किसी भी महत्वपूर्ण समस्या का अनुभव नहीं किया है।

रैंडाइम जो सामने वाले विकास प्रतिमान में अच्छी तरह से फिट बैठता है

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

आइसोलेट्स

डार्ट वीएम में आइसोलेट अवधारणा है। आइसोलेट एक मुख्य धागे का एक संयोजन है जो सीधे डार्ट कोड और अलग-थलग ढेर पर चलता है, जहां डार्ट कोड से ऑब्जेक्ट वास्तव में आवंटित किए जाते हैं। यह एक सरलीकृत संरचना है। आइसोलेट में सहायक / सिस्टम थ्रेड भी हैं, ओएस थ्रेड हैं जो आइसोलेट, आदि में प्रवेश कर सकते हैं और बाहर निकल सकते हैं। स्टैक आइसोलेट में भी मौजूद है लेकिन आप एक उपयोगकर्ता के रूप में इस पर काम नहीं करते हैं। यहां मुख्य बात जिस पर जोर देने की आवश्यकता है, वह यह है कि यदि आप एक आइसोलेट को देखते हैं, तो यह एकल-थ्रेड वातावरण है। डिफ़ॉल्ट रूप से, फ़्लटर एक डिफ़ॉल्ट आइसोलेट का उपयोग करता है। क्या कुछ भी समान नहीं है? हाँ यह जेएस वातावरण है। जेएस की तरह, डार्ट प्रोग्रामर मल्टीथ्रेडिंग के साथ काम नहीं कर सकते हैं। कोई सोच सकता है कि यह असली डेवलपर्स के अधिकारों का गड़बड़, सरलीकरण और उल्लंघन है, लेकिन मुझे लगता है कि जब यूआई के साथ यूआईजब आप सशर्त DOM के साथ काम करते हैं (और स्क्रीन पर बहुभुज नहीं बनाते हैं), तो आपको कई थ्रेड के साथ काम करना खतरनाक नहीं होगा।

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

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

युवा अंतरिक्ष मेहतर (और समानांतर मार्क स्वीप)

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

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

आइडल टाइम जीसी

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

अन्य चीजें हैं जैसेस्लाइडिंग संघनन और संकुचित पॉइंटर्स । पैरलल मार्क स्वीप को चलाने के बाद पहला मेमोरी डिफ्रैग्मेंटेशन मैकेनिज्म है। यह भी एक महंगी प्रक्रिया है और केवल तभी काम करता है जब Idle Time हो। दूसरा दृष्टिकोण, कंप्रेस्ड पॉइंटर्स, 64-बिट पॉइंटर्स को 32 बिट्स में संपीड़ित करता है, जो मेमोरी बचाता है (मुझे लगता है कि यह एक मोबाइल की तुलना में सर्वर वातावरण में बहुत अधिक उपयोगी है)।

सारांश

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

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

संक्षेप में, मैं कहना चाहता हूं कि यदि आप इस बारे में सोच रहे हैं कि अपना नया मोबाइल एप्लिकेशन विकसित करते समय किस तरफ रुख करें, तो Flutter को देखें।

स्पंदन क्यों जीत रहा है?