Firebase Performance: bu nima, metrikalar va qanday kuzatish mumkin

Firebase Performance Monitoring nima

Firebase Performance Monitoring — mobil ilovalarning samaradorlik ko‘rsatkichlarini yig‘ish, jamlash va vizuallashtirish uchun SDK va bulut platformasi. SDK ilovaga o‘rnatiladi va avtomatik ravishda asosiy nuqtalarni instrumentatsiya qiladi: Activity (Android) yoki ViewController (iOS) hayot sikli, URLSession (iOS) yoki OkHttp (Android) orqali tarmoq so‘rovlari va tizim chaqiriqlari. Yig‘ilgan ma’lumotlar Firebase serveriga yuboriladi va ilova versiyalari, qurilmalar, davlatlar va boshqa atributlar bo‘yicha jamlanadi.

Performance SDK arxitekturasi minimal yuk printsipi asosida qurilgan: instrumentatsiya o‘lchanadigan operatsiyalar vaqtiga 1–2% dan ko‘p qo‘shmaydi. Ma’lumotlar asinxron tarzda yig‘iladi va yuborishdan oldin qurilmada buferlanadi, bu UI oqimining samaradorligiga ta’sirni yo‘q qiladi. Ma’lumotlarni yuborish jadval bo‘yicha (standart har 30 daqiqada) yoki 100 KB bufer hajmiga erishilganda amalga oshiriladi.

Firebase Performance-ni Android Studio (CPU Profiler) yoki Xcode Instruments profilchilaridan asosiy farqi ishlab chiqarish monitoringidir. Firebase Performance ma’lumotlarni faqat dasturchi qurilmalaridan emas, balki real foydalanuvchi qurilmalaridan yig‘adi. Bu faqat ma’lum modellar, OT versiyalari yoki muayyan mintaqalarda takrorlanadigan muammolarni aniqlash imkonini beradi — ya’ni boshqariladigan muhitda takrorlab bo‘lmaydigan muammolarni.

SDK kodni o‘zgartirmasdan ma’lumotlarni qanday yig‘adi

Avtomatik instrumentatsiya — Firebase Performance-ning asosiy xususiyati. Android uchun SDK avtomatik ravishda ActivityLifecycleCallbacks ni ro‘yxatdan o‘tkazadi va onCreate va onResume o‘rtasidagi vaqtni (ekran renderlash vaqti) o‘lchaydi. iOS uchun — viewDidLoad va viewDidAppear metodlarini swizzle qiladi. Tarmoq so‘rovlari OkHttpInterceptor (Android) yoki NSURLProtocol (iOS) darajasida ushlanadi. Dasturchi standart ko‘rsatkichlar uchun start/stop chaqiriqlarini qo‘shishi shart emas.

Performance SDK-ni yoqish va o‘chirish Google Services plagin (Android) yoki Info.plist (iOS) orqali boshqariladi. Nosozliklarni tuzatish uchun Performance SDK-ning verbose logini yoqish mumkin, bu qaysi ko‘rsatkichlar yig‘ilayotgani va yuborilayotganini ko‘rsatadi. Ishlab chiqarishda loglarni warning darajasida qoldirish tavsiya etiladi, chunki qo‘shimcha ma’lumot bilan loglarni tiqib qo‘ymaslik kerak. Flutter yoki React Native loyihalari uchun avtomatik instrumentatsiya cheklangan bo‘lishi mumkin — batafsil kod misollari bo‘limida.

Bepul cheklovlar va tariflar

Firebase Performance Spark bepul tarifida izlar soni yoki ma’lumot hajmi bo‘yicha cheklovlarsiz taklif etiladi. Blaze pullik tarifi ham Performance Monitoring uchun to‘lov olmaydi — bu ikkala tarifda ham to‘liq bepul bo‘lgan kam sonli Firebase xizmatlaridan biridir. Faqat bitta cheklov bor: ma’lumotlar 30 kun (Spark) va 365 kungacha (Blaze) saqlanadi. Uzoq muddatli tahlil uchun ma’lumotlarni BigQuery export orqali eksport qiling.

To‘lovsizligi Firebase Performance-ni prototipdan tortib millionlab foydalanuvchilari bo‘lgan enterprise ilovalargacha har qanday loyiha uchun ideal tanlovga aylantiradi. Yagona xarajat moddasi — Performance SDK ma’lumotlarining chiquvchi trafigi, ammo bu ilovaning boshqa tarmoq operatsiyalari bilan solishtirganda arzimas (qurilma uchun oyiga 1 MB dan kam). BigQuery export-da saqlash va so‘rovlar uchun to‘lov olinadi, ammo Performance SDK-ning o‘zi bepul.

Avtomatik metrikalar: kodsiz nima o‘lchanadi

Firebase Performance bir satr kod bo‘lmasdan besh turdagi ko‘rsatkichlarni avtomatik yig‘adi: ilovani ishga tushirish vaqti (app start), sekin so‘rovlar (slow HTTP requests), ekran renderlash tezligi (screen rendering), xotira iste‘moli (memory usage, faqat Android) va kadr chastotasi (frame rate, faqat Android). Ushbu ko‘rsatkichlar SDK ulangandan va birinchi foydalanuvchi sessiyasidan so‘ng darhol Firebase konsolida mavjud bo‘ladi.

App Start Time — jarayonni ishga tushirishdan UI to‘liq o‘zaro ta’sirga tayyor bo‘lgunga qadar bo‘lgan vaqt. Sovuq ishga tushirish (ilova noldan boshlanadi) va iliq ishga tushirish (ilova fon holatidan tiklanadi) ga bo‘linadi. Sovuq ishga tushirish DEX fayllarini yuklash, statik maydonlarni ishga tushirish, Application.onCreate va Activity.onCreate chaqirishni o‘z ichiga oladi. Firebase avtomatik ravishda ishga tushirish turini tasniflaydi va har bir tur uchun vaqt taqsimotini ko‘rsatadi.

Screen Rendering Time — ekranni yuklash boshlanishidan (Android uchun onCreate, iOS uchun viewDidLoad) ekran o‘zaro ta‘sirga tayyor bo‘lgunga qadar (onResume, viewDidAppear) bo‘lgan vaqt. Firebase har bir ekran uchun ma’lumotlarni jamlaydi (sinf nomi yoki custom screen name bo‘yicha), qaysi ekran eng uzoq yuklanayotganini aniqlash imkonini beradi. Android uchun qo‘shimcha ravishda dropped frames o‘lchanadi — ekran renderlash vaqtida o‘tkazib yuborilgan kadrlar soni (jank).

Tarmoq so‘rovlari (HTTP/HTTPS)

Performance SDK URLSession, OkHttp yoki URLConnection orqali ilovadan yuborilgan har bir HTTP/HTTPS so‘rovini avtomatik ravishda ushlaydi va o‘lchaydi. Har bir so‘rov uchun qayd etiladi: URL (xavfsizlik uchun query parametrlarsiz yo‘l), HTTP metodi, javob kodi, baytlardagi javob hajmi, so‘rov davomiyligi va ulanish tezligi (WiFi, Cellular). Ma’lumotlar Firebase konsolining „Network Requests” panelida jamlanadi.

Slow Requests — davomiyligi belgilangan chegaradan oshgan so‘rovlar. Standart „sekin so‘rov” chegarasi 4000 ms. Ushbu ko‘rsatkich server qismi bilan bog‘liq muammolarni aniqlash uchun juda muhim: backend yangilanishidan so‘ng sekin so‘rovlar soni 1% dan 15% gacha oshsa, bu server loglarini zudlik bilan tahlil qilish uchun signaldir. Foydalanuvchilar 5 soniyadan ko‘proq javob kutmaydi — Firebase ma’lumotlari shuni ko‘rsatadiki, agar so‘rov 3 soniyadan ko‘proq davom etsa, foydalanuvchilarning 53% ilovani yopadi.

Avtomatik instrumentatsiyaning cheklovlari

iOS cheklovlari: iOS-da Performance SDK dropped frames ni o‘lchay olmaydi (bu xususiy API). iOS-da jank ni o‘lchash uchun MetricKit yoki CADisplayLink dan foydalaning. Shuningdek iOS-da SDK URLSession dan foydalanmaydigan uchinchi tomon HTTP mijozlari (masalan, SwiftNIO) orqali amalga oshirilgan so‘rovlarni ushlamaydi. Bunday holatlar uchun HTTP atributlari bilan maxsus izlardan foydalaning.

Android cheklovlari: Android-da avtomatik xotira o‘lchovi faqat Android 8.0+ (API 26+) bo‘lgan qurilmalarda mavjud. Eski versiyalar uchun Debug.getMemoryInfo() orqali ma’lumotlarni olish bilan maxsus izlardan foydalaning. SDK shuningdek WebSocket ulanishlarini ushlamaydi — ular uchun alohida izlar kerak. Cheklovlarga qaramasdan, avtomatik ko‘rsatkichlar samaradorlik monitoringi ehtiyojlarining 80% ni qoplaydi.

Maxsus izlar va HTTP atributlari

Maxsus izlar (custom traces) — dasturchi tomonidan muayyan stsenariylarning samaradorligini o‘lchash uchun qo‘lda yaratilgan nomlangan vaqt intervallari: yangiliklar lentasini yuklash, tasvirni qayta ishlash, ma’lumotlarni sinxronlash, murakkab ma’lumotlar bazasi so‘rovini bajarish. Maxsus izlar avtomatik ko‘rsatkichlarni to‘ldiradi va dasturchi samaradorlik uchun muhim deb hisoblagan kod qismlarini o‘lchash imkonini beradi.

Har bir izning nomi (maksimum 100 belgi) va iz ichida qayd etiladigan 5 tagacha maxsus ko‘rsatkich (metrics) bo‘lishi mumkin. Masalan, „image_processing” izida „original_file_size” va „processed_file_size” ko‘rsatkichlarini o‘lchash mumkin. Ko‘rsatkichlar Firebase konsolida taqsimotlar (min, max, average, persentillar) shaklida ko‘rsatiladi, bu nafaqat davomiylikni, balki operatsiyaning xususiyatlarini ham tahlil qilish imkonini beradi.

HTTP atributlari — SDK tomonidan avtomatik ushlanmagan tarmoq so‘rovlari (masalan, WebSocket yoki uchinchi tomon kutubxonalari orqali) uchun maxsus iz turi. HTTP atributlari URL, HTTP metodi, javob kodi va javob hajmini o‘z ichiga oladi. Firebase ularni „Network Requests” bo‘limida avtomatik yig‘ilgan so‘rovlar bilan birga ko‘rsatadi va tarmoq o‘zaro ta‘sirining yagona rasmini ta’minlaydi.

Maxsus izlardan qachon foydalanish kerak

Maxsus izlar quyidagilarni o‘lchash uchun ajralmasdir: mahalliy ma’lumotlar bazasidan (Room, CoreData) ma’lumot yuklash vaqti, murakkab hisoblashlarning davomiyligi (shifrlash, siqish), animatsiyalar va o‘tishlar samaradorligi, uchinchi tomon SDK larining javob vaqti (xaritalar, to‘lovlar, analitika). Har bir bunday stsenariy uchun iz yarating, o‘lchanadigan kodni start/stop bilan o‘rab oling va keyingi segmentatsiya uchun atributlar qo‘shing.

Maxsus izlardan suiiste’mol qilmang. Har bir iz qo‘shimcha batareya va trafik sarfidir. Ishlab chiqarish versiyasida 10–15 dan ortiq faol iz bo‘lmasligi tavsiya etiladi. Nosozliklarni tuzatish uchun ko‘proq iz qo‘shish mumkin, ammo chiqarishdan oldin Remote Config orqali ortiqchalarini o‘chiring (performance_tracing_enabled bayrog‘idan foydalaning). Bu faqat tanlangan foydalanuvchilar yoki sessiyalar uchun batafsil kuzatishni yoqish imkonini beradi.

Segmentatsiya uchun iz atributlari

Maxsus atributlar (custom attributes) — Firebase konsolida keyingi filtrlash uchun izga qo‘shilishi mumkin bo‘lgan kalit-qiymat juftliklari. Masalan, „feed_load” iziga „feed_type” (main, explore, following) va „cache_status” (cold, warm) atributlarini qo‘shish mumkin. Konsolda iz ma’lumotlarini ushbu atributlar bo‘yicha filtrlash va qaysi lenta turi eng sekin yuklanayotganini aniqlash mumkin.

Cheklovlar: har bir iz 5 tagacha maxsus atributga ega bo‘lishi mumkin. Atribut qiymati 100 belgigacha bo‘lgan satrdir. Atributlar iz boshlanishidan oldin o‘rnatilishi kerak; boshlangandan so‘ng atributni o‘zgartirish e’tiborga olinmaydi. Bu cheklov samaradorlik bilan bog‘liq: boshlangandan so‘ng atributlarni o‘rnatish qo‘shimcha sinxronizatsiyani talab qiladi.

Samaradorlik chegaralari va ogohlantirishlar

Chegaralar (thresholds) — Firebase Performance oshib ketganda ogohlantirish yaratadigan sozlanishi mumkin bo‘lgan ko‘rsatkich chegara qiymatlari. Chegaralar Firebase konsolida (Performance > Thresholds bo‘limi) har bir avtomatik ko‘rsatkich uchun o‘rnatiladi: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Ilovaning barcha versiyalari uchun global yoki muayyan versiyalar uchun maxsus chegaralar o‘rnatilishi mumkin.

Ogohlantirishlar (alerts) — chegara oshib ketganda Firebase yuboradigan avtomatik bildirishnomalar. Ogohlantirishlar email, Slack webhook, PagerDuty yoki Cloud Functions (maxsus ishlov berish uchun) ga sozlanishi mumkin. Har bir ogohlantirishda: ko‘rsatkich nomi, joriy qiymat, chegara qiymati, ilova versiyasi, segment (qurilma, davlat) mavjud. Ogohlantirishlar foydalanuvchilarga ko‘rinmasdan oldin samaradorlik pasayishiga reaksiya berish imkonini beradi.

Tavsiya etilgan chegaralar sanoat standartiga ko‘ra (Google I/O 2025): sovuq ishga tushirish — 2 soniyadan kam, iliq ishga tushirish — 1 soniyadan kam, ekran renderi — 500 ms dan kam, HTTP so‘rov davomiyligi — 3000 ms dan kam (95-persentil), sekin so‘rovlar ulushi — 5% dan kam. Yuqori raqobatli ilovalar (Social, E-commerce) uchun maqsadli chegaralar qattiqroq bo‘lishi mumkin: sovuq ishga tushirish < 1.5 soniya, HTTP < 1000 ms.

Firebase konsolida chegaralarni sozlash

Firebase konsolida Performance bo‘limiga o‘ting, Thresholds varag‘ini oching. Har bir ko‘rsatkich uchun kerakli chegara qiymati va oshib ketish ta’sir qilishi kerak bo‘lgan foydalanuvchilar foizini o‘rnating. Masalan: „sovuq ishga tushirishni sekin deb hisoblaymiz, agar foydalanuvchilarning 10% dan ko‘pi uchun 2 soniyadan oshsa”. Firebase joriy ko‘rsatkich qiymatlari va oshib ketish tarixini ko‘rsatib, realistik chegaralarni tanlashga yordam beradi.

Muhim: chegaralar ma’lumot yig‘ishga ta’sir qilmaydi, ular faqat bildirishnomalarni yaratishni boshqaradi. Agar chegara juda past bo‘lsa (masalan, sovuq ishga tushirish 1 soniya, holbuki qurilmalarning 50% 3 soniyada ishga tushadi), ogohlantirishlar doimiy keladi va dasturchilar sezmaydigan ‘‘shovqin’‘ga aylanadi. Chegaralarni joriy ko‘rsatkichlar asosida o‘rnating, so‘ngra ilovani optimallashtirgan sari asta-sekin qattiqlashtiring.

Firebase konsolida Performance Dashboard

Performance Dashboard asosiy ko‘rsatkichlarni ilova versiyasi, qurilma, davlat, ulanish turi va OT versiyasi bo‘yicha bo‘linish bilan vaqt seriyalari shaklida ko‘rsatadi. Har bir ko‘rsatkich uchun mavjud: o‘rtacha qiymat, mediana, 95-persentil, 99-persentil. 95-persentil samaradorlikni baholash uchun eng informativ ko‘rsatkichdir, chunki u chetga chiqqan qiymatlarni e’tiborga olmagan holda ilovaning ‘‘zaif qurilmalarda’‘ qanday ishlashini ko‘rsatadi.

Dashboard versiyalarni taqqoslashni qo‘llab-quvvatlaydi: ko‘rsatkichlarni vizual taqqoslash uchun ikkita ilova versiyasini (joriy va oldingi) tanlang. Yangilanishdan so‘ng 95-persentil ishga tushirish vaqti 2.1 dan 3.4 soniyaga oshsa — regressiya aniq va sekinlashishga sabab bo‘lgan commitni topish kerak. Firebase Performance GitHub, GitLab va Bitbucket bilan integratsiyalashadi, bu ko‘rsatkich o‘zgarishlarini aniq commitlar bilan bog‘lash imkonini beradi.

Performance Monitoring uchun kod misollari

Kotlin tilidagi Android ilovasida Firebase Performance Monitoring integratsiya misollarini ko‘rib chiqamiz. Kod yangiliklar lentasini yuklashni o‘lchash uchun maxsus iz yaratish, avtomatik ushlanmagan so‘rov uchun HTTP atributi qo‘shish va tasvirni qayta ishlash vaqtini o‘lchash uchun Trace dan foydalanishni namoyish etadi. Barcha misollar Remote Config orqali kuzatishni o‘chirish imkoniyatini hisobga oladi.

Foydalanishdan oldin bog‘liqlikni qo‘shing: implementation("com.google.firebase:firebase-perf") Firebase BOM orqali. Avtomatik instrumentatsiya uchun qo‘shimcha sozlash talab qilinmaydi — SDK bog‘liqlik ulangandan so‘ng standart operatsiyalarni avtomatik ushlaydi.

Lentani yuklash uchun maxsus iz

Birinchi misol — serverdan yangiliklar lentasini yuklash vaqtini o‘lchash. Iz tarmoqdan ma’lumot oladigan va JSON ni tahlil qiladigan asinxron fetchFeed operatsiyasini o‘rab oladi. Izga maxsus atributlar qo‘shilgan: ma’lumot manbai (cache yoki network) va olingan postlar soni. Bu ma’lumotlarni segmentlash va lenta qanday sharoitda eng uzoq yuklanayotganini tushunish imkonini beradi.

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 funksiyasi iz atributi sifatida ishlatiladigan source („cache” yoki „network”) parametrini qabul qiladi. Asinxron operatsiya tugagandan so‘ng iz finally blokida to‘xtatiladi, bu istisno holatida ham to‘xtashni kafolatlaydi. items_count ko‘rsatkichi postlar sonining yuklash vaqtiga qanday ta‘sir qilishini tahlil qilish imkonini beradi. Firebase konsolida izlarni source atributi bo‘yicha filtrlash va tarmoqdan yuklash keshdan 3 baravar sekinroq ekanligini ko‘rish mumkin.

Nostandart so‘rov uchun HTTP atributi

Ikkinchi misol — WebSocket orqali amalga oshirilgan so‘rov uchun HTTP atributi (avtomatik ushlanmaydi). URL so‘rovini, uning metodini, javob kodini va hajmini qo‘lda ro‘yxatdan o‘tkazish imkonini beruvchi HttpMetric sinfi ishlatiladi. Firebase bu so‘rovni Network Requests bo‘limida avtomatik ushlanganlar bilan birga ko‘rsatadi.

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()
    }
}

Misolda sendWithHttpMetric nostandart HTTP chaqiruvini ro‘yxatdan o‘tkazish uchun newHttpMetric dan foydalanadi. SDK uni avtomatik ushlamaydi, shuning uchun dasturchi qo‘lda URL, metod, javob kodi va o‘lchamlarni o‘rnatadi. URL ni query parametrsiz o‘rnatish muhim (xavfsizlik va jamlash uchun) — ya’ni /data, /data?token=abc emas. Firebase avtomatik ravishda o‘xshash URL naqshlarini guruhlaydi.

Tasvirni qayta ishlash vaqtini o‘lchash

Uchinchi misol maxsus iz yordamida tasvirni qayta ishlash vaqtini (siqish, hajmni o‘zgartirish) o‘lchashni namoyish etadi. Bu holda iz sinxron operatsiyani o‘rab oladi, ammo ishlab chiqarish uchun UI oqimini bloklamaslik uchun korutinlar yoki RxJava dan foydalaning.

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 funksiyasi tasvirni 80% sifat bilan JPEG ga siqish vaqtini o‘lchaydi. format atributi kelajakda JPEG va WebP siqish vaqtlarini taqqoslash imkonini beradi. output_size_kb ko‘rsatkichi siqish qanchalik samarali ekanligini ko‘rsatadi. Firebase konsolida taqsimotni ko‘rish mumkin: zaif qurilmalarda (byudjet Android) siqish flagmanlarga qaraganda 4 baravar ko‘proq vaqt oladi, bu tasvirlarni serverga yuborishda kechikishlarga sabab bo‘lishi mumkin.

Ma’lumotlar asosida samaradorlikni qanday yaxshilash mumkin

Firebase Performance ma’lumotlarni taqdim etadi, ammo tayyor yechimlarni bermaydi. Ko‘rsatkichlarni tahlil qilish har bir ko‘rsatkich uchun samaradorlik pasayishining odatiy sabablarini tushunishni talab qiladi. Asosiy yomonlashish naqshlari va ularni Performance Monitoring ma’lumotlari asosida tashxislash usullarini ko‘rib chiqamiz. Yondashuv: ko‘rsatkichda anomaliya toping → odatiy sabablarni tekshiring → optimallashtirishni qo‘llang → natijani bir haftadan so‘ng tekshiring.

Sekin sovuq ishga tushirish (> 2 soniya): sabablar — Application.onCreate da SDK larning og‘ir ishga tushirilishi (analitika, crash reporting, map SDK), katta resurslarni yuklash (shriftlar, mavzular), ishga tushirish paytida asosiy oqimda sinxron operatsiyalar. Yechimlar: SDK larni kechiktirib ishga tushirish, resurslarni kechiktirilgan yuklash, ishga tushirish paytida placeholder ko‘rsatish uchun SplashScreen API (Android 12+) dan foydalanish. Firebase Performance ilovaning qaysi versiyasi sekinroq ishga tusha boshlaganini ko‘rsatadi — qanday bog‘liqliklar qo‘shilgani yoki yangilanganini tekshiring.

Sekin ekran renderi (> 500 ms): sabablar — murakkab View iyerarxiyasi (ichma-ich ConstraintLayout, ko‘p Fragment), UI oqimida ma’lumot yuklash (tarmoq yoki disk), og‘ir draw operatsiyalari (katta tasvirlar, maxsus View). Yechimlar: layout iyerarxiyasini optimallashtirish (Android Studio da Layout Inspector), ma’lumotlarni fon oqimiga o‘tkazish, Glide yoki Coil orqali tasvirlarni keshlash. Eng sekin ekranni topish va uni birinchi navbatda optimallashtirish uchun Firebase dagi Screen Rendering filtridan foydalaning.

Tarmoq so‘rovlarini optimallashtirish

Sekin HTTP so‘rovlari (> 3 soniya): sabablar — sekin server, katta payloadlar, keshning yo‘qligi, optimal bo‘lmagan protokol (HTTP/2 o‘rniga HTTP/1.1), DNS hal qilish. Yechimlar: server tomonini tekshiring (uptime, latency), javob hajmini kamaytiring (paginatsiya, GraphQL, JSON o‘rniga protobuf), HTTP sarlavhalari (Cache-Control) orqali keshlashni yoqing, timeaut va qayta urinish mantig‘ini qo‘shish uchun OkHttp Interceptor dan foydalaning.

Firebase Performance so‘rovning vaqt taqsimotini ko‘rsatadi: DNS hal qilish, TCP qo‘l siqish, TLS qo‘l siqish, so‘rov yuborish, javob olish. Vaqtning ko‘p qismi DNS ga to‘g‘ri kelsa — DNS oldindan yuklashdan foydalaning (OkHttp DNS-over-HTTPS). TLS ga to‘g‘ri kelsa — sessiyani qayta tiklash va cipher suites sozlashdan foydalaning. Javob olishga to‘g‘ri kelsa — javob hajmi va foydalanuvchi tarmoq tezligini tekshiring. Firebase ma’lumotlari faqat ‘‘so‘rov sekin’‘ demoq emas, balki protokol darajasida muammoni lokalizatsiya qilish imkonini beradi.

Kuzatishni o‘chirish uchun Remote Config integratsiyasi

Ishlab chiqarish uchun maxsus izlarni masofadan o‘chirish imkonini beruvchi performance_tracing_enabled Remote Config bayrog‘ini qo‘shish tavsiya etiladi. Agar Firebase Performance SDK mijozda juda ko‘p ma’lumot yaratsa yoki samaradorlikka ta’sir qilsa (zaif qurilmalarda), minimal yukga ega bo‘lgan faqat avtomatik ko‘rsatkichlarni qoldirib, barcha foydalanuvchilar uchun izlarni o‘chirish mumkin.

Mantiq misoli: ilova ishga tushganda Remote Config parametrini tekshiramiz performance_tracing_enabled. Agar false bo‘lsa — barcha Firebase.performance.newTrace() chaqiriqlari ma’lumot to‘plamaydigan stub obyektini qaytaradi. Bu iz yaratishdan oldin bayroqni tekshiradigan wrapper sinfi orqali amalga oshiriladi. Bunday yondashuv butun auditoriyaga ta’sir qilmasdan ma’lum foydalanuvchilar (beta testerlar, dasturchilar) uchun batafsil kuzatishni yoqish imkonini beradi.