Рекомендации по повышению эффективности получения данных в Remote Config

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

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

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

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

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

Дальнейшие действия