CoroutineScope — ano ito, saklaw ng buhay at paggana sa coroutine

Ano ang CoroutineScope sa Kotlin?

CoroutineScope — ay isang pangunahing interface mula sa library ng kotlinx.coroutines na nagsisilbing lalagyan para sa mga coroutine. Tinutukoy nito ang mga hangganan ng buhay ng mga coroutine: kapag natapos ang scope, lahat ng coroutine sa loob nito ay awtomatikong kinakansela.

public interface CoroutineScope {
    public val coroutineContext: CoroutineContext
}

Ang interface ay naglalaman lamang ng isang field — coroutineContext. Sa pamamagitan nito, ang scope ay nagbibigay ng dispatcher (Dispatcher), gawain (Job), pangangasiwa ng exception, at iba pang elemento ng konteksto para sa lahat ng coroutine na inilunsad dito.

Papel sa library ng kotlinx.coroutines

Lahat ng function ng paglulunsad ng coroutine — launch, async, runBlocking — ay extension function sa CoroutineScope. Nangangahulugan ito na maaari lamang silang tawagin kung mayroong object ng scope. Ang ganitong disenyo ay ginagarantiyahan na ang bawat coroutine ay may malinaw na tinukoy na magulang at siklo ng buhay.

Saan inilalapat ang CoroutineScope

Sa Android, bawat bahagi ng arkitektura ay may sariling scope: viewModelScope para sa ViewModel, lifecycleScope para sa Activity/Fragment. Sa mga server application, ang scope ay maaaring itali sa isang HTTP request o sa isang pool ng mga koneksyon sa database.

Paano Gumagana ang CoroutineScope: Job at Konkurensiyang Struktural

Ang pag-unawa sa panloob na istraktura ng CoroutineScope ay nangangailangan ng pamilyaridad sa konsepto ng Job at prinsipyo ng konkurensiyang struktural.

Job — Gawain ng Coroutine

Bawat coroutine sa paglulunsad ay nagbabalik ng Job object (o Deferred para sa async). Job ay kumakatawan sa isang gawain na may tinukoy na siklo ng buhay: New, Active, Completing, Completed, Cancelling, Cancelled. Ang mga Job object ay bumubuo ng istraktura ng puno:

• Job ng Magulang — scope kung saan inilunsad ang coroutine
• Job na Anak — bawat coroutine na inilunsad sa pamamagitan ng launch/async
• Pagkansela ng magulang → pagkansela ng lahat ng anak
• Exception sa anak → pagkansela ng magulang (maliban sa supervisorScope)

Prinsipyo ng Konkurensiyang Struktural

Konkurensiyang struktural — pangunahing prinsipyo ng arkitektura ng Kotlin Coroutines, kung saan ang buhay ng coroutine ay nakatali sa buhay ng scope nito. Ito ay kaibahan sa modelo ng “fire-and-forget”, kung saan ang coroutine ay patuloy na nabubuhay pagkatapos ng pagtatapos ng scope. Mga bentahe ng konkurensiyang struktural:

• Mahuhulaan na siklo ng buhay — kapag natapos ang scope, lahat ng coroutine ay garantisadong hihinto
• Awtomatikong pangangasiwa ng error — exception sa anumang coroutine na anak ay kumakalat sa scope
• Walang pagtagas — walang coroutine na nananatiling aktibo pagkatapos ng pagtatapos ng scope
• Malinaw na hierarchy — ang code ay sumasalamin sa lohikal na istraktura ng mga parallel na operasyon

Siklo ng Buhay ng CoroutineScope

Kapag tinawag ang scope.cancel(), ang Job ng scope ay pumunta sa status na Cancelled, na kung saan ay recursively kinakansela ang lahat ng Job na anak. Pagkatapos ng pagkansela, ang scope ay maaari lamang magamit muli sa pamamagitan ng paglikha ng bagong instance ng CoroutineScope.

Paglikha at Pag-configure ng CoroutineScope

Ang CoroutineScope ay maaaring likhain sa pamamagitan ng factory function o sa pamamagitan ng pagpapatupad ng interface sa iyong klase. Talakayin natin ang parehong approach.

Factory Function na CoroutineScope()

val scope = CoroutineScope(Dispatchers.Default + SupervisorJob())

scope.launch {
    println("Tumatakbo sa ${Thread.currentThread().name}")
}

Ang factory function ay tumatanggap ng CoroutineContext at lumilikha ng scope na may tinukoy na konteksto. Sa halimbawa, ginamit ang Dispatchers.Default para sa mga gawaing CPU-intensive at SupervisorJob na nagbubukod ng mga exception sa pagitan ng mga coroutine na anak.

Pagpapatupad ng Interface sa pamamagitan ng Komposisyon

class MyRepository {
    private val scope = CoroutineScope(Dispatchers.IO + Job())

    suspend fun fetchData(): Data = scope.async {
        api.getData()
    }.await()

    fun cleanup() {
        scope.cancel()
    }
}

Itinatago namin ang scope bilang field ng klase at manu-manong tinatawagan ang cleanup para kanselahin ito. Ito ay angkop para sa mga bahagi na may pinamamahalaang siklo ng buhay — halimbawa, para sa mga repositoryo o manager.

Pagpapatupad sa pamamagitan ng Delegasyon

Pinapayagan ng Kotlin ang delegasyon ng pagpapatupad ng CoroutineScope sa pamamagitan ng keyword na by:

class DataLoader : CoroutineScope by CoroutineScope(Dispatchers.IO) {
    fun load() {
        launch {
            // coroutine ay tumatakbo sa DataLoader scope
        }
    }
}

Ang approach na ito ay maginhawa kapag ang klase mismo ay isang scope at nais na magbigay ng mga pamamaraan ng paglulunsad ng coroutine. Gayunpaman, mag-ingat: minamana ng klase ang lahat ng pamamaraan ng CoroutineScope, kabilang ang cancel, na maaaring lumabag sa encapsulation.

GlobalScope vs Pasadyang CoroutineScope

GlobalScope — ay isang singleton ng CoroutineScope para sa buong application. Ang paggamit nito sa production code ay opisyal na hindi inirerekomenda.

Mga Problema ng GlobalScope

• Kakulangan ng konkurensiyang struktural — ang mga coroutine sa GlobalScope ay hindi nakatali sa siklo ng buhay ng bahagi
• Pagtagas ng memorya — ang coroutine ay maaaring magpatuloy sa pagtakbo pagkatapos isara ang Activity/Fragment
• Mahirap na pagsubok — ang GlobalScope ay hindi mapapalitan sa mga pagsubok
• Hindi kontroladong pagkonsumo ng mapagkukunan — maraming coroutine ang maaaring gumana nang mas matagal kaysa sa inaasahan

Kailan Nabibigyang-katwiran ang GlobalScope

Pinapahintulutan ng JetBrains ang GlobalScope lamang sa mga bihirang sitwasyon: mga proseso sa background sa antas ng application na dapat manatiling buhay kahit na matapos isara ang lahat ng Activity (halimbawa, pag-sync ng data, analytics). Ngunit kahit sa mga kasong ito, mas mainam na lumikha ng sariling scope gamit ang CoroutineScope(SupervisorJob()).

Rekomendasyon

Palaging gumamit ng pasadyang CoroutineScope na may tahasang pamamahala ng siklo ng buhay. Sa Android, ito ay viewModelScope at lifecycleScope. Sa mga server application, lumikha ng scope para sa bawat request o pool ng mga koneksyon.

coroutineScope vs supervisorScope: Ano ang Pagkakaiba

Parehong function ay suspend function na lumilikha ng pansamantalang scope para sa mga parallel na gawain, ngunit ang kanilang pag-uugali sa mga exception ay pangunahing naiiba.

Kailan Pumili ng coroutineScope

Gamitin ang coroutineScope kapag maraming parallel na operasyon ang bumubuo ng isang atomikong operasyon. Halimbawa, pagkarga ng data mula sa tatlong server: kung ang isang request ay bumagsak, ang iba ay walang saysay.

suspend fun loadProductPage(): ProductPage = coroutineScope {
    val product = async { api.getProduct() }
    val reviews = async { api.getReviews() }
    ProductPage(product.await(), reviews.await())
}

Kung ang getProduct o getReviews ay naghagis ng exception — parehong coroutine ay kinansela, at ang exception ay kumakalat sa tumatawag na code.

Kailan Pumili ng supervisorScope

Gamitin ang supervisorScope kapag ang mga parallel na operasyon ay hindi nakadepende sa isa’t isa. Halimbawa, pagkarga ng data ng profile sa maraming independiyenteng seksyon: kung ang seksyon ng mga rekomendasyon ay bumagsak, ang header ng profile at listahan ng mga kaibigan ay dapat ipakita.

Mga Karaniwang Pagkakamali sa Paggamit ng CoroutineScope

Talakayin natin ang pinakakaraniwang pagkakamali ng mga developer sa paggamit ng CoroutineScope sa Kotlin.

Pagkakamali 1: Nakalimutang Kanselahin ang Scope

Ang pinakakaraniwang sitwasyon ng pagtagas ng coroutine — paglikha ng scope nang hindi tinatawagan ang cancel kapag natapos ang bahagi. Kung ang scope ay hindi nakansela, ang mga coroutine ay patuloy na tumatakbo, na may hawak na mga reference sa mga bagay. Sa Android, gamitin ang viewModelScope o lifecycleScope, na awtomatikong kinakansela.

Pagkakamali 2: Paggamit ng GlobalScope sa Activity o Fragment

Binabalewala ng GlobalScope ang siklo ng buhay ng mga bahagi ng Android. Ang coroutine na inilunsad sa GlobalScope pagkatapos isara ang Activity ay magpapatuloy sa pagtakbo at susubukan na i-update ang UI — na magdudulot ng crash. Palaging gamitin ang lifecycleScope para sa mga bahagi ng UI.

Pagkakamali 3: Muling Paggamit ng Nakanselang Scope

Pagkatapos tawagan ang cancel(), ang scope ay hindi maaaring magamit muli — lahat ng coroutine sa loob nito ay tapos na. Lumikha ng bagong instance ng CoroutineScope sa pamamagitan ng factory function. Job() ay hindi sumusuporta sa muling pag-activate.

Pagkakamali 4: Maling Delegasyon ng Interface ng CoroutineScope

Sa delegasyon sa pamamagitan ng by, ang klase ay nakakakuha ng pampublikong pamamaraan na cancel() na maaaring tawagan mula sa kahit saan, lumalabag sa encapsulation. Itago ang scope bilang pribadong field, huwag i-delegate ang interface.