أفضل الممارسات لتحسين كفاءة استرجاع البيانات في الإعداد عن بُعد

تمنحك Firebase Remote Config تحكّمًا مرنًا في سلوك تطبيقك ومظهره. يتيح ذلك إمكانات مثل طرح الميزات وإجراء اختبارات A/B على عدّة منصات لتطبيقاتك، وكل ذلك بدون نشر إصدارات جديدة أو التنقّل بين تحديثات متعددة في متجر التطبيقات.

سواء كنت بصدد إنشاء نموذج أوّلي أو إدارة شركة ناشئة متنامية أو إدارة تطبيق مؤسسة على نطاق واسع، فإنّ إدارة حجم جلب الشبكة هي مفتاح تقديم تجربة مستخدم سريعة ومتجاوبة. تؤدي إدارة عملية الإعداد بكفاءة إلى تقليل وقت الاستجابة عند بدء التشغيل على البارد، وتوفير بيانات العميل واستخدام البطارية، ومنع زيادة عبء الشبكة غير الضروري. بالإضافة إلى ذلك، إذا توسّعت قاعدة المستخدمين بسرعة وزاد الاستخدام في المستقبل، فإنّ تبسيط عملية دمج Remote Config يساعد في ضمان بقاء استخدامك فعّالاً.

يمكنك تقليل عدد طلبات الشبكة من جهة العميل بشكل كبير من خلال تحسين كيفية ووقت جلب التطبيقات للمَعلمات ووقت تفعيلها.

الانتقال إلى نمط "الجلب للجلسة التالية"

من الأنماط الشائعة التي يجب تجنُّبها استخدام طلب fetchAndActivate، الذي يجلب القيم الجديدة عبر الشبكة ويفعّلها، عند كل تشغيل للتطبيق مع فترة انتهاء صلاحية قصيرة لذاكرة التخزين المؤقت للقيم التي تم جلبها سابقًا (على سبيل المثال، من 15 دقيقة إلى ساعة). النموذج الذهني وراء هذا النهج هو أنه في كل مرة يفتح فيها المستخدم التطبيق، يتم دائمًا جلب أحدث القيم وتطبيقها. على الرغم من أنّ هناك أوقاتًا يكون فيها التحديث الفوري ضروريًا (على سبيل المثال، إطلاق حملة مبيعات يومية أو عرض ترويجي للعبة)، من المهم تحقيق التوازن بين هذا الهدف والتأثير في أداء تطبيقك واستخدام ميزة الجلب.

يفرض هذا الأسلوب إجراء طلبات جديدة للشبكة في كل مرة تنتهي فيها صلاحية ذاكرة التخزين المؤقت، ما يؤدي إلى زيادة حجم عمليات الجلب للمستخدمين الذين يفتحون التطبيق عدة مرات في اليوم.

بدلاً من ذلك، يمكنك استخدام طلبَي fetch وactivate بشكل منفصل مع ضبط حد أدنى أعلى للفاصل الزمني للجلب من أجل اعتماد نموذج "الجلب للجلسة التالية". لا يزال بإمكانك استخدام fetchAndActivate مع فاصل زمني أعلى للحد الأدنى للجلب لأنّ fetch لا ينفّذ طلب شبكة إلا إذا تم إبطال ذاكرة التخزين المؤقت، ولكن استخدام الاستدعاءَين بشكل منفصل يساعد في ترسيخ النمط وتأسيسه كممارسة عادية في عملية تطوير التطبيق. بالإضافة إلى ذلك، من خلال التفعيل بشكل منفصل، لن تتعرّض لخطر تطبيق قيم الإعدادات في منتصف الجلسة وتعطيل تجربة المستخدم.

طريقة عمل هذا النهج

• التفعيل فورًا عند التشغيل: يتم تطبيق الإعدادات المخزَّنة مؤقتًا من الجلسة السابقة على الفور (تأخير الشبكة بمقدار 0 ملي ثانية).
• الجلب في الخلفية باستخدام ذاكرة تخزين مؤقت أطول (على سبيل المثال، أكثر من 12 أو 24 ساعة): يمكنك طلب الإعدادات المعدَّلة بشكل غير متزامن لإعادة تحميل ذاكرة التخزين المؤقت المحلية للجلسة التالية.

كيفية تحسين حجم الجلب

ويؤدي ضبط حد أدنى أطول للفترة الزمنية بين عمليات الجلب إلى تقليل عدد طلبات الجلب. إنّ جلب قيم جديدة للجلسة التالية وتفعيل القيم المخزّنة مؤقتًا للجلسة الحالية يعني أنّ تطبيقك يتم تحميله على الفور من ذاكرة التخزين المؤقت المحلية على مدار فترة تحقّق أطول، ما يؤدي إلى تحسين تجارب المستخدمين.

على سبيل المثال، إذا ضبطت المَعلمة minimumFetchInterval على 24 ساعة وفتح أحد المستخدمين تطبيقك 5 أو 10 مرات في يوم واحد، ستستجيب حزمة SDK تلقائيًا لعمليات فتح التطبيق من المرة الثانية إلى العاشرة مباشرةً من ذاكرة التخزين المؤقت المحلية، ما يقلّل عدد طلبات الشبكة اليومية التي يرسلها هذا المستخدم من 10 عمليات جلب أو أكثر إلى عملية جلب واحدة.

توضّح الأمثلة التالية شكل عملية التنفيذ هذه على Android وأنظمة Apple الأساسية وتطبيقات الويب:

val remoteConfig = Firebase.remoteConfig

// Set a 24-hour minimum fetch interval (86,400 seconds)
val configSettings = remoteConfigSettings {
    minimumFetchIntervalInSeconds = 86400
}
remoteConfig.setConfigSettingsAsync(configSettings)

// 1. Instantly activate values cached from the LAST session
remoteConfig.activate().addOnCompleteListener {
    applyAppConfigurations()
}

// 2. Fetch new values in the background for the NEXT session
remoteConfig.fetch().addOnCompleteListener { task ->
    if (task.isSuccessful) {
        // Optional: Activate values if needed
    }
}

let remoteConfig = RemoteConfig.remoteConfig()

// Set a 24-hour minimum fetch interval (86,400 seconds)
let settings = RemoteConfigSettings()
settings.minimumFetchInterval = 86400
remoteConfig.configSettings = settings

// 1. Instantly activate values cached from the LAST session
remoteConfig.activate { changed, error in
    guard error == nil else { return }
    DispatchQueue.main.async {
        self.applyAppConfigurations()
    }
}

// 2. Fetch new values in the background for the NEXT session
remoteConfig.fetch { status, error in
    if status == .success {
        // Optional: Activate values if needed
    }
}

import { getRemoteConfig, fetchConfig, activate } from "firebase/remote-config";

const remoteConfig = getRemoteConfig(app);

// Set a 24-hour minimum fetch interval (86,400,000 ms)
remoteConfig.settings.minimumFetchIntervalMillis = 86400000;

// 1. Instantly activate values cached from the LAST session
activate(remoteConfig).then(() => {
    applyAppConfigurations();
});

// 2. Fetch new values in the background for the NEXT session
fetchConfig(remoteConfig).then(() => {
    // Optional: Activate values if needed
});

تنفيذ الجلب "الذكي" المشروط

إذا كان نمط "الجلب للجلسة التالية" يؤدي إلى زيادة وقت الاستجابة بين وقت الحاجة إلى تعديل قيم Remote Config ووقت توفّرها في تطبيقات العميل، ننصحك باستخدام الجلب "الذكي" المشروط.

لتنفيذ ذلك بفعالية، تجنَّب ربط مشغّلات fetch بأحداث عامة في مراحل نشاط واجهة المستخدم، مثل كل مرة يتم فيها تحميل شاشة أو تبديل علامة تبويب أو التركيز على طريقة عرض.

بدلاً من ذلك، يمكنك تفعيل طلبات الجلب بشكل انتقائي استنادًا إلى إجراءات أو حالات صريحة في التطبيق، مثل:

• أحداث تسجيل دخول المستخدمين
• الانتقال إلى مسارات مستخدمين معيّنة يتم فيها استخدام المَعلمات (على سبيل المثال، الدخول إلى مسار دفع أو الانتقال إلى مستوى أعلى في لعبة)

في المقابل، تجنَّب إرسال طلبات جلب البيانات لإجراءات روتينية مثل:

• عندما يفتح المستخدم التطبيق أو يبدأ جلسة جديدة
• عندما ينتقل التطبيق بين حالتَي الخلفية والمقدمة

الخطوات التالية

• كيفية استخدام ميزة "Remote Config في الوقت الفعلي" بشكل استراتيجي
• استكشاف استراتيجيات تحميل Firebase Remote Config