كلّ الوثائق
٢٨ ذو القعدة ١٤٤٧ هـ

كيف نقيس فعلًا قدرة منبّه الفجر على الإيقاظ — منهجيّة

بروتوكول قابل للتكرار لقياس ما إذا كانت تطبيقات مواقيت الصلاة توقظ المستخدم فعلًا. لماذا أكثر ميزات "المنبّه" في التطبيقات الإسلامية مجرّد إشعارات. الفرق التقني بين AlarmKit، والإشعارات الحرجة، والمنبّهات الدقيقة على أندرويد. منهجيّة + تطبيق نداء كمرجع.


كيف نقيس فعلًا قدرة منبّه الفجر على الإيقاظ

أكثر تطبيقات مواقيت الصلاة تُعلن عن “منبّه فجر”. وأكثر هذه المنبّهات إشعاراتٌ في ثوب منبّه — تفشل في إيقاظ المستخدم تقريبًا بقدر ما تنجح، خصوصًا حين يكون الهاتف صامتًا ليلًا أو في وضع “عدم الإزعاج”. هذه الصفحة توثّق:

  1. الفروق التقنية بين منبّه حقيقي وبين الآليات الأضعف التي تُسوَّق على أنّها منبّهات.
  2. بروتوكول قياسٍ قابل للتكرار لتقييم موثوقيّة الإيقاظ في العالم الواقعي.
  3. تطبيق نداء كحالةٍ مرجعية، بكوده الموثّق وسلوكه على كلّ منصّة، مفتوحًا للتدقيق.

لا تتضمّن هذه الصفحة (حتى الآن) نتائج مقارنة مع تطبيقاتٍ أخرى — يستغرق هذا الاختبار ٣٠ يومًا من القياس لكلّ جهاز. المنهجيّة جاهزة للنشر الآن، والنتائج تأتي حين يُجرى القياس.

ما هو “المنبّه” فعلًا في أنظمة الهواتف؟

لا يوجد على آيفون أو أندرويد واجهة برمجية واحدة اسمها “المنبّه”. الكلمة مصطلحٌ تسويقيّ يقابلها عدّة أنماط تنفيذٍ مختلفة، لكلٍّ منها خصائص موثوقيّةٍ مختلفة. من الأقلّ إلى الأكثر موثوقيّة:

١. الإشعار العاديّ

إشعارٌ محليّ مجدول. يُشغّل صوت الإشعار الذي حدّده المستخدم (أو لا صوت إن كان الهاتف صامتًا). يظهر بانر على شاشة القفل. يخضع لكلّ من: وضع الصمت، وعدم الإزعاج، وأوضاع التركيز، وحجم النظام.

هذا ما تُصدره أكثر التطبيقات الإسلامية تحت اسم “منبّه الفجر”. يعمل نهارًا حين يكون الهاتف يقظًا وغير صامت. ويفشل عادةً ليلًا على هاتفٍ صامت — وهو الوقت الوحيد الذي يهمّ فيه.

٢. الإشعار الحرج (آيفون) / الإشعار عالي الأولوية (أندرويد)

إشعارٌ ذو امتيازٍ يتجاوز وضع عدم الإزعاج ووضع الصمت. على آيفون يتطلّب هذا صلاحية Critical Alerts الخاصّة التي تمنحها آبل بشحّ. وعلى أندرويد يتطلّب قناة إشعارٍ عالية الأهمّية، ويعمل على أكثر نسخ المُصنّعين.

أكثر موثوقيّة من الإشعار العاديّ، لكنّه ما زال إشعارًا لا منبّهًا — لا يستحوذ على الشاشة كاملةً، ولا يتطلّب تفاعلًا لإيقافه، ويختلف سلوكه عبر المصنّعين (سامسونج، شاومي، ون بلس، هواوي، كلٌّ يخصّص طبقة الإشعارات على طريقته).

٣. الصوت في الخلفية (نمط “المنبّه الزائف”)

يُبقي التطبيق جلسةً صوتيّةً حيّة في الخلفية ويُشغّل صوت المنبّه عند وقت الإطلاق. غالبًا ما يُجمَع مع إشعار.

كان هذا النمط شائعًا قبل iOS 26 / AlarmKit لأنّ المنبّهات الحقيقية لم تكن متاحةً للتطبيقات الخارجية. وهو نمطٌ هشّ: آيفون يُعلّق جلسات الصوت في الخلفية بشدّة، وقد يقتل النظامُ عمليّةَ التطبيق، أو يقتلها المستخدم بسحبها من شريط التبديل، وكلفة البطاريّة مرتفعة إن أبقى التطبيق الصوت “ساخنًا” طوال الليل.

٤. منبّه حقيقي على مستوى النظام

النظام نفسه هو من يملك الإطلاق — لا عمليّة التطبيق. التطبيق يجدول المنبّه، والمنبّه يُطلق سواءٌ كان التطبيق يعمل أم لا. السلوك يطابق تطبيق الساعة الأصلي: صوتٌ كامل، استحواذٌ على شاشة القفل، يتطلّب إيقافًا يدويًا، يتجاوز وضع الصمت وعدم الإزعاج.

التنفيذات:

  • iOS 26 وما فوقApple AlarmKit، إطار العمل الذي قدّمته آبل في WWDC 2025 خصّيصًا لتمكين التطبيقات الخارجية من منبّهاتٍ حقيقية. هذا هو الطريق الرسميّ الوحيد إلى منبّهٍ حقيقي على آيفون. تُضيف التطبيقات NSAlarmKitUsageDescription إلى Info.plist، ثمّ تستدعي AlarmManager.requestAuthorization()؛ يمنح المستخدم الإذن مرّةً واحدة (الحالات: notDetermined | authorized | denied). وأوضاع التركيز تحتاج إلى إذنٍ لكلّ تطبيق لتجنّب تصفية المنبّه.
  • iOS الأقدم من 26 — لا توجد واجهة منبّهٍ حقيقي للتطبيقات الخارجية. التطبيقات التي تُسوّق “منبّه فجر” على تلك الإصدارات تستخدم في الخلفية إشعاراتٍ حرجة أو صوتًا في الخلفية. كلاهما أضعف من المنبّه الحقيقي.
  • أندرويد (أيّ إصدار)AlarmManager.setExactAndAllowWhileIdle() للإطلاق، إضافةً إلى خدمة foreground عند انطلاق المنبّه، قادرة على عرض شاشةٍ كاملة، وتوجيه الصوت إلى قناة المنبّه، وإعادة التسجيل عند BOOT_COMPLETED ليبقى المنبّه بعد إعادة التشغيل. الإذن مُقيّد منذ Android 12 (SCHEDULE_EXACT_ALARM)، ومنذ Android 14 صار هذا الإذن مرفوضًا افتراضيًا، فإمّا يطلب التطبيق من المستخدم منحه في الإعدادات، أو — لتطبيقات فئة “ساعة منبّه” المشروعة — يُعلن USE_EXACT_ALARM الذي تمنحه قوقل تلقائيًا. نداء يُعلن كليهما: USE_EXACT_ALARM للمسار الحديث، وSCHEDULE_EXACT_ALARM كاحتياط. وقد تتدخّل أنظمة توفير البطاريّة العدوانية لدى المصنّعين (MIUI، OneUI، EMUI)؛ تُخفّف خدمة foreground هذا الأثر على أكثر الأجهزة.

المنبّهات الحقيقية على مستوى النظام هي الآليّة الوحيدة الموثوقة بما يكفي للتوصية بها للفجر. ما عداها إشعاراتٌ احتماليّة.

لماذا لا تُصدر أكثر التطبيقات منبّهًا حقيقيًا؟

ثلاثة أسباب:

  1. AlarmKit جديد. أصدرته آبل في iOS 26. التطبيقات التي لم تُحدَّث منذ 2025 لا تزال على الإشعارات الحرجة أو ما هو أضعف.
  2. Critical Alerts تتطلّب موافقة آبل — وتُمنح لعددٍ قليل نسبيًّا من التطبيقات. التطبيقات التي تريد تجاوز عدم الإزعاج دون AlarmKit تحتاج هذه الصلاحية.
  3. تنفيذ أندرويد ليس تافهًا. المنبّه الحقيقي على أندرويد يتطلّب جدولة AlarmManager، وخدمة foreground بنوع الخدمة الصحيح، ومدير صوتٍ يتجاوز إعدادات صوت الوسائط، ونشاطًا بشاشةٍ كاملة يطلب USE_FULL_SCREEN_INTENT، وخدمة overlay احتياطية، ومستقبل BOOT_COMPLETED، ومعالجة سلوك توفير البطاريّة لدى سامسونج وشاومي وهواوي وون بلس على الأقلّ. وحدة نداء modules/expo-alarm/android/ تقارب ٣٨٠٠ سطرٍ من Kotlin/Java، فضلًا عن اختبارٍ مكثّفٍ عبر المصنّعين.

أكثر الفرق تكتفي بمسار الإشعار لأنّه عمل أيامٍ لا أشهر، وكافٍ لصلوات النهار. أمّا للفجر تحديدًا، فـ”الكافي” ليس كافيًا.

بروتوكول القياس

لتقييم موثوقيّة منبّه الفجر لأيّ تطبيق، نفّذ البروتوكول التالي. قابل للتكرار، قابل للمقارنة بين التطبيقات، يستغرق ٣٠ يومًا لكلّ جهاز.

التهيئة

  1. جهاز الاختبار. هاتفٌ حقيقي (لا محاكي). دوِّن إصدار النظام، والمصنّع، وأيّ إعداداتٍ لتوفير البطاريّة أو إدارة التطبيقات العدوانية.
  2. شروط الاختبار. الهاتف صامت (أو في عدم الإزعاج / التركيز) ليلًا، على الطاولة بجوار السرير بمسافةٍ معتادة. سواءٌ كان موصولًا بالشاحن أم لا — دوِّن الحالة.
  3. التطبيق المُختبَر. مع تفعيل منبّه الفجر، واختيار صوت المنبّه، وأيّ ميزة “تحدّي إيقاظ” إن وُجدت.
  4. العنصر الضابط. الاختبار نفسه على الجهاز نفسه مع منبّه تطبيق الساعة الأصلي في الوقت نفسه. منبّه النظام هو سقف الموثوقيّة.

القياس اليومي

لمدّة ٣٠ يومًا متتالية، سجّل:

الحقلملاحظات
التاريخ
هل انطلق منبّه التطبيق؟نعم/لا
هل رنّ المنبّه بصوتٍ كامل؟نعم / لا / جزئي
هل تطلّب إيقافًا يدويًا؟نعم/لا
هل أيقظ النائم؟نعم/لا (انطباع ذاتيّ — سجّله بصدق)
الفارق بين وقت الجدولة ووقت الإطلاق الفعليبالثواني. الانحراف فوق ١٠ ثوانٍ فشل.
هل انطلق منبّه ساعة النظام (العنصر الضابط)؟نعم/لا
هل أُجبر التطبيق على الإغلاق قبل النوم؟نعم/لا (اختبار “ماذا لو سحبه المستخدم من شريط التبديل”)
هل أُعيد تشغيل الجهاز في آخر ١٢ ساعة؟نعم/لا (اختبار إعادة التسجيل بعد الإقلاع)

التقرير

بعد ٣٠ يومًا:

  • معدّل الإيقاظ = (أيام الإيقاظ / ٣٠). قارنه بالعنصر الضابط.
  • توزّع الانحراف — مدرّجٌ تكراريٌّ لفروق الزمن بين الجدولة والإطلاق.
  • بقاء بعد الإغلاق القسري = (أيام الإطلاق بعد الإغلاق القسري / أيام الإغلاق القسري). يختبر هل ينجو المنبّه من سلوك تنظيف الهاتف المعتاد.
  • بقاء بعد إعادة التشغيل = (أيام الإطلاق بعد إعادة التشغيل / أيام إعادة التشغيل). يختبر إعادة التسجيل عند BOOT_COMPLETED.
  • سقف الصوت = نسبة الأيام التي رنّ فيها المنبّه بصوتٍ كاملٍ بغضّ النظر عن إعداد صوت الوسائط.

المنبّه الحقيقي ينبغي أن يحقّق معدّل إيقاظ أعلى من ٩٥٪، وانحرافًا أقلّ من ٥ ثوانٍ، وبقاءً بعد الإغلاق القسري أعلى من ٩٥٪، وسقف صوت ١٠٠٪ (صوت كامل دائمًا). أمّا “المنبّه” القائم على الإشعار، فيحقّق عادةً ٦٠–٨٥٪ معدّل إيقاظ بتباينٍ عالٍ.

تطبيق نداء كحالة مرجعية

نداء مفتوح المصدر. كود المنبّه على modules/expo-alarm/ في المستودع العامّ.

آيفون

  • iOS 26 وما فوق يستخدم Apple AlarmKit عبر AlarmKit.AlarmManager. الإذن عبر AlarmManager.requestAuthorization() مع NSAlarmKitUsageDescription معلَنٌ في Info.plist. المنبّهات المجدولة تستمرّ بعد إنهاء التطبيق ونوم الجهاز؛ وتُطلق سواءٌ كانت عمليّة التطبيق تعمل أم لا.
  • iOS الأقدم من 26 ميزة المنبّه مغلقة. إشعارات الصلاة (آليّةٌ منفصلة وأضعف) تبقى متاحة، لكنّ نداء لا يقدّمها كمنبّه.
  • الوحدة الأصلية في modules/expo-alarm/ios/.

أندرويد

  • الجدولة: AlarmManager.setExactAndAllowWhileIdle() مع إعلان كلٍّ من USE_EXACT_ALARM وSCHEDULE_EXACT_ALARM في AndroidManifest.xml. على Android 14 وما فوق، تُمنح USE_EXACT_ALARM تلقائيًا لتطبيقات فئة المنبّه؛ وSCHEDULE_EXACT_ALARM احتياط (مرفوضٌ افتراضيًا منذ Android 14، ويحتاج منح المستخدم في الإعدادات إن كان هو المسار الفعّال).
  • معالج الإطلاق: AlarmReceiver (BroadcastReceiver) → AlarmService (خدمة foreground بنوع mediaPlayback) → نشاط AlarmActivity بشاشة كاملة فوق شاشة القفل.
  • الصوت: AlarmAudioManager يوجّه إلى STREAM_ALARM، متجاوزًا إعدادات صوت الوسائط.
  • الاستمراريّة: مستقبل BOOT_COMPLETED يُعيد تسجيل جميع المنبّهات المجدولة بعد إعادة التشغيل.
  • احتياط Overlay: AlarmOverlayService للحالات التي لا تستطيع فيها شاشة القفل أخذ التركيز (بعض نسخ المصنّعين).
  • الوحدة الأصلية في modules/expo-alarm/android/src/main/java/expo/modules/alarm/.

في المنصّتَين

  • تحدّيات الإيقاظ ("tap" و"math"، في modules/expo-alarm/src/index.ts) تتطلّب إيقافًا ذهنيًّا فاعلًا، فتُعالج فشل “اسحب لتُغلق ثمّ عُد للنوم”.
  • أنواع المنبّهات مُنمذجة صراحةً ("fajr" | "jummah") بحيث يكون لكلٍّ منها صوته وتحدّيه وإعدادات التأجيل.
  • المصدر مفتوح. كلّ من يقيّم هذه المنهجيّة يستطيع تدقيق ما يدّعيه نداء مباشرةً.

ما الذي لا يدّعيه هذا القياس

لنبقى صادقين في النطاق:

  • لا يقيس مدى جمال صوت المنبّه.
  • لا يقيس مدى سهولة واجهة الإعدادات.
  • لا يقيّم دقّة المواقيت — مسألةٌ منفصلة تتناولها صفحة المواقيت.
  • لا يصادق على أيّ تطبيق بأنّه “الأفضل”. الموثوقيّة خاصّيةٌ قابلة للقياس؛ التفضيل الذاتيّ ليس كذلك.

لماذا يهمّ هذا؟

الجمهور الذي يهمّه الفجر هو الجمهور الذي يحاول الاستيقاظ للصلاة حين يكون أكثر الناس نائمين. ولهذا الجمهور، “هل رنّ المنبّه بصوتٍ كافٍ لإيقاظك فعلًا” هو المقياس الوحيد المهمّ. وكلّ مقياسٍ آخر بديلٌ عنه.

منهجيّة القياس أعلاه قابلةٌ للتكرار، ونرحّب بنتائج مقارنة من فرق التطبيقات الأخرى — بما فيها تطبيقاتٌ تتفوّق على موثوقيّة نداء. الهدف ليس الفوز بالقياس؛ بل جعل البُعد قابلًا للقياس ليختار المستخدمون عن وعي.

شارك بالنتائج

إن نفّذت هذا البروتوكول على أيّ تطبيقٍ ومواقيتٍ ورغبت في نشر النتائج، افتح issue على https://github.com/NedaaDevs/nedaa/issues بعنوان [alarm benchmark] <اسم التطبيق> v<النسخة> on <الجهاز> مع أرقامك لمدّة ٣٠ يومًا بالصياغة أعلاه.

سننشر النتائج — بما فيها نتائج نداء التي تكشف مشكلاتٍ علينا إصلاحها.


آخر تحديث: ٢٠٢٦-٠٥-١٥. المنهجيّة مستقرّة؛ والنتائج تأتي حين يُجرى القياس.