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ư làm nổi bật nếu có các khoá chế độ thức do các thư viện hoặc API hệ thống khác thu được liên kết với trường hợp sử dụng này. Vì các khoá chế độ thức này là do ứng dụng của bạn, nên có thể khó xác định nguồn của một khoá chế độ thức có vấn đề. Việc sử dụng API không đúng cách có thể khiến ứng dụng của bạn bị gắn cờ do sử dụng quá nhiều khoá chế độ thức, ngay cả khi bạn không thu thập 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 các báo cáo từ các chỉ số quan trọng. Các 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 xáo trộn. Bằng cách sử dụng các công cụ gỡ lỗi để xác định các khoá chế độ thức hoạt động không đúng cách, sau đó tìm kiế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 vấn đề 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 để thu thập khoá chế độ thức, nêu chi tiết tên khoá chế độ thức do 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 thu thập khoá chế độ thức và gán các khoá này cho ứng dụng gọi. AlarmManager thu thập khoá chế độ thức khi chuông báo kêu và giải phóng khoá khi phương thức onReceive() của thông báo truyền tin về chuông báo hoàn tất việc 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 chính xác. Nếu chuông báo không cần 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, điều này 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 để 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 các worker nếu cần xử lý thêm sau khi chuông báo.

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

Media API có thể thu thập khoá chế độ thức khi ghi hoặc phát âm thanh. Các khoá chế độ thức được gán cho ứng dụng gọi điện.

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

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

  • AudioBitPerfect: Dùng để phát âm thanh USB không mất dữ liệu.
  • 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 phim 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, chỉ dành cho các ứng dụng hỗ trợ chế độ này.
  • AudioSpatial: Dùng để phát âm thanh phim hoặc nhạc nhiều 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 lại có độ trễ thấp, chẳng hạn như cho 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 Media API, bạn không cần thu thập trực tiếp khoá chế độ thức; bạn có thể dựa vào các API để thu thập khoá chế độ thức cần thiết cho bạn.
  • Khi sử dụng Media API, hãy kết thúc phiên nội dung nghe nhìn và dịch vụ trên nền trước được liên kết khi bạn không còn cần nữa.

Bluetooth

Bluetooth API của nền tảng chủ yếu giữ khoá chế độ thức của kernel trong khi các thao tác Bluetooth diễn ra, không thể gán cho ứ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 thu thập khoá chế độ thức thủ công trong quá trình ghép nối Bluetooth.
  • Tham khảo hướng dẫn giao tiếp ở chế độ nền để hiểu cách thực hiện giao tiếp Bluetooth ở chế độ nền.
  • Thường thì việc sử dụng WorkManager là đủ nếu không có tác động nào đến người dùng đối với việc giao tiếp bị trì hoãn. Nếu bạn cho rằng cần có khoá chế độ thức thủ công, chỉ cần giữ khoá chế độ thức trong thời gian hoạt động của Bluetooth hoặc xử lý dữ liệu hoạt động.

Cảm biến thiết bị

Có nhiều phương thức để theo dõi dữ liệu cảm biến 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ẻ trên Wear để lấy dữ liệu trên thiết bị, chẳng hạn như độ cao, tần số tim và khoảng cách đã đi.

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

Đối với các trường hợp như theo dõi mức thay đổi của số bước hoặc khoảng cách đã đi, bạn có thể sử dụng Recording API trên thiết bị di động kết hợp với WorkManager để định kỳ truy xuất dữ liệu. Để 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 SensorManager. SensorManager không thu thập khoá chế độ thức thay cho ứng dụng, trừ phi cảm biến là cảm biến đánh thức, bạn có thể xác định cảm biến này bằng API isWakeUpSensor.

Nội dung đề xuất

Việc sử dụng cảm biến để ghi ở tốc độ lấy mẫu cao có thể làm tiêu hao pin đáng kể. Dưới đâ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 theo dõi số bước hoặc khoảng cách đã đi, hãy sử dụng Recording API để ghi 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ị trong quá khứ và tổng số bước.
  • Đối với tính năng 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 là hơn 30 giây để sử dụng logic phân lô cảm biến và giảm số lượng gián đoạn mà ứng dụng nhận được. Khi thiết bị được đánh thức sau đó bằng một điều kiện kích hoạt khác, chẳng hạn như lượt tương tác của người dùng, truy xuất vị trí hoặc lệnh theo lịch biểu, hệ thống sẽ gửi ngay dữ liệu cảm biến được 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 chúng. 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ữ để cập nhật vị trí, bạn sẽ không cần khoá chế độ thức để giữ cho CPU hoạt động. Sử dụng một worker hoặc khoá chế độ thức có thời lượng 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 thu thập 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 thông báo truyền tin FCM onMessageReceived() hoàn tất việc thực thi.

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

Khi một thông báo FCM được nhận trên thiết bị, một khoá chế độ thức ngắn sẽ được giữ bằng 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 FCM.
  • Khô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.
  • Hoàn tất phương thức onMessageReceived() càng nhanh càng tốt hoặc lên lịch cho một worker để tiếp tục tác vụ nếu cần xử lý thêm. Xem hướng dẫn về Firebase để biết thêm thông tin.

JobScheduler

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

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

Tên khoá chế độ thức do JobScheduler thu thập tuỳ 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, không phải là văn bản theo nghĩa đen <package name>. Tuy nhiên, *job* là chuỗi ký tự *job*, có dấu hoa thị; dấu hoa thị không được sử dụng làm ký tự đại diện.

Android 15 trở xuống

Các công việc do người dùng khởi tạo tạo khoá chế độ thức có tên tuâ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ác công việc do người dùng khởi tạo tạo khoá chế độ thức có tên tuân theo mẫu sau:

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

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

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

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

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

Giả sử có một công việc ưu tiên có 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

  • Không thu thập khoá chế độ thức 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 khởi tạo. Thay vào đó, hãy sử dụng User-Initiated Data Transfer (UIDT) API. Đâ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á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 để không hoàn tất trong một số trường hợp. Hãy cân nhắ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.
  • 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 để tối ưu hoá mức sử dụng pin cho các API lên lịch tác vụ.

Vị trí

LocationManager và FusedLocationProviderClient sử dụng khoá chế độ thức để thu thập và gửi thông tin vị trí của thiết bị. Các 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á mức sử dụng vị trí. Cân nhắc triển khai thời gian chờ, tận dụng tính năng phân lô yêu cầu vị trí hoặc sử dụng thông báo cập nhật vị trí thụ động.
  • Tránh thu thập 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ì điều này là dư thừa và cần phải xoá. Khi yêu cầu thông tin cập nhật vị trí bằng cách sử dụng API FusedLocationProvider hoặc LocationManager, hệ thống sẽ tự động kích hoạt tính năng đá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 đó các ứ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ừ các thiết bị khác, có khả năng ảnh hưởng đến mức sử dụng khoá chế độ thức. Các trường hợp sử dụng phổ biến bao gồm:

  • Các ứ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ộ.
  • Các ứng dụng nhắn tin duy trì kết nối ổ cắm mạng với một biến thể trên máy tính.

Hầu hết các lần đánh thức trong các trường hợp nhắn tin từ xa này đều là khoá chế độ thức của nhân hệ điều hành. Vì khoá chế độ thức của kernel không được gán cho ứng dụng, nên không có tên khoá chế độ thức liên kết nào để liệt kê ở đâ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 ứng dụng. Bạn có thể chọn lên lịch cho một worker ưu tiên 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 ứng dụng bằng kết nối ổ cắm, thì không cần khoá chế độ thức để theo dõi các gián đoạn sự kiện. Khi các gói dữ liệu đến đài Wi-Fi hoặc radio di động, phần cứng radio sẽ kích hoạt một gián đoạn ở 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 thu thập khoá chế độ thức để xử lý dữ liệu.
  • Ví dụ: nếu bạn đang sử dụng ktor-network để theo dõi các gói dữ liệu trên ổ cắm mạng, bạn chỉ nên thu thập khoá chế độ thức khi các gói đã được gửi đến ứng dụng.

WorkManager

Các worker của WorkManager thu thập khoá chế độ thức trong khi thực thi các tác vụ ở chế độ nền. Các khoá chế độ thức được gán cho ứng dụng đã tạo các worker.

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

Tên khoá chế độ thức do WorkManager thu thập tuỳ 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 tuân theo mẫu sau:

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

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

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

Các tác vụ thông thường 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 worker.

Ví dụ

Giả sử có một worker ưu tiên có 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 để làm cho 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 các worker của WorkManager. Cụ thể, hãy xác minh rằng các worker này tuân theo hướng dẫn của chúng tôi để tối ưu hoá mức sử dụng pin cho các API lên lịch tác vụ. Để làm cho các 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 khác, chẳng hạn như lớp nào đã lên lịch cho worker.
  • Nếu bạn xác định 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 để không hoàn tất trong một số trường hợp. Hãy cân nhắc phân tích lý do dừng worker, đặc biệt là nếu bạn thấy xảy ra nhiều STOP_REASON_TIMEOUT.
  • Ngoài việc ghi nhật ký 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 thu thập và phân tích dấu vết hệ thống để hiểu thời điểm thu thập và giải phóng khoá chế độ thức.

_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ụ này sẽ không hiển thị tên khoá chế độ thức thực tế. Thay vào đó, các công cụ này sẽ gắn nhãn khoá chế độ thức là _UNKNOWN. Ví dụ: các công cụ có thể thực hiện việc này nếu tên khoá chế độ thức chứa địa chỉ email.

Nội dung đề xuất

Hãy làm theo các phương pháp hay nhất về đặt tên khoá chế độ thức và tránh sử dụng PII trong tên khoá chế độ thức. Nếu bạn tìm thấy một khoá chế độ thức có tên là _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á đó.