हमने RIBs आर्किटेक्चर को कैसे लागू किया। रिपोर्ट Yandex.Taxi

हाय, मेरा नाम अलेक्सई वालेकिन है, मैं एंड्रॉइड के लिए एप्लिकेशन लिख रहा हूं। कुछ महीने पहले, मैंने मोबाइल डेवलपर्स के साथ Yandex.Taxi टीम की बैठक में बात की थी। मेरी रिपोर्ट टैक्सियों में आरआईबी की वास्तुकला के लिए संक्रमण के लिए समर्पित थी (आरआईबी शीर्ष तीन राउटर, इंटरेक्टर, बिल्डर के लिए खड़ा है)। यहाँ वीडियो है, और कट के नीचे - एक संकलन:


- यह एक प्रचार के साथ एक ट्रेन पर थोड़ा कूदने का समय है। यह एंड्रॉइड में वास्तुकला के बारे में एक क्लासिक विषय है।

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



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

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



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



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



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

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



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

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



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



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

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



आपके पास हमेशा किसी न किसी तरह की जड़ होती है। यह रूट आरआईबी है। यह तय करता है कि आपके आवेदन की स्थिति के आधार पर, अपने आप में क्या शामिल है: यह या तो अधिकृत या अनधिकृत स्थिति है। आइए हमारे आवेदन के एक उदाहरण को देखें। शायद आप ऑर्डर पर हैं या ऑर्डर पर नहीं हैं।

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



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

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



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

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

यह कोड पर एक नज़र डालने का समय है और यह सब कैसे दिखता है।



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



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



दूसरा भाग, जो बिल्डर में है, व्यसनों के बारे में है, अर्थात, बच्चे को बाहर से कोई व्यसन कैसे मिलता है।



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



इंटरएक्टर अनिवार्य रूप से सबसे महत्वपूर्ण वर्ग है जो व्यावसायिक तर्क है। इसमें केवल इंजेक्शन लगाने की अनुमति है। यह व्यावहारिक रूप से सबसे महत्वपूर्ण चीज है जिसका परीक्षण किया जा रहा है। यह स्ट्रीम RX घटनाओं का उपयोग करके UI परत से एक घटना प्राप्त करता है। प्रस्तुतकर्ता एक इंटरफ़ेस है जो उन तरीकों को परिभाषित करता है जो मेरी घटना प्रदान करती है।

RIB के लिए और क्या सुविधाजनक है? इस तथ्य से कि इंटरेक्टर और प्रस्तुतकर्ता परत पर आप उस इंटरैक्शन को व्यवस्थित कर सकते हैं जो आपको पसंद है। यह एमवीपी, और एमवीवीएम, और एमवीवीआई हो सकता है। यहां हर कोई यह चुनने के लिए स्वतंत्र है कि उसे क्या पसंद है। प्रस्तुतकर्ता ईवेंट की सदस्यता कुछ इस तरह दिख सकती है।



और यहां बताया गया है कि इन घटनाओं का प्रसंस्करण कैसे दिख सकता है।



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



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

यहाँ एक उदाहरण है कि कैसे इंटरएक्टर यूआई घटनाओं को प्राप्त करता है। Rx स्ट्रीम पर एक नज़र डालें।



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



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

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

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

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

आप RIB का उपयोग करके क्या प्राप्त कर सकते हैं? कोड का अलगाव, समझने योग्य सरल वास्तुकला, संशोधन के लिए आसान तरीका, टुकड़ों से छुटकारा, एकल गतिविधि दृष्टिकोण और सुविधाओं के समानांतर विकास की सुविधा।

संदर्भ:
- github.com/uber/RIBs
- github.com/uber/RIBs/tree/master/android/tutorials
- habr.com/en/company/livetyping/blog/320452
- youtu.be/Q5cTT0M0YXg
- github.com/xzaleksey/Role-Playing-System-V2
- github.com/xzaleksey/DeezerSample

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

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