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

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

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

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

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

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

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

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

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

פעיל

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

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

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

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

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

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

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

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

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

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

Working set

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

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

לעיתים קרובות

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

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

נדיר

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

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

מוגבל

הקטגוריה הזו, שנוספה ב-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 כעדיפות גבוהה שלא בצורה מתאימה, כשלא מופעלת אינטראקציה עם המשתמש, יכול להיות שהעדיפות של הודעות עתידיות תרד.

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