withContext: nədir, kontekst dəyişməsi və korutinalarda işləmə

Kotlin-də withContext nədir?

withContext — kotlinx.coroutines paketindən dayandırıcı funksiyadır, verilmiş kod blokunu müəyyən CoroutineContext-də icra edir və nəticəni orijinal kontekstə qaytarır. Funksiyanın imzası belə görünür:

suspend fun  withContext(
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T
): T

context parametri istənilən CoroutineContext qəbul edir — ən çox standart Dispatchers.IO, Dispatchers.Default və ya Dispatchers.Main-dən biri. Blok məhz bu kontekstdə icra olunur və nəticə withContext-in çağırıldığı yerə qaytarılır.

Əsas xüsusiyyət: avtomatik qayıdış

Lambda tamamlandıqdan sonra withContext zəmanətli şəkildə icranı orijinal dispatcher-ə qaytarır. Bu o deməkdir ki, tərtibatçı fon əməliyyatından sonra əl ilə withContext(Dispatchers.Main) çağırmalı deyil — qayıdış avtomatik baş verir. Bu davranış Kotlin Coroutines spesifikasiyasında 1.3 versiyasından etibarən təsbit edilmişdir.

withContext harada tətbiq olunur

Android inkişafı — withContext-in əsas tətbiq sahəsidir. Tipik ssenari: ViewModel əsas thread-də korutina işə salır, daxilində şəbəkə sorğusu üçün withContext(Dispatchers.IO) çağırılır və nəticə Main-ə avtomatik qayıtdıqdan sonra UI-ni yeniləmək üçün istifadə olunur. Bu yanaşma MVVM arxitekturasının əsasını təşkil edir və Google tərəfindən korutinalar üzrə rəsmi bələdçidə tövsiyə olunur.

withContext necə işləyir: dispatcher-lərin dəyişdirilməsi

withContext-i başa düşmək üçün CoroutineContext və onun əsas komponenti olan dispatcher-i (Dispatcher) anlamaq lazımdır. Hər bir korutinanın kontekst elementləri dəsti var, onların arasında dispatcher kodun hansı thread və ya thread hovuzunda icra olunacağını müəyyən edir.

withContext üçün standart dispatcher-lər

withContext-in yeni korutina yaratmadığını başa düşmək vacibdir — o, mövcud olan üçün yalnız konteksti dəyişir. Bu, onu launch və async-dən fərqləndirən əsas xüsusiyyətdir, çünki onlar yeni korutinalar yaradır. Daxili tətbiq optimallaşdırılıb: tələb olunan kontekst cari ilə üst-üstə düşərsə, dəyişiklik baş vermir — funksiya eyni dispatcher-də icra olunur.

withContext thread-i NƏ ZAMAN dəyişmir

Dispatchers.Main withContext(Dispatchers.Main) daxilində dəyişikliyə səbəb olmur — Kotlin Coroutines kontekstlərin eyniliyini tanıyır və lazımsız əməliyyatı buraxır. Eynilə, artıq Default-da işləyən korutina daxilində withContext(Dispatchers.Default) heç bir əlavə yük yaratmır. Bu optimallaşdırma ContinuationInterceptor-da tətbiq edilmişdir.

withContext vs launch və async: nə vaxt nəyi seçmək

Yeni başlayanlar tez-tez withContext-i launch və async ilə qarışdırır, çünki hər üç funksiya korutinalar və kontekstlə işləyir. Lakin onların təyinatı prinsipial olaraq fərqlidir.

Üç funksiyanın müqayisəsi

Seçim qaydası

Fon thread-də bir əməliyyat yerinə yetirib nəticə almaq lazımdırsa — withContext istifadə edin. Bir neçə müstəqil əməliyyatı paralel işə salmaq lazımdırsa — async ilə await istifadə edin. Nəticə lazım deyilsə (loglama, cache yazma) — launch. Google Android arxitekturasında Repository qatı üçün withContext-i üstünlük verilən alət kimi tövsiyə edir.

withContext ilə kod nümunələri

Kotlin dilində Android tətbiqlərində withContext-in üç praktik ssenarisini nəzərdən keçirək. Hər bir nümunə konkret tapşırığı və düzgün nümunəni göstərir.

Nümunə 1: Repository-də şəbəkə sorğusu

ViewModel korutinadan Main-də repository metodunu çağırır. Daxildə withContext(Dispatchers.IO) HTTP sorğusunu icra edir və nəticə avtomatik qaytarılır:

class UserRepository(
    private val api: UserApi
) {
    suspend fun getUser(id: String): User {
        return withContext(Dispatchers.IO) {
            api.fetchUser(id)
        }
    }
}

ViewModel-dəki korutina getUser-i adi dayandırıcı funksiya kimi çağırır — dispatcher-i açıq şəkildə göstərmədən. withContext thread dəyişdirmə detallarını gizlədir.

Nümunə 2: İki ardıcıl fon əməliyyatı

Bir neçə IO əməliyyatını bir-birinin ardınca yerinə yetirmək lazım olduqda, withContext onları vahid blokda birləşdirir. Bu, hər əməliyyatı ayrıca withContext-ə yerləşdirməkdən daha səmərəlidir:

suspend fun loadUserProfile(id: String): Profile {
    return withContext(Dispatchers.IO) {
        val user = api.fetchUser(id)
        val posts = api.fetchPosts(id)
        Profile(user, posts)
    }
}

Hər iki əməliyyat Dispatchers.IO-da icra olunur və Profile nəticəsi lazımsız kontekst dəyişikliyi olmadan yaradılıb qaytarılır. Əməliyyatlar müstəqildirsə, paralel icra üçün async istifadə etmək daha yaxşıdır.

Nümunə 3: NonCancellable ilə qarışıq kontekst

Bəzi ssenarilərdə ləğv edilə bilməyən kodu icra etmək lazımdır — məsələn, ekran bağlanarkən vəziyyətin saxlanması. withContext + NonCancellable kombinasiyası bu tapşırığı həll edir:

withContext(Dispatchers.IO + NonCancellable) {
    cache.saveState(state)
    analytics.logEvent("state_saved")
}

+ operatoru iki kontekst elementini birləşdirir: IO dispatcher-i və NonCancellable bayrağı. Blok ana korutina ləğv edilsə belə icra olunur — bu, yekunlaşdırma əməliyyatları üçün faydalıdır.

Daxili mexanizm: Continuation və optimallaşdırmalar

withContext-in daxili tətbiqi Continuation mexanizminə — Kotlin korutinalarının mərkəzi abstraksiyasına əsaslanır. Hər bir dayandırma nöqtəsi (suspend point) icra vəziyyətini Continuation obyektində saxlayır və withContext istisna deyil.

withContext bayt kod səviyyəsində konteksti necə dəyişir

Kotlin kompilyatoru withContext-i kotlinx.coroutines-dən withContext metoduna çağırış kimi tərcümə edir, o da daxildə yeni DispatchedContinuation nüsxəsi yaradır. Bu obyekt orijinal Continuation-ı bükür və orada dispatcher-i əvəz edir. Yeni dispatcher cari olandan fərqlidirsə, icra dayandırılır, blok müvafiq thread hovuzuna göndərilir və tamamlandıqdan sonra orijinal kontekstlə bərpa olunur.

Optimallaşdırma: kontekstlər uyğun gələndə fast-path

withContext korutinanın artıq işlədiyi eyni dispatcher ilə çağırıldıqda, Kotlin fast-path işə salır: blok sinxron şəkildə, DispatchedContinuation yaratmadan və thread hovuzuna ötürmədən icra olunur. Bu, withContext-i eyni kontekstlə təkrar çağırışlarda praktiki olaraq pulsuz edir. JetBrains benchmarklarına görə (kotlinx.coroutines 1.8), fast-path 0.1 μs-dən az müddətdə icra olunur.

Məhsuldarlıq baxımından məhdudiyyətlər

Fərqli dispatcher ilə hər withContext çağırışı yeni DispatchedContinuation yaradır və thread dəyişməsi tələb edir — bu, yükdən asılı olaraq 1-dən 5 μs-ə qədər vaxt aparır. Əksər tətbiqlər üçün bu gecikmə nəzərə çarpmır, lakin minlərlə iterasiyası olan dövrülərdə əməliyyatları bir withContext blokunda toplamaq daha yaxşıdır.

withContext istifadəsində tipik səhvlər

Hətta təcrübəli tərtibatçılar withContext ilə işləyərkən səhv edirlər. Dörd ən çox yayılmış problemi və onların qarşısını almaq yollarını nəzərdən keçirək.

Səhv 1: Lazımsız iç-içə withContext

Tərtibatçılar tez-tez hər sətri ayrıca withContext-ə yerləşdirir, əməliyyatları bir blokda birləşdirmək əvəzinə. Fərqli dispatcher ilə hər əlavə çağırış əlavə yük yaradır.

Düzgün: ardıcıl IO əməliyyatlarını bir withContext(Dispatchers.IO) { ... } blokunda birləşdirin. Əgər əməliyyatların bir hissəsi CPU intensivdirsə — eyni blok daxilində withContext(Dispatchers.Default) istifadə edin.

Səhv 2: Paralel tapşırıqlar üçün withContext-in əvəzinə istifadəsi

withContext kodu ardıcıl icra edir. İki müstəqil şəbəkə sorğusu bir withContext-ə yerləşdirilirsə, onlar bir-birinin ardınca icra olunacaq. Paralellik üçün async + await istifadə edin.

// Ardıcıl — yavaş
withContext(Dispatchers.IO) {
    val a = api.fetchA()
    val b = api.fetchB()
}

// Paralel — sürətli
coroutineScope {
    val a = async { api.fetchA() }
    val b = async { api.fetchB() }
    println("${a.await()} ${b.await()}")
}

Səhv 3: Kritik əməliyyatlarda NonCancellable-ı unutmaq

Korutina withContext zamanı ləğv edilərsə, Dispatchers.IO-dakı blok da kəsilir. Nəyin bahasına olursa olsun tamamlanmalı olan əməliyyatlar üçün (verilənlər bazasına yazma, analitika göndərmə) withContext-i NonCancellable ilə birləşdirin.

Səhv 4: IO bloku daxilində UI vəziyyətinin dəyişdirilməsi

Heç vaxt View komponentlərini withContext(Dispatchers.IO) daxilində yeniləməyin. withContext bütün blok tamamlanana qədər Main-ə qayıtmır. UI yeniləməsini withContext-in bağlanan mötərizəsindən sonra edin — onda korutina artıq əsas thread-də olacaq.