Android में प्रतियोगिता के लिए एक आधुनिक दृष्टिकोण: कोटलिन में कोरोटिंस

नमस्कार, हेब्र!

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

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

Kotlin coroutines एक बहुत प्रभावी और पूर्ण टूलकिट है जो प्रबंध प्रतियोगिता को बहुत आसान और अधिक उत्पादक बनाती है।

रोकें और ब्लॉक करें: क्या अंतर है

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

इस मामले में कॉरटीन का लक्ष्य कॉलबैक से दूर करना और प्रतियोगिता को सरल बनाना है।

सरलतम उदाहरण

के साथ शुरू करने के लिए, चलो सबसे सरल उदाहरण लेते हैं: Main (मुख्य धागा) के संदर्भ में कोरटाइन चलाएं। इसमें, हम IO स्ट्रीम से इमेज निकालेंगे और इस इमेज को Main वापस प्रोसेसिंग के लिए भेजेंगे।

 launch(Dispatchers.Main) { val image = withContext(Dispatchers.IO) { getImage() } //    IO imageView.setImageBitmap(image) //     } 

एक एकल-थ्रेडेड फ़ंक्शन के रूप में कोड सरल है। इसके अलावा, जब getImage को IO थ्रेड्स के आवंटित पूल में निष्पादित किया जाता है, तो मुख्य धागा मुफ़्त है और किसी अन्य कार्य को ले सकता है! WithContext फ़ंक्शन वर्तमान coroutine को रोक देता है जबकि इसकी क्रिया चल रही है ( getImage() )। जैसे ही getImage() रिटर्न और मुख्य धागे से looper उपलब्ध हो जाता है, imageView.setImageBitmap(image) मुख्य धागे में काम फिर से शुरू करेगा और imageView.setImageBitmap(image) कॉल imageView.setImageBitmap(image) ।

दूसरा उदाहरण: अब हमें 2 पृष्ठभूमि कार्यों को पूरा करने की आवश्यकता है ताकि उनका उपयोग किया जा सके। हम एसिंक्स / प्रतीक्षित युगल का उपयोग करेंगे ताकि ये दोनों कार्य समानांतर में किए जाएँ, और दोनों कार्य तैयार होते ही मुख्य परिणाम में उनके परिणाम का उपयोग करें:

 val job = launch(Dispatchers.Main) { val deferred1 = async(Dispatchers.Default) { getFirstValue() } val deferred2 = async(Dispatchers.IO) { getSecondValue() } useValues(deferred1.await(), deferred2.await()) } job.join() //    ,      

async launch समान है, लेकिन डिफर्ड ( Future बराबर एक कोटलिन इकाई) देता है, इसलिए इसका परिणाम await() का उपयोग करके प्राप्त किया जा सकता है। जब मापदंडों के बिना बुलाया जाता है, तो यह वर्तमान गुंजाइश के लिए डिफ़ॉल्ट संदर्भ में काम करता है।

फिर से, मुख्य धागा मुक्त रहता है जबकि हम अपने 2 मूल्यों की प्रतीक्षा करते हैं।
जैसा कि आप देख सकते हैं, launch फ़ंक्शन Job देता है, जिसका उपयोग ऑपरेशन पूरा होने तक प्रतीक्षा करने के लिए किया जा सकता है - यह join() फ़ंक्शन का उपयोग करके किया जाता है। यह किसी भी अन्य भाषा की तरह काम करता है, इस चेतावनी के साथ कि यह कोरटाइन को निलंबित कर देता है, और प्रवाह को अवरुद्ध नहीं करता है ।

भेजने

कोरआउट के साथ काम करते समय डिस्पैचिंग एक प्रमुख अवधारणा है। यह क्रिया आपको एक धागे से दूसरे में "कूद" करने की अनुमति देती है।

विचार करें कि Main में प्रेषण के लिए बराबर क्या जावा में दिखता है, अर्थात्।

 runOnUiThread: public final void runOnUiThread(Runnable action) { if (Thread.currentThread() != mUiThread) { mHandler.post(action); //  } else { action.run(); //   } } 

एंड्रॉइड के लिए Main संदर्भ कार्यान्वयन Handler आधारित डिस्पैचर है। तो यह वास्तव में एक बहुत ही उपयुक्त कार्यान्वयन है:

 launch(Dispatchers.Main) { ... } vs launch(Dispatchers.Main, CoroutineStart.UNDISPATCHED) { ... } //   kotlinx 0.26: launch(Dispatchers.Main.immediate) { ... } 

launch(Dispatchers.Main) Runnable to Handler भेजता है, इसलिए इसका कोड तुरंत निष्पादित नहीं होता है।

launch(Dispatchers.Main, CoroutineStart.UNDISPATCHED) वर्तमान थ्रेड में अपनी लैम्ब्डा अभिव्यक्ति को तुरंत निष्पादित करेगा।

Dispatchers.Main । मेन यह सुनिश्चित करता है कि जब कोरटाइन काम करना शुरू करे, तो इसे मुख्य धागे में निर्देशित किया जाएगा ; इसके अलावा, हैंडलर का उपयोग एप्लिकेशन इवेंट लूप में भेजने के लिए एक देशी Android कार्यान्वयन के रूप में किया जाता है।

सटीक कार्यान्वयन इस तरह दिखता है:

 val Main: HandlerDispatcher = HandlerContext(mainHandler, "Main") 

Android में प्रेषण की पेचीदगियों को समझने में मदद करने के लिए यहाँ एक अच्छा लेख है:
एंड्रॉइड कोर को समझना: लोपर, हैंडलर और हैंडलरथ्रेड ।

Coroutine प्रसंग

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

 val job = Job() val exceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable -> whatever(throwable) } launch(Disaptchers.Default+exceptionHandler+job) { ... } 

job.cancel() उन सभी job.cancel() को रद्द कर देगा, जिनके माता-पिता job । एक अपवाद हैंडलर को इन कोरआउट्स में फेंके गए सभी अपवाद प्राप्त होंगे।

क्षेत्र

coroutineScope इंटरफ़ेस त्रुटि से निपटने को सरल coroutineScope है:
यदि इसकी कोई बेटी कोरआउट विफल हो जाती है, तो पूरा दायरा और सभी बाल वाहिनी भी रद्द कर दी जाएंगी।

async उदाहरण में, यदि मान निकालना संभव नहीं था, जबकि एक और कार्य जारी रहा, हमारे पास एक क्षतिग्रस्त राज्य है, और इसके साथ कुछ करने की आवश्यकता है।

useValues साथ काम करते समय, useValues फ़ंक्शन को केवल तभी कहा जाएगा जब दोनों मानों का निष्कर्षण सफल होगा। इसके अलावा, यदि deferred2 विफल रहता है, तो deferred2 रद्द कर deferred1 जाएगा।

 coroutineScope { val deferred1 = async(Dispatchers.Default) { getFirstValue() } val deferred2 = async(Dispatchers.IO) { getSecondValue() } useValues(deferred1.await(), deferred2.await()) } 

आप इसके लिए एक डिफ़ॉल्ट CoroutineContext सेट करने और उसका उपयोग करने के लिए एक पूरी कक्षा को "कार्यक्षेत्र में डाल सकते हैं"।

एक उदाहरण वर्ग, जो CoroutineScope इंटरफ़ेस को लागू करता है:

 open class ScopedViewModel : ViewModel(), CoroutineScope { protected val job = Job() override val coroutineContext = Dispatchers.Main+job override fun onCleared() { super.onCleared() job.cancel() } } 

कोरटाइन में चल रहा है

डिफ़ॉल्ट launch या async प्रबंधक अब वर्तमान स्कोप प्रबंधक बन जाता है।

 launch { val foo = withContext(Dispatchers.IO) { … } // -    CoroutineContext   … } launch(Dispatchers.Default) { // -        … } 

कॉरटीन का स्वायत्त प्रक्षेपण (किसी भी कोरटाइनस्कोप के बाहर):

 GlobalScope.launch(Dispatchers.Main) { // -    . … } 

आप डिफॉल्ट Main डिस्पैचर को सेट करके भी आवेदन के लिए गुंजाइश को परिभाषित कर सकते हैं:

 object AppScope : CoroutineScope by GlobalScope { override val coroutineContext = Dispatchers.Main.immediate } 

टिप्पणी

• Coroutines Java के साथ इंटरऑपरेबिलिटी को सीमित करता है
• ताले से बचने के लिए परिवर्तनशीलता को सीमित करें
• Coroutines को प्रतीक्षा करने के लिए डिज़ाइन किया गया है, न कि धागे को व्यवस्थित करने के लिए
• Dispatchers.Default (और Main ...) में I / O से बचें - यह Dispatchers.IO के लिए है
• स्ट्रीम संसाधन की खपत होती है, इसलिए एकल-थ्रेडेड संदर्भों का उपयोग किया जाता है
• Dispatchers.Default Android 5+ में पेश किए गए ForkJoinPool पर आधारित है
• चैनलों के माध्यम से Coroutines का उपयोग किया जा सकता है

चैनलों का उपयोग करके ताले और कॉलबैक से छुटकारा पाना

JetBrains प्रलेखन से चैनल परिभाषा:

Channel Channel वैचारिक रूप से BlockingQueue समान है। मुख्य अंतर यह है कि यह पुट ऑपरेशन को ब्लॉक नहीं करता है, यह एक सस्पेंड send (या नॉन-ब्लॉकिंग offer ) के लिए प्रदान करता है, और टेक ऑपरेशन को ब्लॉक करने के बजाय, यह एक सस्पेंड receive लिए प्रदान करता है।

अभिनेताओं

चैनलों के साथ काम करने के लिए एक सरल उपकरण पर विचार करें: Actor ।

Actor , फिर से, Handler समान है: हम कोरटाइन के संदर्भ को परिभाषित करते हैं (अर्थात, वह धागा जिसमें हम कार्रवाई करने जा रहे हैं) और इसके साथ एक क्रमबद्ध क्रम में काम करते हैं।

बेशक, यह है कि यहां कॉरटिन का उपयोग किया जाता है; आप पावर और निष्पादित कोड निर्दिष्ट कर सकते हैं - रोकें ।

सिद्धांत रूप में, actor किसी भी कमांड को coroutine चैनल पर पुनर्निर्देशित करेगा। यह एक कमांड के निष्पादन की गारंटी देता है और इसके संदर्भ में संचालन को प्रतिबंधित करता है । यह दृष्टिकोण पूरी तरह से synchronize कॉल से छुटकारा पाने और सभी थ्रेड्स को मुक्त रखने में मदद करता है!

 protected val updateActor by lazy { actor<Update>(capacity = Channel.UNLIMITED) { for (update in channel) when (update) { Refresh -> updateList() is Filter -> filter.filter(update.query) is MediaUpdate -> updateItems(update.mediaList as List<T>) is MediaAddition -> addMedia(update.media as T) is MediaListAddition -> addMedia(update.mediaList as List<T>) is MediaRemoval -> removeMedia(update.media as T) } } } //  fun filter(query: String?) = updateActor.offer(Filter(query)) //  suspend fun filter(query: String?) = updateActor.send(Filter(query)) 

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

 sealed class Update object Refresh : Update() class Filter(val query: String?) : Update() class MediaAddition(val media: Media) : Update() 

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

Android Life Cycle + Coroutines

एंड्रॉइड यूजर इंटरफेस को नियंत्रित करने, कार्यों को रद्द करने और मुख्य धागे को ओवरलोड होने से रोकने के लिए अभिनेता बहुत उपयोगी हो सकते हैं।
आइए इसे कार्यान्वित करें और जब गतिविधि नष्ट हो जाए तो job.cancel() कॉल करें।

 class MyActivity : AppCompatActivity(), CoroutineScope { protected val job = SupervisorJob() //  Job    override val coroutineContext = Dispatchers.Main.immediate+job override fun onDestroy() { super.onDestroy() job.cancel() //      } } 

SupervisorJob क्लास एक अपवाद के साथ नियमित Job समान है जो केवल डाउनस्ट्रीम दिशा में रद्द करता है।

इसलिए, जब हम उनमें से एक में विफल होते हैं, तो हम सभी कोरआउट को रद्द नहीं करते हैं।

एक्सटेंशन फ़ंक्शन के साथ चीजें थोड़ी बेहतर होती हैं जो आपको CoroutineContext किसी भी View से इस CoroutineContext तक पहुंचने की अनुमति देता है।

 val View.coroutineContext: CoroutineContext? get() = (context as? CoroutineScope)?.coroutineContext 

अब हम यह सब जोड़ सकते हैं, setOnClick फ़ंक्शन अपने setOnClick कार्यों को नियंत्रित करने के लिए एक संयुक्त अभिनेता बनाता है। कई नल के मामले में, मध्यवर्ती क्रियाओं को नजरअंदाज किया जाएगा, इस प्रकार एएनआर त्रुटियों (आवेदन का जवाब नहीं देता है) को नष्ट कर दिया जाएगा, और इन कार्यों को Activity के दायरे में किया जाएगा। इसलिए, जब गतिविधि नष्ट हो जाती है, तो यह सब रद्द कर दिया जाएगा।

 fun View.setOnClick(action: suspend () -> Unit) { //         val scope = (context as? CoroutineScope)?: AppScope val eventActor = scope.actor<Unit>(capacity = Channel.CONFLATED) { for (event in channel) action() } //       setOnClickListener { eventActor.offer(Unit) } } 

इस उदाहरण में, हमने Channel को Conflated सेट किया है ताकि यह कुछ घटनाओं को अनदेखा कर दे यदि उनमें से बहुत सारे हैं यदि आप उनमें से कोई भी खोए बिना घटनाओं को कतारबद्ध करना पसंद करते हैं, तो आप इसे Channel.UNLIMITED बदल सकते हैं, लेकिन फिर भी एप्लिकेशन को ANR त्रुटियों से बचाना चाहते हैं।

उपयोगकर्ता इंटरफ़ेस से संबंधित कार्यों को रद्द करने को स्वचालित करने के लिए आप कोरआउट और जीवनचक्र के ढांचे को भी जोड़ सकते हैं:

 val LifecycleOwner.untilDestroy: Job get() { val job = Job() lifecycle.addObserver(object: LifecycleObserver { @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY) fun onDestroy() { job.cancel() } }) return job } //  GlobalScope.launch(Dispatchers.Main, parent = untilDestroy) { /*    ! */ } 

कॉलबैक के साथ स्थिति को सरल बनाएं (भाग 1)

यहां बताया गया है कि Channel साथ कॉलबैक-आधारित एपीआई के उपयोग को कैसे बदलना है।

एपीआई इस तरह काम करता है:

1. requestBrowsing(url, listener) url पर स्थित फ़ोल्डर को पार्स करता है।
2. listener इस फ़ोल्डर में पाई गई किसी भी मीडिया फ़ाइल के लिए onMediaAdded(media: Media) प्राप्त करता है।
3. listener.onBrowseEnd() फ़ोल्डर को पार्स करते समय कहा जाता है

यहाँ VLC ब्राउज़र के लिए सामग्री प्रदाता में पुराना refresh कार्य है:

 private val refreshList = mutableListOf<Media>() fun refresh() = requestBrowsing(url, refreshListener) private val refreshListener = object : EventListener{ override fun onMediaAdded(media: Media) { refreshList.add(media)) } override fun onBrowseEnd() { val list = refreshList.toMutableList() refreshList.clear() launch { dataset.value = list parseSubDirectories() } } } 

इसे कैसे सुधारा जाए?

एक चैनल बनाएं जो refresh में चलेगा। अब ब्राउज़र कॉलबैक केवल मीडिया को इस चैनल पर निर्देशित करेगा, और फिर इसे बंद कर देगा।

अब refresh फंक्शन क्लियर हो गया है। वह एक चैनल बनाता है, वीएलसी ब्राउज़र को कॉल करता है, फिर मीडिया फ़ाइलों की एक सूची बनाता है और इसे संसाधित करता है।

select या consumeEach बजाय consumeEach आप मीडिया के लिए प्रतीक्षा करने के for उपयोग कर सकते हैं, और जैसे ही browserChannel बंद होगा यह लूप टूट जाएगा।

 private lateinit var browserChannel : Channel<Media> override fun onMediaAdded(media: Media) { browserChannel.offer(media) } override fun onBrowseEnd() { browserChannel.close() } suspend fun refresh() { browserChannel = Channel(Channel.UNLIMITED) val refreshList = mutableListOf<Media>() requestBrowsing(url) //        for (media in browserChannel) refreshList.add(media) //   dataset.value = refreshList parseSubDirectories() } 

कॉलबैक के साथ स्थिति को सरल बनाना (भाग 2): रेट्रोफिट

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

देखें कि वास्तव में कैसे काम करते हैं कॉरआउट!

retrofitSuspendCall फ़ंक्शन इसे एक suspend फ़ंक्शन बनाने के लिए एक Retrofit Call अनुरोध लपेटता है।

suspendCoroutine का उपयोग करते suspendCoroutine हम Call.enqueue विधि को कॉल करते हैं और coroutine को रोकते हैं। इस तरह से दिया गया कॉलबैक continuation.resume(response) प्राप्त करेगा। फिर से प्राप्त होने पर सर्वर से प्रतिक्रिया के साथ कॉरटीन को फिर से शुरू करने के लिए continuation.resume(response) कहेंगे।

इसके बाद, हमें बस अपने रेट्रोफ़िट फ़ंक्शंस को retrofitSuspendCall में संयोजित करके क्वेरी परिणामों का उपयोग करके retrofitSuspendCall करना होगा।

 suspend inline fun <reified T> retrofitSuspendCall(request: () -> Call <T> ) : Response <T> = suspendCoroutine { continuation -> request.invoke().enqueue(object : Callback<T> { override fun onResponse(call: Call<T>, response: Response<T>) { continuation.resume(response) } override fun onFailure(call: Call<T>, t: Throwable) { continuation.resumeWithException(t) } }) } suspend fun browse(path: String?) = retrofitSuspendCall { ApiClient.browse(path) } //  (   Main) livedata.value = Repo.browse(path) 

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

यह कार्यान्वयन गिल्डर / कोटलिन-कोरटाइन-रेट्रोफिट लाइब्रेरी से प्रेरित है।

इसी तरह का एक और परिणाम देने के साथ एक जेकवर्टन / रेट्रोफिट 2-कोटलिन-कोरटाइन्स-एडेप्टर भी है।

उपसंहार

Channel का उपयोग कई अन्य तरीकों से किया जा सकता है; अधिक शक्तिशाली कार्यान्वयन के लिए ब्रॉडकास्टनेल देखें कि आपको उपयोगी मिल सकता है।

आप प्रोड्यूस फ़ंक्शन का उपयोग करके चैनल भी बना सकते हैं।

अंत में, चैनलों का उपयोग करना यूआई के घटकों के बीच संचार को व्यवस्थित करने के लिए सुविधाजनक है: एडेप्टर Channel माध्यम से इसके टुकड़े / गतिविधि पर क्लिक की घटनाओं को प्रसारित कर सकता है या, उदाहरण के लिए, Actor माध्यम से।