Praktik terbaik untuk efisiensi pengambilan Remote Config

Firebase Remote Config memberi Anda kontrol yang fleksibel atas perilaku dan tampilan aplikasi. Hal ini memungkinkan kemampuan seperti peluncuran fitur dan pengujian A/B lintas platform untuk aplikasi Anda, semuanya tanpa men-deploy versi baru atau membuka beberapa update app store.

Baik Anda sedang membuat prototipe, menjalankan startup yang berkembang, atau mengelola aplikasi perusahaan dalam skala besar, mengelola volume pengambilan data jaringan sangat penting untuk memberikan pengalaman pengguna yang cepat dan responsif. Pengelolaan konfigurasi yang efisien mengurangi latensi cold start, menghemat penggunaan data dan baterai klien, serta mencegah overhead jaringan yang tidak perlu. Selain itu, jika basis pengguna Anda berkembang pesat dan meningkatkan penggunaan di masa mendatang, menyederhanakan integrasi Remote Config akan membantu memastikan penggunaan Anda tetap efisien.

Anda dapat mengurangi traffic permintaan jaringan sisi klien secara signifikan dengan menyempurnakan cara dan waktu aplikasi mengambil parameter serta waktu aplikasi mengaktifkannya.

Beralih ke pola "ambil untuk sesi berikutnya"

Pola umum yang harus dihindari adalah penggunaan panggilan fetchAndActivate—yang mengambil nilai baru melalui jaringan dan mengaktifkannya—pada setiap peluncuran aplikasi yang dikombinasikan dengan periode habis masa berlaku cache yang singkat untuk nilai yang sebelumnya diambil (misalnya, 15 menit hingga satu jam). Model mental di balik pendekatan ini adalah setiap kali pengguna membuka aplikasi, mereka selalu mendapatkan nilai terbaru yang diambil dan diterapkan. Meskipun ada saatnya update langsung diperlukan (misalnya, menjalankan kampanye penjualan harian atau promosi game), penting untuk menyeimbangkan tujuan tersebut dengan dampak pada performa aplikasi dan penggunaan pengambilan data.

Pendekatan ini memaksakan panggilan jaringan baru setiap kali cache berakhir, sehingga menghasilkan volume pengambilan yang tinggi bagi pengguna yang membuka aplikasi beberapa kali sehari.

Sebagai gantinya, pertimbangkan untuk menggunakan panggilan fetch dan activate secara terpisah dengan interval pengambilan minimum yang lebih tinggi untuk menerapkan model "ambil untuk sesi berikutnya". Anda tetap dapat menggunakan fetchAndActivate dengan interval pengambilan minimum yang lebih tinggi karena fetch hanya mengeksekusi permintaan jaringan jika cache dibatalkan, tetapi menggunakan dua panggilan secara terpisah akan membantu memantapkan pola dan menjadikannya sebagai praktik standar dalam proses pengembangan aplikasi Anda. Selain itu, dengan mengaktifkan secara terpisah, Anda tidak berisiko menerapkan nilai konfigurasi di tengah sesi dan mengganggu pengalaman pengguna.

Cara kerja pendekatan ini

  • Segera aktifkan saat diluncurkan: Terapkan konfigurasi yang di-cache dari sesi sebelumnya secara instan (penundaan jaringan 0 md).
  • Mengambil di latar belakang dengan cache yang lebih lama (misalnya, lebih dari 12 atau 24 jam): Minta konfigurasi yang diupdate secara asinkron untuk memperbarui cache lokal untuk sesi berikutnya.

Cara ini mengoptimalkan volume pengambilan

Interval pengambilan minimum yang lebih panjang akan menghasilkan lebih sedikit permintaan pengambilan. Mengambil nilai baru untuk sesi berikutnya dan mengaktifkan nilai yang di-cache untuk sesi saat ini berarti aplikasi Anda dimuat secara instan dari cache lokal selama periode validasi yang lebih lama, sehingga menghasilkan pengalaman pengguna yang lebih baik.

Misalnya, jika Anda menyetel minimumFetchInterval ke 24 jam dan pengguna membuka aplikasi Anda 5 atau 10 kali dalam satu hari, SDK akan otomatis memenuhi peluncuran 2 hingga 10 langsung dari cache lokal—mengurangi jumlah permintaan jaringan harian pengguna tersebut dari 10 atau lebih pengambilan data menjadi 1.

Contoh berikut menunjukkan tampilan implementasi ini untuk Android, platform Apple, dan aplikasi web:

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

Web

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

Menerapkan pengambilan data "smart" bersyarat

Jika pola "ambil untuk sesi berikutnya" menyebabkan terlalu banyak latensi antara saat Anda perlu memperbarui nilai Remote Config dan saat nilai tersebut tersedia di aplikasi klien, pertimbangkan untuk menerapkan pengambilan "pintar" bersyarat.

Untuk menerapkan hal ini secara efektif, hindari melampirkan pemicu fetch ke hook siklus proses UI yang luas, seperti setiap kali layar dimuat, tab beralih, atau tampilan mendapatkan fokus.

Sebagai gantinya, picu permintaan pengambilan secara selektif berdasarkan tindakan atau status aplikasi eksplisit, seperti:

  • Peristiwa login pengguna
  • Bertransisi ke alur pengguna tertentu tempat parameter Anda digunakan (misalnya, memasuki funnel checkout atau naik level dalam game)

Sebaliknya, hindari memicu permintaan pengambilan untuk tindakan rutin seperti:

  • Saat pengguna membuka aplikasi atau memulai sesi baru
  • Saat aplikasi bertransisi antara status latar belakang dan latar depan

Langkah berikutnya