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

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

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

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

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

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

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

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

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

פעיל

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

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

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

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

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

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

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

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

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

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

קבוצת עבודה

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

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

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

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

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

נדיר

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

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

מוגבל

הקטגוריה הזו, שנוספה ב-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 מפורטות כמה הנחיות.

  • אם האפליקציה לא מציגה התראה כשמתקבלת הודעה מ-RemoteNotification העברת הודעות בענן ב-Firebase‏ (FCM), המשתמש לא יכול לבצע אינטראקציה עם האפליקציה, ולכן היא לא תועבר לקטגוריה "פעילה". למעשה, השימוש היחיד שמיועד ל-RemoteNotification הוא לשלוח התראה למשתמש, כך שהמצב הזה לא אמור לקרות. יש מדיניות אכיפה לגבי השימוש בסוגי ההודעות האלה: חלון ביצוע של 20 שניות שחוזר להתראה המקורית. אין אכיפה אם האפליקציה פועלת בחזית או אם המשתמש מאפשר הפעלה ברקע.

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