Main Thread у мобилном развоју — шта је то, улога и принцип рада

Шта је Main Thread

Main Thread — је нит коју креира оперативни систем при покретању апликације и одговорна је за обраду свих догађаја корисничког интерфејса. У контексту мобилних платформи, Main Thread се такође назива UI Thread, јер се све операције везане за исцртавање, обраду додира и анимације извршавају на њему. Свака апликација има тачно један Main Thread, а сви UI оквири (UIKit, AppKit, Android Views, Compose UI) су thread-unsafe — не гарантују исправан рад при позиву из других нити.

Архитектонски, Main Thread имплементира образац Event Loop: нит бесконачно чека нове догађаје (додире, системска обавештења, тајмере) и обрађује их по редоследу у реду. Док се један догађај обрађује, следећи чека у реду. Ако обрада траје дуже од 100-200 милисекунди, корисник примећује кашњење (jank). Ако дуже од 5 секунди (Android) — систем приказује дијалог ANR (Application Not Responding) и предлаже затварање апликације.

Важност разумевања Main Thread-а је тешко преценити: то је извор 90% проблема са перформансама у мобилним апликацијама. Програмери често забораве да преместе тешке операције (мрежа, датотеке, парсирање JSON, компресија слика) у позадинске нити. Чак и операција која се на емулатору извршава за 10 милисекунди, на стварном уређају са спорим диском може трајати 500 милисекунди и довести до приметног заостајања.

Зашто UI мора да се ажурира само на Main Thread-у

Thread-unsafe UI оквира — архитектонска одлука донета још у првим верзијама UIKit (2007) и Android (2008). Главни разлог су перформансе: синхронизација приступа UI компонентама кроз блокаде (locks) додала би додатни трошак свакој операцији исцртавања. Уместо тога, оквири захтевају да се све промене UI извршавају строго на једној нити, елиминишући race condition без overhead-а.

Замислите да две позадинске нити истовремено позивају textView.setText(). Да је UI thread-safe, оба позива би била синхронизована кроз mutex, што би успорило исцртавање за 20-40%. У тренутној архитектури, сваки позив UI из позадинске нити се или игнорише или изазива пад (у iOS — Main Thread Checker Exception, у Android — CalledFromWrongThreadException). Изузетак — SurfaceView и TextureView у Android-у, где се исцртавање може извршавати из посебне нити.

Модерни мобилни оквири (SwiftUI, Jetpack Compose) задржавају ово ограничење: SwiftUI захтева да се све промене State и ObservedObject дешавају на Main Thread-у, иако је само исцртавање делимично премештено у позадинске нити. Jetpack Compose такође очекује измену State на Main Thread-у. Изузетак — Compose модификатори везани за drawBehind и layout, који се могу позивати из других нити уз експлицитну документацију.

Main Thread у iOS: RunLoop.main и DispatchQueue.main

DispatchQueue.main — основни механизам за слање кода на Main Thread у iOS-у. Ово је серијски ред повезан са главним RunLoop-ом апликације. Сви блокови послати у њега извршавају се секвенцијално, по редоследу приспећа. SwiftUI и UIKit се аутоматски ажурирају ако мењате State или позивате setNeedsLayout() са Main Thread-а. За асинхроно враћање резултата из позадинског задатка користите DispatchQueue.main.async {}.

У Objective-C-Swift мосту такође је доступно Thread.isMainThread — својство које проверава да ли се тренутни код извршава на главној нити. За постојеће UIKit пројекте ово је стандардни образац: if Thread.isMainThread { updateUI() } else { DispatchQueue.main.async { updateUI() } }. У SwiftUI-ју ова провера обично није потребна, јер оквир сам гарантује позивање body и modifier на Main Thread-у.

import UIKit

class ViewController: UIViewController {

    let imageView = UIImageView()

    func loadImageFromNetwork() {
        // Позадинска нит: преузимање слике
        DispatchQueue.global(qos: .background).async { [weak self] in
            guard let url = URL(string: "https://example.com/image.png"),
                  let data = try? Data(contentsOf: url),
                  let image = UIImage(data: data)
            else { return }

            // Повратак на Main Thread за ажурирање UI
            DispatchQueue.main.async {
                self?.imageView.image = image
                self?.imageView.setNeedsLayout()
            }
        }
    }

    // Провера да ли се код извршава на Main Thread-у
    func safeUpdateUI() {
        if Thread.isMainThread {
            updateUI()
        } else {
            DispatchQueue.main.async {
                self.updateUI()
            }
        }
    }

    private func updateUI() {
        print("UI ажуриран на Main Thread-у")
    }
}

Пример loadImageFromNetwork() демонстрира исправан образац: URLSession или Data(contentsOf:) се извршавају на позадинској нити кроз DispatchQueue.global, након чега се резултат враћа на DispatchQueue.main ради ажурирања UIImageView. Без DispatchQueue.main.async апликација ће пасти са NSInternalInconsistencyException при позиву UIKit из позадинске нити.

DispatchQueue.main.async — гаранција повратка

Најпоузданији начин извршавања кода на Main Thread-у у iOS-у — експлицитно слање кроз DispatchQueue.main.async. Чак и ако се већ налазите на Main Thread-у, async слање не изазива проблеме: GCD га обрађује у следећој итерацији RunLoop-а. За синхроно извршавање користите DispatchQueue.main.sync, али то може изазвати deadlock ако позовете sync са Main Thread-а. Правило: async за враћање резултата, sync само ако сте сигурни да нисте на главној нити.

RunLoop.main као основа Main Thread-а

RunLoop.main — је CFRunLoop објекат повезан са главним редом догађаја iOS-а. Он обрађује изворе улаза (touch events), тајмере и DispatchQueue.main блокове. Сваки оквир исцртавања (60/120 FPS) захтева завршетак свих операција у RunLoop-у пре вертикалног синхроног импулса (VSync). Ако операције на Main Thread-у трају дуже од 16.6 ms (60 FPS) или 8.3 ms (120 FPS), апликација прескаче оквире, што се визуелно манифестује као jank или stutter.

Main Thread у Android: Looper и Handler

Looper.getMainLooper() — основни механизам Android-а за рад са главном нити. Сваки Main Thread у Android-у има Looper који бесконачно извлачи поруке из реда (MessageQueue) и прослеђује их Handler-у за обраду. Activity.runOnUiThread() и View.post() су високо ниво омотачи око Handler(Looper.getMainLooper()). Kotlin Coroutines са Dispatchers.Main — модеран начин повратка на главну нит.

Android такође пружа StrictMode — алат за откривање операција које блокирају Main Thread. StrictMode.setThreadPolicy() вам омогућава да поставите политику: забрана мрежних позива (NetworkPolicy), читања са диска (DiskRead), писања на диск (DiskWrite) на главној нити. При кршењу политике генерише се изузетак или се пише порука у logcat.

// Android: рад са Main Thread и Kotlin Coroutines
import android.os.Bundle
import android.widget.TextView
import androidx.activity.ComponentActivity
import androidx.lifecycle.lifecycleScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.launch
import kotlinx.coroutines.withContext
import java.net.URL

class MainActivity : ComponentActivity() {

    private lateinit var textView: TextView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        textView = TextView(this)
        setContentView(textView)

        // Пример: асинхроно учитавање података
        lifecycleScope.launch {
            val result = loadData() // извршава се на Dispatchers.IO
            textView.text = result // UI на Main Thread-у
        }
    }

    private suspend fun loadData(): String {
        return withContext(Dispatchers.IO) {
            URL("https://api.example.com/data").readText()
        }
    }
}

// StrictMode за откривање кршења Main Thread-а
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        StrictMode.setThreadPolicy(
            StrictMode.ThreadPolicy.Builder()
                .detectDiskReads()
                .detectDiskWrites()
                .detectNetwork()
                .penaltyLog()
                .build()
        )
    }
}

Пример у Kotlin-у показује исправну употребу Dispatchers.Main кроз lifecycleScope.launch и Dispatchers.IO кроз withContext. Сав мрежни рад се извршава на IO-диспечеру, а ажурирање TextView — аутоматски на Main Thread-у, јер launch у lifecycleScope подразумевано користи Dispatchers.Main. StrictMode у Application.onCreate() пресреће случајне мрежне позиве и диск операције на главној нити.

Откривање кршења Main Thread-а

Main Thread Checker — алат уграђен у Xcode (доступан од Xcode 9) који проналази позиве UIKit, AppKit и других UI оквира из позадинских нити. Током отклањања грешака, Main Thread Checker анализира све позиве UI-API и при откривању кршења показује breakpoint са детаљним стек трагом. На правим уређајима (у релеасе верзији) Main Thread Checker не ради — кршења ће се манифестовати као пад или нетачно понашање.

У Android-у је аналоган StrictMode (описан горе) и уграђени лог детектор: при позиву View.setText() или View.invalidate() из позадинске нити Android баца CalledFromWrongThreadException. Додатно, Android Studio Profiler показује које се операције извршавају на Main Thread-у. Ако видите мрежне или датотечне операције на Main Thread-у — то је сигуран знак проблема.

Визуелни образац: испрекидан скрол

Најуочљивији симптом блокирања Main Thread-а — janky scroll (испрекидан скрол). Када корисник скролује UITableView или RecyclerView, систем очекује да ће следећи оквир бити готов за 16 ms. Ако се на Main Thread-у извршава декодирање слике или парсирање JSON, исцртавање оквира касни и корисник види трзаје. За дијагностику користите профилер: ако метод prepareDisplay() или layoutSubviews() траје >16 ms — подаци се обрађују на погрешној нити.

Типични сценарији блокирања Main Thread-а

Први сценариј — синхрони мрежни захтев кроз URLConnection или Data(contentsOf:) на Main Thread-у. У Android-у StrictMode са detectNetwork() одмах ће ухватити ово кршење. У iOS-у синхрони URLSession неће дати експлицитну грешку, али ће UI замрзнути на време захтева (1-10 секунди). Решење: користите URLSession.dataTask (iOS) или Retrofit/OkHttp (Android) са асинхроним повратним позивом.

Други сценариј — декодирање и компресија слика. UIImage(data:) или BitmapFactory.decodeResource() у Android-у на главној нити — један од најчешћих узрока jank-а. Слика од 4000x3000 пиксела декодира се 50-150 милисекунди, што прелази лимит од 16 ms. Решење: користите ImageLoader (Kingfisher, Coil, Glide) који гарантују декодирање у позадинској нити.

Трећи сценариј — парсирање JSON. Анализа API одговора кроз JSONSerialization (iOS) или JSONObject (Android) на Main Thread-у. Чак и мали JSON од 100 KB парсира се 5-15 милисекунди, али на спорим уређајима — до 50 милисекунди. У комбинацији са другим операцијама ово се акумулира и доводи до прескочених оквира. Решење: користите kotlinx.serialization/Decodable са позивом parse() на позадинској нити, остављајући на Main Thread-у само доделу резултата.