Main Thread v mobilním vývoji — co to je, role a princip fungování

Co je Main Thread

Main Thread — je vlákno vytvořené operačním systémem při spuštění aplikace, které je odpovědné za zpracování všech událostí uživatelského rozhraní. V kontextu mobilních platforem se Main Thread také nazývá UI Thread, protože na něm jsou prováděny všechny operace související s vykreslováním, zpracováním dotyků a animacemi. Každá aplikace má přesně jeden Main Thread a všechny UI frameworky (UIKit, AppKit, Android Views, Compose UI) jsou thread-unsafe — nezaručují správnou funkci při volání z jiných vláken.

Architektonicky Main Thread implementuje vzor Event Loop: vlákno nekonečně čeká na nové události (dotyky, systémová oznámení, časovače) a zpracovává je v pořadí fronty. Zatímco je jedna událost zpracovávána, další čeká ve frontě. Pokud zpracování trvá déle než 100-200 milisekund, uživatel zaznamená zpoždění (jank). Pokud déle než 5 sekund (Android) — systém zobrazí dialog ANR (Application Not Responding) a nabídne ukončení aplikace.

Důležitost porozumění Main Thread je obtížné přecenit: je zdrojem 90% problémů s výkonem v mobilních aplikacích. Vývojáři často zapomínají přesunout těžké operace (síť, soubory, parsování JSON, komprese obrázků) do vláken na pozadí. I operace, která na emulátoru trvá 10 milisekund, může na skutečném zařízení s pomalým diskem trvat 500 milisekund a vést k znatelnému lagu.

Proč musí být UI aktualizováno pouze na Main Thread

Thread-unsafe UI frameworků — architektonické rozhodnutí přijaté již v prvních verzích UIKit (2007) a Androidu (2008). Hlavním důvodem je výkon: synchronizace přístupu ke komponentám UI prostřednictvím zámků (locks) by přidala režii každé operaci vykreslování. Místo toho frameworky vyžadují, aby všechny změny UI byly prováděny striktně na jednom vlákně, čímž eliminují race condition bez režie.

Představte si, že dvě vlákna na pozadí současně volají textView.setText(). Pokud by UI byl thread-safe, obě volání by byla synchronizována přes mutex, což by zpomalilo vykreslování o 20-40%. V současné architektuře je každé volání UI z vlákna na pozadí buď ignorováno, nebo způsobí pád (v iOS — Main Thread Checker Exception, v Androidu — CalledFromWrongThreadException). Výjimka — SurfaceView a TextureView v Androidu, kde vykreslování může být prováděno z odděleného vlákna.

Moderní mobilní frameworky (SwiftUI, Jetpack Compose) toto omezení zachovávají: SwiftUI vyžaduje, aby všechny změny State a ObservedObject probíhaly na Main Thread, i když samotné vykreslování je částečně přesunuto do vláken na pozadí. Jetpack Compose také očekává úpravu State na Main Thread. Výjimka — modifikátory Compose související s drawBehind a layout, které mohou být volány z jiných vláken s explicitní dokumentací.

Main Thread v iOS: RunLoop.main a DispatchQueue.main

DispatchQueue.main — hlavní mechanismus pro odesílání kódu na Main Thread v iOS. Je to sériová fronta připojená k hlavnímu RunLoop aplikace. Všechny bloky do ní odeslané jsou prováděny sekvenčně, v pořadí příchodu. SwiftUI a UIKit se automaticky aktualizují, pokud upravíte State nebo zavoláte setNeedsLayout() z Main Thread. Pro asynchronní vrácení výsledku z úlohy na pozadí použijte DispatchQueue.main.async {}.

V můstku Objective-C-Swift je také k dispozici Thread.isMainThread — vlastnost, která kontroluje, zda je aktuální kód prováděn na hlavním vlákně. Pro existující projekty UIKit je to standardní vzor: if Thread.isMainThread { updateUI() } else { DispatchQueue.main.async { updateUI() } }. Ve SwiftUI tato kontrola obvykle není nutná, protože framework sám zaručuje, že body a modifier jsou volány na Main Thread.

import UIKit

class ViewController: UIViewController {

    let imageView = UIImageView()

    func loadImageFromNetwork() {
        // Vlákno na pozadí: stahování obrázku
        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 }

            // Návrat na Main Thread pro aktualizaci UI
            DispatchQueue.main.async {
                self?.imageView.image = image
                self?.imageView.setNeedsLayout()
            }
        }
    }

    // Kontrola, zda je kód prováděn na Main Thread
    func safeUpdateUI() {
        if Thread.isMainThread {
            updateUI()
        } else {
            DispatchQueue.main.async {
                self.updateUI()
            }
        }
    }

    private func updateUI() {
        print("UI aktualizováno na Main Thread")
    }
}

Příklad loadImageFromNetwork() demonstruje správný vzor: URLSession nebo Data(contentsOf:) jsou prováděny na vlákně na pozadí přes DispatchQueue.global, poté je výsledek vrácen na DispatchQueue.main pro aktualizaci UIImageView. Bez DispatchQueue.main.async aplikace spadne s NSInternalInconsistencyException při volání UIKit z vlákna na pozadí.

DispatchQueue.main.async — záruka návratu

Nejspolehlivější způsob provádění kódu na Main Thread v iOS — explicitní odeslání přes DispatchQueue.main.async. I když jste již na Main Thread, odeslání async nezpůsobuje problémy: GCD ho zpracuje v další iteraci RunLoop. Pro synchronní provádění použijte DispatchQueue.main.sync, ale to může způsobit deadlock, pokud zavoláte sync z Main Thread. Pravidlo: async pro vrácení výsledku, sync pouze pokud máte jistotu, že nejste na hlavním vlákně.

RunLoop.main jako základ Main Thread

RunLoop.main — je objekt CFRunLoop připojený k hlavní frontě událostí iOS. Zpracovává vstupní zdroje (touch events), časovače a bloky DispatchQueue.main. Každý snímek vykreslování (60/120 FPS) vyžaduje dokončení všech operací v RunLoop před vertikálním synchronizačním impulsem (VSync). Pokud operace na Main Thread trvají déle než 16.6 ms (60 FPS) nebo 8.3 ms (120 FPS), aplikace přeskakuje snímky, což se vizuálně projevuje jako jank nebo stutter.

Main Thread v Androidu: Looper a Handler

Looper.getMainLooper() — hlavní mechanismus Androidu pro práci s hlavním vláknem. Každý Main Thread v Androidu má Looper, který nekonečně vyjímá zprávy z fronty (MessageQueue) a předává je Handleru ke zpracování. Activity.runOnUiThread() a View.post() jsou vysokotrovňové obaly kolem Handler(Looper.getMainLooper()). Kotlin Coroutines s Dispatchers.Main — moderní způsob návratu na hlavní vlákno.

Android také poskytuje StrictMode — nástroj pro detekci operací blokujících Main Thread. StrictMode.setThreadPolicy() umožňuje nastavit politiku: zákaz síťových volání (NetworkPolicy), čtení z disku (DiskRead), zápisu na disk (DiskWrite) na hlavním vlákně. Při porušení politiky je vygenerována výjimka nebo zapsána zpráva do logcat.

// Android: práce s Main Thread a 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)

        // Příklad: asynchronní načítání dat
        lifecycleScope.launch {
            val result = loadData() // prováděno na Dispatchers.IO
            textView.text = result // UI na Main Thread
        }
    }

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

// StrictMode pro detekci porušení Main Thread
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        StrictMode.setThreadPolicy(
            StrictMode.ThreadPolicy.Builder()
                .detectDiskReads()
                .detectDiskWrites()
                .detectNetwork()
                .penaltyLog()
                .build()
        )
    }
}

Příklad v Kotlin ukazuje správné použití Dispatchers.Main přes lifecycleScope.launch a Dispatchers.IO přes withContext. Veškerá síťová práce je prováděna na IO-dispatcheru a aktualizace TextView — automaticky na Main Thread, protože launch v lifecycleScope standardně používá Dispatchers.Main. StrictMode v Application.onCreate() zachycuje náhodná síťová volání a diskové operace na hlavním vlákně.

Detekce porušení Main Thread

Main Thread Checker — nástroj vestavěný do Xcode (dostupný od Xcode 9), který nachází volání UIKit, AppKit a dalších UI frameworků z vláken na pozadí. Během ladění Main Thread Checker analyzuje všechna volání UI-API a při detekci porušení zobrazí breakpoint s podrobným zásobníkem volání. Na skutečných zařízeních (v release sestavení) Main Thread Checker nefunguje — porušení se projeví jako pád nebo nesprávné chování.

V Androidu je obdobou StrictMode (popsáno výše) a vestavěný detektor logů: při volání View.setText() nebo View.invalidate() z vlákna na pozadí Android vyvolá CalledFromWrongThreadException. Navíc Android Studio Profiler ukazuje, které operace jsou prováděny na Main Thread. Pokud vidíte síťové nebo souborové operace na Main Thread — je to jistý znak problému.

Vizuální vzor: trhané scrollování

Nejviditelnější příznak blokování Main Thread — janky scroll (trhané scrollování). Když uživatel scrolluje UITableView nebo RecyclerView, systém očekává, že další snímek bude připraven do 16 ms. Pokud na Main Thread probíhá dekódování obrázku nebo parsování JSON, vykreslení snímku se zpozdí a uživatel vidí škubání. Pro diagnostiku použijte profiler: pokud metoda prepareDisplay() nebo layoutSubviews() trvá >16 ms — data jsou zpracovávána na nesprávném vlákně.

Typické scénáře blokování Main Thread

První scénář — synchronní síťový požadavek přes URLConnection nebo Data(contentsOf:) na Main Thread. V Androidu StrictMode s detectNetwork() okamžitě zachytí toto porušení. V iOS synchronní URLSession neposkytne explicitní chybu, ale UI zamrzne na dobu požadavku (1-10 sekund). Řešení: použijte URLSession.dataTask (iOS) nebo Retrofit/OkHttp (Android) s asynchronním callbackem.

Druhý scénář — dekódování a komprese obrázků. UIImage(data:) nebo BitmapFactory.decodeResource() v Androidu na hlavním vlákně — jedna z nejčastějších příčin janku. Obrázek 4000x3000 pixelů se dekóduje 50-150 milisekund, což překračuje limit 16 ms. Řešení: použijte ImageLoader (Kingfisher, Coil, Glide), které zaručují dekódování na vlákně na pozadí.

Třetí scénář — parsování JSON. Analýza odpovědi API přes JSONSerialization (iOS) nebo JSONObject (Android) na Main Thread. I malý JSON o 100 KB se parsuje 5-15 milisekund, ale na pomalých zařízeních — až 50 milisekund. V kombinaci s jinými operacemi se to kumuluje a vede k přeskočeným snímkům. Řešení: použijte kotlinx.serialization/Decodable s voláním parse() na vlákně na pozadí, ponechte na Main Thread pouze přiřazení výsledku.