מקרים לדוגמה

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

משך הקריאה: 4 דקות
Breana Tate
מהנדס קשרי מפתחים

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

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

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

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

mayank.png

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

זיהוי הבעיה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

manmeet.png

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

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

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

‫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 שלה. 

partialWake.png

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

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

sarthak.png

שנתחיל?

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

נכתב על ידי:

להמשך הקריאה