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

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

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

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

הסבר על נמנום

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

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

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

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

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

הגבלות על נמנום

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

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

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

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

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

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

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

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

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

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

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

שימוש ב-FCM לביצוע פעולות באפליקציה כשהמכשיר לא פעיל

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

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

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

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

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

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

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

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

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

בדיקה באמצעות 'נמנום' ו'מצב המתנה'

כדי להבטיח חוויית שימוש מעולה למשתמשים, מומלץ לבדוק את האפליקציה באופן מלא ב-Doze ו-App Stand.

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

בדיקת האפליקציה באמצעות App Standby

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

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

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

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

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

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