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 را پیاده‌سازی می‌کند: نخ به طور نامحدود منتظر رویدادهای جدید (لمس، اعلان‌های سیستم، تایمرها) می‌ماند و آنها را به ترتیب صف پردازش می‌کند. در حین پردازش یک رویداد، رویداد بعدی در صف منتظر می‌ماند. اگر پردازش بیش از ۱۰۰-۲۰۰ میلی‌ثانیه طول بکشد، کاربر تأخیر (jank) را متوجه می‌شود. اگر بیش از ۵ ثانیه (Android) — سیستم دیالوگ ANR (Application Not Responding) را نشان می‌دهد و پیشنهاد بستن برنامه را می‌دهد.

اهمیت درک Main Thread دشوار است: این منبع ۹۰٪ مشکلات عملکرد در برنامه‌های موبایل است. توسعه‌دهندگان اغلب فراموش می‌کنند عملیات سنگین (شبکه، فایل‌ها، تجزیه JSON، فشرده‌سازی تصاویر) را به نخ‌های پس‌زمینه منتقل کنند. حتی عملیاتی که روی شبیه‌ساز در ۱۰ میلی‌ثانیه اجرا می‌شود، روی دستگاه واقعی با دیسک کند ممکن است ۵۰۰ میلی‌ثانیه طول بکشد و منجر به لگ قابل توجهی شود.

چرا UI فقط در Main Thread باید به‌روزرسانی شود

Thread-unsafe فریم‌ورک‌های UI — تصمیم معماری گرفته شده در اولین نسخه‌های UIKit (۲۰۰۷) و Android (۲۰۰۸). دلیل اصلی عملکرد است: همگام‌سازی دسترسی به کامپوننت‌های UI از طریق قفل‌ها (locks) سربار اضافی به هر عملیات رندر اضافه می‌کرد. در عوض، فریم‌ورک‌ها نیاز دارند که تمام تغییرات UI به طور دقیق روی یک نخ انجام شود، وضعیت مسابقه (race condition) را بدون overhead حذف می‌کند.

تصور کنید دو نخ پس‌زمینه به طور همزمان textView.setText() را فراخوانی می‌کنند. اگر UI thread-safe بود، هر دو فراخوانی از طریق mutex همگام‌سازی می‌شدند که رندر را ۲۰-۴۰٪ کند می‌کرد. در معماری فعلی، هر فراخوانی UI از نخ پس‌زمینه یا نادیده گرفته می‌شود یا باعث crash می‌شود (در 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 روی نخ پس‌زمینه اجرا می‌شوند، پس از آن نتیجه برای به‌روزرسانی UIImageView به DispatchQueue.main بازگردانده می‌شود. بدون DispatchQueue.main.async برنامه با NSInternalInconsistencyException هنگام فراخوانی UIKit از نخ پس‌زمینه crash می‌کند.

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 را پردازش می‌کند. هر فریم رندر (۶۰/۱۲۰ FPS) نیاز به تکمیل تمام عملیات در RunLoop قبل از پالس همگام‌سازی عمودی (VSync) دارد. اگر عملیات در Main Thread بیش از ۱۶.۶ میلی‌ثانیه (۶۰ FPS) یا ۸.۳ میلی‌ثانیه (۱۲۰ FPS) طول بکشد، برنامه فریم‌ها را از دست می‌دهد که از نظر بصری به صورت jank یا stutter ظاهر می‌شود.

Main Thread در Android: Looper و Handler

Looper.getMainLooper() — مکانیسم اصلی Android برای کار با نخ اصلی است. هر Main Thread در Android یک Looper دارد که به طور نامحدود پیام‌ها را از صف (MessageQueue) استخراج کرده و برای پردازش به Handler ارسال می‌کند. Activity.runOnUiThread() و View.post() — اینها wrapperهای سطح بالای 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-dispatcher اجرا می‌شود و به‌روزرسانی 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 با stack trace دقیق نشان می‌دهد. در دستگاه‌های واقعی (در نسخه release) Main Thread Checker کار نمی‌کند — نقض‌ها به صورت crash یا رفتار نادرست ظاهر می‌شوند.

در Android معادل آن StrictMode است (در بالا توضیح داده شده) و آشکارساز لاگ داخلی: هنگام فراخوانی View.setText() یا View.invalidate() از نخ پس‌زمینه، Android CalledFromWrongThreadException را پرتاب می‌کند. علاوه بر این، Android Studio Profiler نشان می‌دهد که کدام عملیات در Main Thread اجرا می‌شوند. اگر عملیات شبکه یا فایل را در Main Thread می‌بینید — این نشانه قطعی مشکل است.

الگوی بصری: اسکرول ناپیوسته

قابل‌توجه‌ترین علامت مسدود شدن Main Thread — janky scroll (اسکرول ناپیوسته). هنگامی که کاربر UITableView یا RecyclerView را اسکرول می‌کند، سیستم انتظار دارد که فریم بعدی در ۱۶ میلی‌ثانیه آماده شود. اگر در Main Thread رمزگشایی تصویر یا تجزیه JSON اجرا شود، رندر فریم به تأخیر می‌افتد و کاربر تکان‌ها را می‌بیند. برای تشخیص از پروفایلر استفاده کنید: اگر متد prepareDisplay() یا layoutSubviews() >۱۶ میلی‌ثانیه طول بکشد — داده‌ها در نخ اشتباه پردازش می‌شوند.

سناریوهای معمول مسدود کردن Main Thread

سناریوی اول — درخواست شبکه همگام از طریق URLConnection یا Data(contentsOf:) در Main Thread. در Android StrictMode با detectNetwork() بلافاصله این نقض را می‌گیرد. در iOS URLSession همگام خطای واضحی نمی‌دهد، اما UI به مدت درخواست (۱-۱۰ ثانیه) قفل می‌شود. راه‌حل: از URLSession.dataTask (iOS) یا Retrofit/OkHttp (Android) با callback ناهمگام استفاده کنید.

سناریوی دوم — رمزگشایی و فشرده‌سازی تصاویر. UIImage(data:) یا BitmapFactory.decodeResource() در Android در نخ اصلی — یکی از شایع‌ترین علل jank. تصویر ۴۰۰۰×۳۰۰۰ پیکسل ۵۰-۱۵۰ میلی‌ثانیه رمزگشایی می‌شود که از حد ۱۶ میلی‌ثانیه فراتر می‌رود. راه‌حل: از ImageLoader (Kingfisher, Coil, Glide) استفاده کنید که رمزگشایی را در نخ پس‌زمینه تضمین می‌کنند.

سناریوی سوم — تجزیه JSON. تجزیه پاسخ API از طریق JSONSerialization (iOS) یا JSONObject (Android) در Main Thread. حتی یک JSON کوچک ۱۰۰ کیلوبایتی ۵-۱۵ میلی‌ثانیه تجزیه می‌شود، اما در دستگاه‌های کند — تا ۵۰ میلی‌ثانیه. در ترکیب با عملیات دیگر این جمع می‌شود و به فریم‌های از دست رفته منجر می‌شود. راه‌حل: از kotlinx.serialization/Decodable با فراخوانی parse() در نخ پس‌زمینه استفاده کنید و فقط تخصیص نتیجه را در Main Thread بگذارید.