Firebase Remote Config: چیست، پارامترها و نحوه مدیریت از راه دور

Firebase Remote Config چیست و چگونه کار می‌کند

Firebase Remote Config سرویسی است که جفت‌های کلید-مقدار را در سمت سرور Firebase ذخیره می‌کند و آنها را به درخواست یا طبق برنامه به دستگاه‌های کلاینت تحویل می‌دهد. هر پارامتر دارای یک نام (رشته)، مقدار (رشته، عدد، boolean یا JSON) است و می‌تواند به شرایط — قوانینی که تعیین می‌کنند یک کاربر خاص چه مقداری دریافت کند — متصل شود. شرایط می‌توانند نسخه برنامه، زبان دستگاه، منطقه، درصد تصادفی و بسیاری از ویژگی‌های دیگر را بررسی کنند.

معماری Remote Config بر مدل push-pull با اولویت pull ساخته شده است. کلاینت به صورت دوره‌ای مقادیر به‌روز را از سرور درخواست می‌کند (به صورت پیش‌فرض هر ۱۲ ساعت). با این حال، توسعه‌دهنده می‌تواند همگام‌سازی فوری را در کد یا از طریق کنسول Firebase (دکمه «Publish changes») آغاز کند. پس از انتشار تغییرات، سرور از طریق Firebase Cloud Messaging یک اعلان push ارسال می‌کند و برنامه پس از دریافت آن می‌تواند پارامترها را مجدداً درخواست کند.

تعرفه رایگان Firebase Remote Config محدودیتی در تعداد پارامترها یا درخواست‌ها ندارد که آن را از سایر سرویس‌های Firebase متمایز می‌کند. تنها محدودیت اندازه پاسخ است که نباید از ۸۰۰ کیلوبایت تجاوز کند (مجموع برای همه پارامترها). این برای سناریوی معمولی کاملاً کافی است: اکثر پروژه‌ها از ۱۰ تا ۵۰ پارامتر استفاده می‌کنند و حجم کل آنها به ندرت از ۱۰۰ کیلوبایت فراتر می‌رود.

Remote Config چگونه تعیین می‌کند چه مقداری به کاربر برگرداند

مکانیسم انتخاب مقدار بر اساس اولویت شرایط است. هر شرط یک قانون را نشان می‌دهد (مثلاً «iOS نسخه > ۱۵.۰»). Remote Config شرایط را به ترتیب اولویت آنها بررسی می‌کند و مقدار اولین شرط منطبق را برمی‌گرداند. اگر هیچ شرطی منطبق نباشد، از مقدار پیش‌فرض (default value) استفاده می‌شود. این مکانیسم امکان ایجاد سلسله‌مراتب قوانین را فراهم می‌کند: از خاص‌ترین به عمومی‌ترین.

مهم: ترتیب شرایط در کنسول Firebase اهمیت دارد. اگر دو شرط بتوانند همزمان برای یک کاربر منطبق شوند، شرطی که در لیست بالاتر است برنده می‌شود. توصیه می‌شود شرایط خاص‌تر (مثلاً برای نسخه خاصی از برنامه) را بالای شرایط عمومی (مثلاً «همه کاربران iOS») قرار دهید. ترتیب نادرست می‌تواند باعث شود که یک تغییر هدفمند هرگز اعمال نشود.

ذخیره‌سازی موقت و طول عمر پارامترها

به صورت پیش‌فرض Remote Config مقادیر دریافت شده از سرور را به مدت ۱۲ ساعت ذخیره می‌کند. این بدان معناست که پس از انتشار تغییرات در کنسول، برنامه آنها را زودتر از ۱۲ ساعت بعد (یا پس از فراخوانی صریح بعدی fetch) مشاهده خواهد کرد. حداقل زمان ذخیره‌سازی موقت را می‌توان از طریق FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 3600) تنظیم کرد — برای تولید حداقل ۱ ساعت توصیه می‌شود تا از درخواست‌های اضافی به سرور و مصرف ترافیک کاربر جلوگیری شود.

برای تست تغییرات در طول توسعه از حداقل فاصله ۰ ثانیه استفاده کنید: FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 0). در این حالت هر فراخوانی fetch مقادیر جاری را از سرور بارگذاری می‌کند. مهم است که قبل از انتشار، فاصله تولیدی را بازگردانید، در غیر این صورت برنامه در هر بار اجرا به سرور متصل می‌شود و هزینه‌ها و مصرف باتری را افزایش می‌دهد.

پارامترها، شرایط و گروه‌های کاربران

پارامتر Remote Config یک متغیر نام‌گذاری شده است که می‌تواند بسته به شرایط یکی از چندین مقدار را بگیرد. انواع مقادیر: string، number (double)، boolean، JSON object (رشته سریال‌سازی شده). پارامترهای JSON برای انتقال داده‌های ساختاریافته بدون ایجاد پارامترهای جداگانه متعدد مفید هستند: به عنوان مثال، یک شی با تنظیمات تم برنامه (primaryColor، backgroundColor، fontSize).

شرایط (conditions) قوانین منطقی هستند که ویژگی‌های کاربر یا دستگاه را بررسی می‌کنند: نسخه سیستم عامل (iOS، Android)، نسخه برنامه، کشور، زبان، گروه کاربری (ویژگی تعریف شده در کد)، درصد تصادفی (برای آزمایش‌های A/B). شرایط می‌توانند از طریق AND منطقی ترکیب شوند: مثلاً «نسخه برنامه >= ۵.۰» و «کشور = روسیه». هر پارامتر می‌تواند تعداد نامحدودی شرط داشته باشد، اما در عمل از ۲ تا ۵ شرط استفاده می‌شود.

برای شخصی‌سازی از ویژگی‌های کاربر (user properties) استفاده کنید — ویژگی‌هایی که در کد برنامه از طریق Firebase Analytics تنظیم می‌شوند. به عنوان مثال، analytics.setUserProperty(«subscription_tier», «premium»). Remote Config می‌تواند این ویژگی را بررسی کرده و مقادیر خاص کاربران premium را برگرداند. شخصی‌سازی از طریق Remote Config نیازی به ایجاد شرایط در سمت کلاینت ندارد — تمام منطق در کنسول ابری متمرکز است.

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

Remote Config از دو مدل بخش‌بندی پشتیبانی می‌کند: مبتنی بر ویژگی‌ها (conditions) و مبتنی بر ویژگی‌های Firebase Analytics (user properties). مدل اول ایستا است: شرط یک ویژگی ثابت را بررسی می‌کند که در طول جلسه یا نسخه برنامه تغییر نمی‌کند. مدل دوم پویا است: ویژگی می‌تواند در هر لحظه از اجرای برنامه تنظیم شود که امکان بخش‌بندی انعطاف‌پذیر کاربران را در زمان اجرا فراهم می‌کند.

مهم: برای استفاده از user properties در Remote Config باید Firebase Analytics را یکپارچه کنید. این الزام به این دلیل است که Remote Config داده‌های کاربر را از Analytics SDK دریافت می‌کند. بدون Analytics، Remote Config فقط با ویژگی‌های دستگاه کار می‌کند (نسخه سیستم عامل، نسخه برنامه، کشور از IP). شخصی‌سازی مبتنی بر رفتار کاربر (مثلاً «۵ خرید انجام داده است») فقط از طریق Analytics در دسترس است.

نسخه‌بندی الگو

الگوی Remote Config (template) مجموعه کاملی از تمام پارامترها، شرایط و مقادیر آنهاست. Firebase تاریخچه تغییرات الگو را ذخیره می‌کند و امکان بازگشت به هر نسخه قبلی را در عرض ۹۰ روز فراهم می‌کند. نسخه‌بندی بسیار مهم است: اگر پس از انتشار تغییرات خطایی کشف شود (مثلاً مقدار نادرست پارامتر رابط کاربری را خراب می‌کند)، می‌توان از طریق کنسول Firebase فوراً الگو را به نسخه کار قبلی بازگرداند.

هر تغییر الگو (انتشار) یک نسخه جدید با شماره منحصر به فرد ایجاد می‌کند. در کنسول Firebase یک گزارش تغییرات با ذکر زمان، کاربر و توضیحات (در صورت پر شدن) در دسترس است. توصیه می‌شود همیشه توضیحاتی به انتشار اضافه کنید: «فید جدید را برای iOS ۱۰٪ گروه آزمایشی فعال کردیم». بدون توضیح پس از یک ماه نمی‌توان به خاطر آورد که دقیقاً در نسخه ۴۲ چه چیزی تغییر کرده است.

نحوه پیاده‌سازی Remote Config در برنامه

پیاده‌سازی Remote Config از سه مرحله تشکیل شده است: راه‌اندازی SDK با تنظیمات (زمان ذخیره‌سازی موقت)، تعریف پارامترهای پیش‌فرض (مقادیر در صورت عدم دسترسی به سرور) و منطق اعمال مقادیر دریافت شده. پارامترهای پیش‌فرض یک بیمه برای مواقعی هستند که دستگاه نمی‌تواند به Firebase متصل شود (عدم اینترنت، سرور در دسترس نیست). بدون default values برنامه از null استفاده می‌کند که می‌تواند منجر به crash شود.

تعریف default values به دو روش انجام می‌شود: برنامه‌نویسی از طریق فراخوانی setDefaultsAsync یا از طریق فایل XML. روش برنامه‌نویسی برای پروژه‌های کوچک مناسب است: همه مقادیر یک بار در زمان راه‌اندازی برنامه مستقیماً در کد تنظیم می‌شوند. روش فایل‌محور برای پروژه‌های با ده‌ها پارامتر ترجیح داده می‌شود: مقادیر در منابع ذخیره می‌شوند و بدون کامپایل مجدد به راحتی قابل ویرایش هستند. توصیه می‌شود ترکیب کنید: تنظیمات پایه در XML و تنظیمات خاص به صورت برنامه‌نویسی.

ناهمزمانی — ویژگی کلیدی Remote Config SDK است. متد fetchAndActivate() درخواست را به سرور در پس‌زمینه انجام می‌دهد و رابط کاربری را مسدود نمی‌کند. پس از اتمام بارگذاری، فعال‌سازی انجام می‌شود — مقادیر پارامترها در حافظه برنامه به‌روز می‌شوند. برای پیگیری اتمام از شنونده‌ها یا کوروتین‌ها (در Android/Kotlin) استفاده کنید. کاربر نباید «جهش» رابط کاربری را هنگام به‌روزرسانی پارامترها ببیند — همه تغییرات باید نرم اعمال شوند.

راه‌اندازی با onComplete و شنونده‌ها

در اولین اجرا Remote Config SDK راه‌اندازی برنامه را مسدود نمی‌کند. در طول همگام‌سازی، برنامه از مقادیر پیش‌فرض استفاده می‌کند. این بدان معناست که کاربر ممکن است در اولین اجرا نسخه قدیمی رابط کاربری را ببیند و پس از اتمام fetch — نسخه جدید. برای پارامترهای حیاتی (مثلاً serverUrl که عملکرد به آن بستگی دارد)، از فعال‌سازی همزمان با انتظار برای نتیجه استفاده کنید.

روش توصیه شده: نمایش صفحه بارگذاری با حداقل تأخیر، اگر برنامه قبل از نمایش اولین صفحه به دریافت پارامترهای به‌روز نیاز حیاتی دارد. در صفحه بارگذاری، fetchAndActivate با زمان انتظار ۵ ثانیه اجرا می‌شود. اگر در عرض ۵ ثانیه پارامترها بارگذاری نشدند، برنامه با default values شروع می‌شود. این کار از انتظار بی‌نهایت در صورت عدم وجود اینترنت جلوگیری می‌کند.

کار با پارامترهای JSON

پارامترهای JSON Remote Config امکان انتقال داده‌های ساختاریافته با یک مقدار را فراهم می‌کنند. به عنوان مثال، یک شی با سبک‌های تم: {«primaryColor»: «#6200EE», «borderRadius»: ۸, «fontFamily»: «Roboto»}. در سمت کلاینت JSON تجزیه شده و روی UI اعمال می‌شود. مزایا: یک پارامتر به جای سه، اتمی بودن به‌روزرسانی (هر سه فیلد همزمان به‌روز می‌شوند)، کنسول تمیز. نقطه ضعف: دشواری خواندن در کنسول Firebase (JSON به صورت رشته نمایش داده می‌شود).

توصیه: از پارامترهای JSON برای گروه‌های مقادیر منطقی مرتبط که با هم به‌روز می‌شوند استفاده کنید (تم‌ها، تنظیمات صفحه، تنظیمات شبکه). برای پارامترهای مستقل (feature toggle، serverUrl) از پارامترهای رشت‌ای یا boolean جداگانه استفاده کنید — خواندن آنها در کنسول آسان‌تر است و پیگیری تغییرات در تاریخچه نسخه‌های الگو ساده‌تر است.

آزمایش A/B با Remote Config

آزمایش A/B — یک قابلیت داخلی Firebase Remote Config است که به شما امکان می‌دهد کاربران را به گروه‌ها تقسیم کنید، برای هر گروه مقادیر مختلف پارامترها تعیین کنید و تأثیر تغییرات را بر معیارهای انتخاب شده اندازه‌گیری کنید. برخلاف تقسیم دستی از طریق شرایط با random_percent، یکپارچه‌سازی با Firebase Analytics به طور خودکار آمار هر گروه آزمایشی را جمع‌آوری می‌کند و معناداری آماری تفاوت‌ها را نشان می‌دهد.

فرآیند آزمایش A/B: توسعه‌دهنده در کنسول Firebase (بخش A/B Testing) یک آزمایش ایجاد می‌کند، یک پارامتر Remote Config را انتخاب می‌کند، مقادیر را برای گروه کنترل و آزمایش تعیین می‌کند و معیار هدف را مشخص می‌کند (مثلاً conversion rate یا revenue). Firebase به طور خودکار کاربران را بین گروه‌ها توزیع می‌کند، داده‌ها را جمع‌آوری می‌کند و پس از ۲ تا ۴ هفته نتیجه را با p-value نشان می‌دهد. اگر نتیجه واضح باشد، می‌توان آزمایش را زودتر متوقف کرد.

معناداری آماری — معیار اصلی توقف آزمایش است. Firebase A/B Testing از رویکرد Frequentist استفاده می‌کند و p-value را برای هر معیار نشان می‌دهد. آستانه معناداری استاندارد ۰.۰۵ است (احتمال اطمینان ۹۵٪). هنگام رسیدن به این آستانه به نفع یکی از گروه‌ها، Firebase توصیه می‌کند آزمایش را متوقف کرده و تغییرات را برای همه کاربران اعمال کند. اگر پس از ۴ هفته معناداری حاصل نشود، آزمایش غیرقطعی تلقی می‌شود.

انواع آزمایش‌ها

Firebase A/B Testing از دو نوع آزمایش پشتیبانی می‌کند: A/B کلاسیک (مقایسه دو مقدار یک پارامتر) و A/B/n چندمتغیره (مقایسه سه یا چند مقدار). برای آزمایش‌های چندمتغیره کاربران بیشتری برای دستیابی به معناداری آماری مورد نیاز است. توصیه می‌شود از A/B/n فقط برای پارامترهای با ۳ تا ۵ گزینه استفاده کنید، جایی که هر گزینه تفاوت اساسی با سایرین دارد.

مدت زمان آزمایش به حجم ترافیک بستگی دارد: برای برنامه‌های با ۱۰۰۰ کاربر فعال در روز، حداقل مدت ۲ هفته است، برای برنامه‌های با ۱۰۰٬۰۰۰ کاربر — ۳ تا ۵ روز. Firebase به طور خودکار زمان لازم را محاسبه می‌کند و در صورت ناکافی بودن ترافیک فعلی برای تشخیص تفاوت‌های معنادار هشدار می‌دهد. مهم: آزمایش را زودتر از موعد مقرر متوقف نکنید، حتی اگر نتیجه آشکار به نظر برسد — این خطای کلاسیک «peeking» است.

معیارهای آزمایش A/B

معیارهای هدف در Firebase A/B Testing بر اساس رویدادهای Firebase Analytics تعریف می‌شوند. معیارهای استاندارد در دسترس هستند: daily active users، revenue، conversion rate، retention، user engagement. همچنین می‌توان یک معیار سفارشی بر اساس هر رویداد Analytics با پارامترهای اضافی ایجاد کرد. به عنوان مثال، معیار «درصد کاربرانی که به صفحه پرداخت رسیده‌اند» از رویداد screen_view با پارامتر screen_name = «payment» ایجاد می‌شود.

توصیه می‌شود یک معیار اولیه (primary metric) را انتخاب کنید که بر اساس آن تصمیم‌گیری در مورد موفقیت آزمایش گرفته می‌شود، و ۲ تا ۳ معیار ثانویه برای تحلیل اضافی. انتخاب چندین معیار اولیه خطر نتیجه مثبت کاذب را افزایش می‌دهد (multiple comparison problem). اگر معیار اولیه انتخاب شده بهبود آماری معناداری نشان ندهد، آزمایش ناموفق تلقی می‌شود، حتی اگر معیارهای ثانویه بهبود یافته باشند.

نمونه کدهای Remote Config در Kotlin

یکپارچه‌سازی Remote Config را در برنامه Android با Kotlin بررسی می‌کنیم. نمونه‌ها شامل راه‌اندازی SDK با زمان ذخیره‌سازی موقت سفارشی، دریافت پارامترهای انواع مختلف، پیاده‌سازی شرط A/B در سمت کلاینت و مدیریت خطا در صورت عدم دسترسی به سرور است. تمام کد در main activity یا کلاس Application اجرا می‌شود تا پارامترها از همان ابتدای برنامه در دسترس باشند.

قبل از استفاده وابستگی را اضافه کنید: implementation(«com.google.firebase:firebase-config») از طریق Firebase BOM. مطمئن شوید Firebase Analytics نیز متصل است، زیرا Remote Config از Analytics برای انتقال ویژگی‌های کاربر استفاده می‌کند.

راه‌اندازی و دریافت پارامترها

اولین نمونه — تنظیمات پایه Remote Config با حداقل فاصله fetch ۱ ساعت برای تولید. SDK در متد onCreate کلاس Application راه‌اندازی می‌شود. پس از fetchAndActivate مقدار پارامتر welcome_message بررسی می‌شود که می‌تواند برای صفحه خوش‌آمدگویی از راه دور تغییر کند.

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

در نمونه setDefaultsAsync default values را از فایل XML res/xml/remote_config_defaults.xml بارگذاری می‌کند. اگر fetch با خطا پایان یابد (عدم شبکه، سرور در دسترس نیست)، برنامه از این مقادیر استفاده خواهد کرد. فایل XML همان نام پارامترهای کنسول Firebase را دارد: <entry key=«welcome_message»>خوش آمدید!</entry>. توصیه می‌شود همیشه برای همه پارامترهای Remote Config default values داشته باشید.

Feature toggle با Remote Config

دومین نمونه — feature toggle (پرچم فعال‌سازی ویژگی). پارامتر new_checkout_enabled از نوع boolean است. اگر مقدار true باشد — برنامه صفحه جدید تسویه حساب را نشان می‌دهد، اگر false — صفحه قدیمی. Feature toggle محبوب‌ترین سناریوی Remote Config است: تغییر فقط یک پارامتر را تحت تأثیر قرار می‌دهد، نیاز به تغییر منطق ندارد و می‌تواند فوراً لغو شود.

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

// استفاده در activity
if (isFeatureEnabled("new_checkout_enabled")) {
    navigateToNewCheckout()
} else {
    navigateToLegacyCheckout()
}

تابع isFeatureEnabled دسترسی به Remote Config را کپسوله می‌کند و می‌تواند به راحتی از طریق mock آزمایش شود. برای feature toggles توصیه می‌شود از قرارداد نام‌گذاری استفاده کنید: پیشوند feature_، ff_ یا flag_ تا در کنسول Firebase بلافاصله هدف پارامتر مشخص باشد. مثال: feature_new_onboarding، ff_dark_mode، flag_v3_api. از پارامترهای پرچم برای فعال/غیرفعال کردن بیش از ۳ ماه استفاده نکنید — انباشت پرچم‌های مرده نگهداری را دشوار می‌کند.

دریافت تنظیمات تم JSON

سومین نمونه — دریافت پارامتر JSON با تنظیمات تم برنامه. پارامتر app_theme شامل یک شی JSON با primaryColor، borderRadius و fontFamily است. در سمت کلاینت JSON با استفاده از Gson یا kotlinx.serialization تجزیه می‌شود و مقادیر روی UI اعمال می‌شوند. این رویکرد به طراحان اجازه می‌دهد تم برنامه را بدون مشارکت توسعه‌دهنده و بدون انتشار جدید تغییر دهند.

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 نیاز به دقت دارد: اگر JSON در کنسول Firebase نادرست باشد (مثلاً کاما جا افتاده باشد)، تجزیه با خطا مواجه می‌شود و برنامه به جای تم جاری default values دریافت می‌کند. توصیه می‌شود رشته‌های JSON را قبل از انتشار از طریق JSON validator تأیید کنید. برای تولید، هنگام تجزیه try-catch اضافه کنید و خطاها را از طریق Firebase Crashlytics ثبت کنید.

بهترین روش‌ها و محدودیت‌ها

Firebase Remote Config ابزاری قدرتمند است، اما در صورت استفاده نادرست می‌تواند منجر به مشکلات عملکرد، قابلیت پیش‌بینی رفتار و امنیت شود. روش‌های کلیدی که به جلوگیری از خطاهای معمول در کار با سرویس کمک می‌کنند و محدودیت‌هایی که هنگام طراحی معماری برنامه باید در نظر گرفته شوند را بررسی می‌کنیم.

از داده‌های حساس خودداری کنید — Remote Config برای ذخیره اسرار (کلیدهای API، توکن‌ها، رمزهای عبور) طراحی نشده است. تمام مقادیر پارامترها در کد کلاینت در دسترس هستند و می‌توانند از حافظه برنامه استخراج شوند. برای داده‌های محرمانه از Cloud Functions با تأیید سرور یا Secret Manager استفاده کنید. در Remote Config فقط پارامترهای عمومی را ذخیره کنید: متن‌ها، پرچم‌ها، تنظیمات UI، URL نقاط پایانی عمومی.

هر تغییر را آزمایش کنید قبل از انتشار برای همه مخاطبان. از آزمایش A/B یا انتشار برای درصد کم (۱ تا ۵٪ کاربران) استفاده کنید تا بررسی کنید که مقدار جدید باعث crash نمی‌شود و نمایش را خراب نمی‌کند. Remote Config محیط staging ندارد — همه تغییرات مستقیماً در تولید منتشر می‌شوند. تنها راه انتشار ایمن، استقرار تدریجی است.

محدودیت‌های پلتفرم: حداکثر تعداد پارامترها — ۲۰۰۰ (برای همه انواع)، حداکثر اندازه یک مقدار — ۲۵۶ کیلوبایت، اندازه کل پاسخ سرور — ۸۰۰ کیلوبایت. تعداد ویژگی‌های کاربر (user properties) که می‌توان در Remote Config استفاده کرد به ۲۵ محدود است. حداقل فاصله fetch — ۰ ثانیه (برای اشکال‌زدایی)، اما استفاده بیش از حد می‌تواند منجر به تجاوز از سهمیه Cloud Functions شود (۳۰٬۰۰۰ درخواست در دقیقه برای هر پروژه).