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

חיי הסוללה הם היבט חשוב בחוויית המשתמש, ולנעילות השכמה יש תפקיד מרכזי בהקשר הזה. האם אתם משתמשים בהם בצורה מוגזמת? בפוסט הזה בבלוג נסביר מהם נעילות השכמה, נציג כמה שיטות מומלצות לשימוש בהן ונסביר איך אפשר להבין טוב יותר את ההתנהגות של האפליקציה שלכם באמצעות המדד ב-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) כמו כתובות אימייל. אם מזוהה מידע אישי, נעילת ההשכמה מתועדת כ-_UNKNOWN, מה שמקשה על ניפוי הבאגים.
• אל תתנו שם ל-wake lock באופן פרוגרמטי באמצעות שמות של מחלקות או שיטות, כי כלים כמו Proguard יכולים להסתיר את השמות האלה. במקום זאת, צריך להשתמש במחרוזת שמוגדרת בהארדקוד.
• אל תוסיפו מוני נתונים או מזהים ייחודיים לתגי Wake Lock. צריך להשתמש באותו תג בכל פעם שהנעילה למניעת שינה פועלת, כדי שהמערכת תוכל לצבור נתוני שימוש לפי שם, וכך יהיה קל יותר לזהות התנהגות חריגה.

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 API.

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

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

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

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

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

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

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

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

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

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

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

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