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

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

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

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

التحوّل إلى نمط "استرداد البيانات للجلسة التالية"

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

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

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

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

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

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

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

على سبيل المثال، إذا ضبطت قيمة minimumFetchInterval على 24 ساعة وفتح أحد المستخدمين تطبيقك 5 أو 10 مرات في يوم واحد، سيستوفي حزمة SDK عمليات التشغيل من 2 إلى 10 تلقائيًا مباشرةً من ذاكرة التخزين المؤقت المحلية، ما يقلّل عدد طلبات الشبكة اليومية التي يرسلها هذا المستخدم من 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