Background Thread في تطوير التطبيقات المحمولة: ما هو، المهام وطرق الاستخدام

ما هو Background Thread

Background Thread — أي خيط في التطبيق ليس Main Thread وليس لديه حق الوصول إلى UI. مهمته هي تحرير الخيط الرئيسي من العمليات الثقيلة للحفاظ على استجابة الواجهة. يقوم نظام التشغيل بتوزيع خيوط الخلفية على أنوية المعالج، مما يسمح بتنفيذ مهام متعددة بالتوازي. يدير iOS مجموعة الخيوط تلقائيًا عبر GCD، ويديرها Android عبر مجموعات Java Executors.

على عكس Main Thread الذي يعالج الأحداث بالتسلسل (واحدًا تلو الآخر)، يمكن لخيوط الخلفية التنفيذ بالتوازي، محدودة فقط بعدد أنوية المعالج. على سبيل المثال، على جهاز بثمانية أنوية يمكن تشغيل ما يصل إلى 8 مهام خلفية متوازية دون تباطؤ كبير. ومع ذلك، يؤدي العدد المفرط من الخيوط (المئات) إلى thread starvation — التنافس على الأنوية وزيادة الحمل الناتج عن تبديل السياق (context switch).

Quality of Service (QoS) — آلية في iOS تسمح بتحديد أولوية المهمة الخلفية. القيم: .userInteractive (الأعلى، قريب من Main Thread)، .userInitiated (المستخدم ينتظر النتيجة)، .default (قياسي)، .utility (المستخدم لا ينتظر مباشرة)، .background (الأدنى، للمزامنة والفهرسة). في Android، المعادل هو Thread.setPriority() من 1 إلى 10، لكن Android يستخدم أيضًا cgroups للإدارة الجماعية لأولويات الخيوط.

Background Thread في iOS: GCD و DispatchQueue.global

DispatchQueue.global(qos:) — الطريقة الرئيسية للحصول على قائمة انتظار خلفية في iOS. يقوم GCD (Grand Central Dispatch) بإنشاء مجموعة خيوط تلقائيًا وتوزيع المهام على الأنوية. الاستدعاء DispatchQueue.global(qos: .background).async {} يرسل كتلة إلى قائمة الانتظار الخلفية بأقل أولوية. للمهام التي تحتاج نتيجتها فورًا، استخدم .userInitiated أو .utility.

OperationQueue — تجريد عالي المستوى فوق GCD يسمح بتعيين التبعيات بين العمليات، والحد الأقصى لعدد العمليات المتزامنة (maxConcurrentOperationCount)، والأولويات. OperationQueue مفيدة للسلاسل المعقدة متعددة المهام: تنزيل ملف → فك ضغط → حفظ في ذاكرة التخزين المؤقت. افتراضيًا، تستخدم OperationQueue خيوط الخلفية ما لم يُذكر خلاف ذلك.

import UIKit

class ImageDownloader {

    func downloadImagesSequentially() {
        let urls = ["https://example.com/1.png", "https://example.com/2.png"]

        // OperationQueue مع maxConcurrentOperationCount = 2
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 2
        queue.qualityOfService = .utility

        for urlString in urls {
            queue.addOperation {
                guard let url = URL(string: urlString),
                      let data = try? Data(contentsOf: url)
                else { return }

                DispatchQueue.main.async {
                    print("تم التحميل: \(url.lastPathComponent)")
                }
            }
        }
    }

    // GCD: قائمة انتظار خلفية عامة مع QoS مختلفة
    func backgroundTaskWithQoS() {
        DispatchQueue.global(qos: .userInitiated).async {
            // أولوية عالية — المستخدم ينتظر النتيجة
            let result = self.heavyComputation()
            DispatchQueue.main.async {
                self.showResult(result)
            }
        }
    }

    private func heavyComputation() -> String {
        Thread.sleep(forTimeInterval: 2) // محاكاة العمل
        return "نتيجة الحسابات"
    }

    private func showResult(_ result: String) {
        print("Result on Main: \(result)")
    }
}

في المثال، يقوم OperationQueue بتحميل صورتين بالتوازي (maxConcurrentOperationCount = 2) مع QoS خلفية عبر qualityOfService = .utility. تستخدم طريقة GCD backgroundTaskWithQoS قائمة انتظار عامة مع .userInitiated لمهمة ينتظر المستخدم نتيجتها. ينتهي كلا الأسلوبين بالعودة إلى DispatchQueue.main لتحديث UI — وهذا مطلب إلزامي في iOS.

قوائم الانتظار الخلفية Serial vs Concurrent

يدعم GCD نوعين من قوائم الانتظار: serial (تسلسلية) و concurrent (متزامنة). تنفذ قوائم الانتظار التسلسلية المهام واحدة تلو الأخرى — وهذا مناسب للوصول إلى مورد مشترك (ملف، قاعدة بيانات) دون أقفال. تنفذ قوائم الانتظار المتزامنة المهام بالتوازي، موزعة على الأنوية المتاحة. DispatchQueue.global دائمًا متزامنة. لإنشاء قائمة انتظار تسلسلية، استخدم DispatchQueue(label: "com.app.queue").

Background Thread في Android: Executors و Dispatchers

Android يوفر عدة مستويات من التجريد لخيوط الخلفية. النهج الكلاسيكي هو java.util.concurrent.Executors.newFixedThreadPool(n) أو Executors.newCachedThreadPool(). النهج الحديث هو Kotlin Coroutines مع Dispatchers.IO (للإدخال/الإخراج: الشبكة، الملفات، قاعدة البيانات) و Dispatchers.Default (للمهام المكثفة للمعالج: الفرز، معالجة الصور). WorkManager للمهام الخلفية المؤجلة والمضمونة.

HandlerThread — فئة متخصصة في Android لإنشاء خيط خلفي مع Looper خاص به (قائمة انتظار الرسائل). على عكس Executors، يسمح HandlerThread بإرسال الرسائل و Runnables عبر Handler. يُستخدم للعمليات التي تتطلب وضعًا في قائمة الانتظار (مثل الكتابة التسلسلية في قاعدة البيانات). بعد الاستخدام، يجب استدعاء quit() أو quitSafely() لتحرير الموارد.

// Android: Executors و Coroutines Dispatchers
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.util.concurrent.Executors

class DataRepository {

    private val ioExecutor = Executors.newFixedThreadPool(4)

    // النهج الكلاسيكي عبر Executors
    fun loadDataLegacy(callback: (String) -> Unit) {
        ioExecutor.execute {
            val result = readFromFile()
            val handler = android.os.Handler(android.os.Looper.getMainLooper())
            handler.post { callback(result) }
        }
    }

    // النهج الحديث عبر Coroutines
    suspend fun loadDataCoroutines(): String {
        return withContext(Dispatchers.IO) {
            // عملية ملف — تُنفذ في مجمع خلفي
            readFromFile()
        }
        // النتيجة تعود تلقائيًا إلى Dispatchers.Main
    }

    // مهمة مكثفة للمعالج على Dispatchers.Default
    suspend fun processImage(pixels: IntArray): IntArray {
        return withContext(Dispatchers.Default) {
            // الفرز، التصفية — تُنفذ على مجمع Default
            pixels.sortedArray()
        }
    }

    private fun readFromFile(): String {
        Thread.sleep(1000) // محاكاة قراءة من ملف
        return "file_content"
    }

    fun cleanup() {
        ioExecutor.shutdown()
    }
}

مثال DataRepository يوضح تطور خيوط الخلفية في Android. الطريقة القديمة loadDataLegacy تستخدم Executors.newFixedThreadPool(4) مع Handler للعودة إلى Main Thread. الطريقة الحديثة loadDataCoroutines تستخدم withContext(Dispatchers.IO) — يتم تعليق coroutine أثناء التنفيذ دون حظر الخيط، وتستأنف تلقائيًا على Main Thread. يُوصى باستخدام Dispatchers.Default للعمليات المكثفة للمعالج (الفرز، التصفية، تحويل البيانات).

Coroutines كمعيار حديث للمهام الخلفية

Kotlin Coroutines — ليست مجرد طريقة للعمل مع الخيوط، بل نموذج مختلف جوهريًا: المهام غير المتزامنة غير مرتبطة بخيط معين ويمكن تعليقها دون حظر. هذا يعني أنه في الخلفية، لا يشغل coroutine خيطًا بل يحرره للمهام الأخرى. تسمح آلية التعليق بتنفيذ مئات الآلاف من المهام المتزامنة على مجموعة من 4–8 خيوط دون thread starvation.

ثلاثة موزعين رئيسيين: Dispatchers.Main (UI، خيط واحد)، Dispatchers.IO (64 خيطًا افتراضيًا للعمليات المحظورة: الشبكة، الملفات، قاعدة البيانات)، Dispatchers.Default (يساوي عدد أنوية المعالج، للحسابات المكثفة). من خلال دمجها عبر withContext، يبدل المطور بين الخيوط دون إنشاء callbacks. withContext هي دالة suspend لا تعود بالتحكم حتى اكتمال المهمة.

// Coroutines: تركيب المهام الخلفية
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay

suspend fun loadUserProfile(userId: String): UserProfile =
    coroutineScope {
        // تحميل متوازي للبيانات من مصادر مختلفة
        val user = async(Dispatchers.IO) { fetchUser(userId) }
        val posts = async(Dispatchers.IO) { fetchPosts(userId) }
        val avatar = async(Dispatchers.Default) {
            processAvatar(fetchAvatar(userId))
        }

        // await() — يتعلق حتى اكتمال جميع المهام
        UserProfile(
            user = user.await(),
            posts = posts.await(),
            avatar = avatar.await()
        )
    }

data class UserProfile(
    val user: String,
    val posts: List<String>,
    val avatar: ByteArray
)

suspend fun fetchUser(id: String): String { delay(300); return "User:$id" }
suspend fun fetchPosts(id: String): List<String> { delay(500); return listOf("Post1") }
suspend fun fetchAvatar(id: String): ByteArray { delay(200); return ByteArray(1024) }
suspend fun processAvatar(data: ByteArray): ByteArray { delay(100); return data }

الدالة loadUserProfile تطلق ثلاث مهام خلفية متوازية عبر async. fetchUser و fetchPosts هي مهام IO (شبكة)، تُنفذ على Dispatchers.IO. processAvatar هي مهمة مكثفة للمعالج (معالجة صور)، تُنفذ على Dispatchers.Default. await() تعلق coroutine حتى اكتمال جميع المهام. إجمالي وقت التنفيذ يساوي أقصى وقت بين المهام الثلاث (500 مللي ثانية لـ fetchPosts)، وليس مجموعها. هذه ميزة رئيسية لـ coroutines على التنفيذ التسلسلي.

التزامن المنظم: منع التسريبات

Structured concurrency — مبدأ حيث يكون لكل coroutine نطاق أبوي، وإلغاء الأب يلغي تلقائيًا coroutines الفرعية. في Android، lifecycleScope يلغي جميع coroutines عند تدمير Activity. viewModelScope يفعل ذلك عند تنظيف ViewModel. هذا يمنع تسرب المهام الخلفية: إذا أغلق المستخدم الشاشة، في الخلفية لن يستمر coroutine في تحميل بيانات لم تعد مطلوبة.

// WorkManager مع coroutines
import android.content.Context
import androidx.work.*
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

class SyncWorker(
    appContext: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(appContext, workerParams) {

    override suspend fun doWork(): Result {
        // يُتنفذ على Dispatchers.Default (افتراضيًا)
        return withContext(Dispatchers.IO) {
            try {
                syncDataToServer()
                Result.success()
            } catch (e: Exception) {
                if (runAttemptCount < 3) Result.retry() else Result.failure()
            }
        }
    }

    private suspend fun syncDataToServer() {
        // محاكاة المزامنة
        delay(1000)
    }
}

// إطلاق مهمة WorkManager مع قيود
fun scheduleSync(context: Context) {
    val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .setRequiresBatteryNotLow(true)
        .build()

    val syncWork = OneTimeWorkRequestBuilder<SyncWorker>()
        .setConstraints(constraints)
        .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, java.util.concurrent.TimeUnit.SECONDS)
        .build()

    WorkManager.getInstance(context).enqueue(syncWork)
}