Broadcast Receiver: ما هو، أنواع البث ومبدأ العمل

ما هو Broadcast Receiver؟

Broadcast Receiver هو مكون Android مصمم لاستقبال ومعالجة رسائل Intent الموزعة من قبل نظام التشغيل أو التطبيقات الأخرى. على عكس Activity و Service، ليس لدى Broadcast Receiver واجهة مستخدم — مهمته تنفيذ إجراء قصير عند حدوث حدث.

يعمل Broadcast Receiver من خلال آلية Intent. يرسل النظام أو التطبيق Intent عبر sendBroadcast أو sendOrderedBroadcast، ويقوم نظام التشغيل بتسليمه إلى المستقبلات المسجلة. يستقبل كل مستقبل Intent في طريقة onReceive، التي يتم تنفيذها في الخيط الرئيسي.

وفقاً لـ Android Compatibility Definition Document، يجب على Broadcast Receiver إكمال onReceive في غضون 10 ثوانٍ — وإلا يعتبره النظام معلقاً وينهي العملية. للمهام الخلفية الطويلة، استخدم JobScheduler أو WorkManager المُشغل من المستقبل.

أنواع البث في Android

يدعم Android نوعين رئيسيين من البث: Normal Broadcast و Ordered Broadcast. الفرق يكمن في ترتيب التسليم والقدرة على مقاطعة سلسلة المعالجة. بالإضافة إلى ذلك، ينقسم البث إلى نظامي (يُولد بواسطة نظام التشغيل) ومخصص (يُُنشأ بواسطة التطبيق).

Normal Broadcast

يتم تسليم Normal Broadcast لجميع المستقبلات المسجلة بشكل غير متزامن بدون ترتيب مضمون. قد يقوم النظام بمعالجة هذه البث بالتوازي — كل مستقبل يحصل على Intent في خيطه الخاص. استدعاء abortBroadcast في Normal Broadcast ليس له تأثير: لا يمكن إلغاء التسليم للمستقبلات الأخرى.

Ordered Broadcast

يتم تسليم Ordered Broadcast بالتسلسل — لكل مستقبل بترتيب تنازلي للسمة android:priority (من 0 إلى 999). بعد المعالجة، يمكن للمستقبل تمرير النتيجة إلى التالي عبر setResultExtras أو مقاطعة السلسلة باستدعاء abortBroadcast. يُستخدم هذا في السيناريوهات حيث يهم ترتيب المعالجة — على سبيل المثال، مستقبلات SMS.

بث النظام

يولد Android العديد من بث النظام: ACTION_BOOT_COMPLETED (تشغيل الجهاز)، ACTION_BATTERY_LOW، ACTION_POWER_CONNECTED، CONNECTIVITY_ACTION، ACTION_PACKAGE_ADDED وغيرها. يحتوي كل Intent على بيانات إضافية في Extras — مستوى البطارية، نوع الاتصال، اسم الحزمة.

Sticky Broadcast هو نوع مهمل كان يحتفظ بآخر قيمة مرسلة. بدلاً من ذلك، استخدم LiveData أو StateFlow أو SharedPreferences مشتركة لتخزين الحالة الأخيرة.

تسجيل Broadcast Receiver

يمكن تسجيل Broadcast Receiver بطريقتين: ثابتاً عبر AndroidManifest.xml أو ديناميكياً في الكود عبر registerReceiver. يعتمد الاختيار على السيناريو: التسجيل الثابت يعمل حتى عندما لا يكون التطبيق قيد التشغيل، التسجيل الديناميكي يعمل فقط طالما أن المكون المسجل نشط.

التسجيل الثابت

يُعلن التسجيل الثابت في البيان باستخدام الوسم <receiver> داخل <application>. لكل مستقبل، يتم تحديد فئة المعالج ومرشح Intent مع الإجراءات التي يجب اعتراضها. يقوم النظام بتحميل هذه المستقبلات عند حدوث بث حتى لو كان التطبيق غير قيد التشغيل.

<!-- Static Broadcast Receiver registration in manifest -->
<receiver android:name=".BootReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

التسجيل الديناميكي

يتم التسجيل الديناميكي باستخدام طريقة registerReceiver في كود Activity أو Service أو Fragment. يعيش المستقبل فقط طالما أن المكون الذي سجله نشط. اتصل دائماً بـ unregisterReceiver في onPause أو onDestroy — وإلا يحدث تسرب للذاكرة وقد ينهي النظام العملية.

الأولوية وترتيب المعالجة

بالنسبة لـ Ordered Broadcast، يتم تحديد ترتيب التسليم بواسطة السمة android:priority. المستقبل ذو الأولوية الأعلى يحصل على Intent أولاً. إذا استدعى abortBroadcast بعد المعالجة، فإن المستقبلات ذات الأولوية الأقل لن تستقبل Intent. للمستقبلات الثابتة، يتم تعيين الأولوية في مرشح Intent في البيان.

نقل البيانات بين المستقبلات

يمكن للمستقبلات في Ordered Broadcast تمرير البيانات إلى التالي في السلسلة عبر setResultExtras أو setResultData. هذا يسمح بمعالجة خط أنابيب: المستقبل الأول يثري Intent ببيانات إضافية، الثاني يستخدمها، الثالث يكمل السلسلة. طريقة getResultExtras تقرأ البيانات التي مررها المستقبل السابق.

بالنسبة لـ Normal Broadcast، الترتيب غير مضمون، لذلك جميع المستقبلات تحصل على Intent الأصلي دون تغيير. إذا كنت بحاجة إلى تأثير المستقبلات على بعضها البعض، استخدم sendOrderedBroadcast بدلاً من sendBroadcast.

القيود في Android 8 والإصدارات الأحدث

قدم Android 8 (API 26, Oreo) قيوداً كبيرة على البث في الخلفية. معظم البث الضمني — تلك غير الموجهة لتطبيق معين — لم تعد تعمل مع التسجيل الثابت. يقوم النظام بحظر المستقبلات المسجلة في البيان لإجراءات مثل CONNECTIVITY_ACTION أو ACTION_BATTERY_LOW.

ما الذي تغير

حدد Google قائمة من البث التي لا تزال تعمل مع التسجيل الثابت: BOOT_COMPLETED و TIME_TICK و Alarm وتغييرات الحزمة — حوالي عشر استثناءات إجمالاً. جميع البث الضمني الأخرى تتطلب الآن تسجيلاً ديناميكياً عبر Context.registerReceiver، الذي يعمل فقط عندما يكون التطبيق في المقدمة.

بدائل Broadcast Receiver

للمهام الخلفية التي كانت تُعالج سابقاً عبر Broadcast Receiver، يوصي Android بـ WorkManager (مهام مؤجلة مع ضمان التنفيذ)، JobScheduler (مهام دورية مع مراعاة حالة الجهاز) و NotificationListenerService (مراقبة الإشعارات). تعمل هذه المكونات بدون قيود Android 8 ومحسنة لاستهلاك الطاقة.

مثال Broadcast Receiver في Kotlin

لنقم بإنشاء Broadcast Receiver لتتبع اتصال الشبكة. سيلتقط المستقبل بث CONNECTIVITY_ACTION ويسجل نوع الاتصال. بالنسبة لـ Android 8+، سنقوم بتسجيله ديناميكياً لأنه بث ضمني مستبعد من التسجيل الثابت.

// Broadcast Receiver لتتبع حالة الشبكة
class NetworkReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
        val network = cm.activeNetwork
        val caps = cm.getNetworkCapabilities(network)

        val connectionType = when {
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) == true -> "WiFi"
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) == true -> "Cellular"
            else -> "Disconnected"
        }

        Log.d("NetworkReceiver", "نوع الاتصال: $connectionType")
    }
}

// التسجيل الديناميكي في Activity
class MainActivity : AppCompatActivity() {

    private val networkReceiver = NetworkReceiver()

    override fun onStart() {
        super.onStart()
        val filter = IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION)
        registerReceiver(networkReceiver, filter)
    }

    override fun onStop() {
        super.onStop()
        unregisterReceiver(networkReceiver)
    }
}

قم دائماً بإلغاء تسجيل المستقبل في onStop — إذا انتقلت Activity إلى الخلفية ولكن بقي المستقبل مسجلاً، لا يمكن للنظام تحرير الموارد. بالنسبة لـ Service، استخدم onDestroy. في الأجزاء (fragments)، سجل المستقبل في onStart وألغِ التسجيل في onStop، متبعاً دورة حياة الجزء.