Многонишковост и Concurrency в мобилното разработване: какво е това, принципи и как работи

Какво е многонишковост?

Многонишковостта е способността на приложението да изпълнява няколко фрагмента код едновременно. Всеки фрагмент се изпълнява в отделна нишка (Thread) — лек процес със собствен стек за извиквания. В мобилното разработване нишките се разделят на две категории: Main Thread (UI нишка) и Background Threads (фонови нишки).

Операционната система сама управлява разпределението на нишките по ядрата на процесора. Съвременните устройства имат 6–8 ядра, така че паралелното изпълнение може да ускори работата. Създаването на нишки обаче е скъпа операция, затова не се препоръчва директна работа с Thread. Вместо това се използват абстракции на по-високо ниво: DispatchQueue, OperationQueue, CoroutineDispatcher.

Concurrency е по-широко понятие от многонишковостта. Concurrency означава, че задачите могат да се изпълняват „едновременно" дори на едно ядро чрез превключване на контекста. Асинхронността (Async/Await) е модел на програмиране, при който задачата не блокира нишка, а връща контрола, докато чака резултат. Съвременните езици (Kotlin, Swift, Dart) имат вградена поддръжка за Async/Await.

В IT Sectr обръщаме специално внимание на правилната архитектура на многонишковостта в началото на проекта. Грешките, допуснати в ранен етап, водят до трудно откриваеми бъгове: състезания на данни, взаимни блокировки и нестабилност на приложението под натоварване. Всеки наш проект преминава преглед на архитектурата на concurrency на етапа на планиране.

Основни нишки (Main/Background)

Main Thread (главната нишка) — единствената нишка в мобилно приложение, която има достъп до UI. На Android се нарича UI Thread, на iOS — Main Thread. Всички операции с интерфейса — промяна на текст, анимация, обработка на докосвания — се извършват само на Main Thread. Ако на главната нишка се изпълнява тежка операция (зареждане на файл, анализиране на JSON), интерфейсът спира да реагира. На Android това води до ANR (Application Not Responding), на iOS — до „замръзване" на екрана.

Background Threads (фонови нишки) са предназначени за всичко, което не е свързано с UI: мрежови заявки, операции с база данни, обработка на изображения, криптография. След завършване резултатът се предава на Main Thread за показване. Всяка платформа предоставя свои инструменти за превключване между нишки: DispatchQueue.main.async в iOS, runOnUiThread или withContext(Dispatchers.Main) в Android.

RunLoop — цикъл за обработка на събития на главната нишка на iOS. RunLoop чака събития (докосвания, таймери, известия) и ги разпределя към съответните манипулатори. На Android аналогът е Looper, свързан с всяка Main Thread. Main Looper безкрайно извлича съобщения от опашката и ги предава на Handler за обработка. Разбирането на RunLoop и Looper помага да се избегнат изтичания на памет и „заекване" на интерфейса.

GCD и OperationQueue (iOS)

Grand Central Dispatch (GCD) — библиотека на Apple за управление на многонишковостта на ниво език C. GCD работи с DispatchQueue — опашки от задачи. Разработчикът не създава нишки ръчно; GCD управлява пул от нишки (Thread Pool), разпределяйки задачите по наличните ядра на процесора. DispatchQueue са два вида: Serial Queue (серийна опашка — задачите се изпълняват една след друга) и Concurrent Queue (конкурентна опашка — задачите могат да се изпълняват едновременно).

Main DispatchQueue — серийна опашка, свързана с главната нишка. Global Queues — конкурентни опашки с различни приоритети (QoS — Quality of Service): userInteractive, userInitiated, utility, background. Изборът на правилния QoS е критичен за производителността: .userInteractive — за задачи, влияещи на UI (анимации, рендериране); .background — за времево некритични задачи (синхронизация, почистване на кеш).

OperationQueue — абстракция над GCD с допълнителни възможности: отмяна на задачи, задаване на зависимости между операциите, контрол на максималния брой конкурентни операции. Операциите са обекти на клас Operation (или BlockOperation). Пример: ако трябва да заредите изображение, след това да приложите филтър и едва тогава да го покажете — OperationQueue със зависимости се справя перфектно. В GCD ще трябва ръчно да синхронизирате тези стъпки чрез DispatchGroup или семафор.

Async/Await в Swift 5.5+ — модерна алтернатива на GCD. Ключовите думи async и await правят асинхронния код линеен и четим. Функциите се маркират като async, а извикванията се очакват чрез await. Системата сама управлява превключването на контекста: по подразбиране async функция се изпълнява на фонова нишка, докато актуализацията на UI се изпълнява на MainActor. @MainActor — атрибут, гарантиращ изпълнение на кода на главната нишка.

Coroutines и Flow (Kotlin)

Coroutines (корутини) — леки нишки за Kotlin, разработени от JetBrains. За разлика от обикновените нишки, корутините не са обвързани с конкретна Thread. Хиляди корутини могат да работят на няколко нишки без значително натоварване. CoroutineScope управлява жизнения цикъл на корутините: viewModelScope е обвързан с ViewModel, lifecycleScope — с Activity/Fragment. Когато обхватът бъде унищожен, всички дъщерни корутини автоматично се отменят.

Dispatchers определят на кой пул от нишки се изпълнява корутината: Dispatchers.Main — UI нишка; Dispatchers.IO — за мрежови заявки и дисково операции; Dispatchers.Default — за изчисления, интензивни за CPU. За смяна на диспечера се използва withContext. Корутините поддържат структуриран concurrency: всяка корутина има родител и когато родителят бъде отменен, всички дъщерни корутини се отменят. Това предотвратява изтичане на памет и висящи задачи.

Flow — студен асинхронен поток от данни от библиотеката на корутините. Flow излъчва стойности последователно: (1) производителят генерира данни, (2) операторите трансформират потока, (3) колекторът консумира резултата. За разлика от LiveData, Flow поддържа сложни вериги от оператори (map, filter, flatMapConcat, catch) и е напълно безопасен за нишки. StateFlow и SharedFlow — горещи разновидности на Flow, идеални за състояние на UI и еднократни събития (Snackbar, навигация).

Channel — друга абстракция на корутини за предаване на данни между корутини. Channel работи като опашка: един изпращач (send) и един или повече получатели (receive). Буферираните канали (Channel(UNLIMITED), Channel(BUFFERED)) позволяват конфигуриране на поведението при препълване. Channel често се използва с Flow за свързване на API, базирани на обратни извиквания, с корутини: callbackFlow { … }.

В IT Sectr активно използваме корутини и Flow във всички Android проекти. Това позволява писане на асинхронен код, който изглежда синхронен, лесно се тества (runTest, TestDispatcher) и не изисква ръчно управление на нишки. Пример за проста корутина със зареждане на данни:

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): List<User> = withContext(Dispatchers.IO) {
        return@withContext try {
            val users = api.fetchUsers()
            dao.insertAll(users)
            users
        } catch (e: Exception) {
            dao.getAll()
        }
    }
}

Rx и Combine

Реактивно програмиране — парадигма, при която данните се разпространяват като асинхронни потоци (Observable, Publisher). RxJava/RxKotlin — най-популярната имплементация за Android, пренесена от .NET Rx. RxSwift — подобна библиотека за iOS. Основни компоненти: Observable (източник на събития), Observer (абонат), Scheduler (управление на нишки), Operators (трансформация на поток).

Combine — рамка на Apple за реактивно програмиране, представена в iOS 13. Combine използва протоколите Publisher (издател) и Subscriber (абонат). За разлика от RxSwift, Combine е вграден в SDK и тясно интегриран със SwiftUI. Оператори в Combine: map, filter, combineLatest, zip, debounce, throttle — покриват повечето сценарии: от свързване на данни към UI до debounce на заявка за търсене.

Future и Promise — модели за работа с един асинхронен резултат. Future представлява стойност, която ще бъде достъпна по-късно. Promise е обещание да се предостави стойност. В Rx това е Single (един успешен отговор или грешка), в Combine — Future Publisher. На практика Future/Promise са удобни за единични API заявки, докато Observable/Publisher — за непрекъснати потоци (геолокация, въвеждане на текст).

Callback и Delegate — класически модели за асинхронни операции. Callback — функция, предадена като аргумент и извикана при завършване на операцията. Delegate — обект, имплементиращ протокол с методи за обработка на събития. Недостатък: „callback ад" (вложени callback-и) и сложност при обработка на грешки. NotificationCenter (iOS) и EventBus (Android) — механизми за разпръскване на събития, полезни за слабо свързана комуникация, но водещи до имплицитни зависимости.

Проблеми на многонишковостта (Race Condition, Deadlock)

Многонишковостта отваря вратата към висока производителност, но същевременно създава риск от трудно откриваеми грешки. Най-често срещаните: Race Condition (състояние на състезание), Deadlock (взаимна блокировка), Livelock (активна блокировка) и Starvation (гладуване на нишка). Разбирането на тези проблеми е задължително умение за всеки мобилен разработчик.

Race Condition

Race Condition възниква, когато две или повече нишки едновременно четат и записват едни и същи данни без синхронизация. Резултатът зависи от това коя нишка ще се изпълни първа. Класически пример: две нишки увеличават брояч. Операцията „прочети → увеличи → запиши" не е атомарна, така че при едновременно изпълнение едно увеличение се „губи". Решението — използване на атомарни операции (AtomicInteger, AtomicReference) или заключвания (Mutex, Semaphore, synchronized).

Deadlock

Deadlock — ситуация, при която всяка нишка държи ресурс и чака ресурс, държан от друга нишка. Никоя нишка не може да продължи. Условия за възникване: взаимно изключване, задържане и чакане, без превантивност, циклично чакане. Предотвратяване: установяване на единен ред за получаване на заключвания, използване на tryLock с таймаут, прилагане на алгоритми без заключване (Lock-Free) (ConcurrentHashMap, CopyOnWriteArrayList).

Livelock и Starvation

Livelock — нишките не са блокирани, но постоянно „прехвърлят" ресурси една на друга, без да извършват полезна работа. Пример: двама души се срещат в коридор и и двамата отстъпват, движейки се в една и съща посока. Starvation — нишка не получава достъп до ресурс, защото други нишки постоянно го прихващат. Решение: справедливи заключвания (fair locks), приоритети на нишките с внимание.

Инструменти за синхронизация

За предотвратяване на проблеми с многонишковостта се използват примитиви за синхронизация: Mutex (взаимно изключване), Semaphore (ограничаване на броя едновременни достъпи), Lock (интерфейс с tryLock), Synchronized (заключване на ниво JVM), @MainActor (Swift — гаранция за изпълнение на главната нишка). На Android е достъпен и ThreadPool чрез Executors.newFixedThreadPool, newCachedThreadPool. Ръчното управление на пулове обаче е прерогатив на наследени проекти; в нови проекти е по-добре да се използват корутини.