Рекомендации по повышению эффективности получения удаленной конфигурации

Firebase Remote Config предоставляет гибкий контроль над поведением и внешним видом вашего приложения. Это позволяет внедрять новые функции и проводить кроссплатформенное A/B-тестирование приложений, не развертывая новые версии и не выполняя многочисленные обновления в магазинах приложений.

Независимо от того, занимаетесь ли вы прототипированием, управляете растущим стартапом или масштабируемым корпоративным приложением, управление объемом сетевых запросов имеет ключевое значение для обеспечения быстрой и отзывчивой работы пользователей. Эффективное управление конфигурацией снижает задержку при холодном запуске, экономит клиентские данные и заряд батареи, а также предотвращает ненужную сетевую нагрузку. Кроме того, если ваша пользовательская база быстро растет и в будущем увеличивается объем использования, оптимизация интеграции Remote Config поможет обеспечить эффективное использование ресурсов.

Вы можете значительно сократить объем сетевых запросов на стороне клиента, уточнив, как и когда приложения получают параметры и когда они их активируют.

Перейдите к шаблону «загрузка для следующей сессии».

Распространенный подход, которого следует избегать, — это использование вызова fetchAndActivate (который одновременно получает новые значения по сети и активирует их) при каждом запуске приложения в сочетании с коротким периодом истечения срока действия кэша для ранее полученных значений (например, от 15 минут до часа). В основе этого подхода лежит представление, что каждый раз, когда пользователь открывает приложение, ему всегда доступны и применяются самые последние полученные значения. Хотя бывают случаи, когда немедленное обновление необходимо (например, при проведении ежедневной рекламной кампании или акции игры), важно сбалансировать эту цель с влиянием на производительность приложения и использование запросов на получение данных.

Такой подход приводит к необходимости повторных сетевых запросов каждый раз, когда истекает срок действия кэша, что генерирует большой объем запросов для пользователей, которые открывают приложение несколько раз в день.

Вместо этого рассмотрите возможность использования вызовов fetch и activate отдельно с более высоким минимальным интервалом выборки, чтобы перейти к модели «выборка для следующей сессии». Вы по-прежнему можете использовать fetchAndActivate с более высоким минимальным интервалом выборки, поскольку fetch выполняет сетевой запрос только в том случае, если кэш аннулирован, но использование двух вызовов отдельно помогает закрепить этот шаблон и установить его в качестве стандартной практики в процессе разработки вашего приложения. Кроме того, при раздельной активации вы избегаете риска применения значений конфигурации в середине сессии и нарушения пользовательского опыта.

Как работает этот подход

  • Активация сразу при запуске: мгновенное применение конфигураций, кэшированных из предыдущей сессии (задержка сети 0 мс).
  • Загрузка в фоновом режиме с более длительным сроком хранения в кэше (например, более 12 или 24 часов): асинхронно запрашивайте обновленные конфигурации для обновления локального кэша для следующей сессии.

Как это оптимизирует объем выборки

Увеличение минимального интервала выборки приводит к уменьшению количества запросов на выборку. Получение новых значений для следующей сессии и активация кэшированных значений для текущей сессии означает, что ваше приложение загружается мгновенно из локального кэша в течение более длительного периода проверки, что приводит к улучшению пользовательского опыта.

Например, если вы установите minimumFetchInterval равным 24 часам, и пользователь откроет ваше приложение 5 или 10 раз за день, SDK автоматически удовлетворит запросы с 2 по 10 непосредственно из локального кэша, уменьшив количество ежедневных сетевых запросов для этого пользователя с 10 или более до 1.

Следующие примеры демонстрируют, как выглядит эта реализация для платформ Android, Apple и веб-приложений:

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 к общим хукам жизненного цикла пользовательского интерфейса, например, каждый раз при загрузке экрана, переключении вкладок или получении фокуса элементом интерфейса.

Вместо этого запускайте запросы на получение данных выборочно на основе явно заданных действий или состояний приложения, например:

  • События входа пользователя в систему
  • Переход к конкретным сценариям взаимодействия пользователя, где используются ваши параметры (например, вход в воронку оформления заказа или повышение уровня в игре).

И наоборот, избегайте запуска запросов на получение данных для выполнения рутинных действий, таких как:

  • Когда пользователь открывает приложение или начинает новую сессию
  • Когда приложение переходит из фонового состояния в активное и обратно

Следующие шаги