Hemat daya dan baterai

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

Dibandingkan dengan perangkat seluler yang lebih besar, perangkat Wear OS memiliki baterai yang lebih kecil, jadi 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 pada berbagai interval sepanjang hari, mereka harus melepaskan perangkat Wear OS dari tubuh mereka 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. Ini tidak boleh menyalin aplikasi seluler Anda secara langsung.
  • Gunakan aplikasi seluler yang ada untuk membantu kasus penggunaan tertentu. Misalnya, internet dan sinkronisasi di jam itu mahal; pertimbangkan apakah perangkat seluler dapat melakukan pekerjaan yang sulit, 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 tugas aplikasi hingga smartwatch diisi dayanya. Terutama untuk tugas yang menggunakan banyak data, seperti menyinkronkan data, dan mengatur {i>database<i}.

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

Panduan daya ini membantu Anda memahami kapan dan bagaimana sistem menjalankan aplikasi Anda, serta bagaimana Anda dapat membatasi {i>runtime<i} aplikasi dan pengurasan baterai. Untuk mempelajari lebih lanjut tentang cara tindakan tertentu yang dicapai—seperti memuat aplikasi atau menggulir daftar—buka panduan terkait performa, seperti Compose di Wear OS panduan performa.

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

Peristiwa yang memengaruhi masa pakai baterai

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

Tabel berikut menunjukkan efek relatif pada 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 dari diperlukan. Berikan pengalaman yang menggunakan selalu aktif mode standby, yang juga dikenal sebagai mode standby.
Mengakses sensor GPS Tinggi Jika memungkinkan, tunggu hingga pengguna meminta akses GPS.
Memastikan penggunaan CPU tetap tinggi Tinggi Konsumsi alur menggunakan Jetpack Compose.
Mengakses sensor detak jantung Sedang Gunakan waktu bangun prosesor saat menerima callback dari API sensor, seperti saat menggunakan Fitur Kesehatan aktif Wear OS.
Mengakses perangkat lain melalui Bluetooth Sedang Buat sesi yang singkat.
Menahan penguncian layar saat aktif Sedang Mengurangi pembuatan wakelock dan penggunaan secara manual WorkManager.

Minimalkan waktu pemakaian perangkat

Di aplikasi Wear OS, ikuti prinsip penggunaan layar berikut:

  • Kunci layar aktif: Hindari jika memungkinkan. Untuk menguji, nonaktifkan Selalu aktif tampilan di setelan sistem, dan amati apakah layar mati dalam periode waktu tunggu.
  • Animasi: Meminimalkan animasi yang rumit, dan berfokus pada rangkuman transisi untuk tampilan yang lebih profesional. Secara khusus, hindari jangka panjang animasi dan loop. Jika loop diperlukan, tambahkan jeda antar-loop setidaknya sama panjang dengan 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 selalu aktif kode 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 proses aplikasi Anda tidak ada aktivitas.

Minimalkan penguncian layar saat aktif

Pada umumnya, hindari operasi apa pun yang mencegah aplikasi Anda tidur, seperti sebagai wakelock. Misalnya, dalam bidang kesehatan & aplikasi kebugaran, olahraga jangka panjang tidak memerlukan penguncian layar saat aktif. Menggunakan waktu bangun prosesor saat menerima callback dari API sensor, seperti saat menggunakan Fitur Kesehatan di Wear OS.

Ada beberapa kasus di mana Anda boleh mendapatkan penguncian layar saat aktif, seperti ketika aplikasi akan melakukan salah satu hal berikut:

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

Battery Historian memungkinkan Anda melihat setiap kemunculan video panjang penguncian layar saat aktif, serta ringkasan jumlah total dan durasi penguncian layar saat aktif sedang ditahan. Memeriksa jumlah dan durasi penguncian layar saat aktif yang dilakukan aplikasi dan membandingkan 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 tersebut diblokir pada dependensi tertentu, seperti ketersediaan jaringan.

Memeriksa bagaimana aplikasi Anda menjadi tidak aktif

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

  • 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 Lihat > Jendela Alat > Profiler:

  1. Periksa pelacakan sistem saat layar berbunyi dan perangkat masuk mode standby.
  2. Cari pekerjaan yang masih berlanjut, dan lihat tingkat penggunaan CPU perangkat.

Perfetto

Perfetto memungkinkan Anda merekam aktivitas lalu memeriksa aplikasi Anda untuk melihat apakah ada aktivitas apakah ada utas yang melakukan pekerjaan apa pun saat layar dimatikan, perangkat masuk ke 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 termasuk tugas-tugas seperti mengambil daftar putar, mendownload item media tertentu, memulai pemutaran, dan menghentikan pemutaran. Dengan menentukan peristiwa ini, Anda dapat melihatnya di Perfetto dan membandingkannya pengaturan waktu dengan penggunaan CPU dan daya aplikasi Anda.

Menganalisis tugas terjadwal aplikasi

Tugas terjadwal, menggunakan WorkManager, memungkinkan Anda melakukan pekerjaan latar belakang . Meskipun beberapa pekerjaan latar belakang harus bersifat berkala, jangan menjalankan tugas juga sering atau untuk durasi yang lama, karena ini dapat menghabiskan baterai perangkat.

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

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

Selain itu, periksa grafik Battery Historian, dengan melihat setiap JobScheduler entri. Saat Anda mengarahkan kursor ke entri tertentu, Battery Historian menunjukkan 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 mewakili pekerjaan latar belakang berkala.

Sensor

Perangkat Wear OS memiliki banyak sensor yang berbeda, seperti GPS. Dalam kebanyakan kasus, gunakan Fitur Kesehatan di Wear OS alih-alih berinteraksi langsung dengan SensorManager. Dalam banyak kasus, Fitur Kesehatan secara cerdas mengelompokkan data ke meningkatkan performa baterai.

Untuk menganalisis penggunaan sensor di aplikasi Anda, jalankan perintah berikut di terminal di 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 mematikan 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. Di beberapa khususnya, jika Anda menggunakan API ini untuk mengirim data, aplikasi Anda harus bangun untuk menerima yang mengupload data. Karena alasan ini, gunakan API ini secara konservatif.

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

  • Tunggu hingga aplikasi Anda aktif sebelum menyiapkan pemroses menggunakan WearableListenerService

  • Mengirimkan perubahan status, bukan mengonfigurasi update cepat. Negara bagian ini perubahan memungkinkan perangkat Wear OS melakukan penghitungan data lokal, seperti saat sesi latihan fisik dimulai.

    Hanya kirimkan perubahan status yang mengupdate UI Anda. Misalnya, jika layar aktivitas hanya menampilkan "kilometer berlari" ke satu angka desimal, jangan kirim perubahan status di Wear OS setiap kali pengguna memindahkan pengukur lain maju.

Untuk menganalisis penggunaan Data Layer API di aplikasi Anda, jalankan perintah berikut dalam di 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 Anda.

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

Kartu dan detail

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

  • Nonaktifkan muat ulang otomatis, atau tingkatkan kecepatan refresh menjadi 2 jam atau jadi lebih panjang.
  • Gunakan Firebase Cloud Messaging (FCM) atau jadwalkan dengan tepat tugas untuk mengirimkan pembaruan data. Berhati-hatilah agar tidak terlalu cepat memperbarui, yang dapat menyebabkan sistem menjadwalkan pekerjaan berulang dengan kecepatan yang lebih cepat daripada pengguna atau platform dapat mengakses data yang diperlukan untuk melakukan pekerjaan itu.
  • Jangan jadwalkan pekerjaan untuk kartu atau detail Anda jika pengguna tidak berinteraksi dengannya.
  • Gunakan pendekatan offline-first.
  • Bagikan satu database ke seluruh aplikasi utama, kartu, dan detail Anda. Ini juga membantu data tetap konsisten di seluruh platform UI.