ב-Android 9 (רמת API 28) ואילך יש תמיכה בקטגוריות של אפליקציות במצב המתנה. קטגוריות של אפליקציות במצב המתנה עוזרות למערכת לתת עדיפות לבקשות של אפליקציות למשאבים על סמך תדירות השימוש באפליקציות ותקופת השימוש האחרונה בהן. על סמך דפוסי השימוש באפליקציות, כל אפליקציה ממוקמת באחד מחמישה קטגוריות של תעדוף. המערכת מגבילה את המשאבים במכשיר שזמינים לכל אפליקציה על סמך הקטגוריה שבה האפליקציה נמצאת.
קטגוריות בעדיפות גבוהה
המערכת מקצה באופן דינמי כל אפליקציה לקטגוריית תעדוף, ומקצה מחדש את האפליקציות לפי הצורך. יכול להיות שהמערכת תסתמך על אפליקציה שהוטענה מראש, שמשתמשת בלמידת מכונה כדי לקבוע את הסבירות לשימוש בכל אפליקציה, ומקצה את האפליקציות לקטגוריות המתאימות.
אם אפליקציית המערכת לא נמצאת במכשיר, המערכת תמייד את האפליקציות לפי תדירות השימוש בהן לאחרונה. אפליקציות פעילות יותר מוקצות לקטגוריות עם עדיפות גבוהה יותר, כך שיהיו לאפליקציה יותר משאבי מערכת. באופן ספציפי, הקטגוריה קובעת את התדירות שבה יתבצעו המשימות של האפליקציה ואת התדירות שבה האפליקציה תוכל להפעיל התראות. ההגבלות האלה חלות רק כשהמכשיר פועל באמצעות סוללה. בזמן שהמכשיר בטעינה, המערכת לא מטילה את ההגבלות האלה.
קטגוריות העדיפות הן:
- פעיל: משתמשים באפליקציה או השתמשו בה לאחרונה מאוד.
- ערכת עבודה: האפליקציה נמצאת בשימוש רגיל.
- שימוש לעיתים קרובות: האפליקציה נמצאת בשימוש לעיתים קרובות, אבל לא מדי יום.
- נדיר: האפליקציה לא בשימוש תדיר.
- מוגבלת: האפליקציה צורכת הרבה משאבי מערכת או שהיא עשויה להתנהגות לא רצויה.
בנוסף לקטגוריות העדיפות האלה, יש אף פעם קטגוריה מיוחדת לאפליקציות שמותקנות אבל לא פועלות אף פעם. המערכת מטילה הגבלות חמורות על האפליקציות האלה.
התיאורים הבאים רלוונטיים למקרה שבו לא נעשה שימוש במודל חיזוי. לעומת זאת, כשהמערכת משתמשת בלמידת מכונה כדי לחזות את ההתנהגות, הקטגוריות נבחרות מראש בהתאם לפעולות הבאות של המשתמש, ולא על סמך השימוש האחרון שלו. לדוגמה, אפליקציה שבה השתמשתם לאחרונה עשויה להיכלל בקטגוריה 'נדיר' כי למידת המכונה צופה שלא תשתמשו באפליקציה במשך כמה שעות.
פעיל
אפליקציה נמצאת בקטגוריה פעילה בזמן השימוש בה, בזמן השימוש בה לאחרונה או כשהיא מבצעת אחת מהפעולות הבאות:
- הפעלת פעילות.
- מפעיל שירות שפועל בחזית במשך זמן רב.
- המשתמש מקייש עליו מהתראה.
אם אפליקציה נמצאת בקטגוריה הפעילה, המערכת לא מטילה הגבלות על המשימות או ההתראות של האפליקציה.
אינטראקציה של משתמשים מקצה אפליקציות כפעילות
ב-Android 9 ואילך (רמת API 28 ואילך), כשהמשתמש מקיים אינטראקציה עם האפליקציה בדרכים מסוימות, המערכת מעבירה את האפליקציה באופן זמני לקטגוריה הפעילה. אחרי שהמשתמש מפסיק לבצע אינטראקציה עם האפליקציה, המערכת ממקמת אותה לקטגוריה על סמך היסטוריית השימוש.
דוגמאות לאינטראקציות שמפעילות את התנהגות המערכת הזו:
המשתמש מקייש על התראה שנשלחת מהאפליקציה.
המשתמש מקיש על לחצן מדיה כדי ליצור אינטראקציה עם שירות בחזית האפליקציה.
המשתמש מתחבר לאפליקציה במהלך האינטראקציה עם Android Automotive OS, שבה האפליקציה משתמשת בשירות שפועל בחזית או ב-
CONNECTION_TYPE_PROJECTION
.
קבוצת עבודה
אפליקציה נמצאת בקטגוריה 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 ואילך:
- אפליקציות למכשיר נלווה
- אפליקציות שפועלות במכשיר במצב הדגמה
- אפליקציות של בעלי המכשיר
- אפליקציות של בעלי הפרופיל
- אפליקציות קבועות
- אפליקציות VPN
- אפליקציות עם התפקיד
ROLE_DIALER
- אפליקציות שהמשתמש הגדיר באופן מפורש ככאלה שמספקות פונקציונליות 'בלתי מוגבלת' בהגדרות המערכת
- אפליקציות עם ווידג'טים פעילים
- אפליקציות שקיבלו לפחות אחת מההרשאות הבאות:
הערכת הקטגוריה של העדיפות
כדי לבדוק לאיזה קטגוריה משויכת האפליקציה, מבצעים אחת מהפעולות הבאות:
קוראים לפונקציה
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 כבעלת עדיפות גבוהה כשהיא לא מפעילה אינטראקציה של משתמש, יכול להיות שהעדיפות של הודעות עתידיות תבוטל.
אם האפליקציות מחולקות לכמה חבילות, יכול להיות שהחבילות האלה נמצאות בקטגוריות שונות ויש להן רמות גישה שונות. בודקים את האפליקציות האלה עם החבילות שהוקצו לקטגוריות שונות כדי לוודא שהאפליקציה פועלת כמו שצריך.