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

Firebase Remote Config מאפשרת לכם שליטה גמישה בהתנהגות ובמראה של האפליקציה. כך אפשר להשתמש ביכולות כמו השקת תכונות ובדיקות A/B חוצות-פלטפורמות באפליקציות, בלי לפרוס גרסאות חדשות או לעבור בין עדכונים שונים בחנויות האפליקציות.

בין אם אתם יוצרים אב טיפוס, מנהלים סטארט-אפ בצמיחה או מנהלים אפליקציה ארגונית בהיקף גדול, ניהול נפח האחזור של הרשת הוא המפתח למתן חוויית משתמש מהירה ורספונסיבית. ניהול יעיל של ההגדרות מצמצם את זמן הטעינה הראשוני, חוסך בנתוני הלקוח ובשימוש בסוללה ומונע תקורה מיותרת ברשת. בנוסף, אם בסיס המשתמשים שלכם יתרחב במהירות והשימוש יגדל בעתיד, ייעול השילוב של Remote Config יעזור לכם לוודא שהשימוש יישאר יעיל.

כדי לצמצם באופן משמעותי את נפח התנועה של בקשות לאחזור מהרשת בצד הלקוח, אפשר לשפר את האופן שבו האפליקציות מאחזרות פרמטרים ואת המועד שבו הן מפעילות אותם.

מעבר לדפוס 'אחזור לשימוש בסשן הבא'

דפוס נפוץ שכדאי להימנע ממנו הוא שימוש בקריאה fetchAndActivate – שגם מאחזרת ערכים חדשים ברשת וגם מפעילה אותם – בכל הפעלה של האפליקציה, בשילוב עם תקופה קצרה של תפוגת מטמון לערכים שאוחזרו בעבר (לדוגמה, 15 דקות עד שעה). המודל המנטלי שמאחורי הגישה הזו הוא שבכל פעם שמשתמש פותח את האפליקציה, המערכת מאחזרת ומחילת את הערכים העדכניים ביותר. לפעמים יש צורך בעדכון מיידי (לדוגמה, כשמפעילים קמפיין מכירות יומי או קידום של משחק), אבל חשוב לאזן בין המטרה הזו לבין ההשפעה על הביצועים של האפליקציה ועל השימוש באחזור.

הגישה הזו מחייבת קריאות חדשות לרשת בכל פעם שתוקף המטמון פג, וכך נוצר נפח אחזור גבוה למשתמשים שפותחים את האפליקציה כמה פעמים ביום.

במקום זאת, כדאי להשתמש בקריאות fetch ו-activate בנפרד עם מרווח זמן מינימלי גבוה יותר בין אחזורים, כדי לאמץ מודל של 'אחזור לסשן הבא'. עדיין אפשר להשתמש ב-fetchAndActivate עם מרווח זמן גדול יותר בין אחזורים, כי fetch מבצע רק בקשה לאחזור מהרשת אם המטמון לא תקף. עם זאת, שימוש בשתי הקריאות בנפרד עוזר לבסס את התבנית ולהפוך אותה לשיטה סטנדרטית בתהליך פיתוח האפליקציה. בנוסף, אם מפעילים את התכונה בנפרד, לא מסתכנים בהחלת ערכי הגדרה באמצע הסשן ובשיבוש חוויית המשתמש.

איך הגישה הזו פועלת

• הפעלה מיידית עם ההשקה: החלת הגדרות שנשמרו במטמון מהסשן הקודם באופן מיידי (0 אלפיות השנייה של השהיית רשת).
• אחזור ברקע עם מטמון ארוך יותר (למשל, יותר מ-12 או 24 שעות): שולחים בקשה אסינכרונית לעדכון ההגדרות כדי לרענן את המטמון המקומי עבור הסשן הבא.

איך התכונה הזו מבצעת אופטימיזציה של נפח האחזור

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

לדוגמה, אם מגדירים את minimumFetchInterval ל-24 שעות ומשתמש פותח את האפליקציה 5 או 10 פעמים ביום אחד, ה-SDK מספק באופן אוטומטי את ההפעלה השנייה עד העשירית ישירות מהמטמון המקומי – כך שמספר בקשות הרשת היומיות של המשתמש יורד מ-10 או יותר אחזורים ל-1.

בדוגמאות הבאות אפשר לראות איך ההטמעה הזו נראית באפליקציות ל-Android, בפלטפורמות של אפל ובאפליקציות אינטרנט:

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