Sprawdzone metody zwiększania wydajności pobierania danych ze Zdalnej konfiguracji

Firebase Remote Config zapewnia elastyczną kontrolę nad działaniem i wyglądem aplikacji. Dzięki temu możesz wdrażać funkcje i przeprowadzać testy A/B na wielu platformach bez konieczności wdrażania nowych wersji aplikacji czy aktualizowania ich w różnych sklepach z aplikacjami.

Niezależnie od tego, czy tworzysz prototyp, prowadzisz rozwijający się startup czy zarządzasz aplikacją dla przedsiębiorstw na dużą skalę, zarządzanie liczbą pobrań z sieci jest kluczem do zapewnienia szybkiego i płynnego działania aplikacji. Efektywne zarządzanie konfiguracją zmniejsza opóźnienia związane z uruchamianiem na zimno, oszczędza dane klienta i baterię oraz zapobiega niepotrzebnemu obciążeniu sieci. Ponadto, jeśli liczba użytkowników szybko wzrośnie i w przyszłości zwiększy się wykorzystanie, usprawnienie integracji z Remote Config pomoże utrzymać efektywne wykorzystanie.

Możesz znacznie zmniejszyć ruch związany z żądaniami sieciowymi po stronie klienta, doprecyzowując, jak i kiedy aplikacje pobierają parametry oraz kiedy je aktywują.

Przejście na wzorzec „pobierania na potrzeby następnej sesji”

Częstym błędem, którego należy unikać, jest używanie wywołania fetchAndActivate, które pobiera nowe wartości przez sieć i je aktywuje, przy każdym uruchomieniu aplikacji w połączeniu z krótkim okresem ważności pamięci podręcznej dla wcześniej pobranych wartości (np. od 15 minut do godziny). Model mentalny tego podejścia polega na tym, że za każdym razem, gdy użytkownik otwiera aplikację, zawsze ma pobrane i zastosowane najnowsze wartości. Czasami natychmiastowa aktualizacja jest konieczna (np. w przypadku codziennej kampanii sprzedażowej lub promocji gry), ale ważne jest, aby zachować równowagę między tym celem a wpływem na wydajność aplikacji i wykorzystanie pobierania.

To podejście wymusza nowe wywołania sieciowe za każdym razem, gdy pamięć podręczna wygaśnie, co generuje dużą liczbę pobrań w przypadku użytkowników, którzy otwierają aplikację kilka razy dziennie.

Zamiast tego rozważ użycie wywołań fetch i activate osobno z wyższym minimalnym interwałem pobierania, aby zastosować model „pobierania na potrzeby następnej sesji”. Nadal możesz używać metody fetchAndActivate z dłuższym minimalnym interwałem pobierania, ponieważ metoda fetch wykonuje żądanie sieciowe tylko wtedy, gdy pamięć podręczna jest unieważniona. Jednak używanie tych 2 wywołań osobno pomaga utrwalić ten wzorzec i uczynić go standardową praktyką w procesie tworzenia aplikacji. Dodatkowo, aktywując je osobno, nie ryzykujesz zastosowania wartości konfiguracji w trakcie sesji i zakłócenia działania aplikacji.

Jak działa ta metoda

  • Aktywuj natychmiast po uruchomieniu: natychmiast zastosuj konfiguracje zapisane w pamięci podręcznej z poprzedniej sesji (opóźnienie sieci 0 ms).
  • Pobieranie w tle z dłuższym okresem przechowywania w pamięci podręcznej (np. dłuższym niż 12 lub 24 godziny): żądaj zaktualizowanych konfiguracji asynchronicznie, aby odświeżyć lokalną pamięć podręczną na potrzeby następnej sesji.

Jak to optymalizuje liczbę pobrań

Dłuższy minimalny interwał pobierania oznacza mniejszą liczbę żądań pobrania. Pobieranie nowych wartości dla następnej sesji i aktywowanie wartości z pamięci podręcznej dla bieżącej sesji oznacza, że aplikacja ładuje się natychmiast z lokalnej pamięci podręcznej przez dłuższy okres weryfikacji, co zapewnia lepsze wrażenia użytkownika.

Jeśli na przykład ustawisz minimumFetchInterval na 24 godziny, a użytkownik otworzy aplikację 5 lub 10 razy w ciągu jednego dnia, pakiet SDK automatycznie obsłuży uruchomienia od 2 do 10 bezpośrednio z lokalnej pamięci podręcznej, co zmniejszy dzienną liczbę żądań sieciowych tego użytkownika z 10 lub więcej do 1.

Poniższe przykłady pokazują, jak wygląda ta implementacja w przypadku Androida, platform Apple i aplikacji internetowych:

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

Sieć

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

Wdrażanie warunkowego „inteligentnego” pobierania

Jeśli wzorzec „pobieranie na potrzeby następnej sesji” powoduje zbyt duże opóźnienie między momentem, w którym musisz zaktualizować wartości Remote Config, a momentem, w którym stają się one dostępne w aplikacjach klienckich, rozważ zastosowanie warunkowego „inteligentnego” pobierania.

Aby skutecznie wdrożyć tę funkcję, unikaj dołączania aktywatorów fetch do ogólnych punktów zaczepienia cyklu życia interfejsu, takich jak każde wczytanie ekranu, przełączenie karty czy ustawienie ostrości widoku.

Zamiast tego wywołuj żądania pobierania selektywnie na podstawie konkretnych działań lub stanów aplikacji, takich jak:

  • Zdarzenia logowania użytkowników
  • przejście do konkretnych wzorców przeglądania, w których używane są Twoje parametry (np. wejście na ścieżkę procesu płatności lub przejście na wyższy poziom w grze);

Z drugiej strony unikaj wywoływania żądań pobierania w przypadku rutynowych działań, takich jak:

  • gdy użytkownik otwiera aplikację lub rozpoczyna nową sesję;
  • gdy aplikacja przechodzi między stanem działania w tle a stanem działania na pierwszym planie;

Dalsze kroki