Main Thread trong phát triển di động — nó là gì, vai trò và nguyên lý hoạt động

Main Thread là gì

Main Thread là luồng được tạo bởi hệ điều hành khi khởi động ứng dụng và chịu trách nhiệm xử lý tất cả các sự kiện giao diện người dùng. Trong bối cảnh nền tảng di động, Main Thread còn được gọi là UI Thread, vì tất cả các thao tác liên quan đến kết xuất, xử lý chạm và hoạt ảnh đều được thực thi trên nó. Mỗi ứng dụng có chính xác một Main Thread, và tất cả các framework UI (UIKit, AppKit, Android Views, Compose UI) đều không an toàn luồng — chúng không đảm bảo hoạt động chính xác khi được gọi từ các luồng khác.

Về mặt kiến trúc, Main Thread triển khai mẫu Event Loop: luồng chờ vô hạn các sự kiện mới (chạm, thông báo hệ thống, bộ hẹn giờ) và xử lý chúng theo thứ tự hàng đợi. Trong khi một sự kiện đang được xử lý, sự kiện tiếp theo chờ trong hàng đợi. Nếu xử lý mất hơn 100-200 mili giây, người dùng nhận thấy độ trễ (jank). Nếu hơn 5 giây (Android) — hệ thống hiển thị hộp thoại ANR (Application Not Responding) và đề nghị đóng ứng dụng.

Tầm quan trọng của việc hiểu Main Thread không thể được đánh giá quá cao: nó là nguồn gốc của 90% vấn đề hiệu suất trong ứng dụng di động. Các nhà phát triển thường quên di chuyển các thao tác nặng (mạng, tệp, phân tích JSON, nén ảnh) sang luồng nền. Ngay cả một thao tác mất 10 mili giây trên trình giả lập cũng có thể mất 500 mili giây trên thiết bị thực với đĩa chậm và gây ra độ trễ đáng kể.

Tại sao UI chỉ nên được cập nhật trên Main Thread

Các framework UI không an toàn luồng là một quyết định kiến trúc được đưa ra trong các phiên bản đầu tiên của UIKit (2007) và Android (2008). Lý do chính là hiệu suất: đồng bộ hóa quyền truy cập vào các thành phần UI thông qua khóa (locks) sẽ thêm chi phí vào mỗi thao tác kết xuất. Thay vào đó, các framework yêu cầu tất cả các thay đổi UI được thực hiện nghiêm ngặt trên một luồng duy nhất, loại bỏ điều kiện cạnh tranh (race conditions) mà không có chi phí.

Hãy tưởng tượng hai luồng nền đồng thời gọi textView.setText(). Nếu UI an toàn luồng, cả hai cuộc gọi sẽ đồng bộ hóa qua mutex, làm chậm kết xuất 20-40%. Trong kiến trúc hiện tại, bất kỳ cuộc gọi UI nào từ luồng nền đều bị bỏ qua hoặc gây ra sự cố (trong iOS — Main Thread Checker Exception, trong Android — CalledFromWrongThreadException). Ngoại lệ là SurfaceView và TextureView trong Android, nơi kết xuất có thể được thực hiện từ một luồng riêng.

Các framework di động hiện đại (SwiftUI, Jetpack Compose) duy trì giới hạn này: SwiftUI yêu cầu tất cả các thay đổi State và ObservedObject xảy ra trên Main Thread, mặc dù kết xuất tự nó được chuyển một phần sang luồng nền. Jetpack Compose cũng mong đợi sửa đổi State trên Main Thread. Ngoại lệ là các bổ tố Compose liên quan đến drawBehind và layout, có thể được gọi từ các luồng khác khi được tài liệu hóa rõ ràng.

Main Thread trong iOS: RunLoop.main và DispatchQueue.main

DispatchQueue.main — cơ chế chính để gửi mã đến Main Thread trong iOS. Đây là hàng đợi tuần tự gắn với RunLoop chính của ứng dụng. Tất cả các khối được gửi đến nó thực thi tuần tự, theo thứ tự đến. SwiftUI và UIKit tự động cập nhật nếu bạn sửa đổi State hoặc gọi setNeedsLayout() từ Main Thread. Để trả về kết quả bất đồng bộ từ tác vụ nền, hãy sử dụng DispatchQueue.main.async {}.

Trong cầu nối Objective-C-Swift, Thread.isMainThread cũng có sẵn — một thuộc tính kiểm tra xem mã hiện tại có đang thực thi trên luồng chính hay không. Đối với các dự án UIKit hiện có, đây là một mẫu tiêu chuẩn: if Thread.isMainThread { updateUI() } else { DispatchQueue.main.async { updateUI() } }. Trong SwiftUI, kiểm tra này thường không cần thiết, vì framework đảm bảo body và modifier thực thi trên Main Thread.

import UIKit

class ViewController: UIViewController {

    let imageView = UIImageView()

    func loadImageFromNetwork() {
        // Luồng nền: đang tải ảnh
        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 }

            // Quay lại Main Thread để cập nhật UI
            DispatchQueue.main.async {
                self?.imageView.image = image
                self?.imageView.setNeedsLayout()
            }
        }
    }

    // Kiểm tra xem mã có đang thực thi trên Main Thread không
    func safeUpdateUI() {
        if Thread.isMainThread {
            updateUI()
        } else {
            DispatchQueue.main.async {
                self.updateUI()
            }
        }
    }

    private func updateUI() {
        print("UI đã được cập nhật trên Main Thread")
    }
}

Trong ví dụ, loadImageFromNetwork() minh họa mẫu chính xác: URLSession hoặc Data(contentsOf:) thực thi trên luồng nền qua DispatchQueue.global, sau đó kết quả được trả về DispatchQueue.main để cập nhật UIImageView. Nếu không có DispatchQueue.main.async, ứng dụng sẽ gặp sự cố với NSInternalInconsistencyException khi gọi UIKit từ luồng nền.

DispatchQueue.main.async — Đảm bảo quay lại

Cách đáng tin cậy nhất để thực thi mã trên Main Thread trong iOS là gửi rõ ràng qua DispatchQueue.main.async. Ngay cả khi bạn đã ở trên Main Thread, gửi async không gây ra vấn đề: GCD xử lý nó ở lần lặp RunLoop tiếp theo. Để thực thi đồng bộ, hãy sử dụng DispatchQueue.main.sync, nhưng điều này có thể gây ra deadlock nếu được gọi từ Main Thread. Quy tắc: async để trả về kết quả, sync chỉ khi bạn được đảm bảo không ở trên luồng chính.

RunLoop.main làm nền tảng của Main Thread

RunLoop.main là một đối tượng CFRunLoop liên kết với hàng đợi sự kiện chính của iOS. Nó xử lý các nguồn đầu vào (sự kiện chạm), bộ hẹn giờ và các khối DispatchQueue.main. Mỗi khung kết xuất (60/120 FPS) yêu cầu tất cả các thao tác trong RunLoop phải hoàn thành trước xung đồng bộ dọc (VSync). Nếu các thao tác trên Main Thread mất hơn 16,6 ms (60 FPS) hoặc 8,3 ms (120 FPS), ứng dụng bỏ qua khung, biểu hiện trực quan là jank hoặc stutter.

Main Thread trong Android: Looper và Handler

Looper.getMainLooper() — cơ chế chính của Android để làm việc với luồng chính. Mỗi Main Thread trong Android có một Looper trích xuất vô hạn các thông báo từ hàng đợi (MessageQueue) và chuyển chúng đến Handler để xử lý. Activity.runOnUiThread() và View.post() là các trình bao bọc cấp cao xung quanh Handler(Looper.getMainLooper()). Kotlin Coroutines với Dispatchers.Main là cách hiện đại để quay lại luồng chính.

Android cũng cung cấp StrictMode — một công cụ phát hiện các thao tác chặn Main Thread. StrictMode.setThreadPolicy() cho phép bạn đặt chính sách: cấm gọi mạng (NetworkPolicy), đọc đĩa (DiskRead), ghi đĩa (DiskWrite) trên luồng chính. Khi vi phạm chính sách, một ngoại lệ được tạo ra hoặc một thông báo được ghi vào logcat.

// Android: Làm việc với Main Thread và 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)

        // Ví dụ: Tải dữ liệu bất đồng bộ
        lifecycleScope.launch {
            val result = loadData() // đang thực thi trên Dispatchers.IO
            textView.text = result // UI trên Main Thread
        }
    }

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

// StrictMode để phát hiện vi phạm Main Thread
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        StrictMode.setThreadPolicy(
            StrictMode.ThreadPolicy.Builder()
                .detectDiskReads()
                .detectDiskWrites()
                .detectNetwork()
                .penaltyLog()
                .build()
        )
    }
}

Ví dụ Kotlin cho thấy cách sử dụng đúng Dispatchers.Main qua lifecycleScope.launch và Dispatchers.IO qua withContext. Tất cả công việc mạng được thực thi trên bộ điều phối IO, trong khi cập nhật TextView tự động xảy ra trên Main Thread, vì launch trong lifecycleScope mặc định sử dụng Dispatchers.Main. StrictMode trong Application.onCreate() chặn các cuộc gọi mạng và thao tác đĩa vô tình trên luồng chính.

Phát hiện vi phạm Main Thread

Main Thread Checker — một công cụ tích hợp trong Xcode (có sẵn từ Xcode 9) phát hiện các cuộc gọi đến UIKit, AppKit và các framework UI khác từ luồng nền. Trong quá trình gỡ lỗi, Main Thread Checker phân tích tất cả các cuộc gọi API UI và khi phát hiện vi phạm, hiển thị điểm dừng với dấu vết ngăn xếp chi tiết. Trên thiết bị thực (trong bản phát hành), Main Thread Checker không hoạt động — vi phạm biểu hiện dưới dạng sự cố hoặc hành vi không chính xác.

Trong Android, tương đương là StrictMode (được mô tả ở trên) và bộ phát hiện nhật ký tích hợp: khi gọi View.setText() hoặc View.invalidate() từ luồng nền, Android ném CalledFromWrongThreadException. Ngoài ra, Android Studio Profiler hiển thị các thao tác đang thực thi trên Main Thread. Nếu bạn thấy các thao tác mạng hoặc tệp trên Main Thread — đây là dấu hiệu rõ ràng của vấn đề.

Mẫu trực quan: Cuộn giật

Triệu chứng dễ nhận thấy nhất của chặn Main Thread là cuộn giật (janky scroll). Khi người dùng cuộn UITableView hoặc RecyclerView, hệ thống mong đợi khung tiếp theo sẵn sàng trong 16 ms. Nếu giải mã ảnh hoặc phân tích JSON đang được thực hiện trên Main Thread, kết xuất khung bị trì hoãn và người dùng thấy giật. Để chẩn đoán, sử dụng hồ sơ: nếu prepareDisplay() hoặc layoutSubviews() mất >16 ms — dữ liệu đang được xử lý trên luồng sai.

Các kịch bản chặn Main Thread điển hình

Kịch bản đầu tiên — yêu cầu mạng đồng bộ qua URLConnection hoặc Data(contentsOf:) trên Main Thread. Trong Android, StrictMode với detectNetwork() ngay lập tức bắt vi phạm này. Trong iOS, URLSession đồng bộ không đưa ra lỗi rõ ràng, nhưng UI bị treo trong suốt yêu cầu (1-10 giây). Giải pháp: sử dụng URLSession.dataTask (iOS) hoặc Retrofit/OkHttp (Android) với callback bất đồng bộ.

Kịch bản thứ hai — giải mã và nén ảnh. UIImage(data:) hoặc BitmapFactory.decodeResource() trong Android trên luồng chính là một trong những nguyên nhân phổ biến nhất của jank. Ảnh 4000x3000 pixel giải mã trong 50-150 mili giây, vượt quá giới hạn 16 ms. Giải pháp: sử dụng ImageLoader (Kingfisher, Coil, Glide), đảm bảo giải mã trong luồng nền.

Kịch bản thứ ba — phân tích JSON. Phân tích phản hồi API qua JSONSerialization (iOS) hoặc JSONObject (Android) trên Main Thread. Ngay cả JSON nhỏ 100 KB cũng được phân tích trong 5-15 mili giây, nhưng trên thiết bị chậm — lên đến 50 mili giây. Kết hợp với các thao tác khác, điều này tích lũy và dẫn đến mất khung. Giải pháp: sử dụng kotlinx.serialization/Decodable với parse() được gọi trên luồng nền, chỉ để lại gán kết quả trên Main Thread.