App Standby — ما هو، مستويات الانتظار ومبدأ العمل

ما هو App Standby

App Standby هو مكون من نظام إدارة الطاقة في Android، تم إدخاله في Android 6.0 (API 23) وتم إعادة صياغته بشكل كبير في Android 9 (API 28). مهمته هي تحديد التطبيقات التي يستخدمها المستخدم نادرًا وتقييد نشاطها الخلفي: طلبات الشبكة، المزامنة، JobScheduler و AlarmManager. بالخلاف من Doze، لا يعتمد App Standby على حالة الشاشة أو حركة الجهاز.

يصنف النظام التطبيقات إلى أربعة buckets (مستويات): Active، Working Set، Frequent و Rare. كل مستوى يحدد مدى تقييد النشاط الخلفي. تحدث الانتقالات بين المستويات تلقائيًا بناءً على أنماط استخدام التطبيق: مدى تكرار فتح المستخدم له، تلقي الإشعارات، التفاعل مع الويجتات.

يعمل App Standby بالتزامن مع Doze Mode ولكنه لا يحل محله. بينما يحد Doze من النشاط الخلفي لجميع التطبيقات عند خمول الجهاز، فإن App Standby يقيد تطبيقات محددة بغض النظر عن حالة الجهاز. ستواجه التطبيقات في مستوى Rare قيودًا حتى عندما يكون الهاتف قيد الاستخدام النشط، إذا لم يقم المستخدم بفتحه لعدة أيام.

Buckets في Android 9+

بدءًا من Android 9 (API 28)، قدمت Google App Standby Buckets — تصنيفًا رسميًا بقيم رقمية. يستخدم النظام التعلم الآلي للتنبؤ بالمرة التالية لتشغيل التطبيق. إذا تنبأ النموذج بأن التطبيق سيفتح خلال الساعات القليلة القادمة، يحصل على bucket Active. إذا كان التنبؤ يشير إلى استخدام نادر — يتم تعيينه كـ Rare.

كيف يعمل App Standby

App Standby يحلل عدة عوامل لتحديد bucket: الوقت منذ آخر مرة فتح فيها المستخدم التطبيق، تكرار التفاعل (عدد المرات التي يتم فيها التشغيل يوميًا/أسبوعيًا)، تلقي إشعارات FCM، وجود ويجتات نشطة على الشاشة الرئيسية، والاشتراك في AlarmManager. كلما طال الوقت دون استخدام التطبيق، كلما كان bucket أقل والقيود أكثر صرامة.

خدمة النظام UsageStatsManager تجمع إحصائيات استخدام التطبيقات وتنقلها إلى StandbyController — مكون في الإطار يقوم بحساب bucket لكل تطبيق. يأخذ StandbyController أيضًا في الاعتبار أحداث النظام: بعد تحديث التطبيق، يتم إعادة تعيين bucket خاصته إلى Active لبضعة أيام ليتمكن المستخدم من تقييم الميزات الجديدة.

ميزة مهمة: App Standby لا يقتل عملية التطبيق، ولكنه يحد قدراته الخلفية. يستمر التطبيق في العمل إذا كان المستخدم يتفاعل معه (bucket Active). بمجرد أن يصغر المستخدم التطبيق ولا يعود إليه، يبدأ النظام في حساب وقت الخمول وقد يخفض bucket إلى Working Set أو Frequent.

تأثير FCM على bucket

يمكن لاستلام رسالة FCM عالية الأولوية رفع bucket التطبيق مؤقتًا إلى Active. يمنح ذلك التطبيق فرصة لأداء مهمة (معالجة الرسالة، مزامنة البيانات) دون قيود. ولكن بعد اكتمال المعالجة، يعود bucket إلى قيمته الأصلية. توصي Google باستخدام هذه الآلية لتوصيل الإشعارات المهمة، وليس لإبقاء التطبيق على قيد الحياة.

مستويات App Standby

App Standby يستخدم أربعة مستويات (buckets) لتصنيف التطبيقات. كل مستوى يحدد وقت التأخير للمهام الخلفية: كلما كان المستوى أقل، طال التأخير. يقوم النظام بتحريك التطبيق تلقائيًا بين المستويات بناءً على إحصائيات الاستخدام المجمعة خلال الأيام 7–14 الأخيرة.

Active — التطبيق النشط

Active — تطبيق تفاعل معه المستخدم مؤخرًا (قام بتشغيله، تلقى إشعارًا أو استخدم ويجتَ). في هذا bucket لا توجد قيود: يتم تشغيل JobScheduler فورًا، الشبكة متاحة، ويعمل AlarmManager بدقة. يبقى التطبيق في Active حتى يتوقف المستخدم عن التفاعل معه لعدة ساعات.

Working Set و Frequent

Working Set — يستخدم التطبيق بانتظام (عدة مرات في الأسبوع). تأخير المهام الخلفية حتى ساعتين. Frequent — يستخدم التطبيق عدة مرات في الشهر. تأخير حتى 4 ساعات. في كلا المستويين، الشبكة متاحة فقط في نوافذ الصيانة، وقد يتأخر AlarmManager. يقوم JobScheduler بتنفيذ المهام في أقرب نافذة.

Rare — نادر الاستخدام

Rare — أشد المستويات صرامة، يتم تعيينه للتطبيقات التي لم يفتحها المستخدم لأكثر من 30 يومًا. يصل تأخير المهام الخلفية إلى 24 ساعة. الشبكة محجوبة بالكامل خارج نوافذ الصيانة، ويعمل AlarmManager فقط بعلامات setAndAllowWhileIdle() بحد مرة واحدة كل 9 دقائق. تظل إشعارات FCM عالية الأولوية تصل ولكنها لا تستطيع رفع bucket.

القيود في App Standby

App Standby يفرض قيودًا على عدة فئات من العمليات الخلفية. بالخلاف من Doze، تنطبق قيود App Standby بغض النظر عن حالة الشاشة وحالة الشحن. يجب على المطور تصميم التطبيق مع مراعاة هذه القيود، خاصة إذا كان الجمهور المستهدف يستخدم التطبيق بشكل غير منتظم.

JobScheduler و WorkManager

JobScheduler — واجهة البرمجة الرئيسية المتأثرة بـ App Standby. اعتمادًا على bucket، يتراوح تأخير تنفيذ المهمة من 2 إلى 24 ساعة. WorkManager، الذي يستخدم JobScheduler داخليًا (على API 23+)، يتعرض أيضًا لهذه التأخيرات. للمهام الحساسة للوقت، استخدم Expedited Work، الذي يبدأ Foreground Service داخليًا ولا يتأثر بالbucket.

قيود الشبكة

لا يمكن للتطبيقات في buckets Working Set، Frequent و Rare إجراء طلبات شبكة عشوائية في أي وقت. يسمح النظام بالوصول إلى الشبكة فقط خلال نوافذ الصيانة، التي تتم مزامنتها مع Doze. لإرسال بيانات حرجة، استخدم FCM عالي الأولوية مع مزامنة لاحقة في نافذة الصيانة.

AlarmManager

AlarmManager في App Standby يتبع نفس القواعد المتبعة في Doze: المنبهات الدقيقة (setExact()) تتأخر، و setAndAllowWhileIdle() محدود بمرة واحدة كل 9 دقائق. لبكيت Rare، يمكن أن يصل التأخير إلى 24 ساعة، مما يجعل AlarmManager غير مناسب للجدولة الدقيقة للمهام في التطبيقات نادرة الاستخدام.

• JobScheduler — تتأخر المهام لمدة 2–24 ساعة حسب bucket
• الشبكة — الوصول فقط في نوافذ الصيانة لـ Working Set وأدنى
• AlarmManager — تتأخر المنبهات الدقيقة؛ setAndAllowWhileIdle — 1/9 دقيقة
• SyncManager — تتأخر مزامنة الحسابات حتى نافذة الصيانة
• تحديثات الويجتات — قد تنخفض تواتر تحديث الويجتات

كيفية الحصول على استثناء

يمكن الحصول على استثناء من App Standby بطريقتين: من خلال إعدادات البطارية للمستخدم (القائمة البيضاء اليدوية) أو من خلال Intent النظام ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. ولكن Google تنظم بصرامة الوصول إلى الاستثناءات — التطبيقات دون سبب صالح تخاطر الرفض على Google Play.

يمكن للمستخدم تعطيل القيود يدويًا لتطبيق محدد من خلال الإعدادات → التطبيقات → [التطبيق] → البطارية → التحسين → لا تحسين. يقوم ذلك بإزالة قيود App Standby و Doze بالكامل للتطبيق المحدد. يمكن للمطور عرض التعليمات أو حوار النظام على المستخدم، ولكنه لا يستطيع إضافة تطبيق بالإجبار إلى الاستثناءات.

Foreground Service مع إشعار يحصل تلقائيًا على استثناء مؤقت من App Standby. أثناء تشغيل الخدمة وعرض إشعار، يتم نقل التطبيق إلى bucket Active بغض النظر عن مستواه الحقيقي. بعد إيقاف الخدمة، يعود bucket إلى قيمته الأصلية. هذه هي أكثر طريقة موثوقة لضمان العمل الخلفي دون طلب استثناءات النظام.

متى طلب استثناء

له معنى طلب القائمة البيضاء فقط للتطبيقات ذات الوظائف الخلفية الحرجة: الملاحة في الوقت الحقيقي، مراقبة الصحة، مكالمات VoIP، حماية الجهاز. لمعظم التطبيقات، يكفي استخدام Foreground Service أو WorkManager. قد ترفض Google Play النشر إذا كان التطبيق يطلب استثناء دون حاجة واضحة.

// طلب استثناء من App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// التحقق من الحالة الحالية
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

اختبار App Standby

اختبار App Standby عبر ADB يسمح بتعيين أي bucket قسريًا لتطبيق والتحقق من سلوكه. هذا مهم جدًا للتطبيقات التي تعتمد على المزامنة الخلفية، الإشعارات أو التحديثات الدورية. يجب إجراء الاختبار على جهاز مادي أو محاكي بنسخة Android 9+.

لتعيين bucket قسريًا، استخدم الأمر adb shell am set-standby-bucket [package] [bucket]، حيث يمكن أن يكون bucket: active، working_set، frequent أو rare. لعرض bucket الحالي — adb shell am get-standby-bucket [package]. يسمح النظام أيضًا بمحاكاة عدم النشاط المطول للتطبيق من خلال الأمر adb shell dumpsys usagestats.

# تعيين bucket Rare للتطبيق
$ adb shell am set-standby-bucket com.example.app rare

# عرض bucket الحالي
$ adb shell am get-standby-bucket com.example.app

# إعادة تعيين جميع buckets إلى Active
$ adb shell dumpsys usagestats clear

# عرض جميع buckets النظام
$ adb shell dumpsys usagestats

ما يجب تحققه

بعد تعيين bucket إلى Rare، تحقق مما: هل تتم مهمة WorkManager خلال 24 ساعة، هل يعمل AlarmManager، هل تصل إشعارات FCM، وهل يعمل Foreground Service بدون قيود. WorkManager بسياسة Expedited Work يجب أن يتنفذ فورًا حتى في bucket Rare، لأنه يستخدم Foreground Service. ستتأخر مهام WorkManager العادية وفقًا للbucket.

أفضل الممارسات

يتطلب تطوير تطبيق مقاوم لِApp Standby نهجًا واعيًا للمهام الخلفية. المبدأ الأساسي: لا تفترض أن التطبيق دائمًا في bucket Active. صمّم العمل الخلفي بحيث يتم تنفيذه بشكل صحيح مع التأخيرات المميزة لبكيت Frequent و Rare.

استخدام WorkManager مع Expedited Work

Expedited Work (WorkManager 2.7+) يقوم بتشغيل Foreground Service داخليًا، مما يمنح المهمة تنفيذًا فوريًا بغض النظر عن bucket. هذا هو الخيار الأمثل للمهام التي لا يمكن تأجيلها: إرسال رسالة، مزامنة بعد الدفع، معالجة مكالمة واردة. تتم مهام WorkManager العادية في نوافذ الصيانة وفقًا للbucket.

FCM لإعادة التنشيط

استخدم رسائل FCM عالية الأولوية لإيقاظ التطبيق من App Standby. عندما يتلقى التطبيق هذه الرسالة، يتم رفع bucket خاصته مؤقتًا إلى Active، مما يسمح له بأداء المهام الضرورية (المزامنة، تحديث البيانات). بعد اكتمال المعالجة، يعود bucket إلى مستواه الأصلي.

تجنب الاحتفاظ الثابت في الذاكرة

لا تحاول التخلص من App Standby باستخدام خدمات خلفية مستمرة أو WakeLock أو رسائل FCM دورية. تكافح Google بنشاط مثل هذه الممارسات — قد يتم وسم التطبيق بأنه مستهلك للطاقة ويتم تقييده بشكل أشد. استخدم WorkManager للمهام الدورية و Foreground Service فقط عندما تكون المهمة مرئية بالفعل للمستخدم.

• WorkManager — واجهة البرمجة المفضلة؛ Expedited Work ينفذ المهام دون تأخير
• FCM عالي الأولوية — يرفع bucket مؤقتًا إلى Active لمعالجة الرسالة
• لا تتخلص من App Standby — يؤدي إلى حجب التطبيق بواسطة النظام
• Foreground Service — ينقل التطبيق مؤقتًا إلى Active أثناء التشغيل
• اختبر التطبيق في buckets Rare و Frequent عبر ADB قبل كل إصدار