Hemat daya dan baterai

Kata kunci: wearos, daya, baterai, performa

Efisiensi daya sangat penting di Wear OS. Prinsip desain Wear OS secara signifikan berfokus pada penggunaan daya perangkat karena smartwatch adalah faktor bentuk kecil, yang dimaksudkan untuk interaksi singkat.

Dibandingkan dengan perangkat seluler yang lebih besar, perangkat Wear OS memiliki baterai yang lebih kecil, sehingga pengurangan daya baterai akan lebih terlihat. Selain itu, pengguna memerlukan lebih banyak upaya untuk mengisi daya perangkat Wear OS, dibandingkan dengan perangkat seluler. Meskipun pengguna dapat mengisi daya perangkat seluler mereka pada berbagai interval sepanjang hari, mereka perlu melepaskan perangkat Wear OS dari tubuh mereka sebelum mengisi daya perangkat.

Untuk meningkatkan efisiensi daya aplikasi, ikuti praktik terbaik desain berikut:

• Desain aplikasi Anda harus memanfaatkan faktor bentuk Wear OS dengan baik. Aplikasi ini tidak boleh menyalin aplikasi seluler Anda secara langsung.
• Gunakan aplikasi seluler yang sudah ada untuk membantu kasus penggunaan tertentu. Misalnya, internet dan sinkronisasi di smartwatch mahal; pertimbangkan apakah perangkat seluler dapat melakukan tugas berat, dan perangkat Wear OS menerima perubahan data.
• Desain kasus penggunaan Anda untuk interaksi yang lebih singkat.
• Pertimbangkan peristiwa Wear OS yang Anda gunakan, dan seberapa sering peristiwa ini terjadi.

• Jika memungkinkan, tunda pekerjaan aplikasi Anda hingga smartwatch mengisi daya. Hal ini terutama berlaku untuk tugas yang memerlukan banyak data, seperti menyinkronkan data, dan mengatur database.

  Jika perangkat sedang diisi dayanya dan memiliki koneksi Wi-Fi, jadwalkan tugas untuk mengambil data, gambar, dan update secara offline yang kemungkinan ingin dilihat pengguna di aplikasi Anda.

Panduan daya ini membantu Anda memahami kapan dan bagaimana sistem menjalankan aplikasi, serta cara membatasi runtime dan konsumsi daya baterai aplikasi. Untuk mempelajari lebih lanjut cara tindakan tertentu dicapai—seperti memuat aplikasi atau men-scroll daftar—buka panduan yang terkait dengan performa, seperti panduan performa Compose di Wear OS.

Memantau penggunaan baterai dari waktu ke waktu

Untuk menganalisis statistik baterai perangkat Wear OS yang menjalankan aplikasi Anda, masukkan perintah berikut di jendela terminal pada mesin pengembangan Anda:

adb shell dumpsys batterystats

Library di GitHub menampilkan parser statistik baterai, yang dapat berguna untuk dijalankan bersama dengan perintah ini.

Peristiwa yang memengaruhi masa pakai baterai

Sebelum memikirkan aplikasi Anda secara khusus, sebaiknya pikirkan secara lebih umum peristiwa yang menggunakan daya di perangkat Wear OS.

Tabel berikut menunjukkan efek relatif pada masa pakai baterai di beberapa peristiwa umum di aplikasi Wear OS. Pengurangan daya yang tepat bervariasi di antara perangkat.

Peristiwa	Dampak pada masa pakai baterai	Cara memitigasi
Mengakses jaringan, termasuk LTE dan Wi-Fi	Sangat tinggi	Tunda akses jaringan yang tidak penting hingga perangkat mengisi daya.
Mengaktifkan layar dan memulai mode interaktif	Tinggi	Jangan mendorong pengguna untuk membiarkan layar menyala lebih lama dari yang diperlukan. Berikan pengalaman yang menggunakan mode selalu aktif, yang juga dikenal sebagai mode standby.
Mengakses sensor GPS	Tinggi	Jika memungkinkan, tunggu hingga pengguna meminta akses GPS.
Menjaga penggunaan CPU tetap tinggi	Tinggi	Menggunakan flow menggunakan Jetpack Compose.
Mengakses sensor detak jantung	Sedang	Gunakan waktu aktif prosesor saat menerima callback dari API sensor, seperti saat menggunakan Fitur Kesehatan di Wear OS.
Mengakses perangkat lain melalui Bluetooth	Sedang	Buat sesi tetap singkat.
Menahan wakelock	Sedang	Kurangi pembuatan wakelock manual dan gunakan WorkManager.

Meminimalkan waktu layar menyala

Di aplikasi Wear OS, ikuti prinsip penggunaan layar berikut:

• Kunci layar aktif: Hindari jika memungkinkan. Untuk menguji, nonaktifkan Layar always-on di setelan sistem, dan amati apakah layar mati dalam periode waktu tunggu.
• Animasi: Minimalkan animasi yang rumit, dan fokuslah pada transisi singkat untuk tampilan yang lebih profesional. Secara khusus, hindari animasi dan loop yang berjalan lama. Jika loop diperlukan, tambahkan jeda di antara loop yang setidaknya sama panjangnya dengan animasi itu sendiri.

• Waktu aktif dalam mode standby: Dukung selalu aktif jika diperlukan, seperti untuk kasus penggunaan kebugaran. Jika aplikasi Anda memerlukan selalu aktif, pastikan aplikasi Anda melakukan hal berikut saat perangkat dalam mode standby:

  • Mengurangi persentase layar perangkat yang menyala.
  • Tidak menampilkan animasi.
  • Tidak memperbarui konten layar, kecuali selama callback onAmbientUpdate().

Meminimalkan penggunaan CPU

Di aplikasi Wear OS, ikuti prinsip penggunaan CPU berikut:

• Buat penggunaan tetap singkat.
• Mengelompokkan operasi terkait, untuk memaksimalkan waktu saat proses aplikasi Anda tidak ada aktivitas.

Meminimalkan wakelock

Pada umumnya, hindari operasi apa pun yang mencegah aplikasi Anda tidur, seperti wakelock. Misalnya, di aplikasi kesehatan & kebugaran, olahraga yang berjalan lama tidak memerlukan wakelock. Gunakan waktu aktif prosesor saat menerima callback dari API sensor, seperti saat menggunakan Fitur Kesehatan di Wear OS.

Ada beberapa kasus saat Anda boleh mendapatkan wakelock, seperti saat aplikasi Anda melakukan salah satu hal berikut:

• Memutar media di latar belakang.
• Menggunakan WorkManager atau JobScheduler. (Sistem menahan wakelock untuk Anda saat menjalankan tugas di latar belakang.)

Battery Historian memungkinkan Anda melihat setiap kemunculan wakelock yang lama, serta ringkasan jumlah total dan durasi wakelock yang ditahan. Periksa jumlah dan durasi wakelock yang disimpan aplikasi Anda, dan bandingkan informasi ini dengan pola penggunaan interaktif aplikasi Anda:

• Periksa wakelock yang tidak terduga.
• Jika durasi lebih lama dari yang diharapkan, pertimbangkan apakah tugas diblokir pada beberapa dependensi, seperti ketersediaan jaringan.

Memeriksa cara aplikasi menjadi tidak aktif

Pertimbangkan apa yang dilakukan aplikasi aktif saat peristiwa perangkat utama terjadi, seperti berikut:

• Layar akan mati dan perangkat akan memasuki mode standby.

• Aplikasi ditutup dengan menggeser.

  Catatan: Saat pengguna menutup aplikasi dengan menggeser, sistem terkadang menunggu beberapa menit sebelum menghentikan proses aplikasi.

Untuk menganalisis aktivitas aplikasi, gunakan alat yang ditampilkan di bagian berikut.

Power Profiler

Power Profiler dapat diakses di menu Android Studio dengan memilih View > Tool Windows > Profiler:

1. Periksa rekaman aktivitas sistem saat layar mati dan perangkat masuk ke mode standby.
2. Cari pekerjaan yang berlanjut, dan tingkat penggunaan CPU perangkat.

Perfetto

Perfetto memungkinkan Anda merekam rekaman aktivitas, lalu memeriksa aplikasi untuk melihat apakah ada thread yang melakukan pekerjaan saat layar dinonaktifkan, perangkat memasuki mode standby, atau pengguna menutup aktivitas aplikasi Anda.

Tentukan peristiwa kustom untuk menandai peristiwa penting aplikasi Anda, termasuk peristiwa khusus domain. Untuk aplikasi media, hal ini akan mencakup tugas seperti mengambil playlist, mendownload item media tertentu, memulai pemutaran, dan menghentikan pemutaran. Dengan menentukan peristiwa ini, Anda dapat melihatnya di Perfetto dan membandingkan waktunya dengan penggunaan CPU dan daya aplikasi Anda.

Menganalisis tugas terjadwal aplikasi

Tugas terjadwal, menggunakan WorkManager, memungkinkan Anda melakukan pekerjaan latar belakang di aplikasi. Meskipun beberapa pekerjaan latar belakang harus bersifat berkala, jangan jalankan tugas terlalu sering atau dalam durasi yang lama, karena hal ini dapat menguras baterai perangkat.

Gunakan Battery Historian untuk memeriksa eksekusi Tugas Terjadwal, baik secara keseluruhan (Statistik sistem > Statistik Jobscheduler) maupun menurut aplikasi (Statistik aplikasi > Tugas terjadwal). Periksa jumlah total dan durasi total:

• Jika tugas berjalan sangat sering, pertimbangkan untuk mengurangi frekuensi ini.
• Pastikan total waktu eksekusi sesuai dengan yang Anda harapkan, dan tidak lebih lama secara signifikan.

Selain itu, periksa grafik Battery Historian, dengan melihat setiap entri JobScheduler. Saat Anda menahan kursor di entri tertentu, Battery Historian akan menampilkan pemilik tugas yang sedang dijalankan. Pertimbangkan hal berikut:

• Untuk aplikasi Anda, durasi eksekusi harus masuk akal.
• Pertimbangkan apakah tugas terjadi saat aplikasi Anda berjalan, atau apakah tugas mewakili pekerjaan latar belakang berkala.

Sensor

Perangkat Wear OS memiliki banyak sensor yang berbeda, seperti GPS. Dalam sebagian besar kasus, gunakan Fitur Kesehatan di Wear OS, bukan berinteraksi langsung dengan SensorManager. Dalam banyak kasus, Fitur Kesehatan mengelompokkan data secara cerdas untuk meningkatkan performa baterai.

Untuk menganalisis penggunaan sensor di aplikasi, jalankan perintah berikut di jendela terminal pada mesin pengembangan Anda:

adb shell dumpsys sensorservice

Hasil perintah ini menampilkan hal berikut:

• Pendaftaran sensor saat ini dan sebelumnya.
• Konfigurasi sensor, termasuk pengelompokan jika ditetapkan.
• Data yang baru-baru ini diambil sampelnya.

Menguji pembatalan pendaftaran dari sensor

Untuk memeriksa apakah aplikasi Anda berhenti mengambil data sensor seperti yang diharapkan, uji skenario berikut:

1. Usap untuk menutup aplikasi.
2. Ketuk layar dengan telapak tangan Anda. Tindakan ini akan menonaktifkan layar atau menempatkan layar dalam mode standby.

Gunakan perintah ADB dari bagian sebelumnya untuk memeriksa apakah sensor ditampilkan dengan benar sebagai tidak terdaftar.

Lapisan Data

Saat menggunakan Data Layer API, setiap transmisi menggunakan sejumlah daya. Secara khusus, jika Anda menggunakan API ini untuk mengirim data, aplikasi Anda harus aktif untuk menerima data. Karena alasan ini, gunakan API ini secara hati-hati.

Catatan: Pertimbangkan untuk mengirim dan menerima beberapa data di lain waktu, menggunakan operasi sinkronisasi WorkManager, saat perangkat Wear OS sedang diisi dayanya.

Beberapa praktik terbaik tambahan untuk menggunakan Data Layer API mencakup hal berikut:

• Tunggu hingga aplikasi aktif sebelum menyiapkan pemroses menggunakan WearableListenerService.

• Mengirim perubahan status, bukan mengonfigurasi update cepat. Perubahan status ini memungkinkan perangkat Wear OS melakukan penghitungan data lokal, seperti saat sesi olahraga dimulai.

  Hanya kirim perubahan status yang mengupdate UI Anda. Misalnya, jika layar aktivitas Anda hanya menampilkan "kilometers ran" ke satu tempat desimal, jangan kirim perubahan status ke Wear OS setiap kali pengguna memindahkan satu meter ke depan.

Untuk menganalisis penggunaan Data Layer API di aplikasi Anda, jalankan perintah berikut di jendela terminal di mesin pengembangan Anda:

adb shell dumpsys activity service WearableService

Hasil perintah ini mencakup hal berikut:

• RpcService: Memungkinkan Anda melihat seberapa sering dan jalur mana yang dipanggil menggunakan MessageClient.
• DataService: Memungkinkan Anda melihat seberapa sering item data ditetapkan menggunakan DataClient.

Aplikasi Kesehatan dan Kebugaran

Jika Anda mengelola aplikasi kesehatan dan kebugaran, gunakan Fitur Kesehatan untuk mengoptimalkan penggunaan sensor aplikasi Anda.

• Untuk ExerciseClient, gunakan Battery Historian untuk memverifikasi perilaku yang benar dalam mode standby. Pastikan aplikasi Anda tidak aktif lebih sering daripada setiap satu atau dua menit untuk menerima data ExerciseUpdate.
• Untuk pemantauan kesehatan umum sepanjang hari, gunakan PassiveMonitoringClient, seperti yang dijelaskan dalam panduan tentang cara memantau data kesehatan dan kebugaran di latar belakang.

Kartu dan detail

Jika aplikasi Anda mendukung kartu atau detail, ikuti praktik terbaik berikut:

• Nonaktifkan muat ulang otomatis, atau tingkatkan kecepatan muat ulang menjadi 2 jam atau lebih lama.
• Gunakan Firebase Cloud Messaging (FCM) atau tugas yang dijadwalkan dengan tepat untuk mengirim pembaruan data. Berhati-hatilah untuk mencegah kecepatan update yang cepat, yang dapat menyebabkan sistem menjadwalkan pekerjaan berulang dengan kecepatan lebih cepat daripada pengguna atau platform dapat mengakses data yang diperlukan untuk melakukan pekerjaan tersebut.
• Jangan menjadwalkan pekerjaan untuk kartu atau detail saat pengguna tidak berinteraksi dengannya.
• Gunakan pendekatan offline-first.
• Membagikan satu database di seluruh aplikasi utama, kartu, dan detail. Hal ini juga membantu data tetap konsisten di seluruh platform UI.