אופטימיזציה של הסוללה באפליקציה באמצעות מדד חסימת מצב השינה של נתוני תפקוד האפליקציה ב-Android

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

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

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

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

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

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

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

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

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

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

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

יש 2 שיטות להשגת נעילות השכמה חלקיות:

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

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

שיטות מומלצות לשימוש ב-Wake Lock

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

כדאי להביא בחשבון את ארבע השאלות הקריטיות הבאות.

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

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

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

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

2. האם נתתם שם נכון ל-wake lock?

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

• אל תכללו בפרמטר השם פרטים אישיים מזהים (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: הגדלת המרווח התקופתי ב-PeriodicWorkRequests.
• ‫SensorManager: כדי להשתמש באפשרות של אצווה, צריך לציין את maxReportLatencyMs כשרושמים את המאזין.
• Fused Location Provider:
  • כדי להקטין את תדירות אחזור המיקום, אפשר להשתמש ב-getLastLocation כדי לאחזר את המיקום האחרון שנשמר במטמון.
  • כדי להשתמש בשיטת עדכון שצורכת פחות סוללה, צריך להשתמש ב-setPriority(PRIORITY_PASSIVE).
  • בנוסף, אפשר להשתמש במנגנון של איגום המיקומים על ידי הגדרת פרק זמן מינימלי לעדכון באמצעות setMinUpdateIntervalMillis.

פרטים נוספים זמינים במאמרי העזרה בנושא שיטות מומלצות לשימוש ב-Wake Lock API.

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

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

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

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

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

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

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

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

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

Android Studio Background Task Inspector

צילום מסך של הכלי Background Task Inspector (בודק משימות ברקע), שבו זוהה worker בשם WeatherSyncWorker (סנכרון מזג האוויר) שניסה שוב ושוב לבצע משימה ונכשל.

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

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

פרטים נוספים זמינים במאמרי העזרה בנושא Background Task Inspector.

WorkManager getStopReason

כדי לבצע באגים בשטח של עובדים עם נעילות השכמה מוגזמות, אפשר להשתמש ב-WorkInfo.getStopReason() ב-WorkManager 2.9.0 ומעלה או ב-JobScheduler, ב-JobParameters.getStopReason() שזמין ב-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) ב-Android Studio
• שימוש בממשק המשתמש של Perfetto
• הקלטת נתונים של מעקב באופן ידני במכשיר ישירות מאפשרויות הפיתוח. 

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

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

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

אפשר לפתוח ולבדוק את נתוני המעקב של המערכת בממשק המשתמש של Perfetto. כשפותחים את המעקב, רואים הדמיה של תהליכים שונים בציר זמן. במדריך הזה נתמקד בנתונים שבקטע Device State (מצב המכשיר).

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

בכל בלוק מופיעים שם האירוע, מתי הוא התחיל ומתי הוא הסתיים. ב-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, ‏ system traces ו-ProfilingManager.