Firebase Performance — ما هو، أداة المراقبة والمقاييس

ما هو Firebase Performance Monitoring؟

Firebase Performance Monitoring هي خدمة سحابية من Google تقوم بجمع وعرض مقاييس أداء التطبيقات المحمولة. الخدمة جزء من مجموعة أدوات Firebase ولا تتطلب دفعاً منفصلاً — المراقبة متاحة ضمن الخطة المجانية Spark (حد 500,000 حدث يومياً) والخطة المدفوعة Blaze. يقوم Firebase Performance تلقائياً بإنشاء تتبعات للسيناريوهات القياسية: بدء تشغيل الشاشة من البارد، بدء التشغيل من الدافئ، طلبات HTTP الخلفية.

تعتمد بنية الخدمة على نوعين من البيانات: traces (تتبعات) و metrics (مقاييس). التتبع هو فاصل زمني ببداية ونهاية، يقاس خلاله مدة التنفيذ. المقياس هو قيمة رقمية: حجم الاستجابة، معدل الأخطاء، السرعة بالبايت/ثانية. يمكن أن يحتوي كل تتبع على عدة مقاييس. يقوم SDK بجمع البيانات على الجهاز، وتخزينها مؤقتاً وإرسالها إلى Firebase في الخلفية بأولوية زمن وصول منخفضة لتجنب التأثير على تجربة المستخدم.

وفقاً لتقرير Google I/O 2024، يُستخدم Firebase Performance في أكثر من 2 مليون تطبيق حول العالم. متوسط وقت اكتشاف مشكلة أداء باستخدام Firebase Performance هو 15 دقيقة بعد الإصدار إذا تم تكوين التنبيهات. بدون مراقبة، يتم اكتشاف مشكلة مماثلة عادةً خلال 2-3 أيام من خلال شكاوى المستخدمين للدعم.

الفرق عن Firebase Crashlytics

Crashlytics يتتبع الأعطال والأخطاء الفادحة — الحالات التي ينتهي فيها التطبيق بشكل غير متوقع. Firebase Performance يراقب الأداء في تطبيق قيد التشغيل: الشاشات البطيئة، طلبات الشبكة الطويلة، تأخيرات استجابة واجهة المستخدم. Crashlytics يجيب على سؤال «لماذا تعطل التطبيق؟»، بينما Performance يجيب على «لماذا يعمل التطبيق ببطء؟». كلا الخدمتين تتكاملان من خلال SDK واحد (Firebase Core) ويتم عرض البيانات في أقسام متجاورة من وحدة تحكم Firebase.

مقاييس النسب المئوية

Firebase Performance لا يظهر القيم المتوسطة — فقط النسب المئوية: P50، P75، P90، P95، P99. هذا أمر بالغ الأهمية للأداء: الوقت المتوسط يخفي القيم المتطرفة. إذا فتح 99 مستخدم شاشة في 200 مللي ثانية وواحد فتحها في 20 ثانية، فإن المتوسط سيكون ~400 مللي ثانية، وهو ما يبدو مقبولاً. سيظهر P99 20 ثانية — المشكلة الحقيقية. يعرض Firebase النسب المئوية على خط زمني، مما يسمح بتتبع الانحدارات بدقة ساعة.

كيف يعمل Firebase Performance Monitoring

Firebase Performance SDK يتم دمجه في التطبيق من خلال التكامل القياسي: إضافة تبعية في Gradle (Android) أو عبر CocoaPods (iOS). بعد تهيئة Firebase في الكود، يبدأ SDK تلقائياً في جمع المقاييس دون تكوين إضافي. مبدأ مهم هو التجميع البطيء: SDK لا يرسل البيانات فوراً، بل يراكمها وينقلها على دفعات عند توفر ظروف شبكة مواتية.

لـ iOS، يستخدم SDK NSURLProtocol لاعتراض طلبات HTTP؛ لـ Android — OkHttp Interceptor. إذا كان التطبيق لا يستخدم OkHttp، يقوم SDK تلقائياً بتغليف HttpURLConnection. الطلبات المعترضة تُثرى بالبيانات الوصفية: Content-Type، حالة الاستجابة، الحجم بالبايت، المدة. جميع البيانات تُنقل عبر HTTPS إلى خادم Firebase بتشفير TLS 1.3.

أحد المتطلبات الرئيسية لـ Firebase Performance هو أن يكون آخر إضافة في قائمة إضافات Gradle. إذا تم انتهاك الترتيب، قد لا يعترض SDK جميع الطلبات أو قد يقيس وقت بدء التشغيل بشكل غير صحيح. توصي Firebase بوضع الإضافة في نهاية كتلة الإضافات، بعد Crashlytics وإضافات Google Services الأخرى.

// build.gradle (Module: app) — الترتيب الصحيح للإضافات
plugins {
    id "com.android.application"
    id "org.jetbrains.kotlin.android"
    id "com.google.gms.google-services"
    id "com.google.firebase.crashlytics"
    id "com.google.firebase.firebase-perf"  // آخر!
}

dependencies {
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-perf"
}

التتبعات التلقائية: الشاشات، بدء التشغيل، الشبكة

Firebase Performance ينشئ ثلاثة أنواع من التتبعات التلقائية: screen trace (وقت عرض الشاشة)، app start trace (وقت بدء تشغيل التطبيق) و network request trace (طلبات HTTP). يقيس screen trace لـ Android الوقت بين استدعاء Activity.onCreate واكتمال عرض الإطار الأول. لـ iOS، يُقاس الوقت بين viewDidLoad و viewDidAppear. ينشئ Firebase تلقائياً تتبعاً لكل شاشة، مستخدماً اسم فئة Activity أو ViewController.

App start trace ينقسم إلى نوعين: البدء من البارد (يبدأ التطبيق من الصفر، العملية لم تكن موجودة) والبدء من الدافئ (يتم استعادة التطبيق من حالة الخلفية). البدء من البارد هو المقياس الأكثر أهمية لأنه يشمل تهيئة جميع SDK، تحميل ملفات DEX وإنشاء أول Activity. يقيس Firebase البدء من البارد من لحظة بدء العملية حتى العرض الكامل للشاشة الأولى. وفقاً لتوصيات Google، يجب ألا يتجاوز البدء من البارد 500 مللي ثانية لـ P50 وثانيتين لـ P99.

Network request trace يسجل تلقائياً كل طلب HTTP مع البيانات الوصفية: URL، الطريقة، رمز الاستجابة، حجم الاستجابة، سرعة النقل. في وحدة تحكم Firebase Performance، يمكنك تصفية الطلبات حسب نمط URL — على سبيل المثال، إظهار جميع الطلبات إلى /api/v2/orders. لكل نمط، يتم عرض النسب المئوية لوقت الاستجابة ومعدلات الأخطاء 4xx/5xx. هذا يسمح باكتشاف تدهور API معين بسرعة دون إعداد تنبيهات فردية.

مقاييس الشاشات بالتفصيل

بالنسبة للشاشات، يحسب Firebase Performance بالإضافة إلى ذلك مقياس «الإطارات المجمدة» — الإطارات التي استغرقت أكثر من 700 مللي ثانية في العرض. يُنظر إلى هذه التجميدات في واجهة المستخدم من قبل المستخدم على أنها «التطبيق تجمد». إذا كانت الشاشة تحتوي على أكثر من 1% من الإطارات المجمدة، يضع Firebase علامة على المقياس كإشكالي. لـ Android، يقوم SDK أيضاً بجمع مقياس slow renders — الإطارات الأطول من 16 مللي ثانية (فقدان 60 إطاراً في الثانية). مزيج screen trace والإطارات المجمدة يعطي صورة كاملة عن وقت التحميل وسلاسة الرسوم المتحركة.

التتبعات المخصصة لسيناريوهات العمل

التتبعات المخصصة تسمح بقياس مدة أي سيناريو مستخدم: تقديم طلب، تحميل صورة إلى السحابة، مزامنة البيانات. يحدد المطور بداية ونهاية التتبع في الكود بشكل صريح ويحدد اسم السيناريو. على عكس التتبعات التلقائية، توفر التتبعات المخصصة تحكماً كاملاً فيما يتم قياسه وتسمح بإضافة سمات للتصفية.

يمكن أن يحتوي كل تتبع مخصص على سمات — أزواج مفتاح-قيمة تُضاف كبيانات وصفية. تساعد السمات في تقسيم البيانات: على سبيل المثال، يمكن تتبع وقت إتمام الطلب بشكل منفصل لـ «promo_user» و «regular_user». يدعم Firebase Performance ما يصل إلى 5 سمات لكل تتبع وما يصل إلى 100 قيمة سمة فريدة. يتم فهرسة السمات وتكون متاحة للتصفية في وحدة تحكم Firebase.

وفقاً لعرض Google I/O 2024، يستخدم فريق Spotify التتبعات المخصصة لـ Firebase لمراقبة وقت التبديل بين المسارات. ساعد ذلك في تقليل متوسط وقت التبديل من 400 مللي ثانية إلى 120 مللي ثانية من خلال تحديد اختناق في تخزين المخزن المؤقت للصوت المؤقت. كانت الرؤية الرئيسية هي التصفية حسب سمة «device_model» — ظهرت المشكلة فقط على أجهزة Samsung التي تعمل بنظام Android 13.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class CheckoutTracker {

    private val firebasePerf = FirebasePerformance.getInstance()

    fun trackCheckoutFlow(userId: String, promoApplied: Boolean) {
        val trace: Trace = firebasePerf.newTrace("checkout_flow")
        trace.putAttribute("promo_user", promoApplied.toString())
        trace.putAttribute("user_tier", "premium")
        trace.start()

        // تنفيذ سيناريو الطلب
        validateCart()
        processPayment()
        confirmOrder()

        trace.stop()
    }
}

دمج Firebase Performance في مشروع Android

يتطلب دمج Firebase Performance في Android ثلاث خطوات: إضافة إضافة google-services، ربط BOM (Bill of Materials) لـ Firebase وإضافة تبعية firebase-perf. يعمل Firebase Performance تلقائياً على جميع Activities والأجزاء إذا كانت تستخدم AppCompatActivity. لشاشات Compose، توصي Firebase باستخدام التتبعات المخصصة لأن screen trace التلقائي لا يدعم Compose مباشرة.

فارق دقيق مهم: إضافة Gradel الخاصة بـ Firebase Performance تعدل البايت كود للتطبيق في وقت الترجمة. تضيف الإضافة كوداً آلياً إلى كل Activity وOkHttp client. هذا قد يزيد وقت البناء بنسبة 5-10% وحجم APK بمقدار 200-400 كيلوبايت. في بنيات التصحيح، يتم تعطيل Firebase Performance تلقائياً — هذا يمنع تشويه المقاييس أثناء التطوير المحلي. للتفعيل الإجباري في وضع التصحيح، استخدم العلم firebasePerformanceInstrumentationEnabled في البيان.

Firebase Performance يدعم أيضاً MetricKit لـ iOS و Perfetto لـ Android — متتبعات نظام منخفضة المستوى. يوفر MetricKit بيانات عن معدل الإطارات واستخدام وحدة المعالجة المركزية والذاكرة على مستوى نظام التشغيل. يقوم Firebase بتجميع هذه البيانات وعرضها في نفس وحدة التحكم حيث تظهر تتبعات HTTP وscreen traces، مما يجمع بين القياس عن بعد للنظام والتطبيق في واجهة واحدة.

طلبات HTTP مع OkHttp

import okhttp3.OkHttpClient
import com.google.firebase.perf.network.FirebasePerfOkHttpClient

val client = OkHttpClient.Builder()
    .addInterceptor FirebasePerfOkHttpClient
    .build()

val request = Request.Builder()
    .url("https://api.example.com/orders")
    .build()

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(call: Call, e: IOException) { /* handle */ }
    override fun onResponse(call: Call, response: Response) { /* handle */ }
})

دمج Firebase Performance في مشروع iOS

لـ iOS، يتم دمج Firebase Performance من خلال CocoaPods أو Swift Package Manager. بعد تثبيت FirebasePerformance و FirebaseCore، يبدأ SDK تلقائياً في جمع المقاييس. لاعتراض طلبات HTTP، يستخدم Firebase Performance iOS NSURLProtocol — آلية نظام تسمح باعتراض جميع تحميلات URL في التطبيق. يسجل SDK فئته الفرعية NSURLProtocol عند بدء التشغيل، وجميع الطلبات عبر URLSession تقع تلقائياً تحت المراقبة.

قيود iOS: Firebase Performance لا يدعم screen trace التلقائي لـ SwiftUI. لتطبيقات SwiftUI، يجب إنشاء تتبعات مخصصة يدوياً عن طريق تغليف جسم View في كتلة بدء/إيقاف. تعمل Firebase على دعم SwiftUI الأصلي، ولكن حالياً يتتبع SDK تلقائياً فقط وحدات تحكم UIView. للتطبيقات الهجينة على UIKit + SwiftUI، يُنصح بإنشاء شاشات على UIKit وتضمين SwiftUI من خلال UIHostingController.

Firebase Performance iOS يوفر أيضاً تكاملاً مع MetricKit — إطار عمل Apple الذي يجمع بيانات تشخيصية على مستوى نظام التشغيل. يرسل MetricKit تقارير يومية بمقاييس وحدة المعالجة المركزية ووحدة معالجة الرسومات والذاكرة ومعدل الإطارات. يقوم Firebase Performance بتجميع هذه التقارير وعرضها في وحدة التحكم جنباً إلى جنب مع التتبعات المخصصة، مما يعطي صورة كاملة للأداء على مستوى التطبيق والنظام.

import FirebasePerformance

final class ImageUploadService {

    func uploadImage(_ data: Data, to url: URL) async throws {
        guard let trace = Performance.startTrace(name: "image_upload") else { return }
        trace?.setValue("image/jpeg", forAttribute: "content_type")
        trace?.setValue("\(data.count)", forAttribute: "file_size")

        var request = URLRequest(url: url)
        request.httpMethod = "POST"
        request.httpBody = data

        let (_, response) = try await URLSession.shared.data(for: request)
        guard let httpResponse = response as? HTTPURLResponse else { return }
        trace?.setValue("\(httpResponse.statusCode)",
                        forAttribute: "status_code")
        trace?.stop()
    }
}