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

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

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

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

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

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

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

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

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

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

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

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

• האפליקציה מקבלת ומשחררת את חסימת מצב שינה באופן ידני באמצעות ממשקי PowerManager API לתרחיש שימוש ספציפי. לרוב, חסימת מצב שינה מתבצעת בשילוב עם Foreground Service – ממשק 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 אחר.

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

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

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

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

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

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

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

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

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

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

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

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

כדי לזהות חלקי חסימת מצב שינה שפועלים לאורך זמן, מצמידים את העקבות בקטע Device State (מצב המכשיר), כמו Top app (האפליקציה העליונה), Screen state (מצב המסך), Long Wake locks (חסימות מצב שינה ארוכות) ו-Jobs (משימות).

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