Hemat daya dan baterai

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

Dibandingkan dengan perangkat seluler yang lebih besar, perangkat Wear OS memiliki baterai yang lebih kecil, sehingga kehabisan baterai 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 dengan berbagai interval sepanjang hari, mereka harus melepaskan perangkat Wear OS dari tubuh sebelum mengisi daya perangkat.

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

  • Desain aplikasi Anda harus memanfaatkan faktor bentuk Wear OS dengan baik. Kode ini tidak boleh langsung menyalin aplikasi seluler Anda.
  • Menggunakan aplikasi seluler yang ada untuk membantu kasus penggunaan tertentu. Misalnya, internet dan sinkronisasi di smartwatch berbiaya mahal; pertimbangkan apakah perangkat seluler dapat melakukan tugas berat, dan perangkat Wear OS menerima perubahan data.
  • Rancang kasus penggunaan Anda untuk interaksi yang lebih singkat.
  • Pertimbangkan peristiwa Wear OS mana yang Anda gunakan, dan seberapa sering peristiwa ini terjadi.
  • Jika memungkinkan, tunda pekerjaan aplikasi hingga smartwatch diisi dayanya. Hal ini terutama berlaku untuk tugas-tugas intensif data, seperti menyinkronkan data, dan mengatur database.

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

Panduan daya ini membantu Anda memahami waktu dan cara sistem menjalankan aplikasi Anda, serta cara membatasi runtime dan pengurasan baterai aplikasi. Untuk mempelajari lebih lanjut cara tindakan tertentu dicapai—seperti memuat aplikasi atau men-scroll daftar—kunjungi 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 memiliki Parser statistik baterai, yang berguna untuk dijalankan bersama dengan perintah ini.

Peristiwa yang memengaruhi masa pakai baterai

Sebelum memikirkan aplikasi secara khusus, ada baiknya mempertimbangkan secara lebih umum tentang peristiwa yang menghabiskan daya pada perangkat Wear OS.

Tabel berikut menunjukkan efek relatif masa pakai baterai di beberapa peristiwa umum di aplikasi Wear OS. Pengurasan daya yang tepat berbeda-beda di setiap perangkat.

Peristiwa Dampak terhadap masa pakai baterai Cara melakukan mitigasi
Mengakses jaringan, termasuk LTE dan Wi-Fi Sangat tinggi Tunda akses jaringan yang tidak penting hingga perangkat diisi dayanya.
Nyalakan layar dan mulai mode interaktif Tinggi Jangan dorong pengguna untuk membuat layar aktif lebih lama dari yang diperlukan. Memberikan 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 Medium Gunakan waktu terbangun prosesor saat menerima callback dari API sensor, seperti saat menggunakan Fitur Kesehatan di Wear OS.
Mengakses perangkat lain melalui Bluetooth Medium Buat sesi yang singkat.
Tahan penguncian layar saat aktif Medium Kurangi pembuatan penguncian layar saat aktif secara manual dan gunakan WorkManager.

Minimalkan waktu pemakaian perangkat

Di aplikasi Wear OS, ikuti prinsip penggunaan layar berikut:

  • Kunci layar: Hindari jika memungkinkan. Untuk menguji, nonaktifkan Layar Selalu aktif di setelan sistem, dan amati apakah layar mati selama periode waktu tunggu.
  • Animasi: Minimalkan animasi yang rumit, dan fokuskan pada transisi singkat untuk tampilan yang lebih profesional. Khususnya, hindari animasi dan loop yang berjalan lama. Jika diperlukan loop, tambahkan jeda di antara loop, yang setidaknya sama panjangnya dengan animasi itu sendiri.
  • Waktu terbangun dalam mode standby: Dukungan selalu aktif jika diperlukan, seperti untuk kasus penggunaan kebugaran. Jika aplikasi Anda harus selalu aktif, pastikan aplikasi 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:

  • Gunakan waktu yang singkat.
  • Kelompokkan operasi terkait, untuk memaksimalkan waktu saat proses aplikasi tidak ada aktivitas.

Meminimalkan penguncian layar saat aktif

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

Ada beberapa kasus yang memungkinkan untuk mendapatkan penguncian layar saat aktif, seperti saat aplikasi Anda melakukan salah satu hal berikut:

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

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

  • Periksa apakah ada penguncian layar saat aktif yang tidak terduga.
  • Jika durasinya lebih lama dari yang diharapkan, pertimbangkan apakah pekerjaan diblokir pada beberapa dependensi, seperti ketersediaan jaringan.

Memeriksa cara aplikasi menjadi tidak aktif

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

  • Layar akan mati dan perangkat memasuki mode standby.
  • Aplikasi akan digeser-geser.

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

Energy Profiler

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

  1. Periksa pelacakan sistem saat layar mati dan perangkat memasuki mode standby.
  2. Cari pekerjaan apa pun yang masih berlanjut, dan lihat tingkat penggunaan CPU perangkat.

Perfetto

Perfetto memungkinkan Anda merekam aktivitas dan kemudian memeriksa aplikasi untuk melihat apakah ada thread yang melakukan pekerjaan apa pun saat layar nonaktif, perangkat masuk ke mode standby, atau pengguna menutup aktivitas aplikasi Anda.

Tentukan peristiwa kustom untuk menandai peristiwa signifikan aplikasi Anda, termasuk peristiwa khusus domain. Untuk aplikasi media, 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 daya dan CPU aplikasi Anda.

Menganalisis tugas terjadwal aplikasi Anda

Tugas terjadwal, menggunakan WorkManager, memungkinkan Anda melakukan pekerjaan latar belakang di aplikasi. Meskipun beberapa tugas latar belakang harus berkala, jangan menjalankan tugas terlalu sering atau untuk durasi yang lama karena dapat menguras daya baterai perangkat.

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

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

Selain itu, periksa grafik Battery Historian, dengan melihat setiap entri JobScheduler. Saat Anda menahan pointer ke entri tertentu, Battery Historian akan menampilkan pemilik tugas yang menjalankan tugas. Pertimbangkan hal berikut:

  • Untuk aplikasi Anda, durasi eksekusi harus wajar.
  • Pertimbangkan apakah tugas terjadi saat aplikasi Anda sedang berjalan, atau apakah tugas merepresentasikan pekerjaan latar belakang berkala.

Sensor

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

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

adb shell dumpsys sensorservice

Hasil perintah ini menunjukkan hal berikut:

  • Pendaftaran sensor saat ini dan sebelumnya.
  • Konfigurasi sensor, termasuk batch jika disetel.
  • Sampel data yang baru-baru ini diambil.

Menguji pembatalan pendaftaran dari sensor

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

  1. Geser untuk menutup aplikasi Anda.
  2. Ketuk layar dengan telapak tangan. 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 beberapa daya. Secara khusus, jika Anda menggunakan API ini untuk mengirim data, aplikasi harus aktif untuk menerima data tersebut. Oleh karena itu, berhati-hatilah dalam menggunakan API ini.

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

  • Tunggu hingga aplikasi aktif sebelum menyiapkan pemroses menggunakan WearableListenerService.
  • Mengirimkan perubahan status, bukan mengonfigurasi update cepat. Perubahan status ini memungkinkan perangkat Wear OS melakukan penghitungan data lokal, seperti saat sesi olahraga dimulai.

    Hanya kirimkan perubahan status yang mengupdate UI Anda. Misalnya, jika layar aktivitas Anda hanya menampilkan "kilometer yang ditempuh" ke satu angka desimal, jangan kirim perubahan status ke Wear OS setiap kali pengguna memajukan satu meter lagi.

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

adb shell dumpsys activity service WearableService

Hasil dari perintah ini meliputi:

  • RpcService: Memungkinkan Anda melihat frekuensi 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.

  • Untuk ExerciseClient, gunakan Battery Historian untuk memverifikasi perilaku yang benar dalam mode standby. Pastikan aplikasi Anda tidak bangun lebih sering dari setiap atau dua menit untuk menerima data ExerciseUpdate.
  • Untuk pemantauan kesehatan umum sepanjang hari, gunakan PassiveMonitoringClient, seperti yang dijelaskan pada 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:

  • Menonaktifkan refresh otomatis, atau meningkatkan kecepatan refresh menjadi 2 jam atau lebih lama.
  • Menggunakan Firebase Cloud Messaging (FCM) atau tugas terjadwal yang tepat untuk mengirim pembaruan data. Hati-hati untuk mencegah laju update yang cepat, yang dapat menyebabkan sistem menjadwalkan pekerjaan berulang pada kecepatan yang lebih cepat daripada pengguna atau platform dapat mengakses data yang diperlukan untuk melakukan pekerjaan tersebut.
  • Jangan menjadwalkan pekerjaan untuk kartu atau detail Anda saat pengguna tidak berinteraksi dengannya.
  • Gunakan pendekatan offline-first.
  • Bagikan satu database di seluruh aplikasi utama, kartu, dan detail Anda. Hal ini juga membantu data tetap konsisten di seluruh platform UI.