Firebase Performance: چیست، معیارها و چگونگی ردیابی

Firebase Performance Monitoring چیست

Firebase Performance Monitoring یک SDK و پلتفرم ابری برای جمع‌آوری، تجمیع و تجسم معیارهای عملکرد برنامه‌های موبایل است. SDK در برنامه جاسازی شده و به طور خودکار نقاط کلیدی را ابزار دقیق می‌کند: چرخه حیات Activity (Android) یا ViewController (iOS)، درخواست‌های شبکه از طریق URLSession (iOS) یا OkHttp (Android) و فراخوانی‌های سیستمی. داده‌های جمع‌آوری شده به سرور Firebase ارسال می‌شوند و بر اساس نسخه‌های برنامه، دستگاه‌ها، کشورها و سایر ویژگی‌ها تجمیع می‌گردند.

معماری Performance SDK بر اساس اصل حداقل سربار ساخته شده است: ابزار دقیق بیش از 1–2% به زمان اجرای عملیات‌های اندازه‌گیری شده اضافه نمی‌کند. داده‌ها به صورت ناهمگام جمع‌آوری و قبل از ارسال روی دستگاه بافر می‌شوند که تأثیر بر عملکرد رشته UI را از بین می‌برد. ارسال داده‌ها طبق برنامه (به طور پیش‌فرض هر 30 دقیقه) یا پس از رسیدن بافر به 100 کیلوبایت انجام می‌شود.

تفاوت کلیدی Firebase Performance با پروفایلرهای Android Studio (CPU Profiler) یا Xcode Instruments نظارت بر تولید است. Firebase Performance داده‌ها را از دستگاه‌های واقعی کاربران جمع‌آوری می‌کند، نه فقط از دستگاه‌های توسعه‌دهنده. این امکان شناسایی مشکلاتی را فراهم می‌کند که فقط در مدل‌های خاص، نسخه‌های سیستم عامل یا مناطق خاص رخ می‌دهند — یعنی مشکلاتی که در محیط کنترل‌شده قابل تکرار نیستند.

SDK چگونه بدون تغییر کد داده جمع‌آوری می‌کند

ابزار دقیق خودکار ویژگی اصلی Firebase Performance است. برای Android، SDK به طور خودکار ActivityLifecycleCallbacks را ثبت کرده و زمان بین onCreate و onResume (زمان رندر صفحه) را اندازه‌گیری می‌کند. برای iOS — متدهای viewDidLoad و viewDidAppear را swizzle می‌کند. درخواست‌های شبکه در سطح OkHttpInterceptor (Android) یا NSURLProtocol (iOS) رهگیری می‌شوند. توسعه‌دهنده نیازی به اضافه کردن فراخوانی‌های start/stop برای معیارهای استاندارد ندارد.

فعال و غیرفعال کردن Performance SDK از طریق پلاگین Google Services (Android) یا Info.plist (iOS) مدیریت می‌شود. برای اشکال‌زدایی می‌توان ثبت وقایع verbose Performance SDK را فعال کرد که نشان می‌دهد چه معیارهایی جمع‌آوری و ارسال می‌شوند. در تولید توصیه می‌شود ثبت وقایع را در سطح warning نگه دارید تا لاگ‌ها با اطلاعات اضافی شلوغ نشوند. برای پروژه‌های Flutter یا React Native، ابزار دقیق خودکار ممکن است محدود باشد — جزئیات بیشتر در بخش نمونه کدها.

محدودیت‌های رایگان و تعرفه‌ها

Firebase Performance در تعرفه رایگان Spark بدون محدودیت در تعداد ردیابی‌ها یا حجم داده ارائه می‌شود. تعرفه پولی Blaze نیز برای Performance Monitoring هزینه‌ای دریافت نمی‌کند — این یکی از معدود سرویس‌های Firebase است که در هر دو تعرفه کاملاً رایگان است. فقط یک محدودیت وجود دارد: داده‌ها به مدت 30 روز (Spark) و تا 365 روز (Blaze) ذخیره می‌شوند. برای تحلیل بلندمدت داده‌ها را از طریق BigQuery export صادر کنید.

رایگان بودن Firebase Performance را به انتخاب ایده‌آلی برای هر پروژه‌ای — از نمونه اولیه تا برنامه enterprise با میلیون‌ها کاربر — تبدیل می‌کند. تنها هزینه، ترافیک خروجی داده‌های Performance SDK است، اما در مقایسه با سایر عملیات‌های شبکه برنامه ناچیز است (کمتر از 1 مگابایت در ماه برای هر دستگاه). در BigQuery export هزینه ذخیره‌سازی و پرس‌وجو اعمال می‌شود، اما خود Performance SDK رایگان است.

معیارهای خودکار: چه چیزی بدون کد اندازه‌گیری می‌شود

Firebase Performance به طور خودکار پنج دسته معیار را بدون حتی یک خط کد جمع‌آوری می‌کند: زمان راه‌اندازی برنامه (app start)، درخواست‌های کند (slow HTTP requests)، سرعت رندر صفحات (screen rendering)، مصرف حافظه (memory usage، فقط Android) و نرخ فریم (frame rate، فقط Android). این معیارها بلافاصله پس از اتصال SDK و اولین جلسه کاربر در کنسول Firebase در دسترس هستند.

App Start Time — زمان از راه‌اندازی فرآیند تا آمادگی کامل UI برای تعامل. به راه‌اندازی سرد (برنامه از صفر شروع می‌شود) و راه‌اندازی گرم (برنامه از حالت پس‌زمینه بازیابی می‌شود) تقسیم می‌شود. راه‌اندازی سرد شامل بارگذاری فایل‌های DEX، مقداردهی اولیه فیلدهای ایستا، فراخوانی Application.onCreate و Activity.onCreate است. Firebase به طور خودکار نوع راه‌اندازی را طبقه‌بندی کرده و توزیع زمان را برای هر نوع نشان می‌دهد.

Screen Rendering Time — زمان از شروع بارگذاری صفحه (onCreate برای Android، viewDidLoad برای iOS) تا زمانی که صفحه برای تعامل آماده می‌شود (onResume، viewDidAppear). Firebase داده‌ها را برای هر صفحه (بر اساس نام کلاس یا custom screen name) تجمیع می‌کند و امکان تعیین کندترین صفحه را فراهم می‌کند. برای Android additionally dropped frames اندازه‌گیری می‌شود — تعداد فریم‌های جاافتاده در هنگام رندر صفحه (jank).

درخواست‌های شبکه (HTTP/HTTPS)

Performance SDK به طور خودکار هر درخواست HTTP/HTTPS ارسال شده از برنامه از طریق URLSession، OkHttp یا URLConnection را رهگیری و اندازه‌گیری می‌کند. برای هر درخواست ثبت می‌شود: URL (مسیر بدون پارامترهای query برای امنیت)، روش HTTP، کد پاسخ، اندازه پاسخ بر حسب بایت، مدت‌زمان درخواست و سرعت اتصال (WiFi، Cellular). داده‌ها در داشبورد „Network Requests” کنسول Firebase تجمیع می‌شوند.

Slow Requests — درخواست‌هایی که مدت‌زمان آنها از آستانه تعیین‌شده فراتر می‌رود. آستانه پیش‌فرض „درخواست کند” 4000 میلی‌ثانیه است. این معیار برای شناسایی مشکلات سمت سرور حیاتی است: اگر پس از به‌روزرسانی بک‌اند تعداد درخواست‌های کند از 1% به 15% افزایش یابد، این سیگنالی برای تحلیل فوری لاگ‌های سرور است. کاربران بیش از 5 ثانیه منتظر پاسخ نمی‌مانند — داده‌های Firebase نشان می‌دهد که اگر درخواست بیش از 3 ثانیه طول بکشد، 53% کاربران برنامه را می‌بندند.

محدودیت‌های ابزار دقیق خودکار

محدودیت‌های iOS: در iOS، Performance SDK نمی‌تواند dropped frames را اندازه‌گیری کند (این یک API خصوصی است). برای اندازه‌گیری jank در iOS از MetricKit یا CADisplayLink استفاده کنید. همچنین در iOS، SDK درخواست‌های انجام شده از طریق کلاینت‌های HTTP شخص ثالث که از URLSession استفاده نمی‌کنند (مانند SwiftNIO) را رهگیری نمی‌کند. برای چنین مواردی از ردیابی‌های سفارشی با ویژگی‌های HTTP استفاده کنید.

محدودیت‌های Android: در Android، اندازه‌گیری خودکار حافظه فقط در دستگاه‌های با Android 8.0+ (API 26+) در دسترس است. برای نسخه‌های قدیمی‌تر از ردیابی‌های سفارشی با دریافت داده از طریق Debug.getMemoryInfo() استفاده کنید. SDK همچنین اتصالات WebSocket را رهگیری نمی‌کند — برای آنها ردیابی‌های جداگانه‌ای نیاز است. با وجود محدودیت‌ها، معیارهای خودکار 80% نیازهای نظارت بر عملکرد را پوشش می‌دهند.

ردیابی‌های سفارشی و ویژگی‌های HTTP

ردیابی‌های سفارشی (custom traces) بازه‌های زمانی نام‌گذاری شده‌ای هستند که توسعه‌دهنده به صورت دستی برای اندازه‌گیری عملکرد سناریوهای خاص ایجاد می‌کند: بارگذاری فید اخبار، پردازش تصویر، همگام‌سازی داده‌ها، اجرای پرس‌وجوی پیچیده پایگاه داده. ردیابی‌های سفارشی معیارهای خودکار را تکمیل کرده و امکان اندازه‌گیری بخش‌هایی از کد را فراهم می‌کنند که توسعه‌دهنده آنها را برای عملکرد حیاتی می‌داند.

هر ردیابی یک نام (حداکثر 100 کاراکتر) دارد و می‌تواند تا 5 معیار (metrics) سفارشی داشته باشد — مقادیر عددی که در داخل ردیابی ثبت می‌شوند. به عنوان مثال، در ردیابی „image_processing” می‌توان معیارهای „original_file_size” و „processed_file_size” را اندازه‌گیری کرد. معیارها در کنسول Firebase به صورت توزیع‌ها (min, max, average, percentiles) نمایش داده می‌شوند که امکان تحلیل نه تنها مدت‌زمان، بلکه ویژگی‌های عملیات را فراهم می‌کند.

ویژگی‌های HTTP نوع خاصی از ردیابی‌های سفارشی برای درخواست‌های شبکه‌ای هستند که به طور خودکار توسط SDK رهگیری نشده‌اند (مانند WebSocket یا کتابخانه‌های شخص ثالث). ویژگی‌های HTTP شامل URL، روش HTTP، کد پاسخ و اندازه پاسخ هستند. Firebase آنها را در بخش „Network Requests” همراه با درخواست‌های جمع‌آوری شده خودکار نمایش می‌دهد و تصویری یکپارچه از تعاملات شبکه ارائه می‌کند.

چه زمانی از ردیابی‌های سفارشی استفاده کنیم

ردیابی‌های سفارشی برای اندازه‌گیری موارد زیر ضروری هستند: زمان بارگذاری داده از پایگاه داده محلی (Room، CoreData)، مدت‌زمان محاسبات پیچیده (رمزنگاری، فشرده‌سازی)، عملکرد انیمیشن‌ها و انتقال‌ها، زمان پاسخ SDKهای شخص ثالث (نقشه‌ها، پرداخت‌ها، تحلیل). برای هر چنین سناریویی یک ردیابی ایجاد کنید، کد اندازه‌گیری‌شده را در start/stop قرار دهید و برای بخش‌بندی بعدی ویژگی‌هایی اضافه کنید.

زیاد از ردیابی‌های سفارشی استفاده نکنید. هر ردیابی مصرف اضافی باتری و ترافیک است. توصیه می‌شود بیش از 10–15 ردیابی فعال در نسخه تولیدی برنامه نداشته باشید. برای اشکال‌زدایی می‌توان ردیابی‌های بیشتری اضافه کرد، اما قبل از انتشار موارد اضافی را از طریق Remote Config غیرفعال کنید (از پرچم performance_tracing_enabled استفاده کنید). این امکان را فراهم می‌کند که ردیابی جزئی فقط برای کاربران یا جلسات انتخاب شده فعال شود.

ویژگی‌های ردیابی برای بخش‌بندی

ویژگی‌های سفارشی (custom attributes) جفت‌های کلید-مقداری هستند که می‌توان برای فیلتر کردن بعدی در کنسول Firebase به ردیابی اضافه کرد. به عنوان مثال، به ردیابی „feed_load” می‌توان ویژگی‌های „feed_type” (main, explore, following) و „cache_status” (cold, warm) را اضافه کرد. در کنسول می‌توان داده‌های ردیابی را بر اساس این ویژگی‌ها فیلتر کرده و تعیین کرد کدام نوع فید کندترین بارگذاری را دارد.

محدودیت‌ها: هر ردیابی می‌تواند تا 5 ویژگی سفارشی داشته باشد. مقدار ویژگی رشته‌ای تا 100 کاراکتر است. ویژگی‌ها باید قبل از شروع ردیابی تنظیم شوند؛ تغییر ویژگی پس از شروع نادیده گرفته می‌شود. این محدودیت به عملکرد مربوط است: تعیین ویژگی‌ها پس از شروع نیاز به همگام‌سازی اضافی دارد.

آستانه‌های عملکرد و هشدارها

آستانه‌ها (thresholds) مقادیر مرزی قابل تنظیم معیارها هستند که Firebase Performance پس از فراتر رفتن از آنها هشدار تولید می‌کند. آستانه‌ها در کنسول Firebase (بخش Performance > Thresholds) برای هر معیار خودکار تنظیم می‌شوند: app start time (cold/warm)، screen rendering time، slow HTTP requests، HTTP response time. می‌توان آستانه‌های سراسری برای همه نسخه‌های برنامه یا آستانه‌های خاص برای نسخه‌های مشخص تعیین کرد.

هشدارها (alerts) اعلان‌های خودکاری هستند که Firebase پس از فراتر رفتن از آستانه ارسال می‌کند. هشدارها را می‌توان برای ایمیل، Slack webhook، PagerDuty یا Cloud Functions (برای پردازش سفارشی) تنظیم کرد. هر هشدار شامل: نام معیار، مقدار فعلی، مقدار آستانه، نسخه برنامه، بخش (دستگاه، کشور) است. هشدارها امکان واکنش به کاهش عملکرد را قبل از اینکه برای کاربران قابل توجه شود فراهم می‌کنند.

آستانه‌های توصیه شده بر اساس استاندارد صنعتی (Google I/O 2025): راه‌اندازی سرد — کمتر از 2 ثانیه، راه‌اندازی گرم — کمتر از 1 ثانیه، رندر صفحه — کمتر از 500 میلی‌ثانیه، مدت‌زمان درخواست HTTP — کمتر از 3000 میلی‌ثانیه (صدک 95)، سهم درخواست‌های کند — کمتر از 5%. برای برنامه‌های با رقابت بالا (Social، E-commerce) آستانه‌های هدف می‌توانند سخت‌تر باشند: راه‌اندازی سرد < 1.5 ثانیه، HTTP < 1000 میلی‌ثانیه.

تنظیم آستانه‌ها در کنسول Firebase

در کنسول Firebase به بخش Performance رفته، برگه Thresholds را باز کنید. برای هر معیار مقدار آستانه مورد نظر و درصد کاربرانی که فراتر رفتن باید روی آنها تأثیر بگذارد را تعیین کنید. به عنوان مثال: “راه‌اندازی سرد را کند در نظر می‌گیریم اگر برای بیش از 10٪ کاربران از 2 ثانیه فراتر رود.” Firebase مقادیر فعلی معیارها و تاریخچه فراتر رفتن را برای کمک به انتخاب آستانه‌های واقع‌بینانه نشان می‌دهد.

مهم: آستانه‌ها بر جمع‌آوری داده‌ها تأثیر نمی‌گذارند، آنها فقط تولید اعلان‌ها را مدیریت می‌کنند. اگر آستانه خیلی پایین باشد (مثلاً راه‌اندازی سرد 1 ثانیه، در حالی که 50% دستگاه‌ها در 3 ثانیه راه‌اندازی می‌شوند)، هشدارها مدام می‌رسند و به “نویز” تبدیل می‌شوند که توسعه‌دهندگان متوجه آن نمی‌شوند. آستانه‌ها را بر اساس شاخص‌های فعلی تنظیم کنید، سپس با بهینه‌سازی برنامه تدریجاً آنها را سخت‌تر کنید.

داشبورد Performance در کنسول Firebase

داشبورد Performance معیارهای کلیدی را به صورت سری‌های زمانی با تفکیک بر اساس نسخه برنامه، دستگاه، کشور، نوع اتصال و نسخه سیستم عامل نمایش می‌دهد. برای هر معیار در دسترس هستند: میانگین، میانه، صدک 95، صدک 99. صدک 95 آموزنده‌ترین معیار برای ارزیابی عملکرد است زیرا نشان می‌دهد برنامه چگونه روی “دستگاه‌های ضعیف” کار می‌کند و مقادیر پرت را نادیده می‌گیرد.

داشبورد از مقایسه نسخه‌ها پشتیبانی می‌کند: دو نسخه از برنامه (فعلی و قبلی) را برای مقایسه بصری معیارها انتخاب کنید. اگر پس از به‌روزرسانی صدک 95 زمان راه‌اندازی از 2.1 به 3.4 ثانیه افزایش یافته باشد — پسرفت آشکار است و باید کامیتی که باعث کندی شده پیدا شود. Firebase Performance با GitHub، GitLab و Bitbucket ادغام می‌شود که امکان ارتباط تغییرات معیارها با کامیت‌های خاص را فراهم می‌کند.

نمونه کدهای Performance Monitoring

نمونه‌های ادغام Firebase Performance Monitoring در برنامه Android با زبان Kotlin را بررسی می‌کنیم. کد ایجاد یک ردیابی سفارشی برای اندازه‌گیری بارگذاری فید اخبار، افزودن ویژگی HTTP برای درخواست غیرخودکار رهگیری‌شده و استفاده از Trace برای اندازه‌گیری زمان پردازش تصویر را نشان می‌دهد. همه نمونه‌ها امکان غیرفعال کردن ردیابی از طریق Remote Config را در نظر می‌گیرند.

قبل از استفاده وابستگی را اضافه کنید: implementation("com.google.firebase:firebase-perf") از طریق Firebase BOM. برای ابزار دقیق خودکار پیکربندی اضافی لازم نیست — SDK پس از اتصال وابستگی به طور خودکار عملیات‌های استاندارد را رهگیری می‌کند.

ردیابی سفارشی برای بارگذاری فید

اولین نمونه — اندازه‌گیری زمان بارگذاری فید اخبار از سرور. ردیابی عملیات ناهمگام fetchFeed را که داده‌ها را از شبکه دریافت و JSON را تجزیه می‌کند، در بر می‌گیرد. به ردیابی ویژگی‌های سفارشی اضافه شده است: منبع داده (cache یا network) و تعداد پست‌های دریافت شده. این امکان بخش‌بندی داده‌ها و درک شرایطی که فید کندترین بارگذاری را دارد فراهم می‌کند.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

تابع loadFeedWithTrace پارامتر source (“cache” یا “network”) را دریافت می‌کند که به عنوان ویژگی ردیابی استفاده می‌شود. پس از تکمیل عملیات ناهمگام، ردیابی در بلوک finally متوقف می‌شود و حتی در صورت استثنا توقف تضمین می‌شود. معیار items_count امکان تحلیل تأثیر تعداد پست‌ها بر زمان بارگذاری را فراهم می‌کند. در کنسول Firebase می‌توان ردیابی‌ها را بر اساس ویژگی source فیلتر کرده و دید که بارگذاری از شبکه 3 برابر کندتر از حافظه پنهان است.

ویژگی HTTP برای درخواست غیراستاندارد

دومین نمونه — ویژگی HTTP برای درخواست انجام شده از طریق WebSocket (که به طور خودکار رهگیری نمی‌شود). از کلاس HttpMetric استفاده می‌شود که امکان ثبت دستی درخواست URL، روش آن، کد پاسخ و اندازه را فراهم می‌کند. Firebase این درخواست را در بخش Network Requests همراه با درخواست‌های خودکار رهگیری‌شده نمایش می‌دهد.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

در نمونه sendWithHttpMetric از newHttpMetric برای ثبت فراخوانی HTTP غیراستاندارد استفاده می‌کند. SDK آن را به طور خودکار رهگیری نمی‌کند، بنابراین توسعه‌دهنده به صورت دستی URL، روش، کد پاسخ و اندازه‌ها را تنظیم می‌کند. مهم است URL را بدون پارامترهای query تنظیم کنید (برای امنیت و تجمیع) — یعنی /data، نه /data?token=abc. Firebase به طور خودکار الگوهای URL مشابه را گروه‌بندی می‌کند.

اندازه‌گیری زمان پردازش تصویر

سومین نمونه اندازه‌گیری زمان پردازش تصویر (فشرده‌سازی، تغییر اندازه) را با استفاده از ردیابی سفارشی نشان می‌دهد. در این مورد ردیابی یک عملیات همگام را در بر می‌گیرد، اما برای تولید از کوروتین‌ها یا RxJava استفاده کنید تا رشته UI مسدود نشود.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

تابع compressImage زمان فشرده‌سازی تصویر به JPEG با کیفیت 80% را اندازه‌گیری می‌کند. ویژگی format امکان مقایسه آینده زمان فشرده‌سازی JPEG در مقابل WebP را فراهم می‌کند. معیار output_size_kb نشان می‌دهد که فشرده‌سازی چقدر مؤثر است. در کنسول Firebase می‌توان توزیع را مشاهده کرد: در دستگاه‌های ضعیف (Android ارزان‌قیمت) فشرده‌سازی 4 برابر بیشتر از دستگاه‌های پرچمدار زمان می‌برد که می‌تواند دلیل تأخیر در ارسال تصاویر به سرور باشد.

چگونه عملکرد را بر اساس داده‌ها بهبود دهیم

Firebase Performance داده‌ها را ارائه می‌دهد اما راه‌حل‌های آماده ارائه نمی‌کند. تحلیل معیارها نیاز به درک علل معمول کاهش عملکرد برای هر معیار دارد. الگوهای اصلی بدتر شدن و روش‌های تشخیص آنها بر اساس داده‌های Performance Monitoring را بررسی می‌کنیم. رویکرد: ناهنجاری در معیار پیدا کنید → علل معمول را بررسی کنید → بهینه‌سازی را اعمال کنید → نتیجه را یک هفته بعد بررسی کنید.

راه‌اندازی سرد کند (> 2 ثانیه): علل — مقداردهی سنگین SDK در Application.onCreate (تحلیل، crash reporting، map SDK)، بارگذاری منابع بزرگ (فونت‌ها، تم‌ها)، عملیات همگام در رشته اصلی هنگام راه‌اندازی. راه‌حل‌ها: مقداردهی تنبل SDK، بارگذاری تأخیری منابع، استفاده از SplashScreen API (Android 12+) برای نمایش placeholder هنگام مقداردهی. Firebase Performance نشان می‌دهد کدام نسخه برنامه کندتر راه‌اندازی شده است — بررسی کنید چه وابستگی‌هایی اضافه یا به‌روزرسانی شده‌اند.

رندر کند صفحه (> 500 میلی‌ثانیه): علل — سلسله‌مراتب پیچیده View (ConstraintLayout تو در تو، Fragment زیاد)، بارگذاری داده در رشته UI (شبکه یا دیسک)، عملیات draw سنگین (تصاویر بزرگ، View سفارشی). راه‌حل‌ها: بهینه‌سازی سلسله‌مراتب layout (Layout Inspector در Android Studio)، انتقال داده به رشته پس‌زمینه، ذخیره‌سازی تصاویر از طریق Glide یا Coil. از فیلتر Screen Rendering در Firebase استفاده کنید تا کندترین صفحه را پیدا کرده و ابتدا آن را بهینه‌سازی کنید.

بهینه‌سازی درخواست‌های شبکه

درخواست‌های HTTP کند (> 3 ثانیه): علل — سرور کند، payload بزرگ، عدم ذخیره‌سازی، پروتکل غیربهینه (HTTP/1.1 به جای HTTP/2)، حل DNS. راه‌حل‌ها: سمت سرور را بررسی کنید (uptime, latency)، اندازه پاسخ را کاهش دهید (صفحه‌بندی، GraphQL، protobuf به جای JSON)، ذخیره‌سازی را از طریق هدرهای HTTP (Cache-Control) فعال کنید، از OkHttp Interceptor برای افزودن زمان‌بندی و منطق تلاش مجدد استفاده کنید.

Firebase Performance توزیع زمان درخواست را نشان می‌دهد: حل DNS، دست‌دهی TCP، دست‌دهی TLS، ارسال درخواست، دریافت پاسخ. اگر بیشتر زمان صرف DNS می‌شود — از پیش‌بارگذاری DNS استفاده کنید (OkHttp DNS-over-HTTPS). اگر صرف TLS می‌شود — از session resumption و تنظیم cipher suites استفاده کنید. اگر صرف دریافت پاسخ می‌شود — اندازه پاسخ و سرعت شبکه کاربر را بررسی کنید. داده‌های Firebase امکان مکان‌یابی مشکل در سطح پروتکل را فراهم می‌کنند، نه فقط گفتن “درخواست کند است”.

ادغام Remote Config برای غیرفعال کردن ردیابی

برای تولید توصیه می‌شود یک پرچم Remote Config performance_tracing_enabled اضافه کنید که امکان غیرفعال کردن از راه دور ردیابی‌های سفارشی را فراهم می‌کند. اگر Firebase Performance SDK در سمت کلاینت داده‌های زیادی تولید کند یا روی عملکرد تأثیر بگذارد (در دستگاه‌های ضعیف)، می‌توان ردیابی‌ها را برای همه کاربران غیرفعال کرد و فقط معیارهای خودکار را که سربار حداقلی دارند باقی گذاشت.

نمونه منطق: هنگام راه‌اندازی برنامه پارامتر Remote Config performance_tracing_enabled را بررسی می‌کنیم. اگر false باشد — همه فراخوانی‌های Firebase.performance.newTrace() یک شیء stub برمی‌گردانند که داده جمع‌آوری نمی‌کند. این از طریق یک کلاس wrapper که قبل از ایجاد ردیابی پرچم را بررسی می‌کند پیاده‌سازی می‌شود. چنین رویکردی امکان فعال‌سازی ردیابی جزئی برای کاربران خاص (تست‌کنندگان بتا، توسعه‌دهندگان) بدون تأثیر بر کل مخاطب را فراهم می‌کند.