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

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

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

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

Переход на шаблон "получение данных для следующего сеанса"

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

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

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

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

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

Как это влияет на объем запросов

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

Например, если вы зададите для параметра minimumFetchInterval значение 24 часа и пользователь откроет ваше приложение 5 или 10 раз за день, SDK автоматически выполнит запуски со второго по десятый из локального кеша. Таким образом, количество запросов к сети для этого пользователя уменьшится с 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 к широким хукам жизненного цикла интерфейса, например каждый раз, когда загружается экран, переключается вкладка или представление получает фокус.

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

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

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

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

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