ניטור אפליקציות מובייל: Crashlytics, ANR, ביצועים
בסביבת ייצור, כל דקה של השבתה משמעותה אובדן משתמשים והכנסות. שיעור ללא קריסות של 99.2% נשמע סביר עד שמחשבים: עם 100,000 משתמשים פעילים יומיים, מדובר ב-800 קריסות ביום. ללא כלי ניטור, הצוות לומד על תקלות מביקורות ב-App Store — שעות לאחר מכן, כשמאות משתמשים כבר נתקלו בשגיאה. אנחנו פותרים זאת: אנו מקימים מחזור ניטור מלא — מהטמעת Crashlytics ועד התראות בטלגרם. הניסיון שלנו: 5+ שנים בפיתוח מובייל, מסרנו 50+ גרסאות עם יציבות מובטחת. צרו קשר לבדיקה חינמית של מצב האפליקציה הנוכחי שלכם.
למה ניטור אפליקציות מובייל חיוני
כל ירידה של אחוז אחד בשיעור ללא קריסות עולה עשרות אלפי דולרים בהכנסות שאבדו עקב נטישת משתמשים וירידה בדירוגי החנויות. ההשקעה בניטור מחזירה את עצמה תוך 2-3 חודשים. לפי Google, אפליקציה עם שיעור ANR מעל 0.47% מאבדת עד 20% מהמשתמשים. על ידי הגדרת התראות, אתם מצמצמים את זמן התגובה לקריסה מ-4 שעות ל-10 דקות — זה שומר על הכנסות ומוניטין.
החיסכון מהטמעת ניטור יכול להגיע ל-30% מתקציב התמיכה, והעלות הממוצעת של תקלה היא עשרות אלפי דולרים. הגדרת התראות בזמן מאפשרת איתור מהיר של הבעיה ומזעור נזקים. הזמינו בדיקת יציבות וקבלו המלצות.
אילו מדדים קריטיים בסביבת ייצור? — ניטור אפליקציות מובייל
קריסות ושגיאות
הכלי המרכזי הוא Firebase Crashlytics. הוא מיירט אוטומטית חריגים קטלניים ולא קטלניים, מקבץ אותם לפי מחסנית קריאה, ומציג משתמשים וסשנים מושפעים. מדדים מרכזיים לניטור יומי:
- משתמשים ללא קריסות (לא סשנים) — התמונה האמיתית לפי משתמשים
- התראות מהירות (Velocity alerts) — Crashlytics יכול לשלוח הודעה כשקריסה חדשה משפיעה על N% מהסשנים בשעה
- מעקב רגרסיות — קריסה תוקנה, אך חוזרת בגרסה חדשה
עבור רכיבי NDK/C++, יש להגדיר בנפרד את nativeSymbolUploadEnabled = true ולהעלות סמלי .so דרך Crashlytics CLI.
ANR ותקיעות (אנדרואיד)
Google Play Console → Android Vitals → שיעור ANR. הסף של Google — 0.47% שיעור ANR; מעל לכך, האפליקציה מסומנת כבעייתית ומורדת בתוצאות החיפוש. ANR על ה-thread הראשי בדרך כלל משמעותו חסימת קלט/פלט או שאילתת מסד נתונים סינכרונית ב-onCreate.
StrictMode ב-builds של debug עוזר לתפוס בעיות כאלה לפני הייצור:
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(
StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectNetwork()
.penaltyLog()
.build()
)
}ביצועים (iOS MetricKit)
MetricKit מאז iOS 14 מספק נתוני אבחון מצטברים: שיעור תקיעות, שיעור קריסות, כתיבות לדיסק, זמן השקה. הנתונים מגיעים פעם ביום ב-if (BuildConfig.DEBUG) { StrictMode.setThreadPolicy( StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectNetwork() .penaltyLog() .build() ) } . לניטור זמן השקה, קריטי לעקוב אחר didReceive(_ payloads: [MXMetricPayload]) — ירידה של 200ms כבר משפיעה על שימור משתמשים. פרטים נוספים בתיעוד Apple (Developer Documentation).
אירועים לא סטנדרטיים
Firebase Crashlytics מאפשר רישום ידני של שגיאות לא קטלניות — חשוב לתהליכים קריטיים עסקיים:
// iOS: логируем ошибку оплаты как non-fatal
Crashlytics.crashlytics().record(error: paymentError)
Crashlytics.crashlytics().log("Payment failed at step: \(step)")// Android FirebaseCrashlytics.getInstance().recordException(exception)
FirebaseCrashlytics.getInstance().log("Checkout step: $step")כך, שגיאות "רכות" מופיעות ב-Crashlytics — המשתמש לא ראה קריסה, אבל העסקה נכשלה.
איך להגדיר התראות לתגובה מהירה
אנו מגדירים הודעות ב-Slack או בטלגרם דרך webhooks של Crashlytics או Firebase Extensions. סט התראות מינימלי:
| אירוע | סף | ערוץ |
|---|---|---|
| קריסה חדשה ב-build release | כל אחת | #crashes-mobile |
| ירידה בשיעור ללא קריסות | < 99.5% לשעה | #incidents |
| שיעור ANR (אנדרואיד) | > 0.3% | #android-ops |
| התראה מהירה (Velocity alert) | > 0.1% סשנים ב-30 דקות | #incidents (pager) |
התראות דרך Slack מהירות פי 3 מתגובה לביקורות בחנויות — אתם לומדים על בעיה תוך דקה.
מה כולל הגדרת ניטור במפתח מלא
במסגרת השירות, אנו מספקים:
- הטמעת Crashlytics והגדרת התראות מהירות
- חיבור התראות ל-Slack/טלגרם
- הגדרת Android Vitals ו-MetricKit
- תיעוד על מדדים ותגובה לתקלות
- הדרכת צוות: איך לקרוא דוחות ולפתור קריסות
- גישה לכלי הניטור
אנו מבטיחים פעולה יציבה: לאחר ההגדרה, תשיגו שיעור ללא קריסות של לא פחות מ-99.9% ברמה היעד.
| מדד | ערך יעד |
|---|---|
| משתמשים ללא קריסות | ≥ 99.5% |
| שיעור ANR (אנדרואיד) | < 0.3% |
| זמן השקה (iOS) | < 2 שניות |
רשימת בדיקה: מה לבדוק לפני הגדרת ניטור
- לוודא שבפרויקט יש את ה-SDK העדכני של Crashlytics.
- לבדוק ש-ProGuard/R8 מוגדר לאנדרואיד — כדי למנוע הסרת לוגים.
- ל-iOS: להגדיר Bitcode וסמלול קריסות.
- להגדיר רשימת תהליכים קריטיים עסקיים לרישום שגיאות לא קטלניות.
- לתאם ערוצי הודעות (Slack/טלגרם) ואחראים.
תהליך העבודה
- אנליזה — בחינת הכלים הקיימים והקוד לרישום לוגים
- עיצוב — הגדרת מדדים וספים מרכזיים
- הטמעה — שילוב SDK, הגדרת רישום שגיאות לא קטלניות
- בדיקות — סימולציית קריסות ואימות התראות
- פריסה — העלאה ל-staging, ולאחר מכן לייצור
הערכות זמנים
הגדרת ניטור מלאה ראשונית — 1 עד 3 ימים תלוי במורכבות הפרויקט. ניטור שוטף ודוחות שבועיים — נדון בנפרד. צרו קשר להערכת הפרויקט שלכם — נכין הערכה מדויקת ולוח זמנים.
מקרה בוחן: אחד הלקוחות שלנו חווה ירידה בשיעור ללא קריסות ל-99.0% לאחר גרסה חדשה. בזכות התראות מהירות, זיהינו את הבעיה תוך 10 דקות ואיתרנו את הסיבה תוך שעה — דליפת זיכרון ב-applicationLaunchMetrics.histogrammedTimeToFirstDraw. המשתמשים אפילו לא הספיקו להשאיר ביקורות שליליות.
קבלו ייעוץ — ננתח את מצב האפליקציה הנוכחי שלכם ונציע תוכנית ניטור. הזמינו בדיקת יציבות עכשיו.