Background Thread в мобилното разработване: какво е, задачи и начини на използване

Какво е Background Thread

Background Thread — всяка нишка в приложението, която не е Main Thread и няма достъп до UI. Нейната задача е да освободи основната нишка от тежки операции, така че интерфейсът да остане отзивчив. Операционната система разпределя фоновите нишки по ядрата на процесора, позволявайки паралелно изпълнение на множество задачи. iOS автоматично управлява пула от нишки чрез GCD, Android — чрез пулове на Java Executors.

За разлика от Main Thread, който обработва събития последователно (едно след друго), фоновите нишки могат да се изпълняват паралелно, ограничени само от броя на CPU ядрата. Например, на устройство с 8 ядра могат да се стартират до 8 паралелни фонови задачи без значително забавяне. Прекомерният брой нишки (стотици) обаче води до thread starvation — конкуренция за ядра и нарастване на разходите за превключване на контекста (context switch).

Quality of Service (QoS) — механизъм на iOS, който позволява да се зададе приоритет на фоновата задача. Стойности: .userInteractive (най-висок, почти Main Thread), .userInitiated (потребителят очаква резултат), .default (стандартен), .utility (потребителят не чака директно), .background (най-нисък, за синхронизация и индексиране). В Android аналогът е Thread.setPriority() от 1 до 10, но Android също използва cgroups за групово управление на приоритетите на нишките.

Background Thread в iOS: GCD и DispatchQueue.global

DispatchQueue.global(qos:) — основният начин за получаване на фонова опашка в iOS. GCD (Grand Central Dispatch) автоматично създава пул от нишки и разпределя задачите по ядрата. Извикването DispatchQueue.global(qos: .background).async {} изпраща блок за изпълнение във фоновата опашка с най-нисък приоритет. За задачи, чийто резултат е необходим незабавно, използвайте .userInitiated или .utility.

OperationQueue — абстракция на по-високо ниво над GCD, която позволява задаване на зависимости между операциите, максимален брой едновременно изпълнявани операции (maxConcurrentOperationCount) и приоритети. OperationQueue е удобна за сложни многозадачни вериги: изтегли файл -> разопаковай -> запази в кеш. По подразбиране OperationQueue използва фонови нишки, освен ако не е посочено друго.

import UIKit

class ImageDownloader {

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

        // OperationQueue с 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("Загружено: \(url.lastPathComponent)")
                }
            }
        }
    }

    // GCD: глобална фонова опашка с различни QoS
    func backgroundTaskWithQoS() {
        DispatchQueue.global(qos: .userInitiated).async {
            // Висок приоритет — потребителят очаква резултат
            let result = self.heavyComputation()
            DispatchQueue.main.async {
                self.showResult(result)
            }
        }
    }

    private func heavyComputation() -> String {
        Thread.sleep(forTimeInterval: 2) // симулация на работа
        return "Резултат от изчисления"
    }

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

В примера OperationQueue зарежда две изображения паралелно (maxConcurrentOperationCount = 2) с фон чрез qualityOfService = .utility. GCD методът backgroundTaskWithQoS използва глобалната опашка с .userInitiated за задача, чийто резултат потребителят очаква. И двата подхода завършват с връщане към DispatchQueue.main за актуализиране на UI — това е задължително изискване на iOS.

Serial vs Concurrent фонови опашки

GCD поддържа два типа опашки: serial (последователни) и concurrent (паралелни). Serial опашките изпълняват задачите една по една — това е удобно за достъп до споделен ресурс (файл, база данни) без заключвания. Concurrent опашките изпълняват задачите паралелно, разпределяйки ги по свободните ядра. DispatchQueue.global — винаги concurrent. За създаване на serial опашка използвайте DispatchQueue(label: "com.app.queue").

Background Thread в Android: Executors и Dispatchers

Android предоставя няколко нива на абстракция за фонови нишки. Класическият подход — java.util.concurrent.Executors.newFixedThreadPool(n) или Executors.newCachedThreadPool(). Съвременният подход — Kotlin Coroutines с Dispatchers.IO (за вход-изход: мрежа, файлове, база данни) и Dispatchers.Default (за CPU-интензивни задачи: сортиране, обработка на изображения). WorkManager — за отложени и гарантирани фонови задачи.

HandlerThread — специален Android клас за създаване на фонова нишка със собствен Looper (опашка от съобщения). За разлика от Executors, HandlerThread позволява изпращане на съобщения и Runnable чрез Handler. Използва се за операции, които изискват поставяне в опашка (напр. последователен запис в база данни). След употреба трябва да се извика quit() или quitSafely() за освобождаване на ресурси.

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

class DataRepository {

    private val ioExecutor = Executors.newFixedThreadPool(4)

    // Класически подход чрез Executors
    fun loadDataLegacy(callback: (String) -> Unit) {
        ioExecutor.execute {
            val result = readFromFile()
            val handler = android.os.Handler(android.os.Looper.getMainLooper())
            handler.post { callback(result) }
        }
    }

    // Съвременен подход чрез Coroutines
    suspend fun loadDataCoroutines(): String {
        return withContext(Dispatchers.IO) {
            // Файлова операция — изпълнява се във фоновия пул
            readFromFile()
        }
        // Резултатът автоматично се връща на Dispatchers.Main
    }

    // CPU-интензивна задача на Dispatchers.Default
    suspend fun processImage(pixels: IntArray): IntArray {
        return withContext(Dispatchers.Default) {
            // Сортиране, филтриране — изпълнява се на Default пула
            pixels.sortedArray()
        }
    }

    private fun readFromFile(): String {
        Thread.sleep(1000) // симулация на четене от файл
        return "file_content"
    }

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

Примерът DataRepository показва еволюцията на фоновите нишки в Android. Старият метод loadDataLegacy използва Executors.newFixedThreadPool(4) с Handler за връщане към Main Thread. Съвременният loadDataCoroutines използва withContext(Dispatchers.IO) — корутината се спира по време на работа, без да блокира нишката, и автоматично се възобновява на Main Thread. Dispatchers.Default се препоръчва за CPU-bound операции (сортиране, филтриране, трансформация на данни).

Корутини като съвременен стандарт за фонови задачи

Kotlin Coroutines — не е просто начин за работа с нишки, а принципно различен модел: асинхронните задачи не са обвързани с конкретна нишка и могат да се спират (suspend) без блокиране. Това означава, че по време на фонова работа корутината не заема нишка, а я освобождава за други задачи. Механизмът suspension позволява изпълнението на стотици хиляди едновременни задачи в пул от 4-8 нишки без thread starvation.

Три основни dispatcher-а: Dispatchers.Main (UI, една нишка), Dispatchers.IO (по подразбиране 64 нишки за блокиращи операции: мрежа, файлове, база данни), Dispatchers.Default (равен на броя на CPU ядрата, за интензивни изчисления). Комбинирайки ги чрез withContext, разработчикът превключва между нишки без създаване на callback-и. withContext е suspend функция, която не връща контрола, докато задачата не бъде завършена.

// Корутини: композиция на фонови задачи
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay

suspend fun loadUserProfile(userId: String): UserProfile =
    coroutineScope {
        // Паралелно зареждане на данни от различни източници
        val user = async(Dispatchers.IO) { fetchUser(userId) }
        val posts = async(Dispatchers.IO) { fetchPosts(userId) }
        val avatar = async(Dispatchers.Default) {
            processAvatar(fetchAvatar(userId))
        }

        // await() — спира се до завършване на всички задачи
        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 }

Функцията loadUserProfile стартира три паралелни фонови задачи чрез async. fetchUser и fetchPosts — IO-bound (мрежа), изпълняват се на Dispatchers.IO. processAvatar — CPU-bound (обработка на изображение), изпълнява се на Dispatchers.Default. await() спира корутината до завършване на всички задачи. Общото време за изпълнение е равно на максималното време от трите задачи (500 ms за fetchPosts), а не на тяхната сума. Това е ключовото предимство на coroutines пред последователното изпълнение.

Structured concurrency: предотвратяване на течове

Structured concurrency — принцип, при който всяка корутина има родителски scope, и отмяната на родителя автоматично отменя дъщерните корутини. В Android lifecycleScope отменя всички корутини при унищожаване на Activity. viewModelScope — при почистване на ViewModel. Това предотвратява течове на фонови задачи: ако потребителят затвори екрана, фоновата корутина няма да продължи да зарежда данни, които вече не са нужни на никого.

// WorkManager с корутини
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 {
        // Изпълнява се на Dispatchers.Default (по подразбиране)
        return withContext(Dispatchers.IO) {
            try {
                syncDataToServer()
                Result.success()
            } catch (e: Exception) {
                if (runAttemptCount < 3) Result.retry() else Result.failure()
            }
        }
    }

    private suspend fun syncDataToServer() {
        // Симулация на синхронизация
        delay(1000)
    }
}

// Стартиране на WorkManager задача с ограничения
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)
}