Background Thread în dezvoltarea mobilă: ce este, sarcini și metode de utilizare

Ce este Background Thread

Background Thread — orice fir în aplicație care nu este Main Thread și nu are acces la UI. Sarcina sa este să elibereze firul principal de operațiunile grele, astfel încât interfața să rămână receptivă. Sistemul de operare distribuie firele de fundal pe nucleele procesorului, permițând executarea paralelă a mai multor sarcini. iOS gestionează automat pool-ul de fire prin GCD, Android — prin pool-urile Java Executors.

Spre deosebire de Main Thread, care procesează evenimente secvențial (unul după altul), firele de fundal pot fi executate în paralel, limitate doar de numărul de nuclee CPU. De exemplu, pe un dispozitiv cu 8 nuclee se pot lansa până la 8 sarcini paralele de fundal fără o încetinire semnificativă. Cu toate acestea, un număr excesiv de fire (sute) duce la thread starvation — concurență pentru nuclee și creșterea costurilor de schimbare a contextului (context switch).

Quality of Service (QoS) — mecanism iOS care permite specificarea priorității sarcinii de fundal. Valori: .userInteractive (cel mai înalt, aproape Main Thread), .userInitiated (utilizatorul așteaptă rezultatul), .default (standard), .utility (utilizatorul nu așteaptă direct), .background (cel mai scăzut, pentru sincronizare și indexare). În Android, analogul este Thread.setPriority() de la 1 la 10, dar Android folosește și cgroups pentru gestionarea în grup a priorităților firelor.

Background Thread în iOS: GCD și DispatchQueue.global

DispatchQueue.global(qos:) — modul principal de a obține o coadă de fundal în iOS. GCD (Grand Central Dispatch) creează automat un pool de fire și distribuie sarcinile pe nuclee. Apelul DispatchQueue.global(qos: .background).async {} trimite un bloc de execuție în coada de fundal cu cea mai mică prioritate. Pentru sarcinile al căror rezultat este necesar imediat, utilizați .userInitiated sau .utility.

OperationQueue — o abstractizare de nivel superior peste GCD, care permite specificarea dependențelor între operațiuni, numărul maxim de operațiuni executate simultan (maxConcurrentOperationCount) și prioritățile. OperationQueue este convenabilă pentru lanțuri complexe multitasking: descarcă fișier -> despachetează -> salvează în cache. În mod implicit, OperationQueue folosește fire de fundal, dacă nu se specifică altfel.

import UIKit

class ImageDownloader {

    func downloadImagesSequentially() {
        let urls = ["https://example.com/1.png", "https://example.com/2.png"]

        // OperationQueue cu maxConcurrentOperationCount = 2
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 2
        queue.qualityOfService = .utility

        for urlString in urls {
            queue.addOperation {
                guard let url = URL(string: urlString),
                      let data = try? Data(contentsOf: url)
                else { return }

                DispatchQueue.main.async {
                    print("Încărcat: \(url.lastPathComponent)")
                }
            }
        }
    }

    // GCD: coadă globală de fundal cu diferite QoS
    func backgroundTaskWithQoS() {
        DispatchQueue.global(qos: .userInitiated).async {
            // Prioritate ridicată — utilizatorul așteaptă rezultatul
            let result = self.heavyComputation()
            DispatchQueue.main.async {
                self.showResult(result)
            }
        }
    }

    private func heavyComputation() -> String {
        Thread.sleep(forTimeInterval: 2) // simulare muncă
        return "Rezultatul calculelor"
    }

    private func showResult(_ result: String) {
        print("Result on Main: \(result)")
    }
}

În exemplu, OperationQueue încarcă două imagini în paralel (maxConcurrentOperationCount = 2) cu fundal prin qualityOfService = .utility. Metoda GCD backgroundTaskWithQoS folosește coada globală cu .userInitiated pentru sarcina al cărei rezultat utilizatorul îl așteaptă. Ambele abordări se încheie cu revenirea pe DispatchQueue.main pentru actualizarea UI — aceasta este o cerință obligatorie iOS.

Cozile de fundal Serial vs Concurrent

GCD suportă două tipuri de cozi: serial (secvențiale) și concurrent (paralele). Cozile serial execută sarcinile una după alta — acest lucru este convenabil pentru accesul la o resursă partajată (fișier, BazăDeDate) fără blocări. Cozile concurrent execută sarcinile în paralel, distribuindu-le pe nucleele libere. DispatchQueue.global — este întotdeauna concurrent. Pentru a crea o coadă serial, utilizați DispatchQueue(label: "com.app.queue").

Background Thread în Android: Executors și Dispatchers

Android oferă mai multe niveluri de abstractizare pentru firele de fundal. Abordarea clasică — java.util.concurrent.Executors.newFixedThreadPool(n) sau Executors.newCachedThreadPool(). Abordarea modernă — Kotlin Coroutines cu Dispatchers.IO (pentru intrare-ieșire: rețea, fișiere, BazăDeDate) și Dispatchers.Default (pentru sarcini intensive CPU: sortare, procesare imagini). WorkManager — pentru sarcini de fundal amânate și garantate.

HandlerThread — o clasă specială Android pentru crearea unui fir de fundal cu propriul Looper (coadă de mesaje). Spre deosebire de Executors, HandlerThread permite trimiterea de mesaje și Runnable prin Handler. Este utilizat pentru operațiuni care necesită punerea în coadă (de exemplu, scrierea secvențială în baza de date). După utilizare, trebuie apelat quit() sau quitSafely() pentru eliberarea resurselor.

// Android: Executors și Coroutines Dispatchers
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.util.concurrent.Executors

class DataRepository {

    private val ioExecutor = Executors.newFixedThreadPool(4)

    // Abordare clasică prin Executors
    fun loadDataLegacy(callback: (String) -> Unit) {
        ioExecutor.execute {
            val result = readFromFile()
            val handler = android.os.Handler(android.os.Looper.getMainLooper())
            handler.post { callback(result) }
        }
    }

    // Abordare modernă prin Coroutines
    suspend fun loadDataCoroutines(): String {
        return withContext(Dispatchers.IO) {
            // Operațiune cu fișier — executată în pool-ul de fundal
            readFromFile()
        }
        // Rezultatul se returnează automat pe Dispatchers.Main
    }

    // Sarcină intensivă CPU pe Dispatchers.Default
    suspend fun processImage(pixels: IntArray): IntArray {
        return withContext(Dispatchers.Default) {
            // Sortare, filtrare — executată pe pool-ul Default
            pixels.sortedArray()
        }
    }

    private fun readFromFile(): String {
        Thread.sleep(1000) // simulare citire din fișier
        return "file_content"
    }

    fun cleanup() {
        ioExecutor.shutdown()
    }
}

Exemplul DataRepository arată evoluția firelor de fundal în Android. Metoda legacy loadDataLegacy folosește Executors.newFixedThreadPool(4) cu Handler pentru revenirea pe Main Thread. Modernul loadDataCoroutines folosește withContext(Dispatchers.IO) — corutina se suspendă pe durata lucrului, fără a bloca firul, și se reia automat pe Main Thread. Dispatchers.Default este recomandat pentru operațiuni CPU-bound (sortare, filtrare, transformare date).

Corutinele ca standard modern pentru sarcini de fundal

Kotlin Coroutines — nu doar un mod de a lucra cu firele, ci un model fundamental diferit: sarcinile asincrone nu sunt legate de un fir specific și se pot suspenda (suspend) fără blocare. Aceasta înseamnă că în timpul lucrului în fundal, corutina nu ocupă un fir, ci îl eliberează pentru alte sarcini. Mecanismul suspension permite executarea a sute de mii de sarcini concurrent pe un pool de 4-8 fire fără thread starvation.

Trei dispatcheri principali: Dispatchers.Main (UI, un fir), Dispatchers.IO (64 de fire în mod implicit pentru operațiuni blocante: rețea, fișiere, BazăDeDate), Dispatchers.Default (egal cu numărul de nuclee CPU, pentru calcule intensive). Combinându-le prin withContext, dezvoltatorul comută între fire fără a crea callback-uri. withContext este o funcție suspend care nu returnează controlul până când sarcina nu este finalizată.

// Corutine: compoziția sarcinilor de fundal
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay

suspend fun loadUserProfile(userId: String): UserProfile =
    coroutineScope {
        // Încărcare paralelă a datelor din diferite surse
        val user = async(Dispatchers.IO) { fetchUser(userId) }
        val posts = async(Dispatchers.IO) { fetchPosts(userId) }
        val avatar = async(Dispatchers.Default) {
            processAvatar(fetchAvatar(userId))
        }

        // await() — se suspendă până la finalizarea tuturor sarcinilor
        UserProfile(
            user = user.await(),
            posts = posts.await(),
            avatar = avatar.await()
        )
    }

data class UserProfile(
    val user: String,
    val posts: List<String>,
    val avatar: ByteArray
)

suspend fun fetchUser(id: String): String { delay(300); return "User:$id" }
suspend fun fetchPosts(id: String): List<String> { delay(500); return listOf("Post1") }
suspend fun fetchAvatar(id: String): ByteArray { delay(200); return ByteArray(1024) }
suspend fun processAvatar(data: ByteArray): ByteArray { delay(100); return data }

Funcția loadUserProfile lansează trei sarcini paralele de fundal prin async. fetchUser și fetchPosts — IO-bound (rețea), se execută pe Dispatchers.IO. processAvatar — CPU-bound (procesare imagine), se execută pe Dispatchers.Default. await() suspendă corutina până la finalizarea tuturor sarcinilor. Timpul total de execuție este egal cu timpul maxim dintre cele trei sarcini (500 ms pentru fetchPosts), nu suma lor. Acesta este avantajul cheie al corutinelor față de execuția secvențială.

Structured concurrency: prevenirea scurgerilor

Structured concurrency — principiul conform căruia fiecare corutină are un scope părinte, iar anularea părintelui anulează automat corutinele copil. În Android, lifecycleScope anulează toate corutinele la distrugerea Activity. viewModelScope — la curățarea ViewModel. Aceasta previne scurgerile sarcinilor de fundal: dacă utilizatorul a închis ecranul, corutina de fundal nu va continua să încarce date care nu mai sunt necesare nimănui.

// WorkManager cu corutine
import android.content.Context
import androidx.work.*
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

class SyncWorker(
    appContext: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(appContext, workerParams) {

    override suspend fun doWork(): Result {
        // Se execută pe Dispatchers.Default (implicit)
        return withContext(Dispatchers.IO) {
            try {
                syncDataToServer()
                Result.success()
            } catch (e: Exception) {
                if (runAttemptCount < 3) Result.retry() else Result.failure()
            }
        }
    }

    private suspend fun syncDataToServer() {
        // Simulare sincronizare
        delay(1000)
    }
}

// Lansare sarcină WorkManager cu constrângeri
fun scheduleSync(context: Context) {
    val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .setRequiresBatteryNotLow(true)
        .build()

    val syncWork = OneTimeWorkRequestBuilder<SyncWorker>()
        .setConstraints(constraints)
        .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, java.util.concurrent.TimeUnit.SECONDS)
        .build()

    WorkManager.getInstance(context).enqueue(syncWork)
}