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

Tài liệu này liệt kê một số tên khoá đánh thức phổ biến mà bạn có thể gặp phải khi sử dụng công cụ gỡ lỗi khoá đánh thức hoặc trong báo cáo từ các chỉ số quan trọng. 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 các khoá đánh thức hoạt động không đúng cách, sau đó tìm tên khoá đánh 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á đánh thức, nêu chi tiết tên khoá đánh 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á đánh thức.

• AlarmManager
• Âm thanh và nội dung nghe nhìn
• Bluetooth
• Cảm biến trên thiết bị
• Giải pháp gửi thông báo qua đám mây của Firebase (FCM)
• JobScheduler
• Vị trí
• Nhắn tin từ xa
• WorkManager
• _UNKNOWN: Do các công cụ gỡ lỗi hiển thị nếu tên khoá đánh thức có vẻ sử dụng thông tin nhận dạng cá nhân (PII).

AlarmManager

AlarmManager thu thập khoá chế độ thức và phân bổ các khoá này cho ứng dụng gọi. AlarmManager thu thập khoá chế độ thức khi chuông báo tắt 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 thực thi xong.

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

AlarmManager tạo khoá đánh 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 chọn 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 dùng chuông báo không chính xác để hệ thống có thêm tính linh hoạt 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 ngạch báo thức do hệ thống áp đặt và thiết kế ứng dụng của bạn để tuân thủ hạn ngạch này.
• Tránh thực hiện các thao tá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 kêu.

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

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

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

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

• AudioBitPerfect: Dùng để phát âm thanh qua USB mà không làm giảm chất lượng.
• AudioDirectOut: Dùng để phát âm thanh không mất dữ liệu 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: Được dùng để ghi âm thanh khi ở chế độ máy quay trong lúc micrô đang hoạt động.
• AudioMix: Dùng để phát âm thanh trê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 những ứng dụng hỗ trợ chế độ này.
• AudioSpatial: Dùng để phát âm thanh đa kênh của phim hoặc nhạc trên các thiết bị hỗ trợ âm thanh không gian.
• AudioUnknown: Được dùng khi các trường hợp khác không áp dụng.
• MmapCapture: Dùng để ghi âm thanh có độ trễ thấp.
• MmapPlayback: Dùng để phát lại 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 các API đa phương tiện, bạn không cần trực tiếp lấy khoá đánh thức; bạn có thể dựa vào các API để lấy khoá đánh thức cần thiết cho bạn.
• Khi sử dụng các API đa phương tiện, hãy kết thúc phiên đa phương tiện và dịch vụ liên kết trên nền trước khi bạn không cần dùng nữa.

Bluetooth

Các API Bluetooth của nền tảng chủ yếu giữ các khoá đánh thức nhân trong khi các thao tác Bluetooth diễn ra, không thể quy 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 nhận được khoá đánh 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.
• Việc sử dụng WorkManager thường là đủ nếu không có tác động nào đến người dùng đối với thông báo bị trì hoãn. Nếu cần khoá đánh thức theo cách thủ công, chỉ giữ khoá đánh 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ó một số phương thức để 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 dùng Wear Health Services để lấy dữ liệu thiết bị, chẳng hạn như độ cao, nhịp 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 để định kỳ truy xuất dữ liệu.

Đố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 để định kỳ truy xuất dữ liệu. Để truy cập vào dữ liệu về số bước đi trong quá khứ (chẳng hạn như tổng số bước đi trong ngày hoặc số bước đi trong 6 giờ qua), Health Connect cũng hỗ trợ tính năng theo dõi số bước đi 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 sử dụng tính năng theo dõi cảm biến thiết bị tuỳ chỉnh bằng SensorManager. SensorManager không nhận được khoá đánh 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 đáng kể pin. Dưới đây là các đề xuất để giảm mức tiêu hao pin và mức sử dụng khoá đánh thức:

• Nếu 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 thiết bị cũ 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ý một cảm biến bằng SensorManager, hãy xác định maxReportLatencyUs dài hơn 30 giây để sử dụng logic kết hợp 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 sự kiện 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 theo lịch, hệ thống sẽ ngay lập tức gửi 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á quá trình 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á đánh thức ngắn mà hệ thống giữ để cập nhật vị trí, bạn không cần khoá đánh thức để giữ cho CPU hoạt động. Sử dụng một worker hoặc khoá đánh 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á đánh thức được lấy trong khi truyền thông báo truyền tin Giải pháp gửi thông báo qua đám mây của Firebase (FCM) đến ứng dụng. Khoá đánh thức sẽ được giải phóng sau khi phương thức truyền tin onMessageReceived() của FCM thực thi xong.

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

Khi thiết bị nhận được một thông báo FCM, một khoá đánh thức ngắn sẽ được giữ lại với tên GOOGLE_C2DM. Trên Android 16 trở lên, tên khoá đánh 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 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.
• Hoàn tất phương thức onMessageReceived() nhanh nhất có thể 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. Hãy xem hướng dẫn của firebase để biết thêm thông tin.

JobScheduler

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

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

Tên khoá đánh thức mà JobScheduler thu được 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, chứ không phải văn bản chữ <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ác công việc do người dùng khởi tạo sẽ tạo khoá đánh 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.1 trở lên

Các công việc do người dùng khởi tạo sẽ tạo khoá đánh thức có tê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 sau:

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

Các 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 được đẩy nhanh 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á đánh 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.1 trở lên, khoá đánh thức sẽ có tên là:

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

Nội dung đề xuất

• Khô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 khởi tạo. Thay vào đó, hãy sử dụng API Lệnh 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ác khoá đánh thức do JobScheduler tạo có mức sử dụng khoá đánh thức cao, thì có thể là do bạn đã định cấu hình sai công việc của mình để không hoàn thành 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 công việc, đặc biệt là nếu bạn thấy STOP_REASON_TIMEOUT xuất hiện 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á đánh thức để thu thập và cung cấp thông tin vị trí của thiết bị. Khoá đánh thức được phân bổ 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 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 thu thập một khoá đánh thức riêng biệt, liên tục để lưu vào bộ nhớ đệm dữ liệu vị trí, vì việc này là không cần thiết và bạn nên 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 quá trì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 cách sử dụ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 việc 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 việc sử dụng khoá đánh 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ắm mạng với một biến thể dành cho máy tính.

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

WorkManager

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

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

Tên khoá đánh thức mà WorkManager thu được 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á đánh thức có tên theo mẫu sau:

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

Android 16.1 trở lên

Các tác vụ ưu tiên tạo khoá đánh thức có tê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 của worker.

Ví dụ

Giả sử có một worker được tăng tốc 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á đánh 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 trở lên và sử dụng WorkManager 2.10.0+, khoá đánh 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á đánh thức chi tiết hơn trên Android 16.1 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ề tối ưu hoá mức sử dụng pin cho các API lập lịch tác vụ. Để làm cho thẻ khoá đánh thức chi tiết hơn trên Android 16.1 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ác khoá đánh thức do WorkManager tạo có mức sử dụng khoá đánh 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 việc phân tích lý do dừng worker, đặc biệt là nếu bạn thấy STOP_REASON_TIMEOUT xuất hiện nhiều lần.
• 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ề 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 để biết thời điểm khoá đánh thức được thu thập và phát hành.

_UNKNOWN

Nếu các công cụ gỡ lỗi cho rằng tên khoá đánh thức 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á đánh thức thực tế. Thay vào đó, chúng sẽ gắn nhãn khoá đánh 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 wake lock chứa địa chỉ email.

Nội dung đề xuất

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