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

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

class Work { fun doWork() = try { for (i in 0 until 10) { Thread.sleep(500) } "work is done" } catch (e: InterruptedException) { "work is cancelled" } } 

AsyncTask

इस दृष्टिकोण के साथ, प्रत्येक कार्य के लिए प्रत्येक AsyncTask बनाया जाता है, जो onPause () या onStop () में रद्द किया जाता है। यह इसलिए किया जाता है ताकि गतिविधि संदर्भ लीक न हो। यह दिखाने के लिए कि इसका क्या मतलब है, मैंने एक छोटा सा उदाहरण दिया।

सबसे पहले, हम मानक AsyncTask को थोड़ा संशोधित करते हैं ताकि इसे पूर्ववत किया जा सके और इसमें से एक त्रुटि वापस आए:

 class AsyncTaskCancellable<Params, Result>( private val job: Job<Params, Result>, private var callback: AsyncTaskCallback<Result>?) : AsyncTask<Params, Void, AsyncTaskCancellable.ResultContainer<Result>>(), WorkManager.Cancellable { interface Job<Params, Result> { fun execute(params: Array<out Params>): Result } override fun doInBackground(vararg params: Params): AsyncTaskCancellable.ResultContainer<Result> { return try { ResultContainer(job.execute(params)) } catch (throwable: Throwable) { ResultContainer(throwable) } } override fun onPostExecute(result: AsyncTaskCancellable.ResultContainer<Result>) { super.onPostExecute(result) if (result.error != null) { callback?.onError(result.error!!) } else { callback?.onDone(result.result!!) } } override fun cancel() { cancel(true) callback = null } class ResultContainer<T> { var error: Throwable? = null var result: T? = null constructor(result: T) { this.result = result } constructor(error: Throwable) { this.error = error } } } 

प्रबंधक को कार्य का शुभारंभ जोड़ें:

 class WorkManager { fun doWorkInAsyncTask(asyncTaskCallback: AsyncTaskCallback<String>): Cancellable { return AsyncTaskCancellable(object : AsyncTaskCancellable.Job<Void, String> { override fun execute(params: Array<out Void>) = Work().doWork() }, asyncTaskCallback).apply { execute() } } } 

हम कार्य शुरू करते हैं, पहले एक को रद्द कर रहे हैं, अगर एक है:

 class MainActivity : AppCompatActivity() { ... loadWithAsyncTask.setOnClickListener { asyncTaskCancellable?.cancel() asyncTaskCancellable = workManager.doWorkInAsyncTask(object : AsyncTaskCallback<String> { override fun onDone(result: String) { onSuccess(result) } override fun onError(throwable: Throwable) { this@MainActivity.onError(throwable) } }) } ... } 

इसे ऑन-प्रेज में रद्द करना न भूलें ():

 override fun onPause() { asyncTaskCancellable?.cancel() super.onPause() } 

यहाँ AsyncTask बंद हो जाता है और कॉलबैक MainActivity का लिंक साफ़ करने के लिए रीसेट करता है। यह दृष्टिकोण तब लागू होता है जब आपको एक त्वरित और महत्वहीन कार्य करने की आवश्यकता होती है, जिसका परिणाम खोने के लिए डरावना नहीं है (उदाहरण के लिए, जब आप स्क्रीन को फ्लिप करते हैं जब गतिविधि फिर से बनाई जाएगी)।

RxJava पर, एक समान कार्यान्वयन अधिक भिन्न नहीं होगा।

हम एक ऑब्जर्वेबल भी बनाते हैं, जिसे Schedulers.computation () पर निष्पादित किया जाएगा, और इसे आगे की सदस्यता के लिए वापस किया जाएगा।

 class WorkManager { ... fun doWorkInRxJava(): Observable<String> { return Observable.fromCallable { Work().doWork() }.subscribeOn(Schedulers.computation()) } ... } 

हम मुख्य धारा में कॉलबैक भेजते हैं और काम करने के लिए सदस्यता लेते हैं:

 class MainActivity : AppCompatActivity() { ... loadWithRx.setOnClickListener { _ -> rxJavaSubscription?.dispose() rxJavaSubscription = workManager.doWorkInRxJava() .observeOn(AndroidSchedulers.mainThread()) .subscribe({ onSuccess(it) }, { onError(it) }) } ... } 

ऑनपोज़ () में अपने लिए सफाई करना न भूलें:

 override fun onPause() { rxJavaSubscription?.dispose() super.onPause() } 

सामान्य तौर पर, RxJava के साथ कार्यान्वयन RxBinding लाइब्रेरी का उपयोग करके थोड़ा पूरक हो सकता है। यह Android घटकों के लिए प्रतिक्रियाशील बाइंडिंग प्रदान करता है। विशेष रूप से, इस मामले में, आप एक अवलोकन प्राप्त करने के लिए RxView.clicks () का उपयोग कर सकते हैं जो आपको बटन के साथ सुनने की अनुमति देता है:

 class MainActivity : AppCompatActivity() { ... rxJavaSubscription = RxView.clicks(loadWithRx) .concatMap { workManager.doWorkInRxJava() .observeOn(AndroidSchedulers.mainThread()) .doOnNext { result -> onSuccess(result) } .onErrorReturn { error -> onError(error) "" } } .subscribe() ... } 

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

एंड्रॉयड प्राथमिकता-jobqueue

यहां हमारे पास एक निश्चित प्रबंधक है जो संचालन का प्रबंधन करता है, और प्रदर्शन उसकी वर्तमान स्थिति के लिए सदस्यता लेता है। LiveData, जो जीवन चक्र से बंधा हुआ है, ऐसे प्रबंधक और UI के बीच एक परत की भूमिका के लिए उत्कृष्ट है। इस उदाहरण में सीधे काम करने के लिए, मैं RxJava का उपयोग करने का सुझाव देता हूं, जिससे कोड निष्पादन को पृष्ठभूमि थ्रेड में स्थानांतरित करना आसान हो जाता है।

हमें सहायक संसाधन आवरण वर्ग की भी आवश्यकता होगी, जिसमें ऑपरेशन की स्थिति, त्रुटि और परिणाम के बारे में जानकारी होगी।

 class Resource<T> private constructor(val status: Status, val data: T?, val error: Throwable?) { constructor(data: T) : this(Status.SUCCESS, data, null) constructor(error: Throwable) : this(Status.ERROR, null, error) constructor() : this(Status.LOADING, null, null) enum class Status { SUCCESS, ERROR, LOADING } } 

अब हम एक WorkViewModel वर्ग लिखने के लिए तैयार हैं जिसमें LiveData उदाहरण होगा और संसाधन का उपयोग करके कार्य की स्थिति में होने वाले परिवर्तनों के बारे में सूचित करेगा। उदाहरण में, मैंने एक छोटे से धोखा दिया और सिर्फ एक काम करने के लिए WorkViewModel बनाया। मैं स्टैटिक्स में RxJava का उपयोग करता हूं, लेकिन मैं LiveData के माध्यम से इसकी सदस्यता लूंगा, इसलिए कोई लीक नहीं होगी।

 class WorkViewModel private constructor() { companion object { val instance = WorkViewModel() } private val liveData: MutableLiveData<Resource<String>> = MutableLiveData() private var workSubscription: Disposable? = null fun startWork(work: Work) { liveData.value = Resource() workSubscription?.dispose() workSubscription = Observable.fromCallable { work.doWork() } .subscribeOn(Schedulers.computation()) .observeOn(AndroidSchedulers.mainThread()) .subscribe({ liveData.value = Resource(it) }, { liveData.value = Resource(it) }) } fun getWork(): LiveData<Resource<String>> = liveData } 

हम एकरूपता को बनाए रखने के लिए कार्य लॉन्च करके वर्कमैन को पूरक करते हैं, अर्थात। ताकि काम हमेशा इस प्रबंधक के माध्यम से शुरू हो:

 class WorkManager { ... fun doOnLiveData() { WorkViewModel.instance.startWork(Work()) } ... } 

और हम इस सब के साथ MainActivity में इंटरैक्शन जोड़ते हैं। WorkViewModel से हमें वर्तमान कार्य की स्थिति प्राप्त होती है, जबकि प्रदर्शन जीवंत है, और हम एक नया काम शुरू करते हैं:

 class MainActivity : AppCompatActivity() { ... WorkViewModel.instance.getWork().observe(this, Observer { when { it?.status == Resource.Status.SUCCESS -> onSuccess(it.data!!) it?.status == Resource.Status.ERROR -> onError(it.error!!) it?.status == Resource.Status.LOADING -> loadWithLiveData.isEnabled = false } }) loadWithLiveData.setOnClickListener { workManager.doOnLiveData() } ... } 

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

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

स्रोत का पूरा संस्करण यहां पाया जा सकता है: गिटहब

मुझे टिप्पणियों में आपके सवालों का जवाब देने में खुशी होगी!