फ्लटर वास्तव में कैसे काम करता है?

विजेट, तत्व, बिल्डकनेक्ट, रेंडरऑजेक्ट, बाइंडिंग क्या हैं? ..?

कठिनाई: शुरुआत

प्रविष्टि

पिछले साल ( नोट: 2018 में ), जब मैंने स्पंदन की शानदार दुनिया में अपनी यात्रा शुरू की, तो इंटरनेट पर बहुत कम जानकारी थी कि आज क्या है। अब, इस तथ्य के बावजूद कि बहुत सारी सामग्रियां पहले ही लिखी जा चुकी हैं, उनमें से केवल एक छोटा हिस्सा इस बारे में बात करता है कि फ्लटर वास्तव में कैसे काम करता है।

विजेट ( विजेट ), तत्व ( तत्व ), बिल्डकॉन्टेक्स क्या हैं? स्पंदन क्यों तेज है? कभी-कभी यह अपेक्षा के अनुरूप काम क्यों नहीं करता है? पेड़ क्या हैं और उनकी आवश्यकता क्यों है?

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

सामग्री:

भाग 1: पृष्ठभूमि

लेख का पहला भाग कुछ प्रमुख अवधारणाओं को प्रस्तुत करता है जिनका उपयोग सामग्री के दूसरे भाग में किया जाएगा और स्पंदन को बेहतर ढंग से समझने में मदद करेगा।

डिवाइस के बारे में थोड़ा सा

आइए अंत से और मूल बातों पर वापस जाएं।

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

वास्तव में, आप सभी देख सकते हैं कि पिक्सेल हैं, जो एक साथ 2-आयामी छवि बनाते हैं, और जब आप अपनी उंगली से स्क्रीन को छूते हैं, तो डिवाइस केवल ग्लास पर आपकी उंगली की स्थिति को पहचानता है।

अधिकांश मामलों में एप्लिकेशन का सारा जादू (देखने के दृष्टिकोण से) इस छवि को निम्नलिखित इंटरैक्शन के आधार पर अपडेट करने के लिए है:

डिवाइस स्क्रीन के साथ ( उदाहरण के लिए, कांच पर एक उंगली )
नेटवर्क के साथ ( उदाहरण के लिए, सर्वर के साथ संचार )
समय के साथ ( जैसे एनीमेशन )
अन्य बाहरी सेंसर के साथ

स्क्रीन पर छवि का दृश्य हार्डवेयर (डिस्प्ले) द्वारा प्रदान किया जाता है, जो नियमित रूप से (आमतौर पर 60 प्रति सेकंड) डिस्प्ले को अपडेट करता है। इसे "ताज़ा दर" कहा जाता है और Hz (हर्ट्ज़) में व्यक्त किया जाता है।

डिस्प्ले GPU (ग्राफिक्स प्रोसेसिंग यूनिट) से डिस्प्ले के लिए जानकारी प्राप्त करता है, जो कि एक विशेष इलेक्ट्रॉनिक सर्किट है जिसे कुछ डेटा (पॉलीगॉन और टेक्सचर) से छवियों को जल्दी से अनुकूलित और डिज़ाइन किया गया है। प्रति सेकंड जितनी बार ग्राफिक्स प्रोसेसर एक "छवि" (= फ्रेम बफर) उत्पन्न कर सकता है उसे प्रदर्शित करने और हार्डवेयर को भेजने के लिए फ्रेम दर ( नोट: फ्रेम दर ) कहा जाता है। इसे प्रति सेकंड फ़्रेम के ब्लॉक का उपयोग करके मापा जाता है ( उदा। 60 फ़्रेम प्रति सेकंड या 60fps )।

आप मुझसे पूछ सकते हैं कि मैंने इस लेख को GPU / हार्डवेयर और एक भौतिक ग्लास सेंसर द्वारा प्रदर्शित 2-आयामी छवि की अवधारणाओं के साथ क्यों शुरू किया, और नियमित स्पंदन विगेट्स के साथ क्या संबंध है?

मुझे लगता है कि यह समझना आसान होगा कि फ़्लटर वास्तव में कैसे काम करता है यदि हम इसे इस दृष्टिकोण से देखते हैं, क्योंकि फ़्लटर एप्लिकेशन के मुख्य लक्ष्यों में से एक यह 2-आयामी छवि बनाना है और इसके साथ बातचीत करने की अनुमति देता है। इसके अलावा, स्पंदन में, यह विश्वास करें या नहीं, लगभग हर चीज स्क्रीन को जल्दी और सही समय पर अपडेट करने की आवश्यकता के कारण है!

कोड और डिवाइस के बीच इंटरफेस

वैसे भी, फ़्लटर में रुचि रखने वाले हर व्यक्ति ने पहले से ही निम्न चित्र को देखा है जो फ़्लटर के उच्च-स्तरीय वास्तुकला का वर्णन करता है।

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

फ़्लटर फ्रेमवर्क एक नीले रंग की एक अमूर्त परत के माध्यम से फ़्लटर इंजन (नीले रंग में) के साथ इंटरैक्ट करता है। एब्स्ट्रैक्शन का यह स्तर डिवाइस के साथ अप्रत्यक्ष बातचीत के लिए कई एपीआई प्रदान करता है।

अमूर्त के इस स्तर के माध्यम से भी, फ़्लटर इंजन फ़्लटर फ्रेमवर्क को सूचित करता है जब:

डिवाइस स्तर पर ब्याज की एक घटना होती है (अभिविन्यास में बदलाव, सेटिंग्स में बदलाव, मेमोरी समस्या, एप्लिकेशन की परिचालन स्थिति ...)
कुछ घटना कांच के स्तर पर होती है (= इशारा)
प्लेटफ़ॉर्म चैनल कुछ डेटा भेजता है
लेकिन यह भी मुख्य रूप से जब फ़्लटर इंजन एक नया फ्रेम प्रस्तुत करने के लिए तैयार है

फ़्लटर फ्रेमवर्क फ़्लटर इंजन रेंडरिंग प्रबंधित करें

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

अपवाद:

इशारे / इशारे (= कांच पर घटना)
प्लेटफ़ॉर्म संदेश (= किसी उपकरण द्वारा उत्पन्न संदेश, जैसे GPS)
डिवाइस संदेश (= संदेश जो डिवाइस स्थिति में परिवर्तन से संबंधित हैं, उदाहरण के लिए, अभिविन्यास, पृष्ठभूमि में भेजे गए अनुप्रयोग, मेमोरी अलर्ट, डिवाइस सेटिंग्स ...)
भविष्य या http प्रतिक्रियाएँ

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

आप मुझसे पूछते हैं: "यदि इशारे से संबंधित किसी प्रकार का कोड निष्पादित होता है और दृश्य परिवर्तन का कारण बनता है, या यदि मैं कार्य की आवृत्ति को सेट करने के लिए टाइमर का उपयोग करता हूं जो दृश्य परिवर्तन (उदाहरण के लिए, एनीमेशन) की ओर जाता है, तो यह कैसे काम करता है?"

यदि आप चाहते हैं कि कोई दृश्य परिवर्तन हो या किसी कोड को टाइमर के आधार पर निष्पादित किया जाए, तो आपको फ़्लटर इंजन को बताने की आवश्यकता है कि कुछ आकर्षित करने की आवश्यकता है।

आमतौर पर, अगली बार फ़्लटर इंजन अपडेट होने पर, यह कुछ कोड को निष्पादित करने के लिए फ़्लटर फ्रेमवर्क पर कॉल करता है और अंततः रेंडरिंग के लिए एक नया दृश्य प्रदान करता है।

इसलिए, एक महत्वपूर्ण सवाल यह है कि फ़्लटर इंजन रेंडरिंग के आधार पर सभी एप्लिकेशन व्यवहार को कैसे व्यवस्थित करता है।

आंतरिक तंत्र का विचार प्राप्त करने के लिए, निम्नलिखित एनीमेशन देखें:

एक संक्षिप्त विवरण (अधिक विवरण बाद में आएगा):

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

RenderView और RenderObject

वर्कफ़्लो के विवरण में गोता लगाने से पहले, रेंडरिंग ट्री की अवधारणा को पेश करने का समय है।

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

ये दृश्य भाग RenderObject नामक वस्तुओं से मेल खाते हैं , जिनका उपयोग किया जाता है:

आकार, स्थिति, ज्यामिति के साथ-साथ "प्रदान की गई सामग्री" के संदर्भ में स्क्रीन के एक निश्चित क्षेत्र को परिभाषित करना
स्क्रीन के उन क्षेत्रों की पहचान करना जो इशारों से प्रभावित हो सकते हैं (= फिंगर टच)

सभी रेंडरऑब्जेक्ट का एक सेट एक पेड़ बनाता है जिसे एक रेंडर ट्री कहा जाता है। इस वृक्ष (= मूल ) के शीर्ष पर हम एक RenderView पाते हैं।

RenderView , Render Tree वस्तुओं के लिए एक सामान्य सतह प्रदान करता है और RenderObject का एक विशेष संस्करण है।

नेत्रहीन, हम इस सब का प्रतिनिधित्व कर सकते हैं:

विजेट और रेंडरऑबजेक्ट के बीच संबंधों पर बाद में चर्चा की जाएगी। इस बीच, यह थोड़ा गहरा जाने का समय है ...

इनिशियल बाइंडिंग

जब फ़्लटर एप्लिकेशन शुरू होता है, तो main() फ़ंक्शन को पहले कहा जाता है, जो अंततः runApp(Widget app) विधि को कॉल करता है।

जब runApp() विधि runApp() तो runApp() फ्रेमवर्क स्वयं और फ़्लटर इंजन के बीच इंटरफेस को इनिशियलाइज़ करता है। इन इंटरफेस को बाइंडिंग ( नोट: बाइंडिंग ) कहा जाता है।

बाइंडिंग का परिचय

बाइंडिंग को फ्रेमवर्क और फ्लटर इंजन के बीच की कड़ी के रूप में बनाया गया है। बाइंडिंग के माध्यम से ही फ़्लटर फ्रेमवर्क और फ़्लटर इंजन के बीच डेटा का आदान-प्रदान किया जा सकता है।
(इस नियम का केवल एक अपवाद है - RenderView , लेकिन हम इस पर बाद में चर्चा करेंगे)।

प्रत्येक बाध्यकारी गतिविधि के क्षेत्र द्वारा समूहीकृत विशिष्ट कार्यों, कार्यों, घटनाओं के एक समूह के प्रसंस्करण के लिए जिम्मेदार है।

इस लेखन के समय, फ़्लटर फ्रेमवर्क में 8 बाइंडिंग हैं।

नीचे उनमें से 4 हैं जिन्हें इस लेख में माना जाएगा:

SchedulerBinding
बंधन बाँधना
रेंडरर बाइंडिंग
विजेट्स बाइंडिंग

पूर्णता के लिए, मैं शेष 4 का उल्लेख करूंगा:

ServicesBinding : प्लेटफ़ॉर्म चैनल द्वारा भेजे गए संदेशों को संसाधित करने के लिए जिम्मेदार
पेंटिंगबाइंडिंग : इमेज कैश को प्रोसेस करने के लिए जिम्मेदार
शब्दार्थ : बंधन : शब्दार्थ से संबंधित हर चीज के बाद के कार्यान्वयन के लिए आरक्षित
TestWidgetsFlutterBinding : विजेट परीक्षण पुस्तकालय द्वारा इस्तेमाल किया

आप WidgetsFlutterBinding का भी उल्लेख कर सकते हैं, लेकिन यह वास्तव में बाध्यकारी नहीं है, बल्कि एक प्रकार का "बाइंडिंग इनिलाइज़र " है ।

निम्नलिखित आरेख बाइंडिंग के बीच बातचीत को दर्शाता है, जिसे मैं अगले और फ़्लटर इंजन पर विचार करने जा रहा हूं।

आइए इनमें से प्रत्येक "कोर" बाइंडिंग को देखें।

SchedulerBinding

इस बंधन की दो मुख्य जिम्मेदारियां हैं:

स्पंदन इंजन कहें: "अरे! अगली बार जब आप व्यस्त नहीं हों, तो मुझे जगाएं ताकि मैं थोड़ा काम कर सकूं और आपको बता सकूं कि क्या प्रस्तुत करना है, या अगर मुझे आपकी ज़रूरत है तो मुझे बाद में कॉल करें ..."
सुनें और इस तरह के "परेशान जागृति" का जवाब दें (नीचे देखें)

शेड्यूलरबाइंडिंग एक वेक-अप कॉल का अनुरोध कब करता है ?

जब टिकर को नया टिक करना होगा

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

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

बंधन बाँधना

यह बाध्यकारी "उंगली" (= इशारा ) के संदर्भ में इंजन के साथ बातचीत करने के लिए सुनता है।

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

रेंडरर बाइंडिंग

यह बंधन फ़्लटर इंजन और रेंडर ट्री के बीच की कड़ी है। वह इसके लिए जिम्मेदार है:

दृश्य प्रभाव और / या शब्दार्थ को प्रभावित करने वाले डिवाइस सेटिंग्स के माध्यम से उपयोगकर्ता द्वारा लागू परिवर्तनों के बारे में सूचित करने के लिए इंजन द्वारा उत्पन्न घटनाओं को सुनना
इंजन में परिवर्तन के बारे में संदेश जो डिस्प्ले पर लागू किया जाएगा

स्क्रीन पर प्रदर्शित होने वाले परिवर्तनों को प्रदान करने के लिए, RendererBinding PipelineOwner को प्रबंधित करने और RenderView को शुरू करने के लिए जिम्मेदार है ।

PipelineOwner एक प्रकार का ऑर्केस्ट्रा है जो जानता है कि घटक के अनुसार RenderObject के साथ क्या किया जाना चाहिए, और इन क्रियाओं का समन्वय करता है।

विजेट्स बाइंडिंग

यह बाध्यकारी उपयोगकर्ता द्वारा डिवाइस सेटिंग्स के माध्यम से लागू किए गए परिवर्तनों को सुनता है जो भाषा (= स्थानीय ) और शब्दार्थ को प्रभावित करते हैं।

छोटा नोट

मेरा मानना है कि स्पंदन के विकास में एक बाद के चरण में , सभी शब्दार्थ से संबंधित घटनाओं को सेमेंटिक्सबाइंडिंग में स्थानांतरित किया जाएगा , लेकिन इस लेखन के समय, यह मामला नहीं है।

इसके अलावा, विजेट्स विगेट्स और फ़्लटर इंजन के बीच की कड़ी है। वह इसके लिए जिम्मेदार है:

विगेट्स की संरचना में परिवर्तन की प्रक्रिया का प्रबंधन
कॉल रेंडर करें

विजेट संरचना में परिवर्तन प्रसंस्करण BuildOwner का उपयोग करके किया जाता है।

BuildOwner ट्रैक रखता है कि किस विजेट को फिर से बनाया जाना है, और अन्य कार्यों को संभालता है जो विजेट संरचना पर लागू होते हैं।

भाग 2. विजेट से पिक्सेल तक

अब जब हमने फ़्लटर के आंतरिक कार्य की मूल बातें सीख ली हैं, तो विजेट्स के बारे में बात करने का समय आ गया है।

सभी फ़्लटर प्रलेखन में आप पढ़ेंगे कि सभी विजेट (विजेट)।

यह लगभग सही है। लेकिन थोड़ा और सटीक होने के लिए, मैं कहना चाहूंगा:

डेवलपर की ओर से, लेआउट और इंटरैक्शन के संदर्भ में उपयोगकर्ता इंटरफ़ेस से संबंधित सब कुछ विगेट्स का उपयोग करके किया जाता है।

इतनी सटीकता क्यों? इस तथ्य के अलावा कि विजेट डेवलपर को आकार, सामग्री, लेआउट और इंटरैक्शन के मामले में स्क्रीन का हिस्सा निर्धारित करने की अनुमति देता है, लेकिन इसके अलावा भी बहुत कुछ है। तो वास्तव में विजेट क्या है?

अपरिवर्तनीय विन्यास

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

 @immutable abstract class Widget extends DiagnosticableTree { const Widget({ this.key }); final Key key; ... }

इसका क्या मतलब है?

एनोटेशन "@immutable" बहुत महत्वपूर्ण है और हमें बताता है कि विजेट वर्ग में किसी भी चर को दूसरे शब्दों में, अंतिम रूप से परिभाषित किया जाना चाहिए : " हर किसी के लिए परिभाषित और असाइन किया गया।" इस प्रकार, एक उदाहरण बनाने के बाद, विजेट अब अपने आंतरिक चर को बदलने में सक्षम नहीं होगा।

चूंकि विजेट अपरिवर्तनीय है, इसलिए इसे एक स्थिर कॉन्फ़िगरेशन माना जा सकता है।

विगेट्स की पदानुक्रमित संरचना

जब आप फ़्लटर के साथ डिज़ाइन करते हैं, तो आप अपनी स्क्रीन की संरचना को कुछ इस तरह से विगेट्स का उपयोग करके परिभाषित करते हैं:

 Widget build(BuildContext context){ return SafeArea( child: Scaffold( appBar: AppBar( title: Text('My title'), ), body: Container( child: Center( child: Text('Centered Text'), ), ), ), ); }

यह उदाहरण 7 विगेट्स का उपयोग करता है जो एक साथ एक पदानुक्रमित संरचना बनाते हैं। इस कोड के आधार पर एक बहुत ही सरल योजना इस प्रकार है:

जैसा कि आप देख सकते हैं, प्रस्तुत आरेख एक पेड़ की तरह दिखता है, जहां SafeArea इसकी जड़ है।

पेड़ों के पीछे जंगल

जैसा कि आप पहले से ही जानते हैं, एक विजेट ही अन्य विजेट का एकत्रीकरण हो सकता है। एक उदाहरण के रूप में, आप पिछले कोड को निम्नानुसार संशोधित कर सकते हैं:

 Widget build(BuildContext context){ return MyOwnWidget(); }

यह विकल्प मानता है कि विजेट "MyOwnWidget" खुद SafeArea , पाड़ प्रदर्शित करेगा। लेकिन इस उदाहरण में सबसे महत्वपूर्ण बात यह है कि

एक विजेट एक पत्ती, एक पेड़ में एक गाँठ, यहां तक कि खुद पेड़ या, क्यों नहीं, पेड़ों का एक जंगल का प्रतिनिधित्व कर सकता है ...

एक पेड़ में तत्व को समझना

इससे क्या लेना-देना है?

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

इस बिंदु को स्पष्ट करने के लिए, एक नेस्टेड गुड़िया के सिद्धांत पर विचार करें: जब बंद होता है, तो आप केवल 1 गुड़िया देखते हैं, लेकिन इसमें एक और होता है, जिसमें बदले में एक और होता है ...

जब स्पंदन सभी विजेट (स्क्रीन का हिस्सा) का विस्तार करता है, तो यह सभी गुड़िया (संपूर्ण का हिस्सा) प्राप्त करने जैसा होगा।

नीचे दी गई तस्वीर पिछले कोड के अनुरूप विगेट्स की अंतिम पदानुक्रमित संरचना का हिस्सा दिखाती है। पीले रंग में, मैंने उन विगेट्स पर प्रकाश डाला, जो पहले कोड में उल्लिखित थे, ताकि आप उन्हें अंतिम पेड़ में परिभाषित कर सकें।

महत्वपूर्ण स्पष्टीकरण

भाषा "विजेट ट्री" केवल समझने में आसानी के लिए मौजूद है, क्योंकि प्रोग्रामर विजेट का उपयोग करते हैं, लेकिन स्पंदन में कोई विजेट ट्री नहीं है!

वास्तव में, "तत्वों का वृक्ष" कहना अधिक सही होगा

यह एक तत्व की अवधारणा को पेश करने का समय है।

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

के साथ शुरू करने के लिए, एक तत्व के बारे में सोचें जो एक नोड है जिसमें माता-पिता और संभवतः एक बच्चा है। माता-पिता-बच्चे के रिश्ते के माध्यम से उन्हें एक साथ जोड़कर, हमें एक पेड़ की संरचना मिलती है।

जैसा कि आप देख सकते हैं, तत्व एक विजेट को इंगित करता है, और एक रेंडरऑब्जेक्ट को भी इंगित कर सकता है ।

इससे भी बेहतर ... तत्व उस विजेट को इंगित करता है जिसने इस तत्व को बनाया है !

आइए संक्षेप:

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

तत्व निर्धारित करते हैं कि प्रदर्शित ब्लॉक के हिस्से एक दूसरे से कैसे संबंधित हैं।

बेहतर कल्पना करने के लिए कि किसी तत्व की अवधारणा कहाँ फिट होती है, आइए निम्नलिखित दृश्य प्रतिनिधित्व को देखें:

जैसा कि आप देख सकते हैं, तत्व पेड़ विगेट्स और रेंडरऑब्जेक्ट्स के बीच वास्तविक संबंध है।

लेकिन विजेट एक तत्व क्यों बनाता है?

विगेट्स की 3 श्रेणियां

स्पंदन में, विगेट्स को 3 श्रेणियों में विभाजित किया गया है, मैं व्यक्तिगत रूप से उन्हें निम्नानुसार कॉल करता हूं (लेकिन यह केवल उन्हें वर्गीकृत करने का मेरा तरीका है) :

प्रतिनिधि

इन विगेट्स का मुख्य उद्देश्य कुछ जानकारी (जो विजेट के लिए सुलभ होना चाहिए) को स्टोर करना है, जो प्रॉक्सी के आधार पर पेड़ की संरचना का हिस्सा है। इस तरह के विजेट का एक उदाहरण InheritedWidget या LayoutId है ।

ये विगेट्स सीधे यूजर इंटरफेस के निर्माण में भाग नहीं लेते हैं, लेकिन इनका उपयोग सूचना प्रदान करने के लिए किया जाता है।
रेंडरर

ये विजेट सीधे स्क्रीन के लेआउट से संबंधित हैं, क्योंकि वे आकार , स्थिति , प्रतिपादन का निर्धारण (या निर्धारित करने के लिए उपयोग किया जाता है)। विशिष्ट उदाहरण हैं: रो , कॉलम , स्टैक , साथ ही पैडिंग , संरेखित , अस्पष्टता , रॉइमैसेज ...
अंग

ये अन्य विजेट हैं जो सीधे आकार, स्थिति, उपस्थिति से संबंधित अंतिम जानकारी प्रदान नहीं करते हैं, बल्कि वे डेटा (या युक्तियां) हैं जिनका उपयोग उसी अंतिम जानकारी को प्राप्त करने के लिए किया जाएगा। इन विगेट्स को आमतौर पर घटकों के रूप में संदर्भित किया जाता है।

उदाहरण: RaisedButton , Scaffold , Text , GestureDetector , कंटेनर ...

यह पीडीएफ फाइल श्रेणी के आधार पर वर्गीकृत किए गए अधिकांश विजेट्स को सूचीबद्ध करती है।

यह अलगाव क्यों महत्वपूर्ण है? क्योंकि विजेट की श्रेणी के आधार पर, संबंधित तत्व प्रकार के साथ जुड़ा हुआ है ...

आइटम प्रकार

कई प्रकार के तत्व हैं:

जैसा कि आप ऊपर चित्र में देख सकते हैं, तत्वों को 2 मुख्य प्रकारों में विभाजित किया गया है:

ComponentElement

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

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

बहुत बढ़िया! इतनी जानकारी, लेकिन यह सब एक दूसरे से कैसे जुड़ा है और इसके बारे में बात करना क्यों दिलचस्प है?

विगेट्स और एलिमेंट्स एक साथ कैसे काम करते हैं

स्पंदन में, सभी यांत्रिकी एक तत्व या रेंडरऑबजेक्ट को अमान्य करने पर आधारित हैं।

तत्व अमान्यकरण निम्नलिखित तरीकों से किया जा सकता है:

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

अमान्य होने का परिणाम यह है कि संबंधित तत्व का एक लिंक गंदे तत्वों की सूची में दिखाई देता है।

रेंडरऑबजेक्ट के अमान्य होने का मतलब है कि तत्वों की संरचना बिल्कुल नहीं बदलती है, लेकिन रेंडर ऑबजेक्ट के स्तर पर बदलाव होता है , उदाहरण के लिए:

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

इस तरह के अमान्यकरण का परिणाम प्रस्तुत करने वाली वस्तुओं (रेंडरऑब्जेक्ट) की सूची में संबंधित रेंडरऑबजेक्ट का एक लिंक है, जिसे पुन: निर्मित या पुन: प्रस्तुत करने की आवश्यकता होती है।

अमान्यकरण के प्रकार के बावजूद, शेड्यूलरबाइंडिंग कहा जाता है (इसे याद रखें?) एक नए फ्रेम को शेड्यूल करने के लिए फ़्लटर इंजन का अनुरोध करने के लिए।

यह ठीक वही क्षण है जब फ़्लटर इंजन "जगाता है" शेड्यूलर बाइंडिंग और सभी जादू होता है ...

ऑनफ्रेम ()

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

नीचे दिए गए आंशिक अनुक्रम आरेख से पता चलता है कि क्या होता है जब शेड्यूलर बाइंडिंग को फ़्लटर इंजन से onDrawFrame () अनुरोध प्राप्त होता है।

चरण 1. तत्व

विजेटबाइंडिंग कहा जाता है , और यह बाइंडिंग पहले तत्वों से जुड़े परिवर्तनों पर विचार करता है। WidgetsBinding buildOwner ऑब्जेक्ट के buildScope विधि को कॉल करता है, क्योंकि BuildOwner आइटम ट्री को संसाधित करने के लिए ज़िम्मेदार है। यह विधि गंदे तत्वों की सूची के माध्यम से जाती है और उनके पुनर्निर्माण का अनुरोध करती है।

इस rebuild() विधि ( rebuild() ) के मुख्य सिद्धांत हैं:

विजेट के build() पद्धति को कॉल करके build() इस तत्व को संदर्भित करता है) (= Widget build (BuildContext context) {...} विधि) को बुलाकर तत्व (इस समय का सबसे अधिक समय लगेगा) के पुनर्निर्माण का अनुरोध है। यह build() विधि एक नया विजेट लौटाएगी
यदि तत्व में "बच्चे" नहीं हैं, तो नए विजेट के लिए एक तत्व बनाया जाता है (नीचे देखें) ( ध्यान दें: inflateWidget ), अन्यथा
नए विजेट की तुलना तत्व के बच्चे द्वारा संदर्भित की गई है
- यदि वे विनिमेय हैं (= एक ही विजेट प्रकार और कुंजी ), तो अद्यतन होता है और बच्चा बच जाता है।
- यदि वे विनिमेय नहीं हैं, तो बच्चे को त्याग दिया जाता है ( ~ खारिज ) और नए विजेट के लिए एक तत्व बनाया जाता है
यह नया आइटम आइटम के एक बच्चे के रूप में मुहिम शुरू की है। ( घुड़सवार) = तत्व वृक्ष में डाला गया)

निम्नलिखित एनीमेशन इस स्पष्टीकरण को थोड़ा स्पष्ट करने की कोशिश करेंगे।

विजेट और तत्वों पर ध्यान दें

एक नए विजेट के लिए, एक विशिष्ट प्रकार का एक तत्व बनाया जाता है जो विजेट श्रेणी से मेल खाता है, अर्थात्:

InheritedWidget -> InheritedElement
StatefulWidget -> स्टेटफुलमेंट
स्टेटलेसविजेट -> स्टेटलेसलेसमेंट
InheritedModel -> InheritedModelElement
InheritedNotifier -> InheritedNotifierElement
लीफ़रेंडरऑब्जेक्टविजेट -> लीफ़रेंडरऑब्जेक्टविप्लमेंट
SingleChildRenderObjectWidget -> SingleChildRenderObjectElement
MultiChildRenderObjectWidget -> MultiChildRenderObjectElement
ParentDataWidget -> ParentDataElement

इन प्रकार के तत्वों में से प्रत्येक का अपना व्यवहार है। उदाहरण के लिए:

स्टेटफुलमेंट , इनिशियलाइज़ेशन पर widget.createState() विधि को कॉल करेगा, जो एक स्टेट बनाएगा और इसे एलिमेंट के साथ संबद्ध करेगा
जब RenderObjectElement प्रकार का एक तत्व माउंट किया जाता है, तो यह एक RenderObject बनाता है। यह रेंडरऑब्जेक्ट को रेंडर ट्री में जोड़ा जाएगा और तत्व से संबद्ध किया जाएगा।

चरण 2. रेंडरऑब्जेक्ट

अब गंदे तत्वों से जुड़े सभी कार्यों को पूरा करने के बाद, एलिमेंट ट्री स्थिर है। तो यह दृश्य प्रक्रिया पर विचार करने का समय है।

चूंकि RendererBinding , Render Tree को रेंडर करने के लिए ज़िम्मेदार है, WidgetsBinding drawFrame विधि को कॉल करता है।

नीचे दिया गया आंशिक आरेख ड्राफ्रेम () अनुरोध के दौरान किए गए कार्यों के अनुक्रम को दर्शाता है।

इस कदम पर, निम्नलिखित क्रियाएं की जाती हैं:

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

इस वर्कफ़्लो के अंत में, डिवाइस स्क्रीन ताज़ा हो जाती है।

भाग 3: इशारों को संभालना

इशारों (= कांच पर उंगली की कार्रवाई से संबंधित घटनाएं ) को GestureBinding का उपयोग करके संसाधित किया जाता है ।

जब फ़्लटर इंजन विंडो के माध्यम से एक इशारे से संबंधित घटना के बारे में जानकारी भेजता है। PointerDataPacket API, GestureBinding इसे स्वीकार करता है, कुछ बफरिंग करता है, और:

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

उम्मीद है कि अब मुझे समझ में आया कि कितना महत्वपूर्ण है ।

भाग 4: एनिमेशन

लेख का यह हिस्सा एनीमेशन की अवधारणा और टिकर की गहरी समझ के बारे में है।

जब आप एनिमेशन के साथ काम करते हैं, तो आप आमतौर पर एनिमेशन के लिए एक एनिमेशनकंट्रोलर या किसी भी विजेट का उपयोग करते हैं ( ध्यान दें: एनीमेटेडक्रॉसफेड )।

स्पंदन में, एनिमेशन से संबंधित सब कुछ टिकर को संदर्भित करता है। टिकर , जब यह सक्रिय होता है, इसका केवल एक ही कार्य होता है: "यह शेड्यूलरबाइंडिंग को कॉलबैक रजिस्टर करने के लिए कहता है और फ़्लटर इंजन को यह बताने के लिए कहता है कि एक नया कॉलबैक प्रकट होने पर उसे जगाने के लिए।" जब फ़्लटर इंजन तैयार हो जाता है, तो यह शेड्यूलरबाइंडिंग को एक अनुरोध के माध्यम से कहता है: " ऑनबिजिनफ्रेम "। SchedulerBinding टिकर कॉलबैक सूची तक पहुँचता है और प्रत्येक को निष्पादित करता है।

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

पूरी तस्वीर

अब हमने सीखा है कि स्पंदन कैसे काम करता है:

BuildContext

अंत में, विभिन्न प्रकार के तत्वों को दिखाने वाले आरेख पर वापस जाएं, और मूल तत्व के हस्ताक्षर पर विचार करें:

 abstract class Element extends DiagnosticableTree implements BuildContext { ... }

हम बहुत प्रसिद्ध BuildContext देखते हैं! लेकिन यह क्या है?

बिल्डकॉनटेक्स्ट एक इंटरफ़ेस है जो कई गेटर्स और तरीकों को परिभाषित करता है जिन्हें एक तत्व द्वारा लागू किया जा सकता है। ज्यादातर BuildContext स्टेटफुलवगेट के लिए स्टेटलेसविडगेट या स्टेट के build() पद्धति में उपयोग किया जाता है।

BuildContext तत्व के अलावा और कुछ नहीं है, जो मेल खाता है
विजेट अपडेट किया जा रहा है ( build या builder तरीकों के अंदर)
StatefulWidget राज्य से संबंधित है जिसमें आप संदर्भ चर का संदर्भ देते हैं।

इसका मतलब है कि अधिकांश डेवलपर्स लगातार इसके बारे में जाने बिना भी तत्वों के साथ काम करते हैं।

बिल्डकॉनटेक्स्ट कितना उपयोगी हो सकता है?

BuildContext , , , BuildContext , :

RenderObject , (, Renderer , -)
RenderObject
. , of (, MediaQuery.of(context) , Theme.of(context) …)

, , BuildContext – , . StatelessWidget , StatefulWidget , setState() , BuildContext .

, !

– , StatelessWidget .
, , StatefulWidget .

 void main(){ runApp(MaterialApp(home: TestPage(),)); } class TestPage extends StatelessWidget { // final because a Widget is immutable (remember?) final bag = {"first": true}; @override Widget build(BuildContext context){ return Scaffold( appBar: AppBar(title: Text('Stateless ??')), body: Container( child: Center( child: GestureDetector( child: Container( width: 50.0, height: 50.0, color: bag["first"] ? Colors.red : Colors.blue, ), onTap: (){ bag["first"] = !bag["first"]; // // This is the trick // (context as Element).markNeedsBuild(); } ), ), ), ); } }

, setState() , : _element.markNeedsBuild() .

निष्कर्ष

: " ". , , Flutter , , , , . , , Widget , Element , BuildContext , RenderObject , . , .

. .

PS , () .
PSS Flutter internals Didier Boelens, )

कैसे स्पंदन काम करता है