यह उन लेखों में से पहला है जहां हम iOS के लिए Reddit एप्लिकेशन की वास्तुकला के बारे में बात करते हैं। यहां हम कार्यक्षमता के बारे में बात कर रहे हैं जो यूआई के करीब काम करती है। विशेष रूप से, मॉडल-व्यू-प्रस्तोता (एमवीपी) वास्तुकला में संक्रमण। ऐसे रिफैक्टरिंग के फायदे:

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

नीचे हमारे स्तरित वास्तुकला का एक दृश्य चित्र है। पहला लेख व्यू और प्रस्तोता स्तरों पर ध्यान केंद्रित करेगा।


हमारे स्तरित वास्तुकला का अंतिम दृश्य

परिवर्तन के लिए आवश्यक शर्तें

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

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

समस्या का सार

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

हमने एमवीसी ताबूत में आखिरी कील लगाई जब हमने टेप के लिए प्रस्तुति स्तर को बदलने का फैसला किया। रेडिट एप्लिकेशन के दर्शक बढ़ रहे हैं, इसलिए स्क्रॉल प्रदर्शन बहुत बार 60 एफपीएस से 45-55 एफपीएस तक नीचा हो गया है। इसका मतलब है कि आपको मूल कार्यान्वयन को बनाए रखते हुए टेप प्रस्तुति परत को फिर से लिखना होगा। लेकिन मौजूदा एमवीसी वास्तुकला में, हम कोड की हजारों लाइनों की नकल किए बिना टेप प्रस्तुति परत को फिर से नहीं लिख सकते हैं।

इसके अलावा, कोड आधार के कई हिस्सों का परीक्षण करना मुश्किल है। कोड प्रस्तुति परत के हार्ड-टेस्टेड क्लास में है, और निर्भरताएं अक्सर अकेले (सिंगलटन) या क्लास में ही हार्ड-कोडेड होती हैं। हम सामान्य परीक्षण की संभावना को महसूस करना चाहते थे।

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

एमवीपी को संक्रमण

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


मॉडल-व्यू-प्रस्तोता चार्ट

बड़े पैमाने पर देखने वाले नियंत्रक से छुटकारा

IOS अनुप्रयोगों के लिए, यह माना जाता है कि दृश्य वस्तुएं UIView के उप-वर्ग हैं, नियंत्रक ऑब्जेक्ट UIViewController के उप-वर्ग हैं, और मॉडल ऑब्जेक्ट सरल ol ऑब्जेक्ट हैं। जैसा कि नाम UIViewController का तात्पर्य है, यहां दृश्य और नियंत्रक एक वस्तु में संयुक्त हैं। यही है, iOS पर MVC मॉडल अक्सर प्रस्तुति स्तर और नियंत्रक के बीच तंग संबंध के कारण अपने फायदे खो देता है। दिलचस्प बात यह है कि Apple खुद इस कनेक्शन को पहचानता है ।


अक्सर, आईओएस के लिए मॉडल-व्यू-कंट्रोलर आर्किटेक्चर में बदल जाता है

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

तो, हम अपने UIViewControllers में सभी बाहरी तर्क निकालते हैं। तब हम प्रस्तुतकर्ता को दृश्य और मॉडल के बीच मध्यस्थ को सौंपते हैं। इस नई भूमिका में, वह UIViewController जैसी वस्तुओं से अनजान है। ध्यान दें कि प्रस्तुतकर्ता एक इंटरफ़ेस के माध्यम से दृश्य के साथ बातचीत करता है। सैद्धांतिक रूप से, आप NSViewController (MacOS के लिए), आदि के लिए एक दृश्य के कार्यान्वयन को बदल सकते हैं।


हम प्रस्तुतकर्ता को प्रस्तुत करने और जिम्मेदारियों को साझा करके ViewController को आसान बनाते हैं

विचारशील एमवीपी विकल्प

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

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

लचीलापन, स्थिरता और स्पष्टता में सुधार

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

एमवीपी वास्तुकला ने हमें दिया है कि इस तरह की संरचना एक मुख्य लाभ है। अब आप किसी विशेष प्रस्तुतकर्ता की संरचना को बदलकर बस नियंत्रक के व्यवहार को बदल सकते हैं। अब हम जटिल और कठोर वंशानुक्रम संरचना को परिभाषित करने के बारे में कम चिंतित हैं। अंत में, देखें नियंत्रकों और प्रस्तुतकर्ता वस्तुओं को समझना आसान है क्योंकि उनके पास कार्यों का एक स्पष्ट सेट है।

प्रस्तुतकर्ता और दृश्य नियंत्रक तर्क के बढ़ते हिस्से को पेश करके, हमने नियंत्रक विरासत पदानुक्रम को सरल बनाया है। नीचे दिए गए आंकड़े से पता चलता है कि हम गैलरीफीड व्यू कॉन्ट्रोलर वर्ग को हटाने में सक्षम थे, क्योंकि हमने यह सभी तर्क प्रस्तुतकर्ता में डाल दिए थे। जैसा कि पहले से ही चर्चा की गई है, विरासत का ऐसा पदानुक्रम समझना आसान है और कम कठोर है।


रचना के माध्यम से वंशानुक्रम के पदानुक्रम को सरल बनाएं

प्रस्तुति परत के कार्यान्वयन के लिए स्वतंत्र परिवर्तन

जैसा कि पहले चर्चा की गई थी, टेप स्क्रॉलिंग प्रदर्शन 60 एफपीएस से 45-55 एफपीएस तक घटने लगा। इसलिए, टेप प्रस्तुति परत के लिए, हमने बनावट का उपयोग करने का निर्णय लिया। यह एक खुला स्रोत Apple UIKit- आधारित प्लेटफॉर्म है जो बैकग्राउंड थ्रेड में प्रीप्रोसेसिंग के माध्यम से इंटरफ़ेस प्रदर्शन को बेहतर बनाता है। पिछले MVC आर्किटेक्चर में, हम बहुत सारे कोड डुप्लीकेशन के बिना प्रस्तुति परत के कार्यान्वयन को बदल नहीं सकते थे।


MVP को लागू करने से पहले, आपको ViewController में बाहरी कोड को डुप्लिकेट करना पड़ा जो कि View (नारंगी) से संबंधित नहीं था

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


एमवीपी कार्यान्वयन के बाद: गैर-दृश्य कोड साझा प्रस्तोता के लिए ले जाया गया

परिणाम क्या है? नीचे दिया गया आरेख टेप स्क्रॉल प्रदर्शन में वृद्धि दर्शाता है। हम बिल्कुल चिकनी स्क्रॉलिंग हासिल करने के लिए लगभग 60 एफपीएस पर रहना चाहते थे।

इकाई परीक्षण

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


इस परत के बाहर गैर-दृश्य कोड ले जाने के बाद परीक्षण क्षेत्र में वृद्धि

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

रेडिट में एमवीपी का महत्वपूर्ण विश्लेषण

हालांकि एमवीपी पर स्विच करने से बहुत मदद मिली है, फिर भी कुछ बातों पर विचार करना बाकी है।

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

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

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


कभी-कभी आप प्रस्तुतकर्ता के बिना एक दृश्य परत से RedditCore परत पर स्विच कर सकते हैं

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

सारांश और भविष्य की योजना

Reddit iOS ऐप में MVP आर्किटेक्चर को फिर से तैयार करने से कई कार्यों को हल करने में मदद मिली। प्रस्तुतकर्ता परत को पेश करके, हमने अन्य कार्यों को बाधित किए बिना, प्रस्तुति परत के नए कार्यान्वयन का समर्थन करने के लिए धीरे-धीरे एप्लिकेशन आर्किटेक्चर विकसित किया। "बड़े पैमाने पर MVC" की सुविधा से कोड स्पष्ट हो गया है - प्रस्तुतकर्ता परत में असंगत तर्क को स्थानांतरित करना। हमने डेवलपर्स को तेजी से पुनरावृति करने और नई सुविधाओं को तैनात करने की क्षमता भी दी। और परीक्षणों में काफी सुधार किया।

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