קטגוריות בהמתנה של אפליקציות

‫Android 9 (רמת API‏ 28) ואילך תומך בדלי המתנה של אפליקציות. הסיווג של האפליקציות לקטגוריות עוזר למערכת לתת עדיפות לבקשות של האפליקציות למשאבים על סמך תדירות השימוש באפליקציות והזמן שעבר מאז השימוש האחרון בהן. על סמך דפוסי השימוש באפליקציה, כל אפליקציה ממוקמת באחד מתוך חמישה סיווגים לפי עדיפות. המערכת מגבילה את משאבי המכשיר שזמינים לכל אפליקציה, בהתאם לקטגוריה שאליה היא משתייכת.

קטגוריות אחסון

המערכת מקצה באופן דינמי כל אפליקציה לקטגוריית עדיפות, ומקצה מחדש את האפליקציות לפי הצורך. יכול להיות שהמערכת תסתמך על אפליקציה שנטענה מראש ומשתמשת בלמידת מכונה כדי לקבוע את הסבירות לשימוש בכל אפליקציה, ותקצה את האפליקציות לדליים המתאימים.

אם אפליקציית המערכת לא קיימת במכשיר, המערכת מסדרת את האפליקציות כברירת מחדל לפי תדירות השימוש בהן. אפליקציות פעילות יותר משויכות לקבוצות שמעניקות להן עדיפות גבוהה יותר, וכך מאפשרות לאפליקציה להשתמש ביותר משאבי מערכת. הקבוצה קובעת במיוחד את התדירות שבה המשימות של האפליקציה פועלות ואת התדירות שבה האפליקציה יכולה להפעיל התראות. ההגבלות האלה חלות רק כשהמכשיר פועל באמצעות סוללה. בזמן שהמכשיר בטעינה, המערכת לא מטילה את ההגבלות האלה.

קטגוריות העדיפות הן:

  • פעילה: האפליקציה נמצאת בשימוש או שהשתמשו בה לאחרונה.
  • סט עבודה: האפליקציה נמצאת בשימוש קבוע.
  • תדיר: האפליקציה נמצאת בשימוש לעיתים קרובות, אבל לא מדי יום.
  • נדיר: האפליקציה לא בשימוש לעיתים קרובות.
  • מוגבלת: האפליקציה צורכת הרבה משאבי מערכת או עשויה להציג התנהגות לא רצויה.

בנוסף לקטגוריות האלה של סדר עדיפויות, יש קטגוריה מיוחדת never לאפליקציות שהותקנו אבל אף פעם לא הופעלו. המערכת מטילה מגבלות חמורות על האפליקציות האלה.

התיאורים הבאים מתייחסים למקרה שבו אין חיזוי. לעומת זאת, כשהתחזית מתבססת על למידת מכונה כדי לחזות את ההתנהגות, המערכת בוחרת את הדליים מתוך ציפייה לפעולות הבאות של המשתמש, ולא על סמך השימוש האחרון. לדוגמה, אפליקציה שהשתמשו בה לאחרונה עשויה להיכנס לקטגוריה 'נדיר' כי למידת מכונה חוזה שאולי לא ישתמשו באפליקציה במשך כמה שעות.

פעיל

אפליקציה נמצאת בקטגוריה פעילה בזמן השימוש בה, אם נעשה בה שימוש לאחרונה או אם היא מבצעת אחת מהפעולות הבאות:

  • מפעיל פעילות.
  • מריצה שירות שפועל בחזית במשך זמן רב.
  • המשתמש מקיש עליה מתוך התראה.

אם אפליקציה נמצאת בדלי הפעיל, המערכת מטילה הגבלות מינימליות על המשימות או ההתראות של האפליקציה:

  • החל מ-Android 16 (רמת API 36), למשימות ברקע יש מכסת זמן ריצה גדולה אם הן מופעלות על ידי אפליקציה בדלי הפעיל. זה כולל משימות שמתוזמנות ישירות באמצעות JobScheduler, וגם משימות שנוצרות על ידי ספריות אחרות כמו WorkManager או DownloadManager.

אינטראקציית משתמשים מקצה אפליקציות כפעילות

ב-Android 9 (רמת API‏ 28) ומעלה, כשהמשתמש מקיים אינטראקציה עם האפליקציה בדרכים מסוימות, המערכת מעבירה את האפליקציה באופן זמני למאגר הפעיל. אחרי שהמשתמש מפסיק את האינטראקציה עם האפליקציה, המערכת ממקמת אותה בדלי על סמך היסטוריית השימוש.

הנה כמה דוגמאות לאינטראקציות שמפעילות את התנהגות המערכת הזו:

  • המשתמש מקיש על התראה שנשלחת מהאפליקציה.

  • המשתמש מקיש על לחצן מדיה כדי לקיים אינטראקציה עם שירות שפועל בחזית באפליקציה.

  • המשתמש מתחבר לאפליקציה שלכם בזמן האינטראקציה עם Android Automotive OS, שבו האפליקציה שלכם משתמשת בשירות שפועל בחזית או ב-CONNECTION_TYPE_PROJECTION.

קבוצת עבודה

אפליקציה נמצאת בדלי working set אם היא פועלת לעיתים קרובות אבל היא לא פעילה. לדוגמה, אפליקציה לרשתות חברתיות שהמשתמש מפעיל כמעט מדי יום, סביר להניח שתהיה בסט העבודה. אפליקציות מקודמות גם ל-bucket של קבוצת העבודה אם נעשה בהן שימוש עקיף.

אם אפליקציה נמצאת בקבוצת העבודה, המערכת מטילה הגבלות קלות על היכולת שלה להריץ משימות ולהפעיל התראות. פרטים נוספים זמינים במאמר בנושא מגבלות משאבים לניהול צריכת חשמל.

אנשי קשר תדירים

אפליקציה נכללת בקטגוריה תדירות גבוהה אם משתמשים בה באופן קבוע, אבל לא בהכרח כל יום. לדוגמה, אפליקציה למעקב אחר אימונים שהמשתמש מפעיל בחדר הכושר עשויה להיכלל בקטגוריה 'תדירות גבוהה'.

אם אפליקציה נמצאת בקטגוריה 'שימוש תדיר', המערכת מטילה מגבלות חזקות יותר על היכולת שלה להריץ משימות ולהפעיל התראות. פרטים נוספים זמינים במאמר בנושא מגבלות משאבים לניהול צריכת חשמל.

נדיר

אפליקציה נמצאת בקטגוריה נדיר אם לא משתמשים בה לעיתים קרובות. לדוגמה, אפליקציה של מלון שהמשתמש מפעיל רק בזמן השהייה במלון עשויה להיכלל בקטגוריה 'נדיר'.

אם אפליקציה נמצאת בקטגוריה 'נדירה', המערכת מטילה עליה הגבלות מחמירות על היכולת שלה להריץ משימות ולהפעיל התראות. המערכת גם מגבילה את היכולת של האפליקציה להתחבר לאינטרנט. פרטים נוספים זמינים במאמר בנושא מגבלות משאבים לניהול צריכת חשמל.

מוגבל

הקטגוריה הזו, שנוספה ב-Android 12 (רמת API 31), היא בעדיפות הכי נמוכה וההגבלות עליה הכי מחמירות מבין כל הקטגוריות. המערכת בוחנת את ההתנהגות של האפליקציה, למשל באיזו תדירות המשתמש מקיים איתה אינטראקציה, כדי להחליט אם למקם את האפליקציה בדלי המוגבל.

ב-Android 13 (רמת API 33) ומעלה, אלא אם האפליקציה שלכם עומדת בדרישות לפטור, המערכת ממקמת את האפליקציה בדלי המוגבל במצבים הבאים:

  • המשתמש לא מקיים אינטראקציה עם האפליקציה שלכם במשך מספר מסוים של ימים. ב-Android 12 (רמת API 31) וב-Android 12L (רמת API 32), מספר הימים הוא 45. ב-Android 13, מספר הימים יורד ל-8.

  • האפליקציה שלך מפעילה מספר מוגזם של שידורים או קישורים במהלך תקופה של 24 שעות.

אם המערכת ממקמת את האפליקציה שלכם בקטגוריה המוגבלת, ההגבלות הבאות חלות:

  • אפשר להריץ משימות פעם ביום בסשן של 10 דקות. במהלך הסשן הזה, המערכת מקבצת את המשימות של האפליקציה עם המשימות של אפליקציות אחרות.
    • משימות מוגבלות לא מופעלות באופן אוטומטי. צריך להיות לפחות עוד ג'וב אחד שפועל או בהמתנה באותו הזמן, שיכול לכלול כל ג'וב אחר.
  • האפליקציה יכולה להריץ פחות משימות שדורשות טיפול מהיר, בהשוואה למצב שבו המערכת ממקמת את האפליקציה בדלי עם פחות הגבלות.
  • האפליקציה יכולה להפעיל התראה אחת ביום. ההתראה יכולה להיות התראה מדויקת או התראה לא מדויקת.

חריגים לקטגוריה המוגבלת

הסוגים הבאים של אפליקציות פטורים מההגבלה של הכניסה לקטגוריה המוגבלת, והם עוקפים את הטריגר של חוסר פעילות, גם ב-Android 12 ואילך:

הערכת קטגוריית העדיפות

כדי לבדוק לאיזה מאגר משויכת האפליקציה, מבצעים אחת מהפעולות הבאות:

  • קוראים לפונקציה getAppStandbyBucket().

  • מריצים את הפקודה הבאה בחלון המסוף: 

    adb shell am get-standby-bucket PACKAGE_NAME

המערכת מגבילה את האפליקציה בכל פעם שהיא ממוקמת בדלי להמתנה של אפליקציות שערכו גדול מ-STANDBY_BUCKET_ACTIVE (10).

שיטות מומלצות

אם האפליקציה שלכם פועלת לפי השיטות המומלצות לשימוש בתכונות Doze והמתנה של אפליקציות, לא תהיה לכם בעיה להשתמש בתכונות המתקדמות יותר לניהול צריכת החשמל. עם זאת, התנהגויות מסוימות של אפליקציות שעבדו היטב בעבר עלולות לגרום לבעיות.

  • אל תנסו להשפיע על המערכת כדי שהאפליקציה שלכם תסווג לקטגוריה מסוימת. השיטה של המערכת לקביעת סדר העדיפויות יכולה להשתנות, ויצרני מכשירים עשויים לבחור לכתוב אפליקציה משלהם לסיווג למשפחות עם אלגוריתם משלהם. במקום זאת, צריך לוודא שהאפליקציה מתנהגת בצורה הולמת לא משנה באיזה סיווג היא נמצאת.
  • אם לאפליקציה אין פעילות של מרכז הבקרה, יכול להיות שהיא אף פעם לא תועבר אל הדלי הפעיל. כדאי לשקול לעצב מחדש את האפליקציה כך שתכלול פעילות כזו.

  • אם המשתמשים לא יכולים ליצור אינטראקציה עם ההתראות של האפליקציה, הם לא יכולים להפעיל את הקידום של האפליקציה לדלי הפעיל. במקרה כזה, כדאי לשקול לעצב מחדש חלק מההתראות כדי לאפשר למשתמשים ליצור אינטראקציה. חלק מההנחיות מופיעות בתבניות העיצוב של התראות ב-Material Design.

  • אם האפליקציה לא מציגה התראה כשמתקבלת הודעה בעדיפות גבוהה של Firebase Cloud Messaging ‏ (FCM), המשתמש לא יכול לבצע פעולות באפליקציה, ולכן היא לא תועבר אל קבוצת המאגר הפעיל. למעשה, השימוש המיועד היחיד בהודעות FCM בעדיפות גבוהה הוא שליחת התראה למשתמש, ולכן המצב הזה לא אמור לקרות. ב-12L (רמת API 32) ובגרסאות קודמות, אם מסמנים הודעת FCM כעדיפות גבוהה שלא בצורה מתאימה, כשהיא לא מפעילה אינטראקציה עם המשתמש, יכול להיות שהעדיפות של הודעות עתידיות תרד.

  • אם האפליקציות מפולגות למספר חבילות, יכול להיות שהחבילות האלה נמצאות בדליים שונים ושיש להן רמות גישה שונות. כדאי לבדוק את האפליקציות האלה עם החבילות שהוקצו לדליים שונים כדי לוודא שהאפליקציה פועלת בצורה תקינה.