अतुल्यकालिक कार्य निष्पादन परत वास्तुकला

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



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


स्पीकर के बारे में: Stepan Goncharov ( stepango ) ग्रैब में काम करता है - यह उबेर की तरह है, लेकिन दक्षिण पूर्व एशिया में। वह 9 वर्षों से अधिक समय से Android विकास में शामिल है। 2014 से कोटलिन में रुचि रखते हैं, और 2016 के बाद से - इसे ठेस में उपयोग करता है। सिंगापुर में कोटलिन यूजर ग्रुप द्वारा आयोजित। यह एक कारण है कि सभी कोड उदाहरण कोटलिन पर होंगे, और इसलिए नहीं कि यह फैशनेबल है।

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

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

RX मुद्दों

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

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

हम इनमें से कुछ समस्याओं को हल करने का प्रयास करेंगे। हम प्रत्येक समस्या को एक बार हल करेंगे, और फिर परिणाम का पुन: उपयोग करेंगे।

समस्या नंबर 1: एक कार्य को एक से अधिक बार करना

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

समस्या को कैसे हल करें? प्रत्येक डेवलपर के पास हल करने के लिए अपना पसंदीदा तरीका होता है: एक पर एक debounce , दूसरा बटन पर clickable = false माध्यम से ब्लॉक हो जाएगा। कोई सामान्य दृष्टिकोण नहीं है, इसलिए ये बग या तो हमारे आवेदन से दिखाई देंगे या गायब हो जाएंगे। हम समस्या का समाधान तभी करते हैं जब QA हमें बताता है: "ओह, मैंने यहाँ क्लिक किया, और यह टूट गया"!

एक स्केलेबल समाधान?

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

चलो हमारे रैपर को "अधिनियम" कहते हैं - अन्य नाम पहले से ही ले लिए गए हैं। ऐसा करने के लिए, एक छोटा typealias और एक सरल interface बनाएं जिसमें केवल एक फ़ील्ड है:

 typealias Id = String interface Act { val id: Id } 

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

संपत्ति में संपत्ति हो सकती है।

जावा से आने वाले प्रोग्रामर के लिए, यह अप्रत्याशित है। आमतौर पर वे इंटरफ़ेस के अंदर getId() तरीके जोड़ते हैं, लेकिन यह गलत समाधान है, getId() के दृष्टिकोण से।

हम कैसे डिजाइन करेंगे?

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

पर्याप्त आईडी क्यों नहीं है?

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

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

नए अंश प्रस्तुत कर रहे हैं: MapDisposable

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

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

हम MapDisposable को इस तरह कहते हैं क्योंकि घटक मैप की तरह काम करेगा, लेकिन इसमें कंपोजिटोसिपेबल गुण होंगे।

नए अंश प्रस्तुत कर रहे हैं: ActExecutor

अगला सार घटक ActExecutor है। यह नए कार्यों को शुरू करता है या शुरू नहीं करता है, यह मैपडिसपोजेबल पर निर्भर करता है और त्रुटि से निपटने को दर्शाता है। नाम कैसे चुनें - प्रलेखन देखें ।

JDK से निकटतम सादृश्य लें। इसमें एक एक्जिक्यूटर है जिसमें आप थ्रेड पास कर सकते हैं और कुछ कर सकते हैं। यह मुझे लगता है कि यह एक अच्छा घटक है और इसे अच्छी तरह से डिज़ाइन किया गया है, इसलिए इसे आधार के रूप में लें।

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

 interface ActExecutor { fun execute( act: Act, e: (Throwable) -> Unit = ::logError) } interface MapDisposable { fun contains(id: Id): Boolean fun add(id: Id, disposable: () -> T) fun remove(id: Id) } 

MapDisposable भी सीमित है: मैप इंटरफ़ेस लें और contains तरीकों को कॉपी करें, add और remove । add मेथड मेप से अलग है: दूसरा तर्क सुंदरता और सुविधा के लिए लंबोदर है। सुविधा यह है कि हम अप्रत्याशित दौड़ की स्थिति को रोकने के लिए लैम्ब्डा को सिंक्रनाइज़ कर सकते हैं । लेकिन हम इस बारे में बात नहीं करेंगे, हम वास्तुकला के बारे में जारी रखेंगे।

इंटरफ़ेस कार्यान्वयन

हमने सभी इंटरफेस घोषित किए हैं और कुछ सरल लागू करने की कोशिश करेंगे। कंप्लीटटेबल एक्ट और सिंगलएक्ट लें।

 class CompletableAct ( override val id: Id, override val completable: Completable ) : Act class SingleAct<T : Any>( override val id: Id, override val single: Single<T> ) : Act 

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

सिंगल के लिए, हमने जेनेरिक प्रकार <T : Any> निर्दिष्ट किया। कोटलिन डेवलपर के रूप में, मैं सिर्फ इस तरह के दृष्टिकोण का उपयोग करना पसंद करता हूं।

नॉन-नाल जेनरिक का उपयोग करने का प्रयास करें।

अब जबकि हमारे पास इंटरफेस का एक सेट है, हम उसी अनुरोध के निष्पादन को रोकने के लिए कुछ तर्क को लागू करते हैं।

 class ActExecutorImpl ( val map: MapDisposable ): ActExecutor { fun execute( act: Act, e: (Throwable) -> Unit ) = when { map.contains(act.id) -> { log("${act.id} - in progress") } else startExecution(act, e) log("${act.id} - Started") } } 

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

बहुत चौकस के लिए - कोई सिंक्रनाइज़ेशन नहीं है, लेकिन GitHub पर स्रोत कोड में सिंक्रनाइज़ेशन है।

 fun startExecution(act: Act, e: (Throwable) -> Unit) { val removeFromMap = { mapDisposable.remove(act.id) } mapDisposable.add(act.id) { when (act) { is CompletableAct -> act.completable .doFinally(removeFromMap) .subscribe({}, e) is SingleAct<*> -> act.single .doFinally(removeFromMap) .subscribe({}, e) else -> throw IllegalArgumentException() } } 

कोड की पठनीयता में सुधार के लिए अंतिम तर्क के रूप में लंबोदा का उपयोग करें। यह सुंदर है और आपके सहयोगी आपको धन्यवाद देंगे।

हम कुछ और कोटलिन चिप्स का उपयोग करेंगे और कंप्लीटटेबल और सिंगल के लिए एक्सटेंशन फ़ंक्शन जोड़ेंगे। उनके साथ, हमें एक कंप्लीटटेबल एक्ट और सिंगलएक्ट बनाने के लिए एक फैक्ट्री मेथड की तलाश नहीं करनी होगी - हम उन्हें एक्सटेंशन फ़ंक्शंस के लिए बनाएंगे।

 fun Completable.toAct(id: Id): Act = CompletableAct(id, this) fun <T: Any> Single<T>.toAct(id: Id): Act = SingleAct(id, this) 

विस्तार कार्यों को किसी भी वर्ग में जोड़ा जा सकता है।

परिणाम

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

 fun act() = Completable.timer(2, SECONDS).toAct("Hello") executor.apply { execute(act()) execute(act()) execute(act()) } Hello - Act Started Hello - Act Duplicate Hello - Act Duplicate Hello - Act Finished 

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

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

समस्या संख्या 2: किस कार्य को रद्द करना है?

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

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

घटक जोड़ें

हम क्वेरी व्यवहार रणनीतियों को कहते हैं और उनके लिए दो इंटरफेस बनाते हैं: रणनीतिहार्ड और रणनीति । हम 2 ऑब्जेक्ट भी बनाते हैं जो कि किस रणनीति के लिए जिम्मेदार हैं।

 interface StrategyHolder { val strategy: Strategy } sealed class Strategy object KillMe : Strategy() object SaveMe : Strategy() 

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

सीलबंद वर्ग को कम विस्तार और लिखना आसान है।

मौजूदा घटकों को अद्यतन करना

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

 interface Act : StrategyHolder { val id: String } class CompletableAct( override val id: String, override val completable: Completable, override val strategy: Strategy = SaveMe ) : Act 

रणनीति

मैंने SaveMe रणनीति चुनी , जो मुझे स्पष्ट लगती है। यह रणनीति केवल निम्नलिखित अनुरोधों को रद्द करती है - पहला अनुरोध हमेशा पूरा होने तक रहेगा।

हमने अपने कार्यान्वयन पर थोड़ा काम किया। हमारे पास एक निष्पादन विधि थी, और अब हमने वहां एक रणनीति जांच जोड़ी है।

• यदि SaveMe रणनीति वही है जो हमने पहले किया था, तो कुछ भी नहीं बदला है।
  
• यदि रणनीति किलमे है , तो पिछले अनुरोध को मार दें और एक नया लॉन्च करें।
  

 override fun execute(act: Act, e: (Throwable) -> Unit) = when { map.contains(act.id) -> when (act.strategy) { KillMe -> { map.remove(act.id) startExecution(act, e) } SaveMe -> log("${act.id} - Act duplicate") } else -> startExecution(act, e) } 

परिणाम

हम न्यूनतम कोड लिखकर आसानी से रणनीतियों का प्रबंधन करने में सक्षम थे। साथ ही, हमारे सहयोगी खुश हैं, और हम ऐसा कुछ कर सकते हैं।

 executor.apply { execute(Completable.timer(2, SECONDS) .toAct("Hello", KillMe)) execute(Completable.timer(2, SECONDS) .toAct("Hello", KillMe)) execute(Completable.timer(2, SECONDS) .toAct("Hello«, KillMe)) } Hello - Act Started Hello - Act Canceled Hello - Act Started Hello - Act Canceled Hello - Act Started Hello - Act Finished 

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

समस्या 3: पर्याप्त रणनीति नहीं

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

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

बहुत सारे सवाल हैं। कैसे समझें कि प्रश्न संबंधित हैं? इन कनेक्शनों को कैसे स्टोर करें? जटिल स्क्रिप्ट कैसे संभालें और कॉपी-पेस्ट न करें? नए घटकों का नाम कैसे दें? कार्य जटिल हैं, और जो हमने पहले ही लागू किया है वह समाधान के लिए उपयुक्त नहीं है।

समूहों के लिए समूह और रणनीति

GroupStrategyHolder नामक एक सरल इंटरफ़ेस बनाएँ। यह थोड़ा अधिक जटिल है - एक के बजाय दो क्षेत्र।

 interface GroupStrategyHolder { val groupStrategy: GroupStrategy val groupKey: String } sealed class GroupStrategy object Default : GroupStrategy() object KillGroup : GroupStrategy() 

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

 interface Act : StrategyHolder, GroupStrategyHolder { val id: String } class CompletableAct( override val id: String, override val completable: Completable, override val strategy: Strategy = SaveMe, override val groupStrategy: GroupStrategy = Default override val groupKey: String = "" ) : Act 

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

कार्यान्वयन को अद्यतन करें

हम निष्पादित विधि पर लौटते हैं। तीसरा कार्य अधिक जटिल है, लेकिन समाधान काफी सरल है: हम एक विशिष्ट अनुरोध के लिए समूह की रणनीति की जांच करते हैं और, यदि यह किलग्रुप है, तो हम पूरे समूह को मारते हैं और सामान्य तर्क निष्पादित करते हैं।

 MapDisposable -> GroupDisposable ... override fun execute(act: Act, e: (Throwable) -> Unit) { if (act.groupStrategy == KillGroup) groupDisposable.removeGroup(act.groupKey) return when { groupDisposable.contains(act.groupKey, act.id) -> when (act.strategy) { KillMe -> { stop(act.groupKey, act.id) startExecution(act, e) } SaveMe -> log("${act.id} - Act duplicate") } else -> startExecution(act, e) } } 

समस्या जटिल है, लेकिन हमारे पास पहले से ही पर्याप्त पर्याप्त बुनियादी ढांचा है - हम इसका विस्तार कर सकते हैं और समस्या का समाधान कर सकते हैं। यदि आप हमारे परिणाम को देखते हैं, तो अब हमें क्या करने की आवश्यकता है?

परिणाम

 fun act(id: String)= Completable.timer(2, SECONDS).toAct( id = id, groupStrategy = KillGroup, groupKey = "Like-Dislike-PostId-1234" ) executor.apply { execute(act(“Like”)) execute(act(“Dislike”)) execute(act(“Like”)) } Like - Act Started Like - Act Canceled Dislike - Act Started Dislike - Act Canceled Like - Act Started Like - Act Finished 

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

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

पिछले उदाहरण में, हमने अधिनियम बनाने के लिए नामित मापदंडों का उपयोग किया है। यह कूल कोड पठनीयता में मदद करता है, खासकर जब बहुत सारे पैरामीटर होते हैं।

आसान पढ़ने के लिए, नामित मापदंडों का उपयोग करें।

आर्किटेक्चर

आइए देखें कि यह निर्णय हमारी वास्तुकला को कैसे प्रभावित कर सकता है। परियोजनाओं पर, मैं अक्सर देखता हूं कि व्यू मॉडल या प्रस्तुतकर्ता बहुत सारी ज़िम्मेदारी लेते हैं, जैसे कि हैक, किसी तरह से / नापसंद के साथ स्थिति को संभालना। आमतौर पर व्यू मॉडल में यह सभी तर्क: बटन लॉकिंग, लाइफ साइकिल हैंडलर, सदस्यता के साथ बहुत सारे डुप्लिकेट कोड।



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

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

और क्या जोड़ना है?

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

संभावनाएं

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

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

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

आइए संभावनाओं पर अधिक विस्तार से विचार करें।

जीवन चक्र प्रसंस्करण

 class ActExecutorImpl( lifecycle: Lifecycle ) : ActExecutor { inir { lifecycle.doOnDestroy { cancelAll() } } ... 

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

बचाना / बहाल करना

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

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

जंजीरों को बुलाओ

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

मैट्रिक्स

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

, , , , - - 10% . , .

निष्कर्ष

— , . «» . , , , , .

, , . — - , , — . — . , . . .

. Kotlin, . , .

AppsConf 2018, AppsConf 2019 . 38 : , Android, UX, , - , , Kotlin.

, youtube- 22–23 .