App Standby — چیست، سطوح انتظار و اصل عملکرد

App Standby چیست

App Standby یک جزء از سیستم مدیریت انرژی Android است که در Android 6.0 (API 23) معرفی و در Android 9 (API 28) به طور قابل توجهی بازطراحی شد. وظیفه آن تعیین این است که کاربر کدام برنامه‌ها را به ندرت استفاده می‌کند و محدود کردن فعالیت پس‌زمینه آن‌ها: درخواست‌های شبکه، همگام‌سازی، JobScheduler و AlarmManager. برخلاف Doze، App Standby به وضعیت صفحه نمایش یا حرکت دستگاه وابسته نیست.

سیستم برنامه‌ها را بر اساس چهار bucket (سطح) طبقه‌بندی می‌کند: Active، Working Set، Frequent و Rare. هر سطح تعیین می‌کند که فعالیت پس‌زمینه چقدر محدود می‌شود. انتقال بین سطوح به طور خودکار بر اساس الگوهای استفاده از برنامه انجام می‌شود: تعداد دفعات باز کردن برنامه توسط کاربر، دریافت اعلان‌ها، تعامل با ویجت‌ها.

App Standby همراه با Doze Mode کار می‌کند اما جایگزین آن نمی‌شود. اگر Doze فعالیت پس‌زمینه همه برنامه‌ها را در زمان بیکاری دستگاه محدود می‌کند، App Standby برنامه‌های خاص را مستقل از وضعیت دستگاه محدود می‌کند. برنامه با سطح Rare حتی در زمان استفاده فعال از تلفن نیز محدودیت خواهد داشت، اگر کاربر چندین روز آن را باز نکرده باشد.

Bucket در 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 high-priority می‌تواند به طور موقت bucket برنامه را به Active افزایش دهد. این به برنامه امکان می‌دهد تا یک وظیفه را بدون محدودیت انجام دهد (پردازش پیام، همگام‌سازی داده‌ها). با این حال، پس از اتمام پردازش، bucket به مقدار اولیه بازمی‌گردد. Google استفاده از این مکانیسم را برای تحویل اعلان‌های مهم توصیه می‌کند، نه برای زنده نگه داشتن برنامه.

سطوح App Standby

App Standby از چهار سطح (bucket) برای طبقه‌بندی برنامه‌ها استفاده می‌کند. هر سطح زمان تأخیر برای وظایف پس‌زمینه را تعیین می‌کند: هر چه سطح پایین‌تر باشد، تأخیر بیشتر است. سیستم به طور خودکار برنامه را بین سطوح بر اساس آمار استفاده جمع‌آوری شده در 7–14 روز اخیر جابه‌جا می‌کند.

Active — برنامه فعال

Active — برنامه‌ای که کاربر اخیراً با آن تعامل داشته (راه‌اندازی، دریافت اعلان یا استفاده از ویجت). در این bucket محدودیتی وجود ندارد: JobScheduler بلافاصله اجرا می‌شود، شبکه در دسترس است، AlarmManager دقیقاً فعال می‌شود. برنامه تا زمانی که کاربر تعامل با آن را برای چند ساعت متوقف کند، در Active باقی می‌ماند.

Working Set و Frequent

Working Set — برنامه به طور منظم استفاده می‌شود (چند بار در هفته). تأخیر وظایف پس‌زمینه تا 2 ساعت. Frequent — برنامه چند بار در ماه استفاده می‌شود. تأخیر تا 4 ساعت. در هر دو سطح، شبکه فقط در پنجره‌های سرویس در دسترس است و AlarmManager ممکن است به تأخیر بیفتد. JobScheduler وظایف را در نزدیک‌ترین پنجره انجام می‌دهد.

Rare — کم‌استفاده

Rare — سخت‌ترین سطح، که به برنامه‌هایی اختصاص داده می‌شود که کاربر بیش از 30 روز باز نکرده است. تأخیر وظایف پس‌زمینه به 24 ساعت می‌رسد. شبکه خارج از پنجره‌های سرویس کاملاً مسدود می‌شود، AlarmManager فقط با پرچم‌های setAndAllowWhileIdle() با محدودیت 1 بار در 9 دقیقه کار می‌کند. اعلان‌های FCM high-priority همچنان تحویل داده می‌شوند، اما نمی‌توانند bucket را افزایش دهند.

محدودیت‌ها در App Standby

App Standby محدودیت‌هایی بر چندین دسته از عملیات‌های پس‌زمینه اعمال می‌کند. برخلاف Doze، محدودیت‌های App Standby مستقل از وضعیت صفحه نمایش و شارژر عمل می‌کنند. توسعه‌دهنده باید برنامه را با در نظر گرفتن این محدودیت‌ها طراحی کند، به ویژه اگر مخاطبان هدف از برنامه به طور نامنظم استفاده می‌کنند.

JobScheduler و WorkManager

JobScheduler — API اصلی که App Standby روی آن تأثیر می‌گذارد. بسته به bucket، تأخیر اجرای وظایف از 2 تا 24 ساعت متغیر است. WorkManager که از JobScheduler در زیرساخت خود استفاده می‌کند (در API 23+)، نیز تحت این تأخیرها قرار می‌گیرد. برای وظایف حساس به زمان از Expedited Work استفاده کنید که یک Foreground Service را راه‌اندازی می‌کند و به bucket وابسته نیست.

محدودیت‌های شبکه

برنامه‌ها در bucket Working Set، Frequent و Rare نمی‌توانند در هر زمان درخواست‌های شبکه دلخواه انجام دهند. سیستم فقط در پنجره‌های سرویس که با Doze هماهنگ شده‌اند، اجازه دسترسی به شبکه را می‌دهد. برای ارسال داده‌های حیاتی از FCM high-priority با همگام‌سازی بعدی در پنجره سرویس استفاده کنید.

AlarmManager

AlarmManager در App Standby تابع همان قوانین Doze است: هشدارهای دقیق (setExact()) به تأخیر می‌افتند و setAndAllowWhileIdle() به 1 بار در 9 دقیقه محدود می‌شود. برای bucket Rare تأخیر می‌تواند به 24 ساعت برسد که AlarmManager را برای برنامه‌ریزی دقیق وظایف در برنامه‌های کم‌استفاده نامناسب می‌کند.

• JobScheduler — وظایف بسته به bucket 2–24 ساعت به تأخیر می‌افتند
• شبکه — دسترسی فقط در پنجره‌های سرویس برای Working Set و پایین‌تر
• AlarmManager — هشدارهای دقیق به تأخیر می‌افتند؛ setAndAllowWhileIdle — 1/9 دقیقه
• SyncManager — همگام‌سازی حساب‌ها تا پنجره سرویس به تأخیر می‌افتد
• Widget updates — فرکانس به‌روزرسانی ویجت‌ها ممکن است کاهش یابد

نحوه دریافت معافیت

معافیت از App Standby به دو روش قابل دریافت است: از طریق تنظیمات باتری کاربر (Whitelist دستی) یا از طریق Intent سیستمی ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. با این حال، Google دسترسی به معافیت‌ها را به شدت تنظیم می‌کند — برنامه‌هایی که دلیل موجهی برای معافیت ندارند، در معرض رد شدن در Google Play هستند.

کاربر می‌تواند به صورت دستی محدودیت‌ها را برای یک برنامه خاص از طریق Settings → Apps → [App] → Battery → Optimization → Don't optimize غیرفعال کند. این کار محدودیت‌های App Standby و Doze را برای برنامه انتخاب شده کاملاً برمی‌دارد. توسعه‌دهنده می‌تواند به کاربر راهنما یا گفتگوی سیستمی نشان دهد، اما نمی‌تواند برنامه را به اجبار به استثناها اضافه کند.

Foreground Service با اعلان به طور خودکار معافیت موقت از App Standby دریافت می‌کند. تا زمانی که سرویس فعال است و اعلان نمایش می‌دهد، برنامه مستقل از سطح واقعی خود به bucket Active منتقل می‌شود. پس از توقف سرویس، bucket به مقدار اولیه بازمی‌گردد. این مطمئن‌ترین راه برای تضمین کار پس‌زمینه بدون درخواست استثناهای سیستمی است.

چه زمانی معافیت درخواست کنیم

درخواست Whitelist فقط برای برنامه‌هایی با عملکرد حیاتی پس‌زمینه معنا دارد: ناوبری بی‌درنگ، پایش سلامت، تماس‌های 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

# بازنشانی همه bucket‌ها به Active
$ adb shell dumpsys usagestats clear

# مشاهده همه bucket‌های سیستم
$ 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 است. کار پس‌زمینه را طوری طراحی کنید که با تأخیرهای مشخصه bucket Frequent و Rare به درستی کار کند.

از WorkManager با Expedited Work استفاده کنید

Expedited Work (WorkManager 2.7+) یک Foreground Service را در زیرساخت خود راه‌اندازی می‌کند که به وظیفه اجرای فوری مستقل از bucket را می‌دهد. این انتخاب بهینه برای وظایفی است که نمی‌توانند به تأخیر بیفتند: ارسال پیام، همگام‌سازی پس از پرداخت، پردازش تماس ورودی. وظایف معمولی WorkManager در پنجره‌های سرویس با در نظر گرفتن bucket اجرا می‌شوند.

FCM برای فعال‌سازی مجدد

از پیام‌های FCM high-priority برای بیدار کردن برنامه از App Standby استفاده کنید. هنگامی که برنامه چنین پیامی دریافت می‌کند، bucket آن به طور موقت به Active افزایش می‌یابد و می‌تواند وظایف لازم را انجام دهد (همگام‌سازی، به‌روزرسانی داده‌ها). پس از اتمام پردازش، bucket به سطح اولیه بازمی‌گردد.

از نگهداری دائمی در حافظه خودداری کنید

سعی نکنید App Standby را با سرویس‌های پس‌زمینه ثابت، WakeLock یا پیام‌های دوره‌ای FCM دور بزنید. Google فعالانه با چنین روش‌هایی مبارزه می‌کند — برنامه ممکن است به عنوان پرمصرف علامت‌گذاری شده و محدودتر شود. از WorkManager برای وظایف دوره‌ای و Foreground Service فقط زمانی استفاده کنید که وظیفه واقعاً برای کاربر قابل مشاهده است.

• WorkManager — API ترجیحی؛ Expedited Work وظایف را بدون تأخیر انجام می‌دهد
• FCM high-priority — به طور موقت bucket را برای پردازش پیام به Active افزایش می‌دهد
• دور نزنید App Standby را — این منجر به مسدود شدن برنامه توسط سیستم می‌شود
• Foreground Service — به طور موقت برنامه را به Active در طول کار منتقل می‌کند
• تست کنید برنامه را در bucket Rare و Frequent از طریق ADB قبل از هر انتشار