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

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

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

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

מעבר לתבנית "אחזור לסשן הבא"

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

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

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

איך הגישה הזו עובדת

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

איך זה משפר את נפח השליפה

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

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

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

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
    }
}

iOS+‎

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

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

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

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

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

השלבים הבאים