استراتيجيات التحميل في ميزة "الإعداد عن بُعد في Firebase"
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
توفّر Firebase Remote Config الكثير من المرونة في كيفية ووقت جلب القيم الجديدة من الخادم وتفعيلها في تطبيقك، ما يتيح لك ضمان تقديم تجربة عالية الجودة للمستخدمين النهائيين من خلال التحكّم في توقيت أي تغييرات مرئية في الإعدادات. يمكنك استرجاع القيم الجديدة عند تشغيل التطبيق باستخدام
fetchAndActivate()، واستخدام
Remote Config في الوقت الفعلي
كطريقة تكميلية لاسترجاع أحدث قيم المَعلمات تلقائيًا
بعد نشر إصدار جديد من Remote Config.
يتناول هذا الدليل بعض استراتيجيات التحميل ويناقش الاعتبارات الرئيسية لاختيار الخيار الأفضل لتطبيقك.
الاستراتيجية 1: استرجاع المَعلمات وتفعيلها عند التحميل
في هذه الاستراتيجية، سيطلب تطبيقك fetchAndActivate() عند بدء تشغيله للمرة الأولى من أجل جلب قيم جديدة من Remote Config وتفعيلها فور انتهاء تحميلها. يعمل هذا الأسلوب البسيط بشكل جيد مع تغييرات الإعدادات التي لا تؤدي إلى أي تغييرات مرئية كبيرة في واجهة المستخدم. ويجب تجنُّبها في أي حالة قد تتغير فيها واجهة المستخدم بشكل ملحوظ أثناء استخدام المستخدمين لها.
بعد أن يستدعي تطبيقك الدالة fetchAndActivate()، يمكنه البدء في الاستماع إلى التعديلات على قيمة المَعلمة في الوقت الفعلي من خلال استدعاء الدالة addOnConfigUpdateListener. تبدأ هذه الطريقة في الاستماع إلى أي تعديلات على قيم المَعلمات من جهة الخادم، وتسترجعها تلقائيًا، ثم تستدعي أداة المعالجة. تتمثّل إحدى الاستراتيجيات البسيطة في تفعيل القيم الجديدة في المستمع. ومع ذلك، كما ذكرنا في ما يخص fetchAndActivate()،
يجب تجنُّب التفعيل الفوري لواجهات المستخدم الحسّاسة.
الاستراتيجية 2: التفعيل في الخلفية أثناء عرض شاشة التحميل
كحلّ لمشكلة واجهة المستخدم المحتملة التي تمت مواجهتها في الاستراتيجية 1، يمكنك الاعتماد على شاشة تحميل. بدلاً من بدء تشغيل تطبيقك على الفور، اعرض شاشة تحميل واستدعِ fetchAndActivate في معالج الإكمال.
بعد ذلك مباشرةً، يمكنك إغلاق شاشة التحميل والسماح للمستخدم ببدء التفاعل مع تطبيقك، وذلك باستخدام دالة رد الاتصال أو الإشعار مرة أخرى.
في حال استخدام هذه الاستراتيجية، ننصحك بإضافة مهلة إلى شاشة التحميل. قد يكون المهلة الزمنية البالغة دقيقة واحدة في خدمة "الإعداد عن بُعد" طويلة جدًا بالنسبة إلى تجربة بدء تشغيل تطبيق عالي الجودة للمستخدمين.
يُعد الاستماع إلى Remote Config التحديثات في الوقت الفعلي من خلال طلب
addOnConfigUpdateListener طريقة فعّالة لاستخدام هذه الاستراتيجية. أضِف أداة معالجة الأحداث عند عرض شاشة التحميل، ثم استخدِم activate() في نقطة واحدة أو أكثر في تطبيقك حيث لن تتسبّب قيم Remote Config في حدوث تغييرات مرئية كبيرة.
الاستراتيجية 3: تحميل قيم جديدة عند بدء التشغيل التالي
تتمثّل الاستراتيجية الفعّالة في تحميل قيم الإعدادات الجديدة ليتم تفعيلها عند تشغيل تطبيقك في المرة التالية. في هذه الاستراتيجية، يفعّل تطبيقك القيم التي تم استرجاعها عند بدء التشغيل قبل محاولة استرجاع قيم جديدة، وذلك على افتراض أنّه ربما سبق له استرجاع قيم إعدادات جديدة ولكن لم يتم تفعيلها بعد. ترتيب العمليات لهذه الاستراتيجية هو:
عند بدء التشغيل، فعِّل على الفور القيم التي تم استرجاعها سابقًا. ويطبّق هذا الإجراء أي قيم نزّلتها من الخادم في جلسة سابقة، وهو إجراء فوري تقريبًا.
أثناء تفاعل المستخدم مع تطبيقك، ابدأ طلبًا غير متزامن لجلب قيم جديدة وفقًا للحد الأدنى التلقائي لفاصل الجلب الزمني، وأضِف أداة معالجة لتعديل الإعدادات في الوقت الفعلي. سيجلب المستمع في الوقت الفعلي تلقائيًا أي قيم يتم نشرها على الخادم أثناء تشغيل تطبيقك.
تتجاوز التعديلات في الوقت الفعلي إعداد الحدّ الأدنى للفاصل الزمني بين عمليات الجلب.
في معالج الإكمال أو دالة الرجوع الخاصة بطلب الجلب، لا تفعل أي شيء.
سيحتفظ تطبيقك بالقيم التي تم تنزيلها إلى أن تفعّلها في المرة التالية التي يتم فيها تشغيل التطبيق.
باستخدام هذه الاستراتيجية، يتم تقليل وقت انتظار المستخدم بشكل كبير. يضمن الجمع بين استراتيجيتَي الجلب والاستماع في الوقت الفعلي مع طلبات activate() حسب الحاجة في دورة حياة التطبيق حصول المستخدمين على أحدث القيم من Remote Config أثناء تفاعلهم مع تطبيقك.
استراتيجيات التحميل المضاد
كما قد تكون أدركت من المناقشة أعلاه حول إيجابيات وسلبيات التحميل، هناك نمطان من الاستخدام يجب تجنّبهما.
لا تعدِّل أو تبدِّل جوانب واجهة المستخدم أثناء عرض المستخدم لها أو تفاعله معها، إلا إذا كان لديك أسباب قوية متعلقة بالتطبيق أو بنشاطك التجاري، مثل إزالة خيارات متعلقة بعرض ترويجي انتهى للتو.
لا ترسِل أعدادًا كبيرة من طلبات الجلب المتزامنة، لأنّ ذلك قد يؤدي إلى أن يقيّد الخادم تطبيقك. إذا كنت بحاجة إلى جلب التحديثات بشكل متكرر، استخدِم الوقت الفعلي Remote Config. على الرغم من أنّ خطر الحدّ من عدد الطلبات منخفض في معظم سيناريوهات الإنتاج، يمكن أن يشكّل مشكلة أثناء التطوير النشط، وقد تم تصميم Remote Config في الوقت الفعلي لحالة الاستخدام هذه. اطّلِع على إرشادات الحدّ من عدد الطلبات.
لا تعتمد على الاتصال بالشبكة للحصول على قيم Remote Config.
احرِص على ضبط قيم المَعلمات التلقائية داخل التطبيق لكي يتصرف تطبيقك دائمًا على النحو المتوقّع. يمكنك مزامنة القيم التلقائية للتطبيق وخادم Remote Config الخلفي بشكل دوري باستخدام الإعدادات التلقائية للنموذج الذي تم تنزيله.
الخطوات التالية
لا تشكّل هذه الاستراتيجيات الأساسية الثلاث بأي حال من الأحوال قائمة كاملة بطرق تحميل قيم الإعدادات. واستنادًا إلى احتياجاتك، يمكنك وضع استراتيجيات أكثر تعقيدًا.
راجِع مرجع واجهة برمجة التطبيقات (API) لمنصتك لمعرفة المزيد عن عمليات الاستدعاء المحدّدة لاسترداد قيم الإعدادات وتفعيلها.
تاريخ التعديل الأخير: 2025-09-03 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-09-03 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["\u003cbr /\u003e\n\nFirebase Remote Config provides lots of flexibility for how and when to\nfetch new values from the server and activate them in your app, allowing you to\nensure a quality end user experience by controlling the timing of any visible\nconfiguration changes. You can fetch new values on application launch using\n`fetchAndActivate()`, and use\n[real-time Remote Config](/docs/remote-config#how_it_works)\nas a complementary method to automatically fetch the latest parameter values\nafter a new version of your Remote Config is published.\n\nThis guide looks at a few loading strategies and\ndiscusses key considerations for picking the best option for your app.\n\nStrategy 1: Fetch and activate on load\n\nIn this strategy, your app would call `fetchAndActivate()` when your app first\nstarts up to fetch new values from Remote Config and activate them as soon\nas they are done loading. This simple approach works well for configuration\nchanges that don't cause\nany dramatic visual changes in your UI. It should be\navoided in any situation where your UI could change noticeably\nwhile users are in the middle of using it.\n\nAfter your app calls `fetchAndActivate()`, it can start listening for parameter\nvalue updates in real time by calling `addOnConfigUpdateListener`. This method\nstarts listening for any server-side updates to parameter values, fetches them\nautomatically, then calls the listener. A simple strategy is to activate the new\nvalues in the listener. However, as mentioned for `fetchAndActivate()`,\nactivating immediately should be avoided for sensitive UIs.\n\nStrategy 2: Activate behind loading screen\n\nAs a remedy to the potential UI issue encountered in strategy 1, you could rely\non a loading screen. Instead of starting up your app right away, show a loading\nscreen and call `fetchAndActivate` in your completion handler.\nThen right after that --- again using a callback or a notification\n--- dismiss the loading screen and allow the user to start interacting with\nyour app.\n\nIf you use this strategy, it's recommended to add a timeout to the loading\nscreen. Remote Config's\none-minute timeout may be too long for a quality app startup experience for\nusers.\n\nListening for real-time Remote Config updates by calling\n`addOnConfigUpdateListener` works well with this strategy. Add the listener when\nthe loading screen is displayed, then use `activate()` at one or more points in\nyour app where Remote Config values won't cause dramatic visual changes.\n| **Note:** If you are loading values for an [A/B Testing](/docs/ab-testing/abtest-config) experiment, this strategy is very strongly recommended. With A/B Testing, additional time is required as the user is placed into an experiment and the experimental values are applied.\n\nStrategy 3: Load new values for next startup\n\nAn effective strategy is to load new configuration values to\nactivate on your app's *next* startup. In this strategy, your app activates\nfetched values on startup before attempting to fetch new ones, operating on the\nassumption that it may have already fetched --- but not yet activated\n--- new configuration values. The order of operations for this strategy is:\n\n1. On startup, immediately activate previously fetched values. This applies any values you've downloaded from the server in a previous session, and is nearly instantaneous.\n2. While the user interacts with your app, kick off an asynchronous call to fetch new values according to the default minimum fetch interval and add a real-time config update listener. The real-time listener will automatically fetch any values that are published on the server while your app is running. Real-time updates bypass the minimum fetch interval setting.\n3. In the completion handler or callback for the fetch call, do nothing. Your app will keep the downloaded values until you activate them the next time the app starts.\n\nWith this strategy, user wait time is greatly minimized. Combining the fetch\nand real-time listener strategies with `activate()` calls as needed in the app lifecycle makes sure users\nhave the latest values from Remote Config as they interact with your app.\n| **Tip:** Use `fetch()` and `addOnConfigUpdateListener()` as complementary methods. It's recommended to call fetch once per app launch, then start listening for updates in real time and activate them as needed. Listening for real-time updates makes it possible to get the latest parameter values without calling fetch frequently.\n\nLoading anti-strategies\n\nAs you may have understood from the above discussion of loading pros and cons,\nthere are a couple of usage patterns to avoid.\n\n- **Don't** update or switch aspects of the UI while the user is viewing or interacting with it --- *unless* you have strong app or business reasons for doing so, like removing options related to a promotion that has just ended.\n- **Don't** send mass numbers of simultaneous fetch requests, which could result in the server throttling your app. If you need to fetch updates frequently, use [real-time Remote Config](/docs/remote-config#how_does_it_work). While the risk of throttling is low in most production scenarios, it can be an issue during active development---and real-time Remote Config is designed for this use case. Check out the [throttling\n guidance](/docs/remote-config/get-started#throttling).\n- **Don't** rely on network connectivity to obtain Remote Config values. **Do** set in-app default parameter values so that your app always behaves as expected. You can periodically keep app and Remote Config backend default values in sync using [downloaded template\n defaults](/docs/remote-config/templates#download_template_defaults).\n\nNext steps\n\nThese three basic strategies do not by any means comprise a complete list of the\nways to load configuration values. Depending on your needs, you could devise\nmuch more sophisticated strategies.\n\nCheck out the API reference for your platform to learn more about the specific\ncalls for fetching and activating configuration values."]]
