Firebase Crashlytics vs Sentry مقارنة

SDK مجانية وخفيفة من Google لتتبع الأعطال (crash)

VS
Sentry

تتبع الأخطاء + الأداء + إعادة تشغيل الجلسة في منصة واحدة، قابلة للاستضافة الذاتية

12 دقائق للقراءةServices

الحكم السريع

قاعدة واضحة: إذا كنت تبحث فقط عن إجابة سؤال "متى تعطّل التطبيق" وميزانيتك صفر، فـ Crashlytics هو الخيار — يستغرق إعداده دقائق ولا يحمل خطر فاتورة مفاجئة. أما إذا أردت الأخطاء والأداء وإعادة تشغيل الجلسة (session replay) في لوحة واحدة، أو كنت بحاجة إلى إبقاء البيانات في بنيتك التحتية الخاصة بموجب GDPR، فنطاق Sentry يبرر هذه التكلفة. تستخدم فرق كثيرة الأداتين معًا؛ إن اخترت هذا المسار، قِس أثر وجود SDK مزدوج على حجم التطبيق ووقت الإقلاع في بنائك (build) الخاص.

Firebase CrashlyticsSentry
اقرأ الخلاصة كاملة

مقارنة الدرجات

جارٍ تحميل الرسم البياني...

التقييم التفصيلي

التقييم التفصيلي: Firebase Crashlytics و Sentry — درجات كل فئة من 10
الفئةFirebase CrashlyticsSentry
الأداء
7/10
9/10
سهولة التعلّم
9/10
6/10
النظام البيئي
6/10
9/10
المجتمع
8/10
8/10
سوق العمل
6/10
7/10
الاستدامة المستقبلية
7/10
8/10

الإيجابيات والسلبيات

Firebase Crashlytics

الإيجابيات

  • مجانية بالكامل — لا رسوم حسب الاستخدام أو الحدث
  • متكاملة في لوحة واحدة مع منتجات Firebase console الأخرى (Analytics وPerformance وRemote Config)
  • الإعداد يستغرق دقائق، وبأقل قدر من التهيئة (configuration)
  • دعم SDK رسمي لـ Android/iOS/Flutter/Unity/NDK
  • نسبة المستخدمين الخالية من الأعطال (crash-free) وتنبيهات السرعة (velocity alerts) حسب الإصدار مدمجة افتراضيًا
  • الوصول إلى البيانات الخام ممكن عبر تصدير BigQuery
  • تكامل أصلي (native) مع Google Play Console في جانب Android

السلبيات

  • لا توجد وحدة أداء/تتبع (performance/tracing) منفصلة — التركيز على الأعطال فقط
  • لا يوجد إعادة تشغيل الجلسة (session replay) أو تسجيل مسار المستخدم
  • لا يوجد خيار استضافة ذاتية (self-host) — تبقى البيانات دائمًا في بنية Google التحتية
  • قواعد التنبيه محدودة بخمسة أنواع أحداث ثابتة (new fatal/non-fatal، regressed، trending، increasing-velocity) — لا يمكن تعريف حدود/شروط مخصصة كما في Sentry

الأنسب لـ

الفرق ذات الميزانية الصفرية التي يكفيها تتبع الأعطال فقطالمشاريع التي تستخدم Firebase بالفعل (Auth وFirestore وRemote Config)تطبيقات الجوال في مرحلة MVP والمراحل المبكرةالفرق التي تريد تتبع مقاييس crash-free في Google Play/App Store

Sentry

الإيجابيات

  • Tracing وProfiling وSession Replay وLogs وFeature Flags في لوحة واحدة
  • مع خيار الاستضافة الذاتية (self-hosted) يمكن أن تبقى البيانات بالكامل في بنيتك التحتية الخاصة
  • مجتمع مفتوح المصدر كبير بأكثر من 44 ألف نجمة على GitHub (سبتمبر 2026)
  • وتيرة إصدارات أسبوعية نشطة لـ sentry-cocoa/sentry-react-native/sentry-dart
  • يمكن أتمتة رفع dSYM/خريطة المصدر عبر sentry-cli + Xcode Build Phase
  • يمكن اختيار منطقة تخزين البيانات: الولايات المتحدة أو الاتحاد الأوروبي (فرانكفورت)
  • تكامل Slack (`/sentry link`، إجراء تنبيه، إشعار اختباري) مدمج افتراضيًا
  • أتمتة خريطة ProGuard/R8 موثّقة رسميًا

السلبيات

  • رسوم لكل خطأ عند تجاوز الحصة — أي ارتفاع مفاجئ في الأخطاء قد يضخّم الفاتورة بسرعة
  • الإعداد يتطلب تهيئة (configuration) أكثر مقارنة بـ Crashlytics (خطوات mapping/dSYM)
  • بعض ميزات SaaS مثل Spike Protection وSeer AI/ML غير متوفرة في النسخة ذاتية الاستضافة
  • لا يمكن تغيير منطقة تخزين البيانات (الولايات المتحدة/الاتحاد الأوروبي) بعد إنشاء المؤسسة
  • خطة Developer المجانية مقتصرة على مستخدم واحد فقط

الأنسب لـ

الفرق التي تريد الأخطاء + الأداء + إعادة تشغيل الجلسة في لوحة واحدةالشركات التي تريد إبقاء البيانات في بنيتها التحتية الخاصة (self-host) بموجب GDPRمن يريد توحيد الخلفية (backend) والجوال والويب في منصة مراقبة (observability) واحدةالفرق التي تهمها وتيرة تحديثات SDK النشطة وإصلاح الأخطاء السريع

مقارنة الكود

Firebase Crashlytics
// Firebase Crashlytics - Android (Kotlin): الإعداد وتسجيل الأخطاء غير القاتلة (non-fatal)
// build.gradle.kts (app)
// plugins { id("com.google.gms.google-services"); id("com.google.firebase.crashlytics") }
// dependencies { implementation(platform("com.google.firebase:firebase-bom:34.19.0"))
//                implementation("com.google.firebase:firebase-crashlytics") }

import com.google.firebase.Firebase
import com.google.firebase.crashlytics.crashlytics
import com.google.firebase.crashlytics.setCustomKeys

class CheckoutViewModel {

    private val crashlytics = Firebase.crashlytics

    fun onPaymentStarted(orderId: String, amount: Double) {
        // Breadcrumb: لمعرفة الخطوة التي حدث فيها العطل إن حدث
        crashlytics.log("payment_started order=$orderId amount=$amount")
        crashlytics.setCustomKeys {
            key("order_id", orderId)
            key("payment_amount", amount)
            key("user_tier", "premium")
        }
    }

    fun onPaymentFailed(error: Throwable, orderId: String) {
        // تسجيل الخطأ دون تعطيل التطبيق (non-fatal)
        crashlytics.setCustomKey("order_id", orderId)
        crashlytics.recordException(error)
    }

    fun identifyUser(userId: String) {
        crashlytics.setUserId(userId)
    }
}

// AndroidManifest.xml: firebase_crashlytics_collection_enabled=false (فعّله بعد موافقة المستخدم)
// Runtime: Firebase.crashlytics.setCrashlyticsCollectionEnabled(true)
Sentry
// Sentry - iOS (Swift): الأخطاء + الأداء + إعادة تشغيل الجلسة في SDK واحدة
// Package.swift / SPM: https://github.com/getsentry/sentry-cocoa

import Sentry

func configureSentry() {
    SentrySDK.start { options in
        options.dsn = "https://<public-key>@o<org-id>.ingest.sentry.io/<project-id>"
        options.debug = false

        // تتبع الأداء (Performance tracing)
        options.tracesSampleRate = 0.2

        // UI Profiling (sentry-cocoa 9.x): مرتبط بدورة حياة التتبع (trace lifecycle)
        options.configureProfiling = {
            $0.lifecycle = .trace
            $0.sessionSampleRate = 1.0
        }

        // Session Replay: يسجّل مسار الشاشة قبل حدوث العطل
        options.sessionReplay.onErrorSampleRate = 1.0
        options.sessionReplay.sessionSampleRate = 0.1

        // لقطة شاشة + التسلسل الهرمي للعرض عند حدوث الخطأ
        options.attachScreenshot = true
        options.attachViewHierarchy = true
    }
}

// Breadcrumb + سياق مخصص + التقاط الأخطاء غير القاتلة (non-fatal)
func onPaymentFailed(_ error: Error, orderId: String) {
    let crumb = Breadcrumb(level: .error, category: "payment")
    crumb.message = "payment_failed order=\(orderId)"
    SentrySDK.addBreadcrumb(crumb)

    SentrySDK.configureScope { scope in
        scope.setTag(value: orderId, key: "order_id")
        scope.setUser(User(userId: "u_123"))
    }
    SentrySDK.capture(error: error)
}

// رفع dSYM تلقائيًا (Xcode Run Script Build Phase):
// sentry-cli debug-files upload --include-sources "$DWARF_DSYM_FOLDER_PATH"

الخلاصة

قاعدة واضحة: إذا كنت تبحث فقط عن إجابة سؤال "متى تعطّل التطبيق" وميزانيتك صفر، فـ Crashlytics هو الخيار — يستغرق إعداده دقائق ولا يحمل خطر فاتورة مفاجئة. أما إذا أردت الأخطاء والأداء وإعادة تشغيل الجلسة (session replay) في لوحة واحدة، أو كنت بحاجة إلى إبقاء البيانات في بنيتك التحتية الخاصة بموجب GDPR، فنطاق Sentry يبرر هذه التكلفة. تستخدم فرق كثيرة الأداتين معًا؛ إن اخترت هذا المسار، قِس أثر وجود SDK مزدوج على حجم التطبيق ووقت الإقلاع في بنائك (build) الخاص.

احصل على استشارة مجانية
الأسئلة الشائعة

الأسئلة الشائعة

Crashlytics يكفي إن كان تتبع الأعطال وحده كافيًا والميزانية يجب أن تكون صفرًا؛ أما Sentry فهو الخيار الصحيح للفريق الذي يريد إلى جانب تتبع الأخطاء تتبع الأداء (tracing) وإعادة تشغيل الجلسة، والاستضافة الذاتية عند الحاجة. كلاهما يقدّم SDK سهلة الإعداد، والقرار يعود إلى سؤالي النطاق والميزانية.

مقالات مدونة ذات صلة

عرض جميع المقالات

مشاريع ذات صلة

عرض جميع المشاريع
جميع المقارنات