Hemat daya dan baterai

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

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

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

  • Desain aplikasi Anda harus memanfaatkan faktor bentuk Wear OS dengan baik. Sebaiknya jangan menyalin aplikasi seluler secara langsung.
  • Gunakan aplikasi seluler yang ada untuk membantu kasus penggunaan tertentu. Misalnya, internet dan sinkronisasi pada smartwatch itu mahal; pertimbangkan apakah perangkat seluler dapat melakukan tugas yang sulit, dan perangkat Wear OS akan 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 tugas aplikasi hingga smartwatch diisi dayanya. Hal ini terutama berlaku untuk tugas yang memerlukan banyak 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, serta cara Anda dapat membatasi runtime aplikasi dan pengurasan baterai. Untuk mempelajari lebih lanjut cara tindakan tertentu dilakukan—seperti memuat aplikasi atau men-scroll daftar—buka panduan terkait performa, seperti Panduan performa Compose di Wear OS.

Pantau 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 mungkin berguna untuk dijalankan bersama dengan perintah ini.

Peristiwa yang memengaruhi masa pakai baterai

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

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

Peristiwa Dampak pada masa pakai baterai Cara melakukan mitigasi
Mengakses jaringan, termasuk LTE dan Wi-Fi Sangat tinggi Tunda akses jaringan yang tidak penting hingga perangkat mengisi daya.
Aktifkan layar dan mulai mode interaktif Tinggi Jangan dorong pengguna untuk membiarkan layar menyala lebih lama dari yang diperlukan. Menyediakan pengalaman yang menggunakan mode selalu aktif, yang juga dikenal sebagai mode standby.
Mengakses sensor GPS Tinggi Jika memungkinkan, tunggu hingga pengguna meminta akses GPS.
Memastikan penggunaan CPU tetap tinggi Tinggi Menggunakan flow menggunakan Jetpack Compose.
Mengakses sensor detak jantung Medium Gunakan waktu aktif 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.
Menahan penguncian layar saat aktif Medium Kurangi pembuatan wakelock secara manual dan gunakan WorkManager.

Minimalkan waktu pemakaian perangkat

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 agar terlihat lebih profesional. Secara khusus, hindari animasi dan loop yang berjalan lama. Jika loop diperlukan, tambahkan jeda antar-loop, setidaknya selama animasi itu sendiri.

  • Waktu terbangun dalam mode standby: Mendukung selalu aktif jika diperlukan, seperti untuk kasus penggunaan kebugaran. Jika aplikasi Anda mengharuskan aplikasi 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 fitur yang singkat.
  • Kelompokkan operasi terkait, untuk memaksimalkan waktu saat proses aplikasi tidak ada aktivitas.

Minimalkan penguncian layar saat aktif

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

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

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

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

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

Memeriksa bagaimana aplikasi Anda menjadi tidak aktif

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

  • Layar akan berbunyi dan perangkat masuk ke mode standby.

  • Aplikasi ditutup dengan 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 berbunyi dan perangkat memasuki mode standby.
  2. Cari pekerjaan yang masih berlanjut, dan lihat tingkat penggunaan CPU perangkat.

Perfetto

Perfetto memungkinkan Anda merekam aktivitas, lalu memeriksa aplikasi untuk melihat apakah ada thread yang melakukan pekerjaan apa pun 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, data ini akan mencakup tugas-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

Tugas terjadwal, dengan menggunakan WorkManager, memungkinkan Anda melakukan pekerjaan latar belakang di aplikasi. Meskipun beberapa pekerjaan latar belakang harus berkala, jangan menjalankan tugas terlalu sering atau dalam durasi yang lama, karena hal ini dapat menghabiskan daya 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 total durasi:

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

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

  • Untuk aplikasi Anda, durasi eksekusi harus masuk akal.
  • Pertimbangkan apakah tugas terjadi saat aplikasi 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 Anda:

adb shell dumpsys sensorservice

Hasil dari perintah ini menampilkan hal berikut:

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

Menguji pembatalan pendaftaran dari sensor

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

  1. Geser untuk menutup aplikasi Anda.
  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 akan menggunakan sebagian daya. Secara khusus, jika Anda menggunakan API ini untuk mengirim data, aplikasi harus aktif untuk menerima data tersebut. Karena alasan ini, gunakan API ini secara konservatif.

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

  • Tunggu hingga aplikasi Anda 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 berjalan" ke satu angka desimal, jangan kirim perubahan status ke Wear OS setiap kali pengguna menggerakkan pengukur lain ke depan.

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

adb shell dumpsys activity service WearableService

Hasil dari 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 memelihara 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 menit 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 ini:

  • Nonaktifkan refresh otomatis, atau tingkatkan kecepatan refresh 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 yang lebih cepat daripada pengguna atau platform yang dapat mengakses data yang diperlukan untuk melakukan pekerjaan tersebut.
  • Jangan jadwalkan pekerjaan untuk kartu atau detail Anda saat pengguna tidak berinteraksi dengannya.
  • Gunakan pendekatan offline-first.
  • Bagikan satu database ke seluruh aplikasi utama, kartu, dan detail Anda. Hal ini juga membantu data tetap konsisten di seluruh platform UI.