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. Используется для операций, которые требуют постановки в очередь (например, последовательная запись в БД). После использования HandlerThread нужно вызвать 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. Legacy-метод loadDataLegacy использует Executors.newFixedThreadPool(4) с Handler для возврата на Main Thread. Современный loadDataCoroutines использует withContext(Dispatchers.IO) — корутина приостанавливается на время работы, не блокируя поток, и автоматически возобновляется на Main Thread. Dispatchers.Default рекомендуется для CPU-bound операций (сортировка, фильтрация, трансформация данных).

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

Kotlin Coroutines — не просто способ работы с потоками, а принципиально иная модель: асинхронные задачи не привязаны к конкретному потоку и могут приостанавливаться (suspend) без блокировки. Это значит, что while in background, корутина не занимает поток, а освобождает его для других задач. Механизм suspension позволяет выполнять сотни тысяч concurrent задач на пуле из 4-8 потоков без thread starvation.

Три основных диспатчера: 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 мс для fetchPosts), а не их сумме. Это ключевое преимущество coroutines перед последовательным выполнением.

Structured concurrency: предотвращение утечек

Structured concurrency — принцип, при котором каждая корутина имеет родительский scope, и отмена родителя автоматически отменяет дочерние корутины. В Android lifecycleScope отменяет все корутины при уничтожении Activity. viewModelScope — при очистке ViewModel. Это предотвращает утечки фоновых задач: если пользователь закрыл экран, while in background корутина не будет продолжать загрузку данных, которые уже никому не нужны.

// 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)
}