הגדרת ניטור משתמשים אמיתי (RUM) לאפליקציות מובייל: למה אתה צריך את זה

הגדרת ניטור משתמשים אמיתי (RUM) לאפליקציות מובייל: למה אתם צריכים את זה

תארו לעצמכם: משתמש במכשיר Xiaomi Redmi Note 9 מתלונן שמסך רשימת המוצרים מגמגם. ניטור סינתטי מראה 60 FPS מושלמים, אבל ברשת LTE באזור שלהם, יש פסק זמן ברשת ב-8 שניות. בלי RUM, אתם מגלים על זה רק מביקורות ב-Play Market. RUM לוכד כל גמגום בממשק, כל ANR, כל שגיאת רשת. הניסיון שלנו מראה: 30% מהבאגים הקריטיים בלתי נראים בבדיקות סינתטיות. הטמעת RUM ביותר מ-50 פרויקטים קיצצה את זמן האבחון פי 3 וחוסכת עד $1500 בחודש על ידי איתור מהיר של צווארי בקבוק.

ההבדל בין RUM לניטור סינתטי

RUM אוסף נתונים ממכשירים אמיתיים, בעוד ניטור סינתטי רץ בסביבה מבוקרת. ניטור סינתטי לא יראה שמסך התשלום במכשיר Huawei P40 מגמגם בגלל ציור יתר ב-FrameLayout. RUM לוכד כל אירוע: View, Action, Resource, Error, Long Task. בין אלה, Long Task הוא המדד בעל הערך הדיאגנוסטי הגבוה ביותר. מסמכי Datadog RUM (מסמכי Datadog RUM) קובעים שמעל 50% מתקריות הביצועים מתגלות דרך Long Tasks.

אילו נתונים RUM אוסף?

סט אירועים סטנדרטי ב-RUM למובייל:

• View — מעברי מסך (פתיחה, סגירה, משך)
• Action — הקשה, החלקה, גלילה, לחיצה ארוכה
• Resource — בקשת HTTP: כתובת URL, שיטה, סטטוס, גודל, זמן השהיה
• Error — חריגה מטופלת, חריגה לא מטופלת, ANR, קריסה
• Long Task — פעולה על ה-thread הראשי > 100ms (אנדרואיד) / runloop ראשי > 16ms (iOS)

מכל האירועים, בעל הערך הדיאגנוסטי הגבוה ביותר הוא Long Task המתואם עם View. אם Long Task של 250ms מתרחש במהלך מעבר למסך התשלום עבור 15% מהמשתמשים, זו באג ביצועים קונקרטי, לא "לפעמים זה מגמגם" מעורפל.

למה Long Task הוא המדד המרכזי

Long Task מצביע ישירות על חסימת ממשק המשתמש. לדוגמה, בפרויקט אחד לאחר שילוב RUM, גילינו שטעינת רשימת ההזמנות באנדרואיד ביצעה מיון כבד על ה-thread הראשי (Long Task של 400ms). התיקון: העברת המיון ל-coroutine. בלי RUM, הבעיה הזו הייתה נשארת בלתי מזוהה.

השוואת כלי RUM

עבור רוב המוצרים, Firebase Performance היא נקודת התחלה טובה (חינמי, ללא צורך בהגדרות לרשת). אבל ברגע שצריך מתאם עם מעקבי שרת או מאפיינים עסקיים מותאמים אישית, עוברים ל-Datadog או Sentry. Datadog מעבד פי 10 יותר אירועים מאשר Firebase Performance בעלות דומה.

איך לבחור sessionSampleRate

sessionSampleRate קובע את אחוז הסשנים הנשלחים ל-RUM. עם DAU גבוה (לדוגמה, מיליון), 100% סשנים זה יקר. נוהג סטנדרטי: 100% לגרסאות חדשות ב-48 השעות הראשונות, ואז ירידה ל-20–30%. כדי למצוא שגיאות נדירות (לדוגמה, ANRs על 0.5% מהמכשירים), צריך דגימה גבוהה. בחירה מאוזנת היא 50%.

דוגמת הגדרה עם Datadog RUM

import DatadogRUM
RUM.enable(with: RUM.Configuration(
    applicationID: "your-rum-app-id",
    sessionSampleRate: 80, // 80% сессий
    telemetrySampleRate: 20,
    trackBackgroundEvents: false // не трекаем фоновые события
))

אינסטרומנטציה ידנית של View (SwiftUI)

struct ProductListView: View {
    var body: some View {
        List(products) { product in
            ProductRow(product: product)
        }
        .trackRUMView(name: "ProductList")
    }
}

ניטור בקשת רשת ספציפית

// С URLSession + Datadog
let delegate = DDURLSessionDelegate()
let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil)

Datadog מזריק אוטומטית import DatadogRUM RUM.enable(with: RUM.Configuration( applicationID: "your-rum-app-id", sessionSampleRate: 80, // 80% сессий telemetrySampleRate: 20, trackBackgroundEvents: false // не трекаем фоновые события )) לכל בקשה דרך הסשן הזה — אין צורך ב-interceptors נוספים.

בעיות נפוצות בהטמעת RUM

באג נפוץ: Views נסגרים מוקדם מדי. לדוגמה, ב-UIKit ללא קריאה מפורשת ל-struct ProductListView: View { var body: some View { List(products) { product in ProductRow(product: product) } .trackRUMView(name: "ProductList") } } , הסוכן סוגר את ה-View ב-// С URLSession + Datadog let delegate = DDURLSessionDelegate() let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) , אבל אם ה-controller מציג bottom sheet מעל עצמו, ה-View נסגר ונפתח מחדש, ויוצר רשומה כפולה. פתרון:

// iOS — явное управление View lifecycle
override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    RUM.monitor?.startView(viewController: self, name: "ProductDetail")
}

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    if isMovingFromParent {
        RUM.monitor?.stopView(viewController: self)
    }
}

תהליך הטמעת RUM

מה כלול בעבודה?

• בחירת כלי על בסיס המחסנית והתקציב (Datadog / Sentry / Firebase / New Relic)
• שילוב SDK עם sessionSampleRate אופטימלי
• אינסטרומנטציה של מעברי View (iOS, אנדרואיד, Flutter)
• הגדרת HTTP interceptor למעקב אחר משאבי רשת
• הגדרת לוגיקת הסכמה לעמידה ב-GDPR
• בניית דשבורד: זמן טעינת View p75/p95, שיעור שגיאות, שיעור Long Task
• הדרכת צוות לשימוש בדשבורד

ציר זמן והערכת עלות

הגדרת RUM בסיסית אורכת 1–2 ימים. מאפיינים מותאמים אישית ודשבורדים מוסיפים עוד 1–2 ימים. בממוצע, ההשקעה מחזירה את עצמה תוך 2–3 חודשים על ידי קיצור זמן איתור הבאגים. העלות מחושבת באופן אישי לפי מורכבות האפליקציה והכלי הנבחר. צרו קשר להערכה מדויקת. לצוות שלנו יש ניסיון של 7+ שנים בפיתוח מובייל. קבלו ייעוץ לבחירת כלי ה-RUM המתאים.