איך WHOOP צמצמה ביותר מ-90% את מספר הסשנים שבהם נעשה שימוש מוגזם בחסימה חלקית של מצב השינה

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

מוקדם יותר השנה, Google Play השיק מדד חדש ב-תפקוד האפליקציה: נעילות חלקיות ממושכות מדי של מצב המתנה. המדד הזה מודד את אחוז הסשנים של המשתמשים שבהם השימוש המצטבר בחסימת מצב שינה (wake lock) שלא פטורה עולה על שעתיים בתקופה של 24 שעות. מטרת המדד הזה היא לעזור לכם לזהות ולטפל במקורות אפשריים להתרוקנות הסוללה, וזה חיוני כדי לספק חוויית משתמש מעולה.

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

לדברי מהאנק סאיני (Mayank Saini), מהנדס Android בכיר ב-WHOOP,  הנתון הזה 'העניק לצוות הזדמנות להעלות את הרף של היעילות ב-Android', אחרי שתפקוד האפליקציה ב-Android vitals סימן את האפליקציה בגלל אחוז גבוה מדי של חסימת מצב שינה חלקית – 15% – שחרג מסף 5% המומלץ.

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

זיהוי הבעיה

כדי להבין איפה להתחיל, הצוות פנה קודם לתפקוד האפליקציה כדי לקבל תובנות נוספות לגבי חסימות מצב שינה שהשפיעו על המדד. בעזרת לוח הבקרה של מדד תפקוד האפליקציה ב-Android בנושא חסימות חלקיות מוגזמות של מצב השינה, הם הצליחו לזהות שאחד מה-workers של WorkManager (שמזוהה בלוח הבקרה כ-androidx.work.impl.background.systemjob.SystemJobService) הוא הגורם העיקרי לחסימות חלקיות מוגזמות של מצב השינה. כדי לתמוך ב-"always-on experience" (חוויה של הפעלה תמידית) של WHOOP, האפליקציה משתמשת ב-WorkManager למשימות ברקע כמו סנכרון תקופתי ושליחת עדכונים חוזרים למכשיר הלביש. 

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

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

שימוש במדדים ובנתונים פנימיים כדי לצמצם את האפשרויות לסיבה

ב-WHOOP כבר הייתה תשתית פנימית שהוגדרה למעקב אחרי מדדים של WorkManager. הם מבצעים מעקב תקופתי אחרי:

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

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

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

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

חקירה: הבחנה בין וריאציות של עובדים

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

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

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

מנמיט טוטג'ה (Manmeet Tuteja), מהנדס Android II ב-WHOOP, אמר: "הפיצול הזה גם עזר לנו לוודא שהבעיה מתרחשת בשני הווריאנטים, מה שהצביע על כך שהבעיה לא קשורה להגדרת התזמון אלא לבעיה משותפת של לוגיקה עסקית בתוך הטמעת העובד".

מידע נוסף על התנהגות העובדים ופתרון הבעיה הבסיסית

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

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

‫CoroutineWorker שנועד להמתין לחיבור לחיישן WHOOP לפני שממשיכים. 

אם העבודה התחילה בלי חיישן מחובר, הסמל whoopSensorFlow– שמציין אם החיישן מחובר – היה null. ה-SensorWorker לא התייחס לזה כתנאי ליציאה מוקדמת והמשיך לפעול, למעשה המתין לחיבור ללא הגבלת זמן. כתוצאה מכך, WorkManager החזיק בחסימה חלקית של מצב השינה עד שהעבודה הגיעה לזמן קצוב, מה שהוביל לשימוש גבוה בחסימה של מצב השינה ברקע ולתזמון מחדש תכוף ולא רצוי של SensorWorker.

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

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

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

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

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

בסופו של דבר, חברת WHOOP ראתה ירידה באחוז חסימות מצב השינה החלקיות המוגזמות מ-15% לפחות מ-1% תוך 30 יום בלבד אחרי הטמעת השינויים ב-Worker שלה. 

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

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

איך מתחילים

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