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

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

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

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

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

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

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

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

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

פעיל

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

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

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

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

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

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

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

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

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

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

קבוצת עבודה

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

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

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

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

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

נדיר

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

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

מוגבל

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

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

  • המשתמש לא יוצר אינטראקציה עם האפליקציה שלכם במשך מספר מסוים של ימים. ב-Android 12 (רמת API 31) וב-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 כעדיפות גבוהה שלא בצורה מתאימה, כשהיא לא מפעילה אינטראקציה עם המשתמש, יכול להיות שהעדיפות של הודעות עתידיות תרד.

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