מקרים לדוגמה
איך WHOOP צמצמה ביותר מ-90% את מספר הסשנים שבהם נעשה שימוש מוגזם בחסימה חלקית של מצב השינה
משך הקריאה: 4 דקות
כשמפתחים אפליקציית Android למכשיר לביש, העבודה האמיתית מתחילה כשהמסך כבוי. WHOOP עוזרת למשתמשים להבין איך הגוף שלהם מגיב לאימונים, להתאוששות, לשינה ולמתח, ולמשתמשי WHOOP רבים ב-Android, סנכרון וקישוריות אמינים ברקע הם מה שמאפשרים את התובנות האלה.
מוקדם יותר השנה, צוות Google Play השיק מדד חדש בתכונה 'תפקוד האפליקציה': נעילות חלקיות מוגזמות של מצב המתנה. המדד הזה מודד את אחוז הסשנים של המשתמשים שבהם השימוש המצטבר בחסימת מצב שינה (לא כולל חסימות שפטורות מהמדידה) חורג משעתיים במהלך תקופה של 24 שעות. מטרת המדד הזה היא לעזור לכם לזהות ולטפל במקורות אפשריים להתרוקנות הסוללה, וזה חיוני כדי לספק חוויית משתמש מעולה.
החל מ-1 במרץ 2026, אפליקציות שלא יעמדו בסף האיכות עלולות להיחסם להצגה בפלטפורמות של Google Play לגילוי אפליקציות. יכול להיות שתוצג גם אזהרה בדף האפליקציה בחנות Google Play, שמציינת שהאפליקציה עשויה להשתמש בסוללה יותר מהצפוי.
לדברי מהאנק סאיני (Mayank Saini), מהנדס Android בכיר ב-WHOOP, 'הייתה כאן הזדמנות לצוות להעלות את הרף של היעילות ב-Android'. זאת לאחר שתפקוד האפליקציה ב-Android Vitals סימן את האפליקציה בגלל אחוז גבוה מדי של חסימת מצב שינה חלקית – 15% – שחרג מסף 5% המומלץ.
הצוות ראה במדד 'תפקוד האפליקציה' אות ברור לכך שהעבודה ברקע מונעת את מעבר המעבד למצב שינה למשך זמן ארוך מהנדרש. פתרון הבעיה הזו יאפשר להם להמשיך לספק חוויית משתמש מעולה, ובמקביל לצמצם את הזמן המבוזבז ברקע ולשמור על קישוריות וסנכרון אמינים ובזמן אמת של Bluetooth.
זיהוי הבעיה
כדי להבין איפה להתחיל, הצוות פנה קודם לתפקוד האפליקציה כדי לקבל תובנות נוספות לגבי חסימות מצב שינה שהשפיעו על המדד. בעזרת לוח הבקרה של מדד תפקוד האפליקציה בנושא חסימות חלקיות מוגזמות של מצב השינה, הם הצליחו לזהות שאחד מה-Worker של WorkManager (שמזוהה בלוח הבקרה כ-androidx.work.impl.background.systemjob.SystemJobService) הוא הגורם העיקרי לחסימות חלקיות מוגזמות של מצב השינה. כדי לתמוך ב-WHOOP ב'חוויה של הפעלה תמידית', האפליקציה משתמשת ב-WorkManager למשימות ברקע כמו סנכרון תקופתי ושליחת עדכונים חוזרים למכשיר הלביש.
למרות שהצוות ידע ש-WorkManager מקבל חסימת מצב שינה בזמן ביצוע משימות ברקע, עד להוספת המדד 'חסימות חלקיות מוגזמות של מצב שינה' במדד תפקוד האפליקציה ב-Android, לא הייתה לו אפשרות לראות איך כל העבודה ברקע (מעבר ל-WorkManager) מתבצעת.
אחרי שהצוות זיהה בלוח הבקרה ש-WorkManager הוא הגורם העיקרי לבעיה, הוא התמקד בזיהוי איזה מהעובדים תרם הכי הרבה לבעיה, ופעל לפתרון שלה.
שימוש במדדים ובנתונים פנימיים כדי לצמצם את האפשרויות ולמצוא את הסיבה
ב-WHOOP כבר הייתה תשתית פנימית שהוגדרה למעקב אחרי מדדים של WorkManager. הם עוקבים באופן תקופתי אחרי:
- זמן ריצה ממוצע: כמה זמן העובד פועל?
- פסק זמן (timeout): באיזו תדירות ה-worker מגיע לפסק זמן במקום להשלים את הפעולה?
- ניסיונות חוזרים: באיזו תדירות העובד מנסה שוב אם העבודה נכשלה או שהזמן שהוקצב לה הסתיים?
- ביטולים: באיזו תדירות העבודה בוטלה?
מעקב אחרי יותר מנתוני הצלחה וכישלון של העובדים מאפשר לצוות לראות את יעילות העבודה שלו.
המדדים הפנימיים סימנו זמן ריצה ממוצע גבוה עבור מספר מצומצם של עובדים, וכך אפשרו להם לצמצם עוד יותר את החקירה.
בנוסף למדדים הפנימיים שלהם, הצוות השתמש גם בBackground Task Inspector של Android Studio כדי לבדוק ולנפות באגים בעובדים הרלוונטיים, עם דגש ספציפי על חסימות מצב שינה המשויכות, כדי להתאים למדד שסומן בתפקוד האפליקציה.
חקירה: הבחנה בין וריאציות של עובדים
חלק מהעובדים ב-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 למפתחים אחרים שרוצים לשפר את היעילות של העבודה ברקע:
איך מתחילים
אם אתם רוצים לנסות לצמצם את נעילות ההשכמה החלקיות המוגזמות באפליקציה או לשפר את יעילות העובדים, תוכלו לעיין במדד נעילות ההשכמה החלקיות המוגזמות באפליקציה בתפקוד האפליקציה, ולעיין במסמכי המידע על נעילות השכמה כדי לקבל עוד שיטות מומלצות ואסטרטגיות לניפוי באגים.
להמשך הקריאה
-
מקרים לדוגמה
Karrot היא אפליקציה של זירת מסחר בין עמיתים שמבוססת על קהילה מקומית. האפליקציה מאפשרת למשתמשים לקנות, למכור ולסחור בפריטים עם משתמשים מאומתים אחרים. מאז ההשקה בדרום קוריאה בשנת 2015, הפלטפורמה התרחבה לשווקים גלובליים וצברה יותר מ-43 מיליון משתמשים רשומים.
Thomas Ezan, Tracy Agyemang • משך הקריאה: 2 דקות
-
מקרים לדוגמה
Monzo הוא בנק דיגיטלי בבריטניה עם 15 מיליון לקוחות, והמספרים ממשיכים לגדול. כשהאפליקציה גדלה, צוות ההנדסה זיהה את זמן ההפעלה של האפליקציה כנקודה קריטית לשיפור, אבל חשש שיידרשו שינויים משמעותיים בבסיס הקוד.
Ben Weiss, Tracy Agyemang • משך הקריאה: 2 דקות
-
מקרים לדוגמה
בעולם הדינמי של הרשתות החברתיות, תשומת הלב של המשתמשים נמשכת או נעלמת במהירות. אפליקציות Meta (פייסבוק ואינסטגרם) הן בין הפלטפורמות החברתיות הגדולות בעולם, והן משרתות מיליארדי משתמשים ברחבי העולם.
Mayuri Khinvasara Khabya, Tracy Agyemang • משך הקריאה: 4 דקות
כדאי תמיד להיות בעניינים
רוצים לקבל טיפים עדכניים לפיתוח Android ישירות לאימייל כל שבוע?