เอกสารนี้จะช่วยคุณระบุกรณีการใช้งาน Wake Lock ในแอปและเพิ่มประสิทธิภาพ รวมถึงไฮไลต์หากมี Wake Lock ที่ได้จากไลบรารีอื่นๆ หรือ API ของระบบที่เชื่อมโยงกับกรณีการใช้งานนี้ เนื่องจาก Wake Lock เหล่านี้มีสาเหตุมาจากแอปของคุณ จึงอาจระบุแหล่งที่มาของ Wake Lock ที่มีปัญหาได้ยาก การใช้ API อย่างไม่ถูกต้องอาจทำให้ระบบแจ้งว่าแอปของคุณใช้ Wake Lock มากเกินไป แม้ว่าคุณจะไม่ได้ขอ Wake Lock อย่างชัดเจนก็ตาม
เอกสารนี้แสดงชื่อ Wake Lock ที่พบบ่อยบางชื่อที่คุณอาจพบเมื่อใช้เครื่องมือแก้ไขข้อบกพร่องของ Wake Lock หรือในรายงานจาก Vitals ชื่อเหล่านี้อาจมาจาก API ของไลบรารีหรือระบบ หรืออาจมีการปกปิด การใช้เครื่องมือแก้ไขข้อบกพร่องเพื่อระบุ Wake Lock ที่ทำงานผิดปกติ แล้วค้นหาชื่อ Wake Lock ในเอกสารนี้จะช่วยให้คุณทราบว่า API ใดอาจเป็นสาเหตุของปัญหา และดูคำแนะนำเกี่ยวกับวิธีเพิ่มประสิทธิภาพการใช้งานได้
เอกสารนี้อธิบาย Use Case ทั่วไปสำหรับการรับ Wake Lock โดยให้รายละเอียดเกี่ยวกับ ชื่อ Wake Lock ที่ใช้โดย API และไลบรารีต่างๆ รวมถึงให้ คำแนะนำและแนวทางปฏิบัติแนะนำสำหรับการเพิ่มประสิทธิภาพและลดการใช้งาน Wake Lock
- AlarmManager
- เสียงและสื่อ
- บลูทูธ
- เซ็นเซอร์ของอุปกรณ์
- Firebase Cloud Message (FCM)
- JobScheduler
- ตำแหน่ง
- การรับส่งข้อความระยะไกล
- WorkManager
_UNKNOWN: แสดงโดยเครื่องมือแก้ไขข้อบกพร่องหากชื่อ Wake Lock ดูเหมือนจะใช้ข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (PII)
AlarmManager
AlarmManager จะรับ Wake Lock และเชื่อมโยงกับแอปที่เรียกใช้
AlarmManager จะรับ Wake Lock เมื่อสัญญาณเตือนดังขึ้น และจะปล่อย
ล็อกเมื่อเมธอด onReceive()
ของการออกอากาศสัญญาณเตือนทำงานเสร็จ
ชื่อ Wake Lock
AlarmManager สร้างการทำงานขณะล็อกที่มีชื่อว่า *alarm* (เครื่องหมายดอกจันเป็นส่วนหนึ่งของชื่อ Wake Lock ไม่ใช่ไวลด์การ์ด)
คำแนะนำ
เราขอแนะนำให้ปฏิบัติตามแนวทางต่อไปนี้เพื่อเพิ่มประสิทธิภาพการทำงานของสัญญาณเตือน
- ดูเลือกประเภทการปลุกเพื่อเลือกระหว่างการปลุกแบบไม่แน่นอนหรือ แบบแน่นอน หากการปลุกไม่จำเป็นต้องแม่นยำ ให้ใช้การปลุกที่ไม่แน่นอนเพื่อให้ ระบบมีความยืดหยุ่นในการกำหนดเวลามากขึ้น ซึ่งจะช่วยยืดอายุการใช้งานแบตเตอรี่ได้
- โปรดทราบโควต้าการปลุกที่ระบบกำหนดและออกแบบแอปให้เป็นไปตามโควต้าดังกล่าว
- หลีกเลี่ยงการทำงานที่ใช้เวลานานในวิธี
onReceive()และ กำหนดเวลาให้ผู้ปฏิบัติงานหากต้องมีการประมวลผลเพิ่มเติมหลังจากที่สัญญาณเตือนดังขึ้น
เสียงและสื่อ
API สื่อจะรับ Wake Lock ได้เมื่อบันทึกหรือเล่นเสียง ระบบจะระบุว่าแอปการโทรเป็นผู้ใช้ Wake Lock
ชื่อ Wake Lock
API สื่อจะรับ Wake Lock ที่มีชื่อต่างๆ ซึ่งขึ้นต้นด้วย Audio
AudioBitPerfect: ใช้สำหรับการเล่นเสียง USB แบบไม่สูญเสียข้อมูลAudioDirectOut: ใช้สำหรับการเล่นเสียงแบบไม่สูญเสียรายละเอียดบนทีวีหรืออุปกรณ์พิเศษAudioDup: ใช้สำหรับการเล่นการแจ้งเตือนขณะเชื่อมต่อโดยใช้บลูทูธ หรือ USBAudioIn: ใช้สำหรับการบันทึกเสียงเมื่ออยู่ในโหมดกล้องวิดีโอขณะที่ไมโครโฟน เปิดอยู่AudioMix: ใช้สำหรับการเล่นเสียงไปยังอุปกรณ์ทั่วไปAudioOffload: ใช้สำหรับการเล่นเพลงอย่างเดียวในระยะยาว สำหรับแอปที่รองรับ โหมดนี้AudioSpatial: ใช้สำหรับการเล่นเสียงภาพยนตร์หรือเพลงแบบหลายช่องบน อุปกรณ์ที่รองรับเสียงรอบทิศทางAudioUnknown: ใช้เมื่อสถานการณ์อื่นๆ ไม่เกี่ยวข้องMmapCapture: ใช้สำหรับการบันทึกเสียงที่มีเวลาในการตอบสนองต่ำMmapPlayback: ใช้สำหรับการเล่นที่มีเวลาในการตอบสนองต่ำ เช่น สำหรับการเล่นเกมหรือสำหรับแอปพลิเคชันเสียงระดับมืออาชีพ
คำแนะนำ
เราขอแนะนำให้ปฏิบัติดังนี้
- อย่าประกาศชื่อ Wake Lock ที่ขึ้นต้นด้วย
Audio - หากใช้ Media API คุณไม่จำเป็นต้องขอ Wake Lock โดยตรง แต่สามารถใช้ API เพื่อขอ Wake Lock ที่จำเป็นให้คุณได้
- เมื่อใช้ Media API ให้สิ้นสุดเซสชันสื่อและบริการที่ทำงานอยู่เบื้องหน้าที่เชื่อมโยงเมื่อไม่ต้องการใช้แล้ว
บลูทูธ
โดยหลักแล้ว Bluetooth API ของแพลตฟอร์มจะถือการล็อกการปลุกของเคอร์เนลขณะที่การดำเนินการผ่านบลูทูธ เกิดขึ้น ซึ่งไม่สามารถระบุแหล่งที่มาของแอปพลิเคชันได้
คำแนะนำ
- ใช้การจับคู่อุปกรณ์เสริมเพื่อจับคู่อุปกรณ์บลูทูธเพื่อหลีกเลี่ยง การได้ Wake Lock ด้วยตนเองในระหว่างการจับคู่บลูทูธ
- โปรดดูคำแนะนำสื่อสารในเบื้องหลังเพื่อทำความเข้าใจวิธีสื่อสารผ่านบลูทูธในเบื้องหลัง
- การใช้
WorkManagerมักจะเพียงพอในกรณีที่ไม่มีผลกระทบต่อผู้ใช้ในการสื่อสารที่ล่าช้า หากเห็นว่าจำเป็นต้องใช้ Wake Lock ด้วยตนเอง ให้ใช้ Wake Lock เฉพาะในระยะเวลาของกิจกรรมบลูทูธหรือการประมวลผลข้อมูลกิจกรรมเท่านั้น
เซ็นเซอร์ของอุปกรณ์
การติดตามข้อมูลเซ็นเซอร์ของอุปกรณ์ เช่น จำนวนก้าว ข้อมูลตัวตรวจวัดความเร่งหรือเครื่องวัดการหมุน ทำได้หลายวิธี
ใน Wear OS ให้ใช้ Wear Health Services เพื่อดึงข้อมูลอุปกรณ์ เช่น ระดับความสูง อัตราการเต้นของหัวใจ และระยะทางที่เดินทาง
หากแอปพลิเคชันอื่นๆ รวบรวมข้อมูล คุณสามารถใช้ Health Connect ร่วมกับ WorkManager เพื่อดึงข้อมูลเป็นระยะๆ ได้
สำหรับสถานการณ์ต่างๆ เช่น การติดตามส่วนต่างของจำนวนก้าวหรือระยะทางที่เดิน คุณสามารถใช้ Recording API บนอุปกรณ์เคลื่อนที่ร่วมกับ WorkManager เพื่อดึงข้อมูลเป็นระยะๆ ได้ หากต้องการเข้าถึงข้อมูลจำนวนก้าวในอดีต (เช่น จำนวนก้าวทั้งหมดต่อวัน หรือจำนวนก้าวในช่วง 6 ชั่วโมงที่ผ่านมา) Health Connect ยังรองรับการติดตามจำนวนก้าวในอุปกรณ์สำหรับอุปกรณ์ที่ใช้ Android 14 ขึ้นไปด้วย
ในบางกรณี คุณอาจต้องใช้การติดตามเซ็นเซอร์อุปกรณ์ที่กำหนดเองโดยใช้
SensorManager SensorManager ไม่ได้ขอ
Wake Lock ในนามของแอป เว้นแต่เซ็นเซอร์จะเป็นเซ็นเซอร์ปลุก
ซึ่งระบุได้โดยใช้ API isWakeUpSensor
คำแนะนำ
การใช้เซ็นเซอร์เพื่อบันทึกที่อัตราการสุ่มตัวอย่างสูงอาจทำให้แบตเตอรี่หมดเร็วมาก คำแนะนำในการลดการใช้แบตเตอรี่และ Wake Lock มีดังนี้
- หากติดตามจำนวนก้าวหรือระยะทางที่เดินทาง ให้ใช้ Recording API เพื่อบันทึกข้อมูลในลักษณะที่ประหยัดแบตเตอรี่ สำหรับอุปกรณ์ที่ใช้ Android 14 ขึ้นไป ให้พิจารณาใช้ Health Connect เพื่อเข้าถึงอุปกรณ์ในอดีตและจำนวนก้าวที่รวบรวมไว้
- สำหรับการติดตามเซ็นเซอร์แบบพาสซีฟใน Wear OS ให้ใช้ Wear Health Services เพื่อเพิ่มประสิทธิภาพการใช้งานแบตเตอรี่
- เมื่อลงทะเบียนเซ็นเซอร์กับ
SensorManagerให้กำหนดmaxReportLatencyUsมากกว่า 30 วินาทีเพื่อใช้ ตรรกะการจัดกลุ่มเซ็นเซอร์และลดจำนวน การขัดจังหวะที่แอปพลิเคชันได้รับ เมื่ออุปกรณ์ตื่นขึ้นในภายหลัง จากทริกเกอร์อื่น เช่น การโต้ตอบของผู้ใช้ การดึงข้อมูลตำแหน่ง หรือ งานที่กำหนดเวลาไว้ ระบบจะส่งข้อมูลเซ็นเซอร์ที่แคชไว้ทันที - หากแอปต้องใช้ทั้งข้อมูลตำแหน่งและข้อมูลเซ็นเซอร์ ให้ซิงค์การดึงและการประมวลผลเหตุการณ์ การรวมค่าที่อ่านได้จากเซ็นเซอร์ไว้ใน Wake Lock แบบย่อที่ระบบใช้สำหรับการอัปเดตตำแหน่งจะช่วยให้คุณไม่ต้องใช้ Wake Lock เพื่อให้ CPU ทำงานอยู่ ใช้ Worker หรือ Wake Lock ระยะสั้นเพื่อจัดการการอัปโหลดและการประมวลผลข้อมูลที่รวมกันนี้
ข้อความ Firebase Cloud (FCM)
ระบบจะรับ Wake Lock ขณะส่งข้อความที่ออกอากาศของ Firebase Cloud Messaging (FCM) ไปยังแอป
ระบบจะปล่อย Wake Lock เมื่อวิธีการ onMessageReceived() ของการออกอากาศ FCM ทำงานเสร็จ
ชื่อ Wake Lock
เมื่ออุปกรณ์ได้รับข้อความ FCM ระบบจะใช้ Wake Lock แบบสั้นที่มีชื่อ GOOGLE_C2DM ใน Android 16 ขึ้นไป ชื่อ Wake Lock คือ GCM_MESSAGE
คำแนะนำ
เราขอแนะนำให้ปฏิบัติตามแนวทางต่อไปนี้เพื่อเพิ่มประสิทธิภาพลักษณะการทำงานของ FCM
- เพิ่มประสิทธิภาพความถี่ในการนำส่ง FCM
- อย่าใช้ FCM ที่มีลำดับความสำคัญสูง เว้นแต่ข้อความนั้นจำเป็นต้องส่งทันที
onMessageReceived()วิธีการให้เสร็จสมบูรณ์โดยเร็วที่สุด หรือ กำหนดเวลาให้ผู้ปฏิบัติงานดำเนินการต่อหากต้องมีการประมวลผลเพิ่มเติม ดูข้อมูลเพิ่มเติมได้ที่คำแนะนำเกี่ยวกับ Firebase
JobScheduler
งาน JobScheduler จะได้ล็อกการปลุกระบบขณะดำเนินงานใน เบื้องหลัง ระบบจะระบุการล็อกการปลุกให้กับแอปที่สร้าง Worker
ชื่อ Wake Lock
ชื่อ Wake Lock ที่ JobScheduler ได้รับจะขึ้นอยู่กับเวอร์ชันของระบบ Android ที่ทำงานอยู่และวัตถุประสงค์ของงาน
รายการที่อยู่ในวงเล็บเหลี่ยมคือตัวแปร เช่น "<package_name>" คือชื่อแพ็กเกจของแอป ไม่ใช่ข้อความตามตัวอักษร <package name> อย่างไรก็ตาม *job* คือลำดับอักขระ
*job* ที่มีเครื่องหมายดอกจัน โดยไม่ได้ใช้เครื่องหมายดอกจันเป็นไวลด์การ์ด
Android 15 และต่ำกว่า
งานที่ผู้ใช้เริ่มจะสร้าง Wake Lock ที่มีชื่อตามรูปแบบต่อไปนี้
*job*u/@<name_space>@/<package_name>/<classname>
งานอื่นๆ ที่ใช้รูปแบบนี้
*job*/@<name_space>@/<package_name>/<classname>
Android 16 QPR2 ขึ้นไป
งานที่ผู้ใช้เริ่มจะสร้าง Wake Lock ที่มีชื่อตามรูปแบบต่อไปนี้
*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
งานด่วนใช้รูปแบบต่อไปนี้
*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
งานปกติใช้รูปแบบนี้
*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
ตัวอย่าง
สมมติว่ามีงานด่วนที่มีเนมสเปซ backup และแท็กการติดตาม started ชื่อแพ็กเกจคือ com.example.app และคลาสที่สร้างงานคือ com.backup.BackupFileService
ในอุปกรณ์ที่ใช้ Android 15 หรือต่ำกว่า Wake Lock จะมีชื่อดังนี้
*job*/@backup@/com.example.app/com.backup.BackupFileService
ในอุปกรณ์ที่ใช้ Android 16 QPR2 ขึ้นไป Wake Lock จะมีชื่อดังนี้
*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService
คำแนะนำ
- อย่าใช้ Wake Lock ด้วยตนเองสำหรับกรณีการใช้งานการดาวน์โหลด/ อัปโหลดที่ผู้ใช้เริ่ม แต่ให้ใช้ API การโอนข้อมูลที่เริ่มต้นโดยผู้ใช้ (UIDT) แทน นี่คือเส้นทางที่กำหนดไว้สำหรับงานการโอนข้อมูลที่ใช้เวลานานซึ่งเริ่มต้นโดยผู้ใช้
- หากพบว่า JobScheduler สร้าง Wake Lock ที่มีการใช้งาน Wake Lock สูง
อาจเป็นเพราะคุณกำหนดค่า Job ไม่ถูกต้องเพื่อให้ไม่เสร็จสมบูรณ์ในบาง
สถานการณ์ พิจารณาการวิเคราะห์สาเหตุที่งานหยุด
โดยเฉพาะอย่างยิ่งหากคุณเห็นว่า
STOP_REASON_TIMEOUTเกิดขึ้นบ่อย - ตรวจสอบการใช้งานงาน JobScheduler โดยเฉพาะอย่างยิ่ง ให้ทำตามคำแนะนำของเรา สำหรับการเพิ่มประสิทธิภาพการใช้แบตเตอรี่สำหรับ API การตั้งเวลางาน
ตำแหน่ง
LocationManager และ FusedLocationProviderClient ใช้
การล็อกการปลุกเพื่อรับและส่งตำแหน่งของอุปกรณ์ ระบบจะระบุแหล่งที่มาของ Wake Lock
ไปยังแอปที่เรียก API เหล่านั้น
ชื่อ Wake Lock
บริการตำแหน่งใช้ชื่อต่อไปนี้
CollectionLib-SigCollectorNetworkLocationLocatorNetworkLocationScannerNlpCollectorWakeLockNlpWakeLock*location*
คำแนะนำ
- โปรดดูคำแนะนำเพื่อเพิ่มประสิทธิภาพการใช้ตำแหน่ง พิจารณา การใช้การหมดเวลา การใช้ประโยชน์จากการจัดกลุ่มคำขอตำแหน่ง หรือการใช้การอัปเดตตำแหน่งแบบพาสซีฟ
- หลีกเลี่ยงการรับ Wake Lock แบบต่อเนื่องแยกต่างหากเพื่อแคชข้อมูลตำแหน่ง
เนื่องจากซ้ำซ้อนและควรนำออก
เมื่อขอการอัปเดตตำแหน่งโดยใช้
FusedLocationProviderหรือLocationManagerAPI ระบบจะ ทริกเกอร์การปลุกอุปกรณ์โดยอัตโนมัติระหว่างการเรียกกลับของเหตุการณ์ตำแหน่ง แต่ให้จัดเก็บเหตุการณ์ตำแหน่งไว้ในหน่วยความจำหรือที่เก็บข้อมูล และประมวลผลเหตุการณ์ตำแหน่งเป็นระยะๆ โดยใช้WorkManager
การรับส่งข้อความระยะไกล
ส่วนนี้จะอธิบายสถานการณ์ที่เกี่ยวข้องกับการรับส่งข้อความจากระยะไกลซึ่งแอปอาจต้องรักษาการเชื่อมต่อหรือตอบสนองต่อเหตุการณ์จากอุปกรณ์อื่นๆ ซึ่งอาจส่งผลต่อการใช้ Wake Lock Use Case ทั่วไปมีดังนี้
- แอปที่ใช้ร่วมกันสำหรับการตรวจสอบวิดีโอหรือเสียงซึ่งต้องตรวจสอบเหตุการณ์ ที่เกิดขึ้นในอุปกรณ์ภายนอกที่เชื่อมต่อผ่านเครือข่าย LAN
- แอปส่งข้อความที่คงการเชื่อมต่อซ็อกเก็ตเครือข่ายกับแอปเวอร์ชันเดสก์ท็อป
การปลุกระบบส่วนใหญ่ในสถานการณ์การรับส่งข้อความระยะไกลเหล่านี้คือ Wake Lock ของเคอร์เนล เนื่องจากไม่ได้ระบุ Wake Lock ของเคอร์เนล ให้กับแอป จึงไม่มีชื่อ Wake Lock ที่เกี่ยวข้อง ให้แสดงที่นี่
คำแนะนำ
- หากประมวลผลเหตุการณ์เครือข่ายในฝั่งเซิร์ฟเวอร์ได้ ให้ใช้ FCM เพื่อรับข้อมูลในไคลเอ็นต์ คุณเลือกตั้งเวลาWorker ที่เร่งด่วนได้หากต้องประมวลผลข้อมูล FCM เพิ่มเติม
- หากต้องประมวลผลเหตุการณ์ในฝั่งไคลเอ็นต์โดยใช้การเชื่อมต่อซ็อกเก็ต คุณไม่จำเป็นต้องใช้ Wake Lock เพื่อฟังการขัดจังหวะของเหตุการณ์ เมื่อแพ็กเก็ตข้อมูลมาถึงวิทยุ Wi-Fi หรือเซลลูลาร์ ฮาร์ดแวร์วิทยุ จะทริกเกอร์การหยุดชะงักในรูปแบบของ Wake Lock ของเคอร์เนล จากนั้นคุณอาจเลือกกำหนดเวลาให้ Worker หรือ รับ Wake Lock เพื่อประมวลผลข้อมูล
- เช่น หากคุณใช้
ktor-networkเพื่อฟังแพ็กเก็ตข้อมูลในซ็อกเก็ตเครือข่าย คุณควรขอ Wake Lock เฉพาะเมื่อมีการส่งแพ็กเก็ตไปยังไคลเอ็นต์แล้วเท่านั้น
WorkManager
Worker ของ WorkManager จะได้รับล็อกการปลุกระบบขณะที่ดำเนินการในเบื้องหลัง ระบบจะระบุการล็อกการปลุกให้กับแอปที่สร้าง Worker
ชื่อ Wake Lock
ชื่อ Wake Lock ที่ WorkManager ได้รับจะขึ้นอยู่กับเวอร์ชันของระบบ Android ที่กำลังทำงานอยู่
Android 15 และต่ำกว่า
งาน WorkManager จะสร้าง Wake Lock โดยมีชื่อตามรูปแบบต่อไปนี้
*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 QPR2 ขึ้นไป
งานที่เร่งด่วนจะสร้าง Wake Lock ที่มีชื่อตามรูปแบบต่อไปนี้
*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
งานปกติมีรูปแบบดังนี้
*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
โดยค่าเริ่มต้น <trace_tag> คือชื่อ Worker
ตัวอย่าง
สมมติว่ามีผู้ปฏิบัติงานที่เร่งด่วนชื่อ BackupFileWorker ชื่อแพ็กเกจ
คือ com.example.app
ในอุปกรณ์ที่ใช้ Android 15 หรือต่ำกว่า Wake Lock จะมีชื่อดังนี้
*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService
ในอุปกรณ์ที่ใช้ Android 16 QPR2 ขึ้นไปและใช้ WorkManager 2.10.0+
ระบบจะตั้งชื่อ Wake Lock ดังนี้
*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService
คำแนะนำ
- อัปเกรด WorkManager เป็นเวอร์ชันเสถียรล่าสุดเพื่อให้ แท็ก Wake Lock มีรายละเอียดมากขึ้นใน Android 16 QPR2 ขึ้นไป
- ตรวจสอบการใช้งาน Worker ของ WorkManager โดยเฉพาะอย่างยิ่ง ให้ตรวจสอบว่าแอปเป็นไปตาม
คำแนะนำในการเพิ่มประสิทธิภาพการใช้แบตเตอรี่สำหรับ API การตั้งเวลางาน
หากต้องการให้แท็ก Wake Lock มีรายละเอียดมากขึ้นใน Android 16 QPR2 ขึ้นไป ให้ใช้วิธี
setTraceTagใน Worker เพื่อเพิ่มข้อมูลการแก้ไขข้อบกพร่อง เช่น คลาสที่กำหนดเวลา Worker - หากคุณพบ Wake Lock ที่สร้างโดย WorkManager ซึ่งมีการใช้งาน Wake Lock สูง อาจเป็นเพราะคุณกำหนดค่า Worker ไม่ถูกต้องเพื่อให้ไม่
ทำงานให้เสร็จในบางสถานการณ์ พิจารณาการวิเคราะห์เหตุผลที่หยุด Worker โดยเฉพาะหากคุณเห็น
STOP_REASON_TIMEOUTเกิดขึ้นบ่อย - นอกเหนือจากการบันทึกเหตุผลที่หยุดการทำงานของ Worker แล้ว โปรดดูเอกสารประกอบเกี่ยวกับการแก้ไขข้อบกพร่องของ Worker นอกจากนี้ ให้พิจารณาการรวบรวมและวิเคราะห์การติดตามระบบเพื่อทำความเข้าใจว่าเมื่อใดที่ได้และปล่อย Wake Lock
_UNKNOWN
หากเครื่องมือแก้ไขข้อบกพร่องคิดว่าชื่อ Wake Lock มีข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (PII) เครื่องมือจะไม่แสดงชื่อ Wake Lock จริง แต่จะติดป้ายกำกับ Wake Lock เป็น _UNKNOWN แทน เช่น เครื่องมืออาจทำเช่นนี้หากชื่อ Wake Lock มีอีเมล
คำแนะนำ
ทําตามแนวทางปฏิบัติแนะนําในการตั้งชื่อ Wake Lock และหลีกเลี่ยงการใช้ PII ในชื่อ Wake Lock หากพบ Wake Lock ที่ชื่อ _UNKNOWN ซึ่งเชื่อมโยงกับแอปของคุณ ให้ลอง
ระบุว่า Wake Lock นั้นคืออะไร แล้วตั้งชื่ออื่น