אופטימיזציה ל'נמנום' ול'מצב המתנה'

ב-Android יש שתי תכונות לחיסכון בחשמל שמאריכות את חיי הסוללה של המשתמשים על ידי ניהול ההתנהגות של האפליקציות כשהמכשיר לא מחובר למקור חשמל: Doze ואפליקציה במצב המתנה. מצב חיסכון בסוללה מפחית את צריכת הסוללה על ידי דחיית פעילות המעבד (CPU) ופעילות ברשת ברקע של אפליקציות, כשהמכשיר לא בשימוש במשך פרקי זמן ארוכים. אפליקציה במצב המתנה דוחה את הפעילות ברשת ברקע של אפליקציות שאין בהן פעילות משתמשים לאחרונה.

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

התכונות "נמנום" ו"אפליקציה במצב המתנה" מנהלות את ההתנהגות של כל האפליקציות שפועלות ב-Android מגרסה 6.0 ומעלה, גם אם הן לא מטרגטות באופן ספציפי את רמת ה-API המיועדת 23. כדי להבטיח את חוויית המשתמש הטובה ביותר, כדאי לבדוק את האפליקציה במצב Doze ובמצב "אפליקציה במצב המתנה", ולבצע את ההתאמות הנדרשות בקוד. בקטעים הבאים מפורט מידע נוסף.

הסבר על מצב Doze

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

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

איור 1. מצב Doze מספק חלון זמן קבוע לתחזוקה, שבו אפליקציות יכולות להשתמש ברשת ולטפל בפעילויות בהמתנה.

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

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

הגבלות על מצב Doze

המערכת מחילה את ההגבלות הבאות על האפליקציות כשהמכשיר במצב Doze:

רשימת משימות לשינה קלה

התאמת האפליקציה למצב Doze

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

כדי לתזמן התראות, אפשר להשתמש בשתי השיטות הבאות של AlarmManager: setAndAllowWhileIdle() ו-setExactAndAllowWhileIdle(). בשיטות האלה, אתם יכולים להגדיר התראות שמופעלות גם אם המכשיר במצב Doze.

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

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

הסבר על אפליקציה במצב המתנה

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

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

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

שימוש ב-FCM כדי ליצור אינטראקציה עם האפליקציה כשהמכשיר במצב חוסר פעילות

העברת הודעות בענן ב-Firebase‏ (FCM) הוא שירות מהענן למכשיר, שמאפשר לתמוך בהעברת הודעות בזמן אמת במורד הזרם בין שירותי קצה עורפי לבין אפליקציות במכשירי Android. ‫FCM מספק חיבור יחיד וקבוע לענן. כל האפליקציות שצריכות העברת הודעות בזמן אמת יכולות לשתף את החיבור הזה. החיבור המשותף הזה משפר משמעותית את צריכת הסוללה, כי הוא מייתר את הצורך של כמה אפליקציות לשמור על חיבורים קבועים ונפרדים משלהן, מה שיכול לרוקן את הסוללה במהירות. לכן, אם האפליקציה שלכם דורשת שילוב של העברת הודעות עם שירות לקצה העורפי, מומלץ מאוד להשתמש ב-FCM אם אפשר, במקום לתחזק חיבור קבוע משלכם לרשת.

‫FCM מותאם לעבודה עם מצבי חוסר הפעילות "חיסכון בסוללה" ו"אפליקציה במצב המתנה". סוג ההודעה RemoteNotification ב-FCM מאפשר להעיר את האפליקציה כדי לעורר עניין אצל המשתמש. במצב Doze או במצב המתנה של האפליקציה, המערכת מעבירה את ההודעה ונותנת לאפליקציה גישה זמנית לשירותי הרשת ולנעילות חלקיות של מצב שינה, ואז מחזירה את המכשיר או האפליקציה למצב המתנה. בהתראות שחשובות מבחינת הזמן וגלויות למשתמשים, כדאי להשתמש בסוגי ההודעות של RemoteNotification כדי לאפשר מסירה במצב Doze. ההודעות האלה יכולות להפעיל התראות. מידע נוסף זמין בהנחיות של FCM בנושא RemoteNotification.

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

כשיטה מומלצת כללית, אם האפליקציה שלכם דורשת העברת הודעות במורד הזרם, השתמשו ב-FCM. אם האפליקציה כבר משתמשת ב-FCM, ודאו שהיא משתמשת ב-RemoteNotification להודעות שמובילות להתראות שגלויות למשתמשים.

אל תשתמשו ב-RemoteNotification במצבים הבאים:

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

תמיכה בתרחישי שימוש אחרים

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

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

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

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

בדיקה עם מצב Doze ואפליקציה במצב המתנה

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

בדיקת האפליקציה במצב Doze

כדי לבדוק את מצב Doze:

  1. מגדירים מכשיר פיזי או מכשיר וירטואלי עם קובץ אימג' של מערכת Android בגרסה 6.0 (רמת API‏ 23) ומעלה.
  2. מחברים את המכשיר למחשב הפיתוח ומתקינים את האפליקציה.
  3. מפעילים את האפליקציה ומשאירים אותה פעילה.
  4. מריצים את הפקודה הבאה כדי לאלץ את המערכת להיכנס למצב חוסר פעילות:
        $ adb shell dumpsys deviceidle force-idle
        
  5. כשהכול מוכן, יוצאים ממצב חוסר פעילות באמצעות הפקודה הבאה:
        $ adb shell dumpsys deviceidle unforce
        
  6. מפעילים מחדש את המכשיר באמצעות הפקודה הבאה:
        $ adb shell dumpsys battery reset
        
  7. בודקים את ההתנהגות של האפליקציה אחרי שמפעילים מחדש את המכשיר. חשוב לוודא שהאפליקציה חוזרת לפעול בצורה תקינה כשהמכשיר יוצא ממצב Doze.

איך בודקים את האפליקציה במצב המתנה

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

  1. מגדירים מכשיר פיזי או מכשיר וירטואלי עם קובץ אימג' של מערכת Android בגרסה 6.0 (רמת API‏ 23) ומעלה.
  2. מחברים את המכשיר למחשב הפיתוח ומתקינים את האפליקציה.
  3. מפעילים את האפליקציה ומשאירים אותה פעילה.
  4. כדי לאלץ את האפליקציה להיכנס למצב המתנה, מריצים את הפקודות הבאות:
        $ adb shell dumpsys battery unplug
        $ adb shell am set-inactive <packageName> true
        
  5. כדי לדמות את הפעלת האפליקציה, משתמשים בפקודות הבאות:
        $ adb shell am set-inactive <packageName> false
        $ adb shell am get-inactive <packageName>
        
  6. בודקים את ההתנהגות של האפליקציה אחרי שמעירים אותה. מוודאים שהאפליקציה חוזרת לפעול בצורה חלקה ממצב המתנה. חשוב במיוחד לבדוק אם ההתראות והמשימות ברקע של האפליקציה פועלות כצפוי.

תרחישים לדוגמה של שימוש מקובל לפטור

בטבלה הבאה מפורטים כמה תרחישים לדוגמה, ומצוין אם מותר לאפליקציות להשתמש בפעולת ה-Intent‏ ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS במצבים האלה. באופן כללי, האפליקציה לא עומדת בתנאים האלה, אלא אם מצב חיסכון בסוללה או אפליקציה במצב המתנה משבשים את הפונקציונליות העיקרית של האפליקציה, או שיש סיבה טכנית שבגללה האפליקציה לא יכולה להשתמש בהודעות RemoteNotification של FCM.

מידע נוסף זמין במאמר תמיכה בתרחישים אחרים לדוגמה.

סוג תרחיש שימוש אפשר להשתמש ב-FCM? האם הפטור מקובל? הערות
אפליקציה להעברת הודעות מיידיות, לצ'אט או לשיחות. נדרשת מסירה של הודעות בזמן אמת למשתמשים כשהמכשיר במצב Doze או כשהאפליקציה במצב המתנה. כן, באמצעות FCM לא קביל משתמשים בהודעות FCM RemoteNotification כדי להעיר את האפליקציה ולגשת לרשת.
כן, אבל לא משתמשת בהודעות FCM RemoteNotification.
אפליקציות להעברת הודעות מיידיות, לצ'אט או לאפליקציות שיחות, אפליקציות VOIP ארגוניות. לא, אי אפשר להשתמש ב-FCM בגלל תלות טכנית בשירות הודעות אחר, או בגלל שמצב Doze ואפליקציה במצב המתנה משבשים את הפונקציונליות העיקרית של האפליקציה. סביר
אפליקציית הבטיחות. אפליקציות ששומרות על הבטיחות של המשתמשים ושל המשפחות שלהם. אם רלוונטי. סביר
אפליקציה לאוטומציה של משימות. הפונקציה העיקרית של האפליקציה היא תזמון פעולות אוטומטיות, כמו שליחת הודעות מיידיות, שיחות טלפון או ניהול תמונות חדשות. אם רלוונטי. סביר
אפליקציה נלווית לציוד היקפי. הפונקציה העיקרית של האפליקציה היא לשמור על חיבור קבוע עם הציוד ההיקפי כדי לספק לו גישה לאינטרנט. אם רלוונטי. סביר
האפליקציה צריכה להתחבר למכשיר היקפי רק מדי פעם כדי לסנכרן, או שהיא צריכה להתחבר רק למכשירים, כמו אוזניות אלחוטיות, שמחוברים באמצעות פרופילי Bluetooth רגילים. אם רלוונטי. לא קביל