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

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

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

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

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

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

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

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

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

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

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

יש 2 שיטות להשגת wake locks חלקיים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יש כמה שיטות ליצירת מעקב מערכת: 

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

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

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

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

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