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

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

שימוש מוגזם בחסימה חלקית של מצב השינה בתפקוד האפליקציה

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

התכונה הזו מגבירה את החשיבות של יעילות הסוללה לצד אינדיקטורים קיימים ליציבות של מדדי הליבה: שיעור גבוה של קריסות שהשפיעו על המשתמשים ושל מקרי ANR. הגדרנו סף התנהגות לא תקינה לשימוש מופרז בחסימת מצב שינה. החל מ-1 במרץ 2026, אם הכותר לא יעמוד בסף האיכות הזה, יכול להיות שנחריג אותו מפלטפורמות בולטות לחיפוש תוכן, כמו המלצות. במקרים מסוימים, יכול להיות שנציג אזהרה בדף האפליקציה בחנות כדי לציין למשתמשים שהאפליקציה עלולה לגרום לריקון מוגבר של הסוללה.

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

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

• חסימות מצב שינה נמשכות לפחות שעתיים בפרק זמן של 24 שעות.
• היא משפיעה על יותר מ-5% מהסשנים באפליקציה, בממוצע של 28 ימים.

חסימות מצב שינה שנוצרו על ידי ממשקי API של אודיו, מיקום ו-JobScheduler שהופעלו על ידי המשתמש לא נכללות בחישוב של חסימות מצב השינה.

הסבר על חסימות מצב שינה

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

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

יש שתי שיטות להשגת חסימות חלקיות של מצב שינה:

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

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

שיטות מומלצות לשימוש בחסימת מצב שינה

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

כדאי לשאול את עצמכם את ארבע השאלות החשובות הבאות.

‫1. האם שקלתם אפשרויות חלופיות לחסימת מצב שינה?

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

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

1. האם המסך צריך להישאר דלוק?
   • כן: במקום זאת, עיינו במסמכי התיעוד בנושא השארת המסך פועל
2. האם האפליקציה מפעילה שירות שפועל בחזית?
   • לא: אין צורך להפעיל באופן ידני חסימת מצב שינה.
3. האם השהיית המכשיר פוגעת בחוויית המשתמש?
   • לא: לדוגמה, עדכון של התראה אחרי שהמכשיר יוצא ממצב שינה לא דורש חסימת מצב שינה.
   • כן: אם חשוב למנוע את השהיית המכשיר, למשל תקשורת מתמשכת עם מכשיר חיצוני, ממשיכים.
4. האם כבר יש API שמונע מהמכשיר לעבור למצב שינה?
   • אתם יכולים להיעזר במאמרי עזרה זיהוי חסימות מצב שינה שנוצרו על ידי ממשקי API אחרים כדי לזהות תרחישים שבהם חסימות מצב שינה נוצרות על ידי ממשקי API אחרים, כמו LocationManager.
   • אם אין ממשקי API, עוברים לשאלה האחרונה.
5. אם עניתם על כל השאלות האלה והגעתם למסקנה שאין חלופה, אתם צריכים להמשיך ברכישה ידנית של חסימת מצב שינה.

‫2. האם נתתם לחסימת מצב השינה שם נכון?

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

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

‫3. האם חסימת מצב השינה שנרכשה תמיד משתחררת?

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

לדוגמה, אם נזרקת חריגה שלא נתפסה במהלך processingWork()‎, יכול להיות שהקריאה ל-release()‎ לא תתבצע אף פעם. במקום זאת, אפשר להשתמש בבלוק try-finally כדי להבטיח שחסימת מצב השינה תבוטל, גם אם מתרחשת חריגה.

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

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

‫4. אפשר להפחית את תדירות ההפעלה?

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

• ‫WorkManager: מגדילים את המרווח התקופתי ב-PeriodicWorkRequest.
• ‫SensorManager: כדי להשתמש באצווה, צריך לציין את הערך של maxReportLatencyMs כשרושמים את המאזין.
• ספק מיקום משולב (FLP):
  • כדי להפחית את תדירות השליפה של המיקום, אפשר להשתמש ב-getLastLocation כדי לקבל את המיקום האחרון שנשמר במטמון.
  • כדי להשתמש בשיטת עדכון שצורכת פחות סוללה, משתמשים ב-setPriority(PRIORITY_PASSIVE).
  • בנוסף, אתם יכולים להשתמש במנגנון של אצווה לפי מיקום על ידי הגדרת מרווח עדכון מינימלי באמצעות setMinUpdateIntervalMillis.

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

ניפוי באגים בשימוש מופרז בחסימת מצב שינה

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

זיהוי ראשוני באמצעות Play Console

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

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

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

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

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

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

‫Background Task Inspector ב-Android Studio

צילום מסך של Background Task Inspector, שבו הוא הצליח לזהות את ה-worker‏ "WeatherSyncWorker" שניסה שוב ושוב ונכשל.

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

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

פרטים נוספים זמינים במסמכי התיעוד של Background Task Inspector.

WorkManager getStopReason

כדי לנפות באגים בשטח של worker-ים עם יותר מדי חסימות מצב שינה, אפשר להשתמש ב-WorkInfo.getStopReason() ב-WorkManager בגרסה 2.9.0 ואילך, או ב-JobParameters.getStopReason() ב-JobScheduler שזמין ב-SDK בגרסה 31 ואילך. 

ה-API הזה עוזר לתעד את הסיבה לכך ש-worker הפסיק לפעול (למשל, STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), ומצביע על בעיות כמו זמן קצוב לתפוגה שנגמר לעיתים קרובות בגלל שזמן הריצה נגמר.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

מידע נוסף על אופטימיזציה של השימוש בסוללה בממשקי API לתזמון משימות

ניפוי באגים בסוגים אחרים של חסימות מוגזמות של מצב שינה

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

איסוף עקבות המערכת

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

יש כמה דרכים לתעד את עקבות המערכת: 

• שימוש בכלי שורת הפקודה של עקבות המערכת
• שימוש ב-CPU Profiler של Android Studio
• שימוש בממשק המשתמש של Perfetto
• הקלטת מעקב באופן ידני במכשיר ישירות מאפשרויות הפיתוח. 

מפעילים את הקטגוריה "power:PowerManagement" של Atrace בממשק המשתמש של Perfetto בכרטיסייה "אפליקציות ושירותים של Android". 

לא משנה באיזו שיטה תבחרו, חשוב לוודא שאתם אוספים את קטגוריית Atrace‏ "power:PowerManagement" כדי לאפשר צפייה בטראקים של מצב המכשיר. 

בדיקת ממשק המשתמש של Perfetto וניתוח SQL

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

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

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

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

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

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

שימוש ב-ProfilingManager לאיסוף נתוני מעקב בשטח

אם קשה לשחזר את הבעיות, ProfilingManager (נוסף ב-SDK 35) הוא ממשק API פרוגרמטי שמאפשר למפתחים לאסוף עקבות מערכת בשטח באמצעות טריגרים של התחלה וסיום. הוא מאפשר שליטה רבה יותר בנקודות הטריגר להתחלה ולסיום של איסוף הפרופילים, ואוכף הגבלת קצב של יצירת בקשות ברמת המערכת כדי למנוע השפעה על ביצועי המכשיר. 

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

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

סיכום

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

אם תבינו איך להטמיע בצורה נכונה חסימות מצב שינה, תוכלו לשפר משמעותית את ביצועי הסוללה של האפליקציה. כדי להבטיח שהאפליקציה תצליח ב-Google Play, חשוב להשתמש בממשקי API חלופיים, לפעול לפי השיטות המומלצות לחסימת מצב שינה ולהשתמש בכלים יעילים לניפוי באגים, כמו Background Task Inspector, עקבות המערכת ו-ProfilingManager.