שיטות מומלצות לאחזור יעיל של הגדרות תצורה מרחוק

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 ל-lifecycle hooks רחבים של ממשק המשתמש, כמו בכל פעם שמסך נטען, כרטיסייה עוברת או תצוגה מקבלת פוקוס.

במקום זאת, הפעילו בקשות אחזור באופן סלקטיבי על סמך פעולות או מצבים מפורשים באפליקציה, כמו:

• אירועי כניסה של משתמשים
• מעבר למסלולי משתמש ספציפיים שבהם נעשה שימוש בפרמטרים (לדוגמה, כניסה למשפך התשלום או עליית שלב במשחק)

לעומת זאת, כדאי להימנע מהפעלת בקשות אחזור לפעולות שגרתיות כמו:

• כשמשתמש פותח את האפליקציה או מתחיל סשן חדש
• כשהאפליקציה עוברת בין מצב רקע למצב חזית

השלבים הבאים

• איך משתמשים ב-Remote Config בזמן אמת באופן אסטרטגי
• שיטות טעינה של Firebase Remote Config