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

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

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

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

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

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

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

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

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

פעיל

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

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

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

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

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

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

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

  • המשתמש מקיש על התראה שהאפליקציה שלכם שולחת.

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

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

קבוצת עבודה

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

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

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

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

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

נדיר

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

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

מוגבל

המאגר הזה, שנוסף ב-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).

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

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

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

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

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

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