Firebase Remote Config: bu nədir, parametrlər və uzaqdan necə idarə etmək olar

Firebase Remote Config nədir və necə işləyir

Firebase Remote Config Firebase server tərəfində açar-dəyər cütlərini saxlayan və onları sorğu əsasında və ya cədvəl üzrə klient cihazlara çatdıran xidmətdir. Hər bir parametrin adı (sətir), dəyəri (sətir, rəqəm, boolean və ya JSON) var və şərtlərə — konkret istifadəçinin hansı dəyəri alacağını müəyyən edən qaydalara bağlana bilər. Şərtlər tətbiq versiyasını, cihazın dilini, regionu, təsadüfi faizi və bir çox digər atributları yoxlaya bilər.

Remote Config-in arxitekturası push-pull modelinə əsaslanır, pull prioritetlidir. Klient dövri olaraq serverdən cari dəyərləri sorğulayır (standart olaraq hər 12 saatda). Lakin tərtibatçı koddan və ya Firebase konsolu vasitəsilə dərhal sinxronizasiyanı başlada bilər (“Publish changes” düyməsi). Dəyişikliklər dərc edildikdən sonra server Firebase Cloud Messaging vasitəsilə push bildirişi göndərir və tətbiq onu aldıqdan sonra parametrləri yenidən sorğulaya bilər.

Pulsuz tarif Firebase Remote Config-də parametrlərin və ya sorğuların sayında məhdudiyyət yoxdur, bu da onu digər Firebase xidmətlərindən fərqləndirir. Yeganə məhdudiyyət cavabın ölçüsüdür — 800 KB-dan çox olmamalıdır (bütün parametrlər üçün cəmi). Bu tipik ssenari üçün tam kifayətdir: əksər layihələr 10-50 parametrdən istifadə edir və onların ümumi həcmi nadir hallarda 100 KB-ı keçir.

Remote Config istifadəçiyə hansı dəyəri qaytaracağını necə müəyyən edir

Dəyər seçim mexanizmi şərtlərin prioritetinə əsaslanır. Hər bir şərt bir qaydanı təmsil edir (məsələn, “iOS versiya > 15.0”). Remote Config şərtləri prioritet sırası ilə yoxlayır və ilk uyğun şərtin dəyərini qaytarır. Heç bir şərt uyğun gəlmirsə, standart dəyər (default value) istifadə olunur. Bu mexanizm ən spesifikdən ən ümumiyə doğru qaydalar iyerarxiyası yaratmağa imkan verir.

Vacibdir: Firebase konsolunda şərtlərin sırası əhəmiyyətlidir. Əgər iki şərt eyni anda bir istifadəçiyə uyğun gələ bilərsə, siyahıda yuxarıda olan qalib gəlir. Daha spesifik şərtləri (məsələn, konkret tətbiq versiyası üçün) ümumi şərtlərdən (məsələn, “Bütün iOS istifadəçiləri”) yuxarıda yerləşdirmək tövsiyə olunur. Səhv sıra dar məqsədli dəyişikliyin heç vaxt tətbiq edilməməsinə səbəb ola bilər.

Keşləmə və parametrlərin ömür müddəti

Standart olaraq Remote Config serverdən alınan dəyərləri 12 saat keşləyir. Bu o deməkdir ki, konsolda dəyişikliklər dərc edildikdən sonra tətbiq onları 12 saatdan tez görməyəcək (və ya növbəti açıq fetch çağırışından sonra). Minimum keşləmə müddəti FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 3600) vasitəsilə təyin edilə bilər — istehsal üçün ən azı 1 saat tövsiyə olunur, serverə həddindən artıq sorğuların və istifadəçi trafikinin qarşısını almaq üçün.

İnkişaf zamanı dəyişiklikləri sınamaq üçün minimum intervalı 0 saniyə istifadə edin: FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 0). Bu rejimdə hər fetch çağırışı serverdən cari dəyərləri yükləyəcək. Buraxılışdan əvvəl istehsal intervalını geri qaytarmağı unutmamaq vacibdir, əks halda hər işə salınmada tətbiq serverə müraciət edərək xərcləri və batareya istehlakını artıracaq.

Parametrlər, şərtlər və istifadəçi qrupları

Remote Config parametri şərtlərdən asılı olaraq bir neçə dəyərdən birini qəbul edə bilən adlandırılmış dəyişəndir. Dəyər növləri: string, number (double), boolean, JSON object (seriyalaşdırılmış sətir). JSON parametrləri çoxlu ayrıca parametrlər yaratmadan strukturlu məlumatları ötürmək üçün əlverişlidir: məsələn, tətbiq mövzusu parametrləri olan obyekt (primaryColor, backgroundColor, fontSize).

Şərtlər (conditions) — istifadəçinin və ya cihazın atributlarını yoxlayan məntiqi qaydalar: OS versiyası (iOS, Android), tətbiq versiyası, ölkə, dil, istifadəçi auditoriyası (koddakı xassə), təsadüfi faiz (A/B testləri üçün). Şərtlər məntiqi AND ilə birləşdirilə bilər: məsələn, “tətbiq versiyası >= 5.0” VƏ “ölkə = Rusiya”. Hər bir parametrin qeyri-məhdud sayda şərti ola bilər, lakin praktikada 2-5 istifadə olunur.

Fərdiləşdirmə üçün istifadəçi xassələrindən (user properties) istifadə edin — Firebase Analytics vasitəsilə tətbiq kodunda təyin edilən atributlar. Məsələn, analytics.setUserProperty(“subscription_tier”, “premium”). Remote Config bu xassəni yoxlaya və premium istifadəçilər üçün xüsusi dəyərlər qaytara bilər. Remote Config vasitəsilə fərdiləşdirmə klient tərəfdə şərtlər yaratmağı tələb etmir — bütün məntiq bulud konsolunda cəmləşib.

İstifadəçi qrupları və seqmentasiya

Remote Config iki seqmentasiya modelini dəstəkləyir: atributlara əsaslanan (conditions) və Firebase Analytics xassələrinə əsaslanan (user properties). Birinci model statikdir: şərt sessiya və ya tətbiq versiyası daxilində dəyişməyən sabit atributu yoxlayır. İkinci model dinamikdir: xassə tətbiqin işinin istənilən anında təyin edilə bilər ki, bu da istifadəçiləri icra müddətində çevik seqmentləşdirməyə imkan verir.

Vacibdir: Remote Config-də user properties istifadə etmək üçün Firebase Analytics-i inteqrasiya etmək lazımdır. Bu tələb onunla bağlıdır ki, Remote Config istifadəçi məlumatlarını Analytics SDK-dan alır. Analytics olmadan Remote Config yalnız cihaz atributları ilə işləyir (OS versiyası, tətbiq versiyası, IP-dən ölkə). İstifadəçi davranışına əsaslanan fərdiləşdirmə (məsələn, “5 alış etdi”) yalnız Analytics vasitəsilə mümkündür.

Şablon versiyalaşdırması

Remote Config şablonu (template) bütün parametrlərin, şərtlərin və onların dəyərlərinin tam dəstidir. Firebase şablon dəyişikliklərinin tarixçəsini saxlayır və 90 gün ərzində istənilən əvvəlki versiyaya geri qayıtmağa imkan verir. Versiyalaşdırma kritik əhəmiyyətlidir: əgər dəyişikliklər dərc edildikdən sonra xəta aşkar edilərsə (məsələn, səhv parametr dəyəri UI-ni pozur), Firebase konsolu vasitəsilə şablonu dərhal əvvəlki işlək versiyaya qaytarmaq olar.

Şablondakı hər dəyişiklik (dərc) unikal nömrə ilə yeni versiya yaradır. Firebase konsolunda vaxt, istifadəçi və təsvir (doldurulubsa) göstərilməklə dəyişiklik jurnalı mövcuddur. Həmişə dərcə təsvir əlavə etmək tövsiyə olunur: “Yeni lent üçün iOS 10% test qrupu aktivləşdirildi”. Təsvir olmadan bir aydan sonra 42-ci versiyada nəyin dəyişdirildiyini xatırlamaq mümkün deyil.

Remote Config-i tətbiqə necə inteqrasiya etmək olar

Remote Config-in inteqrasiyası üç addımdan ibarətdir: SDK-nı parametrlərlə (keşləmə müddəti) işə salmaq, standart parametrləri (server əlçatmaz olduqda dəyərlər) təyin etmək və alınan dəyərlərin tətbiqi məntiqi. Standart parametrlər cihazın Firebase-ə qoşula bilməməsi halında (internet yoxdur, server əlçatmazdır) sığortadır. Default values olmadan tətbiq null istifadə edəcək və bu crash-a səbəb ola bilər.

Default values təyini iki yolla həyata keçirilir: proqram vasitəsilə setDefaultsAsync çağırışı ilə və ya XML faylı vasitəsilə. Proqram üsulu kiçik layihələr üçün əlverişlidir: bütün dəyərlər tətbiq başlayanda bir dəfə bilavasitə koddakı təyin edilir. Fayl üsulu onlarla parametri olan layihələr üçün üstünlük təşkil edir: dəyərlər resurslarda saxlanılır və yenidən kompilyasiya etmədən asanlıqla redaktə edilə bilər. Birləşdirmək tövsiyə olunur: əsas parametrlər XML-də, spesifik olanlar isə proqram vasitəsilə.

Asinxronluq — Remote Config SDK-nın əsas xüsusiyyətidir. fetchAndActivate() metodu serverə sorğunu fon axınında yerinə yetirir, UI-ni bloklamır. Yükləmə başa çatdıqdan sonra aktivasiya baş verir — parametr dəyərləri tətbiqin yaddaşında yenilənir. Başa çatmanı izləmək üçün dinləyicilərdən və ya korutinlərdən (Android/Kotlin-də) istifadə edin. İstifadəçi parametrlər yenilənərkən UI-nin “sıçramasını” görməməlidir — bütün dəyişikliklər hamar tətbiq edilməlidir.

onComplete və dinləyicilərlə işə salma

İlk işə salınmada Remote Config SDK tətbiqin işə salınmasını bloklamır. Sinxronizasiya baş verərkən tətbiq standart dəyərlərdən istifadə edir. Bu o deməkdir ki, istifadəçi ilk işə salınmada köhnə interfeysi görə bilər, fetch başa çatdıqdan sonra isə yenisini. Kritik parametrlər üçün (məsələn, iş qabiliyyətindən asılı olan serverUrl), nəticəni gözləyən sinxron aktivasiyadan istifadə edin.

Tövsiyə olunan təcrübə: tətbiq ilk ekranı göstərməzdən əvvəl cari parametrləri əldə etməsi kritikdirsə, minimal gecikmə ilə yükləmə ekranı göstərin. Yükləmə ekranında 5 saniyə timeout ilə fetchAndActivate işə salınır. Əgər 5 saniyə ərzində parametrlər yüklənməzsə, tətbiq default values ilə başlayır. Bu, internet olmadıqda sonsuz gözləmənin qarşısını alır.

JSON parametrləri ilə iş

JSON parametrləri Remote Config bir dəyərlə strukturlu məlumatları ötürməyə imkan verir. Məsələn, mövzu stilləri olan obyekt: {“primaryColor”: “#6200EE”, “borderRadius”: 8, “fontFamily”: “Roboto”}. Klient tərəfdə JSON parse edilir və UI-ə tətbiq olunur. Üstünlükləri: üç əvəzinə bir parametr, yeniləmənin atomarlığı (hər üç sahə eyni anda yenilənir), təmiz konsol. Çatışmazlıq: Firebase konsolunda oxunma çətinliyi (JSON sətir kimi göstərilir).

Tövsiyə: məntiqi əlaqəli dəyər qrupları üçün JSON parametrlərindən istifadə edin ki, onlar birlikdə yenilənir (mövzular, ekran konfiqurasiyası, şəbəkə parametrləri). Müstəqil parametrlər üçün (feature toggle, serverUrl) ayrıca sətir və ya boolean parametrlərdən istifadə edin — onları konsolda oxumaq və şablon versiya tarixçəsində dəyişiklikləri izləmək daha asandır.

Remote Config ilə A/B testi

A/B testi — Firebase Remote Config-in daxili imkanıdır, istifadəçiləri qruplara bölməyə, hər qrup üçün müxtəlif parametr dəyərləri təyin etməyə və dəyişikliklərin seçilmiş metrikalara təsirini ölçməyə imkan verir. random_percent ilə şərtlər vasitəsilə əl ilə bölmədən fərqli olaraq, Firebase Analytics ilə inteqrasiya avtomatik olaraq hər eksperimental qrup üzrə statistika toplayır və fərqlərin statistik əhəmiyyətini göstərir.

A/B test prosesi: tərtibatçı Firebase konsolunda (A/B Testing bölməsi) eksperiment yaradır, Remote Config parametrini seçir, nəzarət və test qrupları üçün dəyərlər təyin edir və hədəf metrikanı müəyyən edir (məsələn, conversion rate və ya revenue). Firebase avtomatik olaraq istifadəçiləri qruplara bölür, məlumat toplayır və 2-4 həftə sonra p-value ilə nəticə göstərir. Nəticə birmənalı olarsa, eksperimenti vaxtından əvvəl dayandırmaq olar.

Statistik əhəmiyyət — eksperimenti dayandırmaq üçün əsas meyardır. Firebase A/B Testing Frequentist yanaşmasından istifadə edir və hər metrika üçün p-value göstərir. Standart əhəmiyyət həddi 0.05-dir (95% etibarlılıq ehtimalı). Bu həddə qruplardan birinin xeyrinə çatdıqda Firebase eksperimenti dayandırmağı və dəyişiklikləri bütün istifadəçilərə tətbiq etməyi tövsiyə edir. Əgər 4 həftədən sonra əhəmiyyət əldə edilməzsə, eksperiment nəticəsiz sayılır.

Eksperiment növləri

Firebase A/B Testing iki növ eksperimenti dəstəkləyir: klassik A/B (bir parametrin iki dəyərinin müqayisəsi) və çoxvariantlı A/B/n (üç və daha çox dəyərin müqayisəsi). Çoxvariantlı testlər üçün statistik əhəmiyyətə çatmaq üçün daha çox istifadəçi tələb olunur. A/B/n-dən yalnız 3-5 variantı olan parametrlər üçün istifadə etmək tövsiyə olunur, burada hər variant digərlərindən köklü şəkildə fərqlənir.

Eksperimentin müddəti trafikin həcmindən asılıdır: gündə 1000 aktiv istifadəçisi olan tətbiqlər üçün minimum müddət 2 həftə, 100 000 istifadəçisi olan tətbiqlər üçün 3-5 gündür. Firebase avtomatik olaraq lazımi vaxtı hesablayır və cari trafikin əhəmiyyətli fərqləri aşkar etmək üçün kifayət etmədiyi halda xəbərdarlıq edir. Vacibdir: hesablanmış müddətdən əvvəl eksperimenti dayandırmayın, hətta nəticə aydın görünsə belə — bu klassik “peeking” səhvdir.

A/B testi üçün metrikalar

Hədəf metrikalar Firebase A/B Testing-də Firebase Analytics hadisələri əsasında müəyyən edilir. Standart metrikalar mövcuddur: daily active users, revenue, conversion rate, retention, user engagement. Əlavə parametrlərlə istənilən Analytics hadisəsi əsasında fərdi metrika da yaradıla bilər. Məsələn, “Ödəniş ekranına çatan istifadəçilərin faizi” metriki screen_view hadisəsindən screen_name = “payment” parametri ilə yaradılır.

Eksperimentin uğuru haqqında qərar vermək üçün bir əsas metrika (primary metric) seçmək və əlavə analiz üçün 2-3 ikinci dərəcəli metrika seçmək tövsiyə olunur. Bir neçə əsas metrika seçmək yalançı müsbət nəticə riskini artırır (multiple comparison problem). Seçilmiş əsas metrika statistik əhəmiyyətli yaxşılaşma göstərməzsə, ikinci dərəcəli metrikalar yaxşılaşsa belə, eksperiment uğursuz sayılır.

Kotlin-də Remote Config üçün kod nümunələri

Remote Config inteqrasiyasını Kotlin-də Android tətbiqində nəzərdən keçirək. Nümunələrə fərdi keşləmə müddəti ilə SDK-nın işə salınması, müxtəlif növ parametrlərin alınması, klient tərəfdə A/B şərtinin tətbiqi və server əlçatmaz olduqda xəta idarəsi daxildir. Bütün kod main activity və ya Application sinfində icra olunur ki, parametrlər tətbiqin ən əvvəlindən əlçatan olsun.

İstifadədən əvvəl asılılığı əlavə edin: implementation(“com.google.firebase:firebase-config”) Firebase BOM vasitəsilə. Firebase Analytics-in də qoşulduğuna əmin olun, çünki Remote Config istifadəçi xassələrini ötürmək üçün Analytics-dən istifadə edir.

Parametrlərin işə salınması və alınması

Birinci nümunə — Remote Config-in əsas qurulumu, istehsal üçün minimum fetch intervalı 1 saat. SDK Application sinfinin onCreate metodunda işə salınır. fetchAndActivate-dən sonra welcome_message parametrinin dəyəri yoxlanılır, bu parametr qarşılama ekranı üçün uzaqdan dəyişdirilə bilər.

class MainApp : Application() {

    override fun onCreate() {
        super.onCreate()
        val remoteConfig = Firebase.remoteConfig
        val settings = FirebaseRemoteConfigSettings.Builder()
            .setMinimumFetchIntervalInSeconds(3600)
            .build()

        remoteConfig.setConfigSettingsAsync(settings)
        remoteConfig.setDefaultsAsync(
            R.xml.remote_config_defaults
        )

        remoteConfig.fetchAndActivate()
            .addOnCompleteListener { task ->
                if (task.isSuccessful) {
                    val welcomeMsg = remoteConfig
                        .getString("welcome_message")
                    Log.d("RemoteConfig", welcomeMsg)
                }
            }
    }
}

Nümunədə setDefaultsAsync XML faylından res/xml/remote_config_defaults.xml default values yükləyir. Əgər fetch xəta ilə başa çatarsa (şəbəkə yoxdur, server əlçatmazdır), tətbiq bu dəyərlərdən istifadə edəcək. XML faylı Firebase konsolunda olduğu kimi eyni parametr adlarını ehtiva edir: <entry key=“welcome_message”>Xoş gəldiniz!</entry>. Bütün Remote Config parametrləri üçün həmişə default values olması tövsiyə olunur.

Remote Config ilə feature toggle

İkinci nümunə — feature toggle (funksiyanı aktivləşdirmə bayrağı). new_checkout_enabled parametri boolean tipinə malikdir. Dəyər true olarsa, tətbiq yeni sifariş ekranını göstərir, false olarsa — köhnəsini. Feature toggle Remote Config-in ən populyar ssenarisidir: dəyişiklik yalnız bir parametrə təsir edir, məntiqin dəyişdirilməsini tələb etmir və dərhal geri qaytarıla bilər.

fun isFeatureEnabled(paramName: String): Boolean {
    return Firebase.remoteConfig
        .getBoolean(paramName)
}

// Activity-də istifadə
if (isFeatureEnabled("new_checkout_enabled")) {
    navigateToNewCheckout()
} else {
    navigateToLegacyCheckout()
}

isFeatureEnabled funksiyası Remote Config-ə girişi inkapsulyasiya edir və mock vasitəsilə asanlıqla test edilə bilər. Feature toggles üçün adlandırma konvensiyasından istifadə etmək tövsiyə olunur: feature_, ff_ və ya flag_ prefiksi, Firebase konsolunda parametrin məqsədinin dərhal aydın olması üçün. Nümunə: feature_new_onboarding, ff_dark_mode, flag_v3_api. 3 aydan çox aktivləşdirmə/deaktiv etmə üçün bayraq parametrlərindən istifadə etməyin — ölü bayraqların yığılması texniki xidməti çətinləşdirir.

JSON mövzu konfiqurasiyasının alınması

Üçüncü nümunə — tətbiq mövzusu parametrləri ilə JSON parametrinin alınması. app_theme parametri primaryColor, borderRadius və fontFamily ilə JSON obyektini ehtiva edir. Klient tərəfdə JSON Gson və ya kotlinx.serialization istifadə edərək parse edilir və dəyərlər UI-ə tətbiq olunur. Bu yanaşma dizaynerlərə tərtibatçının iştirakı olmadan və buraxılış etmədən tətbiq mövzusunu dəyişməyə imkan verir.

data class AppTheme(
    val primaryColor: String = "#6200EE",
    val borderRadius: Int = 8,
    val fontFamily: String = "Roboto"
)

fun getAppTheme(): AppTheme {
    val json = Firebase.remoteConfig
        .getString("app_theme")
    return Gson().fromJson(json, AppTheme::class.java)
}

JSON ilə iş diqqət tələb edir: Firebase konsolundakı JSON səhv olarsa (məsələn, vergül buraxılıbsa), parse xəta ilə başa çatacaq və tətbiq cari mövzu əvəzinə default values alacaq. Dərc etməzdən əvvəl JSON sətirlərini JSON validator vasitəsilə yoxlamaq tövsiyə olunur. İstehsal üçün parse zamanı try-catch əlavə edin və xətaları Firebase Crashlytics vasitəsilə qeyd edin.

Ən yaxşı təcrübələr və məhdudiyyətlər

Firebase Remote Config güclü alətdir, lakin səhv istifadə edildikdə performans, davranışın proqnozlaşdırıla bilməsi və təhlükəsizliklə bağlı problemlərə səbəb ola bilər. Xidmətlə işləyərkən tipik səhvlərdən qaçmağa kömək edəcək əsas təcrübələri və tətbiq arxitekturasını layihələndirərkən nəzərə alınmalı məhdudiyyətləri nəzərdən keçirək.

Həssas məlumatlardan çəkinin — Remote Config sirləri (API açarları, tokenlər, parollar) saxlamaq üçün nəzərdə tutulmayıb. Bütün parametr dəyərləri klient kodu üçün əlçatandır və tətbiq yaddaşından çıxarıla bilər. Məxfi məlumatlar üçün server yoxlaması ilə Cloud Functions və ya Secret Manager istifadə edin. Remote Config-də yalnız ictimai parametrləri saxlayın: mətnlər, bayraqlar, UI parametrləri, ictimai endpoint URL-ləri.

Hər dəyişikliyi sınayın bütün auditoriyaya dərc etməzdən əvvəl. Yeni dəyərin crash-a səbəb olmadığını və göstərilməni pozmadığını yoxlamaq üçün A/B testi və ya kiçik faizlə (1-5% istifadəçi) dərc etmədən istifadə edin. Remote Config-in staging mühiti yoxdur — bütün dəyişikliklər dərhal istehsala dərc olunur. Təhlükəsiz dərcin yeganə yolu tədricən yaymadır.

Platforma məhdudiyyətləri: maksimum parametr sayı — 2000 (bütün növlər üçün), bir dəyərin maksimum ölçüsü — 256 KB, server cavabının ümumi ölçüsü — 800 KB. Remote Config-də istifadə edilə bilən istifadəçi xassələrinin (user properties) sayı 25 ilə məhdudlaşır. Minimum fetch intervalı — 0 saniyə (sazlama üçün), lakin həddindən artıq istifadə Cloud Functions limitini aşa bilər (dəqiqədə layihə üzrə 30 000 sorğu).