Xác định và tối ưu hoá các trường hợp sử dụng khoá đánh thức

Tài liệu này giúp bạn xác định và tối ưu hoá các trường hợp sử dụng khoá chế độ thức trong ứng dụng, cũng như nêu bật nếu có khoá chế độ thức do các thư viện khác hoặc API hệ thống liên kết với trường hợp sử dụng này thu nạp. Vì các khoá chế độ thức này là do ứng dụng của bạn gây ra, nên việc xác định chính xác nguồn của khoá chế độ thức có vấn đề có thể gặp khó khăn. Việc sử dụng API không chính xác có thể khiến ứng dụng của bạn bị gắn cờ vì sử dụng quá nhiều khoá chế độ thức, ngay cả khi bạn không có được khoá chế độ thức một cách rõ ràng.

Tài liệu này liệt kê một số tên khoá chế độ thức phổ biến mà bạn có thể gặp phải khi sử dụng các công cụ gỡ lỗi khoá chế độ thức hoặc trong báo cáo từ vitals. Những tên này có thể bắt nguồn từ một thư viện hoặc API hệ thống, hoặc có thể bị làm rối mã nguồn. Bằng cách sử dụng các công cụ gỡ lỗi để xác định khoá chế độ thức hoạt động không đúng cách, sau đó tìm tên khoá chế độ thức trong tài liệu này, bạn có thể xác định API nào có thể gây ra sự cố và tìm các đề xuất về cách tối ưu hoá việc sử dụng API đó.

Tài liệu này trình bày các trường hợp sử dụng phổ biến để lấy khoá chế độ thức, nêu chi tiết tên khoá chế độ thức mà nhiều API và thư viện sử dụng, đồng thời đưa ra các đề xuất và phương pháp hay nhất để tối ưu hoá và giảm mức sử dụng khoá chế độ thức.

AlarmManager

AlarmManager lấy khoá chế độ thức và gán khoá đó cho ứng dụng gọi. AlarmManager lấy khoá chế độ thức khi chuông báo thức kêu và nhả khoá khi phương thức onReceive() của thông báo chuông báo thức hoàn tất quá trình thực thi.

Tên khoá chế độ thức

AlarmManager tạo khoá chế độ thức có tên là *alarm*. (Dấu hoa thị là một phần của tên khoá chế độ thức, không đại diện cho ký tự đại diện.)

Nội dung đề xuất

Bạn nên áp dụng các phương pháp sau để tối ưu hoá hành vi của chuông báo:

  • Tham khảo phần chọn loại chuông báo để quyết định giữa chuông báo không chính xác hoặc chuông báo chính xác. Nếu chuông báo của bạn không cần phải chính xác, hãy sử dụng chuông báo không chính xác để hệ thống linh hoạt hơn trong việc lên lịch, nhờ đó có thể cải thiện thời lượng pin.
  • Hãy lưu ý đến hạn mức chuông báo do hệ thống áp đặt và thiết kế ứng dụng của bạn sao cho tuân thủ các hạn mức đó.
  • Tránh thực hiện công việc kéo dài trong phương thức onReceive() và lên lịch cho trình thực thi nếu cần xử lý thêm sau khi chuông báo thức kêu.

Âm thanh và nội dung nghe nhìn

API đa phương tiện có thể nhận khoá chế độ thức khi ghi âm hoặc phát âm thanh. Khoá chế độ thức được phân bổ cho ứng dụng gọi điện.

Tên khoá chế độ thức

Media API thu nạp khoá chế độ thức bằng nhiều tên bắt đầu bằng Audio:

  • AudioBitPerfect: Dùng để phát âm thanh không tổn hao qua USB.
  • AudioDirectOut: Dùng để phát âm thanh không tổn hao trên TV hoặc thiết bị đặc biệt.
  • AudioDup: Dùng để phát thông báo khi kết nối bằng Bluetooth hoặc USB.
  • AudioIn: Dùng để thu âm thanh khi ở chế độ máy quay trong khi micrô đang hoạt động.
  • AudioMix: Dùng để phát âm thanh đến một thiết bị thông thường.
  • AudioOffload: Dùng để phát nhạc trong thời gian dài, đối với các ứng dụng hỗ trợ chế độ này.
  • AudioSpatial: Dùng để phát lại âm thanh phim hoặc nhạc đa kênh trên các thiết bị hỗ trợ âm thanh không gian.
  • AudioUnknown: Dùng khi các trường hợp khác không áp dụng.
  • MmapCapture: Dùng để thu âm thanh có độ trễ thấp.
  • MmapPlayback: Dùng để phát có độ trễ thấp, chẳng hạn như để chơi trò chơi hoặc cho các ứng dụng âm thanh chuyên nghiệp.

Nội dung đề xuất

Bạn nên áp dụng các phương pháp sau:

  • Không khai báo tên khoá chế độ thức bắt đầu bằng Audio.
  • Nếu đang sử dụng API nội dung nghe nhìn, bạn không cần phải trực tiếp lấy khoá chế độ thức; bạn có thể dựa vào API để lấy khoá chế độ thức cần thiết cho mình.
  • Khi bạn sử dụng API nội dung nghe nhìn, hãy kết thúc phiên phát nội dung nghe nhìn và dịch vụ nền trước liên quan khi bạn không cần đến nữa.

Bluetooth

Các API Bluetooth của nền tảng chủ yếu giữ khoá chế độ thức của nhân hệ điều hành trong khi các hành động Bluetooth diễn ra, không phải do ứng dụng.

Nội dung đề xuất

  • Sử dụng tính năng Ghép nối thiết bị đồng hành để ghép nối các thiết bị Bluetooth nhằm tránh việc phải lấy khoá chế độ thức theo cách thủ công trong quá trình ghép nối Bluetooth.
  • Tham khảo hướng dẫn giao tiếp trong nền để hiểu cách giao tiếp Bluetooth trong nền.
  • Bạn thường chỉ cần sử dụng WorkManager nếu việc chậm trễ thông báo không ảnh hưởng đến người dùng. Nếu bạn cho rằng cần phải khoá chế độ thức theo cách thủ công, thì chỉ giữ khoá chế độ thức trong thời gian hoạt động Bluetooth hoặc xử lý dữ liệu hoạt động.

Cảm biến thiết bị

Có một số phương pháp để theo dõi dữ liệu cảm biến của thiết bị, chẳng hạn như số bước, dữ liệu gia tốc kế hoặc con quay hồi chuyển.

Trên Wear OS, hãy sử dụng Dịch vụ sức khoẻ Wear để lấy dữ liệu thiết bị như độ cao, tần số tim và quãng đường đã đi.

Nếu dữ liệu được thu thập bởi các ứng dụng khác, bạn có thể sử dụng Health Connect kết hợp với WorkManager để truy xuất dữ liệu định kỳ.

Đối với các trường hợp như theo dõi mức chênh lệch về số bước hoặc quãng đường đã đi, bạn có thể sử dụng Recording API trên thiết bị di động kết hợp với WorkManager để truy xuất dữ liệu định kỳ. Để truy cập vào dữ liệu số bước trong quá khứ (chẳng hạn như tổng số bước hằng ngày hoặc số bước trong 6 giờ qua), Health Connect cũng hỗ trợ tính năng theo dõi số bước trên thiết bị cho các thiết bị chạy Android 14 trở lên.

Trong một số trường hợp, bạn có thể cần theo dõi cảm biến thiết bị tuỳ chỉnh bằng cách sử dụng SensorManager. SensorManager không nhận được khoá chế độ thức thay cho ứng dụng, trừ phi cảm biến là cảm biến đánh thức, có thể được xác định bằng API isWakeUpSensor.

Nội dung đề xuất

Việc sử dụng cảm biến để ghi lại ở tốc độ lấy mẫu cao có thể làm tiêu hao pin đáng kể. Sau đây là các đề xuất để giảm mức tiêu hao pin và mức sử dụng khoá chế độ thức:

  • Nếu bạn theo dõi số bước hoặc quãng đường đã đi, hãy sử dụng Recording API để ghi lại dữ liệu theo cách tiết kiệm pin. Đối với các thiết bị chạy Android 14 trở lên, hãy cân nhắc sử dụng Health Connect để truy cập vào dữ liệu thiết bị trước đây và số bước tổng hợp.
  • Để theo dõi cảm biến thụ động trên Wear OS, hãy sử dụng Dịch vụ sức khoẻ trên Wear để tối ưu hoá mức sử dụng pin.
  • Khi đăng ký cảm biến bằng SensorManager, hãy xác định maxReportLatencyUs hơn 30 giây để sử dụng logic phân lô cảm biến và giảm số lần gián đoạn mà ứng dụng nhận được. Khi thiết bị được đánh thức sau đó bằng một trình kích hoạt khác, chẳng hạn như hoạt động tương tác của người dùng, truy xuất vị trí hoặc một công việc đã lên lịch, hệ thống sẽ ngay lập tức gửi dữ liệu cảm biến đã lưu vào bộ nhớ đệm.
  • Nếu ứng dụng của bạn yêu cầu cả dữ liệu vị trí và dữ liệu cảm biến, hãy đồng bộ hoá việc truy xuất và xử lý sự kiện của các dữ liệu này. Bằng cách kết hợp các chỉ số cảm biến vào khoá chế độ thức ngắn mà hệ thống giữ để thông báo cập nhật vị trí, bạn không cần khoá chế độ thức để giữ cho CPU luôn hoạt động. Sử dụng worker hoặc khoá chế độ thức trong thời gian ngắn để xử lý việc tải lên và xử lý dữ liệu kết hợp này.

Giải pháp gửi thông báo qua đám mây của Firebase (FCM)

Khoá chế độ thức được lấy trong khi gửi thông báo truyền tin của Giải pháp gửi thông báo qua đám mây của Firebase (FCM) đến ứng dụng. Khoá chế độ thức được giải phóng sau khi phương thức onMessageReceived() của thông báo truyền tin FCM thực thi xong.

Tên khoá chế độ thức

Khi thiết bị nhận được thông báo FCM, một khoá chế độ thức ngắn sẽ được giữ với tên GOOGLE_C2DM. Trên Android 16 trở lên, tên khoá chế độ thức là GCM_MESSAGE.

Nội dung đề xuất

Bạn nên áp dụng các phương pháp sau để tối ưu hoá hành vi của FCM:

  • Tối ưu hoá tần suất gửi thông báo bằng FCM.
  • Đừng sử dụng FCM có mức độ ưu tiên cao trừ phi thông báo thực sự cần được gửi ngay lập tức.
  • Yêu cầu phương thức onMessageReceived() hoàn tất nhanh nhất có thể hoặc lên lịch cho một trình thực thi tiếp tục tác vụ nếu cần xử lý thêm. Hãy xem hướng dẫn về Firebase để biết thêm thông tin.

JobScheduler

Các công việc của JobScheduler sẽ nhận được khoá chế độ thức trong khi thực thi các tác vụ ở chế độ nền. Khoá chế độ thức được quy cho ứng dụng đã tạo worker.

Tên khoá chế độ thức

Tên khoá chế độ thức mà JobScheduler thu nạp phụ thuộc vào phiên bản hệ thống Android mà chúng đang chạy và mục đích của công việc.

Các mục được đặt trong dấu ngoặc nhọn là các biến. Ví dụ: "<package_name>" là tên gói của ứng dụng, chứ không phải văn bản cố định <package name>. Tuy nhiên, *job* là chuỗi ký tự *job*, có dấu hoa thị; dấu hoa thị không được dùng làm ký tự đại diện.

Android 15 trở xuống

Công việc do người dùng khởi tạo sẽ tạo khoá chế độ thức có tên theo mẫu sau:

*job*u/@<name_space>@/<package_name>/<classname>

Các công việc khác sử dụng mẫu này:

*job*/@<name_space>@/<package_name>/<classname>
Android 16 QPR2 trở lên

Công việc do người dùng khởi tạo sẽ tạo khoá chế độ thức có tên theo mẫu sau:

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Công việc ưu tiên sử dụng mẫu này:

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Công việc thông thường sử dụng mẫu sau:

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
Ví dụ

Giả sử có một công việc ưu tiên với không gian tên backup và thẻ theo dõi started. Tên gói là com.example.app và lớp đã tạo công việc là com.backup.BackupFileService.

Trên các thiết bị chạy Android 15 trở xuống, khoá chế độ thức sẽ có tên là:

*job*/@backup@/com.example.app/com.backup.BackupFileService

Trên các thiết bị chạy Android 16 QPR2 trở lên, khoá chế độ thức sẽ có tên là:

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

Nội dung đề xuất

  • Đừng bật khoá chế độ thức theo cách thủ công cho các trường hợp sử dụng tải xuống/ tải lên do người dùng bắt đầu. Thay vào đó, hãy sử dụng API Chuyển dữ liệu do người dùng yêu cầu (UIDT). Đây là đường dẫn được chỉ định cho các tác vụ chuyển dữ liệu chạy trong thời gian dài do người dùng khởi tạo.
  • Nếu bạn xác định được khoá chế độ thức do JobScheduler tạo có mức sử dụng khoá chế độ thức cao, thì có thể là do bạn đã định cấu hình sai công việc khiến công việc không hoàn tất trong một số trường hợp nhất định. Cân nhắc việc phân tích lý do dừng công việc, đặc biệt là nếu bạn thấy STOP_REASON_TIMEOUT xảy ra nhiều lần.
  • Kiểm tra mức sử dụng các tác vụ JobScheduler. Cụ thể, hãy làm theo hướng dẫn của chúng tôi về cách tối ưu hoá mức sử dụng pin cho các API lập lịch tác vụ.

Vị trí

LocationManager và FusedLocationProviderClient sử dụng khoá chế độ thức để thu nạp và cung cấp thông tin vị trí của thiết bị. Khoá chế độ thức được gán cho ứng dụng đã gọi các API đó.

Tên khoá chế độ thức

Dịch vụ vị trí sử dụng các tên sau:

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

Nội dung đề xuất

  • Tham khảo hướng dẫn của chúng tôi để Tối ưu hoá việc sử dụng thông tin vị trí. Hãy cân nhắc việc triển khai thời gian chờ, tận dụng tính năng gửi yêu cầu vị trí theo lô hoặc sử dụng thông báo cập nhật vị trí thụ động.
  • Tránh lấy khoá chế độ thức riêng biệt, liên tục để lưu dữ liệu vị trí vào bộ nhớ đệm, vì việc này là thừa và nên được loại bỏ. Khi yêu cầu thông báo cập nhật vị trí bằng API FusedLocationProvider hoặc LocationManager, hệ thống sẽ tự động kích hoạt chế độ đánh thức thiết bị trong lệnh gọi lại sự kiện vị trí. Thay vào đó, hãy lưu trữ các sự kiện vị trí trong bộ nhớ hoặc bộ nhớ, và xử lý các sự kiện vị trí định kỳ bằng WorkManager.

Nhắn tin từ xa

Phần này thảo luận về các trường hợp liên quan đến tính năng nhắn tin từ xa, trong đó ứng dụng có thể cần duy trì kết nối hoặc phản ứng với các sự kiện từ thiết bị khác, có khả năng ảnh hưởng đến việc sử dụng khoá chế độ thức. Các trường hợp sử dụng phổ biến bao gồm:

  • Ứng dụng đồng hành giám sát video hoặc âm thanh cần giám sát các sự kiện xảy ra trên một thiết bị bên ngoài được kết nối qua mạng cục bộ.
  • Ứng dụng nhắn tin duy trì kết nối cổng mạng với một biến thể dành cho máy tính.

Hầu hết các hoạt động đánh thức trong các trường hợp nhắn tin từ xa này là khoá chế độ thức của nhân hệ điều hành. Vì khoá chế độ thức của nhân hệ điều hành không được gán cho ứng dụng, nên không có tên khoá chế độ thức liên quan để liệt kê tại đây.

Nội dung đề xuất

  • Nếu các sự kiện mạng có thể được xử lý ở phía máy chủ, hãy sử dụng FCM để nhận thông tin trên máy khách. Bạn có thể chọn lên lịch cho một worker nhanh nếu cần xử lý thêm dữ liệu FCM.
  • Nếu các sự kiện phải được xử lý ở phía máy khách bằng kết nối ổ cắm, thì bạn không cần khoá chế độ thức để theo dõi các sự kiện gián đoạn. Khi các gói dữ liệu đến Wi-Fi hoặc radio di động, phần cứng radio sẽ kích hoạt một lệnh ngắt dưới dạng khoá chế độ thức của nhân hệ điều hành. Sau đó, bạn có thể chọn lên lịch cho một worker hoặc lấy khoá chế độ thức để xử lý dữ liệu.
  • Ví dụ: nếu đang sử dụng ktor-network để theo dõi các gói dữ liệu trên một cổng mạng, bạn chỉ nên lấy khoá chế độ thức khi các gói đã được phân phối đến ứng dụng.

WorkManager

Trình thực thi WorkManager nhận khoá chế độ thức trong khi thực thi các tác vụ ở chế độ nền. Khoá chế độ thức được quy cho ứng dụng đã tạo worker.

Tên khoá chế độ thức

Tên khoá chế độ thức mà WorkManager thu nạp phụ thuộc vào phiên bản hệ thống Android mà chúng đang chạy.

Android 15 trở xuống

Các tác vụ WorkManager tạo khoá chế độ thức có tên theo mẫu sau:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 QPR2 trở lên

Tác vụ nhanh tạo khoá chế độ thức có tên theo mẫu sau:

*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Các công việc thường nhật tuân theo mẫu sau:

*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Theo mặc định, <trace_tag> là tên của worker.

Ví dụ

Giả sử có một worker được ưu tiên tên là BackupFileWorker. Tên gói là com.example.app.

Trên các thiết bị chạy Android 15 trở xuống, khoá chế độ thức sẽ có tên là:

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Trên các thiết bị chạy Android 16 QPR2 trở lên và sử dụng WorkManager 2.10.0+, khoá chế độ thức sẽ có tên là:

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Nội dung đề xuất

  • Nâng cấp phiên bản WorkManager lên phiên bản ổn định mới nhất để các thẻ khoá chế độ thức chi tiết hơn trên Android 16 QPR2 trở lên.
  • Kiểm tra mức sử dụng trình thực thi WorkManager. Cụ thể, hãy xác minh rằng ứng dụng tuân thủ hướng dẫn của chúng tôi về việc tối ưu hoá mức sử dụng pin cho các API lập lịch tác vụ. Để thẻ khoá chế độ thức chi tiết hơn trên Android 16 QPR2 trở lên, hãy sử dụng phương thức setTraceTag trên worker để thêm thông tin gỡ lỗi, chẳng hạn như lớp nào đã lên lịch cho worker.
  • Nếu bạn xác định được các khoá chế độ thức do WorkManager tạo có mức sử dụng khoá chế độ thức cao, thì có thể là do bạn đã định cấu hình sai worker khiến worker không hoàn tất trong một số trường hợp nhất định. Hãy cân nhắc việc phân tích lý do dừng worker, đặc biệt là nếu bạn thấy STOP_REASON_TIMEOUT xảy ra nhiều lần.
  • Ngoài việc ghi lại lý do dừng worker, hãy tham khảo tài liệu của chúng tôi về cách gỡ lỗi worker. Ngoài ra, hãy cân nhắc việc thu thập và phân tích dấu vết hệ thống để hiểu thời điểm khoá chế độ thức được thu nạp và giải phóng.

_UNKNOWN

Nếu các công cụ gỡ lỗi cho rằng tên khoá chế độ thức chứa thông tin nhận dạng cá nhân (PII), thì các công cụ đó sẽ không hiển thị tên khoá chế độ thức thực tế. Thay vào đó, các thiết bị này gắn nhãn khoá chế độ thức là _UNKNOWN. Ví dụ: các công cụ có thể làm việc này nếu tên khoá chế độ thức chứa địa chỉ email.

Nội dung đề xuất

Làm theo các phương pháp hay nhất về việc đặt tên khoá chế độ thức và tránh sử dụng thông tin nhận dạng cá nhân (PII) trong tên khoá chế độ thức. Nếu bạn tìm thấy khoá chế độ thức có tên _UNKNOWN được gán cho ứng dụng của mình, hãy cố gắng xác định khoá chế độ thức đó và đặt tên khác cho khoá đó.