मल्टीमॉड्यूलरिटी और डैगर 2. यैंडेक्स लेक्चर

जब आपका एप्लिकेशन मल्टी-मॉड्यूल आर्किटेक्चर पर बनाया जाता है, तो आपको यह सुनिश्चित करने के लिए बहुत समय समर्पित करना होगा कि मॉड्यूल के बीच सभी संचार कोड में सही तरीके से लिखे गए हैं। इस काम का आधा हिस्सा डैगर 2 ढांचे को सौंपा जा सकता है। एंड्रॉइड के लिए Yandex.Map समूह के प्रमुख, व्लादिमीर टैगकोव नोक्सा ने डैगर 2 का उपयोग करते हुए बहु- मॉड्यूलरता और डीआई के सुविधाजनक संगठन के पेशेवरों और विपक्षों के बारे में बात की।


- मेरा नाम व्लादिमीर है, मैं Yandex.Maps को विकसित कर रहा हूं और आज मैं आपको मॉड्यूलरिटी और दूसरे डैगर के बारे में बताऊंगा।

मैंने सबसे लंबे हिस्से को तब समझा जब मैंने खुद इसका अध्ययन किया, सबसे तेज़। दूसरा भाग, जिसके ऊपर मैं कई हफ्तों तक बैठा रहा, मैं आपको बहुत जल्दी और संक्षिप्त रूप से बताऊंगा।



हमने मैप्स में मॉड्यूल में विभाजित करने की एक कठिन प्रक्रिया क्यों शुरू की? हम सिर्फ बिल्ड स्पीड बढ़ाना चाहते थे, हर कोई इसके बारे में जानता है।

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

मैं एक जलती हुई चप्पल को फेंकना चाहता हूं [k] उपयुक्त, जो विधानसभा की गति को धीमा कर देती है। मैं उससे बहुत नफरत नहीं करता, लेकिन मैं उससे बहुत प्यार करता हूं। वह मुझे डैगर का उपयोग करने देता है।



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

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

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

मॉड्यूल, मॉड्यूल, मॉड्यूल ... ग्रेड मॉड्यूल, डैगर मॉड्यूल, इंटरफ़ेस मॉड्यूल भयानक हैं।



रिपोर्ट में तीन भाग शामिल होंगे: छोटा, बड़ा और जटिल। सबसे पहले, एजीपी में कार्यान्वयन और एपीआई के बीच का अंतर। एंड्रॉइड ग्रैडल प्लगिन 3.0 अपेक्षाकृत हाल ही में दिखाई दिया है। उसके सामने सब कुछ कैसा था?



यहां एक स्वस्थ डेवलपर की एक विशिष्ट परियोजना है, जिसमें तीन मॉड्यूल शामिल हैं: ऐप मॉड्यूल, जो मुख्य एक है, को इकट्ठा किया जाता है और आवेदन में स्थापित किया जाता है, और दो फ़ीचर मॉड्यूल।

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

हमारा मुख्य मॉड्यूल बदल गया है, हमें इसे किसी तरह से फिर से करने की आवश्यकता है। हम इसमें कोड बदलते हैं। पीला रंग - कोड परिवर्तन।



परियोजना को फिर से प्रस्तुत करने के बाद। यह स्पष्ट है कि एक मॉड्यूल को बदलने के बाद, इसे फिर से बनाया जाना होगा, फिर से तैयार करना होगा। ठीक है।



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

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



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

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



यहां कार्यान्वयन में, यह स्पष्ट रूप से देखा गया है कि कोर और ऐप के बीच एक संबंध है। यहां हम स्पष्ट रूप से समझ सकते हैं कि हमें इसकी आवश्यकता नहीं है, हम इससे छुटकारा चाहते हैं, इसलिए इसे हटा दें। सब कुछ आसान होता जा रहा है।



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



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



हम केवल अपने कोर मॉड्यूल से एपीआई को एक अलग मॉड्यूल, इसके एपीआई को स्थानांतरित कर सकते हैं, जिसका हम उपयोग करते हैं। और एक अलग मॉड्यूल में हम इन इंटरफेस के कार्यान्वयन को निकाल सकते हैं।



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

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



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



एक अन्य विकल्प हमेशा काम नहीं करता है। उदाहरण के लिए, यदि यह किसी प्रकार का नेटवर्क है, तो मैं शायद ही सोच सकता हूं कि यह कैसे हो सकता है, लेकिन यदि यह किसी प्रकार की उपयोगकर्ता लॉगिन स्क्रीन है, तो यह अच्छी तरह से हो सकता है।



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

पहला भाग समाप्त होने के साथ। क्या मॉड्यूल हैं?



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



यदि आपके पास एक छोटी परियोजना है, तो आम के साथ आप अधिक आराम महसूस कर सकते हैं, तो आपको बहुत जोश में नहीं होना पड़ेगा।



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



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



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

हम प्रोजेक्ट में डैगर का उपयोग करते हैं, हम इसे पसंद करते हैं, और हम विभिन्न मॉड्यूल के संदर्भ में इस लाभ से सबसे अधिक लाभ प्राप्त करना चाहते थे।



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

हमारे सुविधा मॉड्यूल के अंदर एक अलग निर्भरता ग्राफ कैसे व्यवस्थित करें?



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



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

लेकिन एक उपाय है। आप सिर्फ कंपोनेंट का उपयोग कर सकते हैं।



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



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



OtherComponent को भी वहां लिखा गया है, और यह भ्रामक है, क्योंकि वास्तव में, आप न केवल वहाँ घटक सम्मिलित कर सकते हैं।

हम वास्तविकता में इस व्यवसाय का उपयोग कैसे करना चाहेंगे?



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



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

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



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

चलो परिणामों पर चलते हैं।



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



एक और महत्वपूर्ण परिणाम। फ़ीचर मॉड्यूल को हाइलाइट करने से पहले, यह इस तरह दिखता था: मेनफ्रेम पर यह 28 सेकंड था, अब यह 49 सेकंड है। हमने पहले मॉड्यूल को आवंटित किया है, और पहले से ही लगभग दो बार विधानसभा का एक मंदी प्राप्त किया है।



और एक अन्य विकल्प हमारे मॉड्यूल का एक साधारण वृद्धिशील संयोजन है, न कि एक सुविधा, जैसा कि पिछले एक में है। मॉड्यूल आवंटित होने तक 28 सेकंड थे। जब हमने एक कोड आवंटित किया, जिसे हर बार पुनर्निर्माण करने की आवश्यकता नहीं थी, और [k] उपयुक्त, जिसे हर बार प्रदर्शन करने की आवश्यकता नहीं थी, हमने तीन सेकंड जीते। भगवान जानता है क्या, लेकिन मुझे उम्मीद है कि प्रत्येक नए मॉड्यूल के साथ, समय केवल घट जाएगा।

यहां लेखों के उपयोगी लिंक दिए गए हैं: एपीआई बनाम कार्यान्वयन , बिल्ड समय माप के साथ लेख , नमूना मॉड्यूल । प्रस्तुति उपलब्ध होगी। आपका धन्यवाद