Permintaan yang dibuat oleh aplikasi Anda ke jaringan adalah salah satu penyebab utama baterai cepat habis karena permintaan tersebut mengaktifkan radio seluler atau Wi-Fi yang boros daya. Selain daya yang diperlukan untuk mengirim dan menerima paket, radio ini menggunakan daya tambahan hanya untuk mengaktifkan dan tetap aktif. Sesuatu yang sederhana seperti permintaan jaringan setiap 15 detik dapat membuat radio seluler aktif secara terus menerus dan menghabiskan daya baterai dengan cepat.
Ada tiga jenis umum update reguler:
- Dimulai oleh pengguna. Melakukan update berdasarkan beberapa perilaku pengguna, seperti gestur tarik untuk memuat ulang.
- Dimulai aplikasi. Melakukan update secara berulang.
- Dimulai oleh server. Melakukan update sebagai respons terhadap notifikasi dari server.
Topik ini membahas setiap hal tersebut dan membahas cara tambahan untuk mengoptimalkannya guna mengurangi pemakaian baterai.
Mengoptimalkan permintaan yang dimulai pengguna
Permintaan yang dimulai pengguna biasanya terjadi sebagai respons terhadap beberapa perilaku pengguna. Misalnya, aplikasi yang digunakan untuk membaca artikel berita terbaru dapat memungkinkan pengguna melakukan gestur tarik untuk memuat ulang guna memeriksa artikel baru. Anda dapat menggunakan teknik berikut untuk merespons permintaan yang dimulai pengguna sekaligus mengoptimalkan penggunaan jaringan.
Membatasi permintaan pengguna
Anda dapat mengabaikan beberapa permintaan yang dimulai pengguna jika tidak diperlukan, seperti beberapa gestur tarik untuk memuat ulang dalam jangka waktu singkat untuk memeriksa data baru saat data saat ini masih baru. Bertindak untuk setiap dapat menyia-nyiakan banyak daya dengan membuat radio tetap aktif. J pendekatan yang lebih efisien adalah membatasi permintaan yang dimulai oleh pengguna sehingga hanya satu permintaan yang dapat dibuat selama periode waktu tertentu, mengurangi seberapa sering radio digunakan.
Menggunakan cache
Dengan menyimpan data aplikasi dalam cache, Anda membuat salinan lokal informasi yang perlu dirujuk oleh aplikasi. Kemudian, aplikasi Anda dapat mengakses salinan lokal informasi yang sama beberapa kali tanpa harus membuka koneksi jaringan untuk membuat permintaan baru.
Anda harus menyimpan data dalam cache seaktif mungkin, termasuk resource statis dan download on demand seperti gambar ukuran penuh. Anda dapat menggunakan HTTP header cache untuk memastikan strategi penyimpanan cache Anda tidak mengakibatkan aplikasi menampilkan data usang. Untuk mengetahui informasi selengkapnya tentang menyimpan respons jaringan ke dalam cache, lihat Menghindari download yang berlebihan.
Di Android 11 dan yang lebih tinggi, aplikasi Anda dapat menggunakan set data besar yang sama dengan yang digunakan aplikasi lain untuk kasus penggunaan seperti machine learning dan pemutaran media. Saat memerlukan akses ke set data bersama, aplikasi Anda dapat terlebih dahulu memeriksa versi yang di-cache sebelum mencoba mendownload salinan baru. Untuk mempelajari lebih lanjut tentang {i>dataset<i} bersama, lihat Mengakses set data bersama.
Mengurangi frekuensi download data lebih banyak dengan menggunakan bandwidth lebih besar
Ketika terhubung melalui radio nirkabel, {i>bandwidth<i} yang lebih tinggi umumnya harga biaya baterai yang lebih tinggi, yang berarti bahwa 5G biasanya mengonsumsi lebih banyak energi daripada LTE, yang pada gilirannya lebih mahal daripada 3G.
Artinya, meskipun status radio yang mendasarinya bervariasi berdasarkan teknologi radio, secara umum berbicara tentang dampak baterai relatif terhadap keadaan {i>tail-time<i} perubahan lebih besar untuk radio dengan bandwidth lebih tinggi. Untuk mengetahui informasi selengkapnya tentang tail-time, lihat The radio state komputer.
Pada saat yang sama, bandwidth yang lebih tinggi berarti Anda dapat mengambil lebih banyak data secara agresif, mengunduh lebih banyak data dalam waktu yang sama. Mungkin lebih sedikit secara intuitif, karena biaya baterai {i>tail-time<i} relatif lebih tinggi, itu juga lebih efisien untuk membuat radio tetap aktif untuk waktu yang lebih lama selama setiap transfer guna mengurangi frekuensi pembaruan.
Misalnya, jika radio LTE memiliki dua kali lipat bandwidth dan menggunakan energi dua kali lipat dari 3G, Anda harus mendownload data empat kali lebih banyak dalam setiap sesi—atau berpotensi sebanyak 10 MB. Saat mendownload data sebanyak ini, sebaiknya pertimbangkan pengaruh dari melakukan prefetch di penyimpanan lokal yang tersedia dan hapus cache prefetch Anda secara teratur.
Anda dapat menggunakan
ConnectivityManager
untuk mendaftar
pemroses untuk jaringan default, dan
TelephonyManager
untuk mendaftar
PhoneStateListener
ke
menentukan jenis koneksi
perangkat saat ini. Setelah jenis koneksi diketahui,
Anda dapat mengubah rutinitas pengambilan data:
Kotlin
val cm = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager val tm = getSystemService(Context.TELEPHONY_SERVICE) as TelephonyManager private var hasWifi = false private var hasCellular = false private var cellModifier: Float = 1f private val networkCallback = object : ConnectivityManager.NetworkCallback() { // Network capabilities have changed for the network override fun onCapabilitiesChanged( network: Network, networkCapabilities: NetworkCapabilities ) { super.onCapabilitiesChanged(network, networkCapabilities) hasCellular = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) hasWifi = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_WIFI) } } private val phoneStateListener = object : PhoneStateListener() { override fun onPreciseDataConnectionStateChanged( dataConnectionState: PreciseDataConnectionState ) { cellModifier = when (dataConnectionState.networkType) { TelephonyManager.NETWORK_TYPE_LTE or TelephonyManager.NETWORK_TYPE_HSPAP -> 4f TelephonyManager.NETWORK_TYPE_EDGE or TelephonyManager.NETWORK_TYPE_GPRS -> 1/2f else -> 1f } } private class NetworkState { private var defaultNetwork: Network? = null private var defaultCapabilities: NetworkCapabilities? = null fun setDefaultNetwork(network: Network?, caps: NetworkCapabilities?) = synchronized(this) { defaultNetwork = network defaultCapabilities = caps } val isDefaultNetworkWifi get() = synchronized(this) { defaultCapabilities?.hasTransport(TRANSPORT_WIFI) ?: false } val isDefaultNetworkCellular get() = synchronized(this) { defaultCapabilities?.hasTransport(TRANSPORT_CELLULAR) ?: false } val isDefaultNetworkUnmetered get() = synchronized(this) { defaultCapabilities?.hasCapability(NET_CAPABILITY_NOT_METERED) ?: false } var cellNetworkType: Int = TelephonyManager.NETWORK_TYPE_UNKNOWN get() = synchronized(this) { field } set(t) = synchronized(this) { field = t } private val cellModifier: Float get() = synchronized(this) { when (cellNetworkType) { TelephonyManager.NETWORK_TYPE_LTE or TelephonyManager.NETWORK_TYPE_HSPAP -> 4f TelephonyManager.NETWORK_TYPE_EDGE or TelephonyManager.NETWORK_TYPE_GPRS -> 1 / 2f else -> 1f } } val prefetchCacheSize: Int get() = when { isDefaultNetworkWifi -> MAX_PREFETCH_CACHE isDefaultNetworkCellular -> (DEFAULT_PREFETCH_CACHE * cellModifier).toInt() else -> DEFAULT_PREFETCH_CACHE } } private val networkState = NetworkState() private val networkCallback = object : ConnectivityManager.NetworkCallback() { // Network capabilities have changed for the network override fun onCapabilitiesChanged( network: Network, networkCapabilities: NetworkCapabilities ) { networkState.setDefaultNetwork(network, networkCapabilities) } override fun onLost(network: Network?) { networkState.setDefaultNetwork(null, null) } } private val telephonyCallback = object : TelephonyCallback(), TelephonyCallback.PreciseDataConnectionStateListener { override fun onPreciseDataConnectionStateChanged(dataConnectionState: PreciseDataConnectionState) { networkState.cellNetworkType = dataConnectionState.networkType } } connectivityManager.registerDefaultNetworkCallback(networkCallback) telephonyManager.registerTelephonyCallback(telephonyCallback) private val prefetchCacheSize: Int get() { return when { hasWifi -> MAX_PREFETCH_CACHE hasCellular -> (DEFAULT_PREFETCH_CACHE * cellModifier).toInt() else -> DEFAULT_PREFETCH_CACHE } } }
Java
ConnectivityManager cm = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE); TelephonyManager tm = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE); private boolean hasWifi = false; private boolean hasCellular = false; private float cellModifier = 1f; private ConnectivityManager.NetworkCallback networkCallback = new ConnectivityManager.NetworkCallback() { @Override public void onCapabilitiesChanged( @NonNull Network network, @NonNull NetworkCapabilities networkCapabilities ) { super.onCapabilitiesChanged(network, networkCapabilities); hasCellular = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR); hasWifi = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_WIFI); } }; private PhoneStateListener phoneStateListener = new PhoneStateListener() { @Override public void onPreciseDataConnectionStateChanged( @NonNull PreciseDataConnectionState dataConnectionState ) { switch (dataConnectionState.getNetworkType()) { case (TelephonyManager.NETWORK_TYPE_LTE | TelephonyManager.NETWORK_TYPE_HSPAP): cellModifier = 4; Break; case (TelephonyManager.NETWORK_TYPE_EDGE | TelephonyManager.NETWORK_TYPE_GPRS): cellModifier = 1/2.0f; Break; default: cellModifier = 1; Break; } } }; cm.registerDefaultNetworkCallback(networkCallback); tm.listen( phoneStateListener, PhoneStateListener.LISTEN_PRECISE_DATA_CONNECTION_STATE ); public int getPrefetchCacheSize() { if (hasWifi) { return MAX_PREFETCH_SIZE; } if (hasCellular) { return (int) (DEFAULT_PREFETCH_SIZE * cellModifier); } return DEFAULT_PREFETCH_SIZE; }
Mengoptimalkan permintaan yang dimulai oleh aplikasi
Permintaan yang dimulai aplikasi biasanya terjadi sesuai jadwal, seperti aplikasi yang mengirim log atau analisis ke layanan backend. Saat menangani permintaan yang dimulai aplikasi, pertimbangkan prioritas permintaan tersebut, apakah permintaan tersebut dapat digabungkan bersama, dan apakah permintaan tersebut dapat ditangguhkan hingga perangkat diisi daya atau terhubung ke jaringan tanpa kuota. Permintaan ini dapat dioptimalkan dengan penjadwalan dan dengan menggunakan {i>library<i} seperti WorkManager.
Permintaan jaringan batch
Pada perangkat seluler, proses menyalakan radio, membuat koneksi, dan menjaga agar radio tetap aktif memakai daya dalam jumlah besar. Oleh karena itu, memproses masing-masing permintaan secara acak dapat menghabiskan daya yang signifikan dan mengurangi masa pakai baterai. Pendekatan yang lebih efisien adalah membuat antrean serangkaian permintaan jaringan dan memprosesnya secara bersamaan. Dengan pendekatan ini, sistem hanya akan menggunakan daya yang diperlukan untuk menyalakan radio satu kali, dan tetap mendapatkan semua data yang diminta oleh aplikasi.
Menggunakan WorkManager
Anda dapat menggunakan library WorkManager
untuk melakukan pekerjaan sesuai jadwal yang efisien
yang mempertimbangkan apakah kondisi tertentu terpenuhi, seperti ketersediaan jaringan
dan status daya. Misalnya, Anda memiliki
Subclass Worker
dipanggil
DownloadHeadlinesWorker
yang mengambil judul berita terbaru. Pekerja ini
dapat dijadwalkan untuk berjalan setiap jam, asalkan perangkat terhubung ke
jaringan tanpa kuota dan baterai perangkat tidak rendah, dengan strategi percobaan ulang kustom
jika ada masalah saat mengambil data, seperti yang ditunjukkan di bawah:
Kotlin
val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresBatteryNotLow(true) .build() val request = PeriodicWorkRequestBuilder<DownloadHeadlinesWorker>(1, TimeUnit.HOURS) .setConstraints(constraints) .setBackoffCriteria(BackoffPolicy.LINEAR, 1L, TimeUnit.MINUTES) .build() WorkManager.getInstance(context).enqueue(request)
Java
Constraints constraints = new Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresBatteryNotLow(true) .build(); WorkRequest request = new PeriodicWorkRequest.Builder(DownloadHeadlinesWorker.class, 1, TimeUnit.HOURS) .setBackoffCriteria(BackoffPolicy.LINEAR, 1L, TimeUnit.MINUTES) .build(); WorkManager.getInstance(this).enqueue(request);
Selain WorkManager, platform Android menyediakan beberapa alat lainnya untuk membantu Anda membuat jadwal yang efisien guna menyelesaikan tugas jaringan, seperti sebagai polling. Untuk mempelajari lebih lanjut cara menggunakan alat ini, lihat Panduan untuk pemrosesan latar belakang.
Mengoptimalkan permintaan yang dimulai server
Permintaan yang dimulai server biasanya terjadi sebagai respons terhadap notifikasi dari server. Misalnya, aplikasi yang digunakan untuk membaca artikel berita terbaru mungkin menerima notifikasi tentang sekumpulan artikel baru yang sesuai dengan preferensi personalisasi, yang kemudian diunduh.
Mengirim pembaruan server dengan Firebase Cloud Messaging
Firebase Cloud Messaging (FCM) adalah mekanisme ringan yang digunakan untuk mengirimkan data dari server ke instance aplikasi tertentu. Dengan FCM, server dapat memberi tahu aplikasi yang berjalan di perangkat tertentu bahwa ada data baru yang tersedia.
Dibandingkan dengan polling, ketika aplikasi Anda harus melakukan ping ke server secara teratur untuk meminta data baru, model yang digerakkan oleh peristiwa ini akan memungkinkan aplikasi Anda membuat koneksi baru hanya jika mengetahui ada data untuk didownload. Model ini meminimalkan koneksi yang tidak perlu dan mengurangi latensi saat memperbarui informasi dalam aplikasi Anda.
FCM diimplementasikan menggunakan koneksi TCP/IP persisten. Penggunaan FCM akan meminimalkan jumlah koneksi persisten dan memungkinkan platform mengoptimalkan bandwidth serta meminimalkan dampak terkait masa pakai baterai.