ข่าวสารผลิตภัณฑ์
เพิ่มประสิทธิภาพแบตเตอรี่ของแอปโดยใช้เมตริก Wake Lock ของ Android Vitals
ใช้เวลาอ่าน 7 นาที
อายุการใช้งานแบตเตอรี่เป็นแง่มุมที่สำคัญของประสบการณ์ของผู้ใช้ และ Wake Lock มีบทบาทสำคัญในเรื่องนี้ คุณใช้ฟีเจอร์เหล่านี้มากเกินไปหรือไม่ ในบล็อกโพสต์นี้ เราจะมาดูกันว่า Wake Lock คืออะไร แนวทางปฏิบัติแนะนำในการใช้ Wake Lock และวิธีทำความเข้าใจลักษณะการทำงานของแอปของคุณเองให้ดียิ่งขึ้นด้วยเมตริกของ Play Console
การใช้งาน Wake Lock บางส่วนมากเกินไปใน Android Vitals
ตอนนี้ Play Console จะตรวจสอบแบตเตอรี่หมดเร็ว โดยมุ่งเน้นที่การใช้ Wake Lock บางส่วนมากเกินไปเป็นตัวชี้วัดประสิทธิภาพหลัก
ฟีเจอร์นี้จะเพิ่มความสำคัญของประสิทธิภาพแบตเตอรี่ควบคู่ไปกับตัวบ่งชี้ความเสถียรของเมตริกหลักที่มีอยู่ ได้แก่ การขัดข้องที่ผู้ใช้รับรู้มากเกินไปและ ANR เราได้กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องสำหรับ Wake Lock ที่มากเกินไป ตั้งแต่วันที่ 1 มีนาคม 2026 หากภาพยนตร์/รายการทีวีไม่เป็นไปตามเกณฑ์คุณภาพนี้ เราอาจยกเว้นภาพยนตร์/รายการทีวีดังกล่าวจากแพลตฟอร์มการค้นพบที่โดดเด่น เช่น คำแนะนำ ในบางกรณี เราอาจแสดงคำเตือนในข้อมูลสินค้าใน Store เพื่อแจ้งให้ผู้ใช้ทราบว่าแอปของคุณอาจทำให้แบตเตอรี่หมดเร็วเกินไป
คำเตือนเกี่ยวกับ Wake Lock มากเกินไปในภาพรวมของ Android Vitals
สำหรับอุปกรณ์เคลื่อนที่ เมตริก Android Vitals จะใช้กับการ Wake Lock ที่ไม่ได้รับการยกเว้นซึ่งได้มาขณะที่หน้าจอปิดอยู่และแอปทำงานอยู่ในเบื้องหลังหรือเรียกใช้บริการที่ทำงานอยู่เบื้องหน้า Android Vitals จะพิจารณาว่าการใช้งาน Wake Lock บางส่วนมากเกินไปในกรณีต่อไปนี้
- มีการล็อกการปลุกอย่างน้อย 2 ชั่วโมงภายในระยะเวลา 24 ชั่วโมง
- ส่งผลต่อเซสชันของแอปมากกว่า 5% โดยเฉลี่ยในช่วง 28 วัน
ระบบจะไม่นำ Wake Lock ที่สร้างโดย API ที่ผู้ใช้เริ่มต้นสำหรับ เสียง ตำแหน่ง และ JobScheduler มาคำนวณ
ทำความเข้าใจเกี่ยวกับ Wake Lock
Wake Lock เป็นกลไกที่ช่วยให้แอปสามารถทำให้ CPU ของอุปกรณ์ทำงานได้แม้ว่าผู้ใช้จะไม่ได้โต้ตอบกับอุปกรณ์อยู่ก็ตาม
Wake Lock บางส่วนจะทำให้ CPU ทำงานต่อไปแม้ว่าหน้าจอจะปิดอยู่ ซึ่งจะป้องกันไม่ให้ CPU เข้าสู่สถานะ "ระงับ" ที่ใช้พลังงานต่ำ Wake Lock แบบเต็มจะทำให้ทั้งหน้าจอและ CPU ทำงานต่อไป
Wake Lock แบบต่อเนื่องบางส่วนมี 2 วิธีในการรับ ดังนี้
- แอปจะรับและปล่อย Wake Lock ด้วยตนเองโดยใช้ API ของ PowerManager สำหรับ Use Case ที่เฉพาะเจาะจง ซึ่งมักจะรับพร้อมกับ Foreground Service ซึ่งเป็น API วงจรแพลตฟอร์มที่มีไว้สำหรับการดำเนินการที่ผู้ใช้รับรู้ได้
- หรืออีกทางหนึ่งคือ API อื่นจะได้รับ Wake Lock และระบุแหล่งที่มาของแอปเนื่องจากการใช้งาน API ซึ่งดูข้อมูลเพิ่มเติมได้ในส่วนแนวทางปฏิบัติแนะนำ
แม้ว่าการล็อกการปลุกจะจำเป็นสำหรับงานต่างๆ เช่น การดาวน์โหลดไฟล์ขนาดใหญ่ที่ผู้ใช้เริ่ม แต่การใช้งานมากเกินไปหรือไม่เหมาะสมอาจทำให้แบตเตอรี่หมดอย่างรวดเร็ว เราเคยเห็นกรณีที่แอปถือ Wake Lock เป็นเวลาหลายชั่วโมงหรือปล่อย Wake Lock ไม่ถูกต้อง ซึ่งทำให้ผู้ใช้ร้องเรียนเรื่องแบตเตอรี่หมดเร็วแม้ว่าจะไม่ได้โต้ตอบกับแอปก็ตาม
แนวทางปฏิบัติแนะนำสำหรับการใช้ Wake Lock
ก่อนจะไปดูวิธีแก้ไขข้อบกพร่องของการใช้ Wake Lock มากเกินไป โปรดตรวจสอบว่าคุณทำตามแนวทางปฏิบัติแนะนำสำหรับ Wake Lock
ลองพิจารณาคำถามสำคัญ 4 ข้อต่อไปนี้
1. คุณเคยพิจารณาตัวเลือก Wake Lock อื่นๆ ไหม
ก่อนพิจารณาการรับ Wake Lock บางส่วนด้วยตนเอง ให้ทำตามแผนผังการตัดสินใจนี้
โฟลว์ชาร์ตเพื่อตัดสินใจว่าจะรับ Wake Lock ด้วยตนเองเมื่อใด
- หน้าจอต้องเปิดอยู่ไหม
- ใช่ โปรดดูเอกสารประกอบเปิดหน้าจอไว้แทน
- แอปพลิเคชันกำลังเรียกใช้บริการที่ทำงานอยู่เบื้องหน้าใช่ไหม
- ไม่ คุณไม่จำเป็นต้องรับ Wake Lock ด้วยตนเอง
- การระงับอุปกรณ์จะส่งผลเสียต่อประสบการณ์ของผู้ใช้ไหม
- ไม่: เช่น การอัปเดตการแจ้งเตือนหลังจากอุปกรณ์ตื่นขึ้นมาไม่จำเป็นต้องใช้ Wake Lock
- ใช่: หากจำเป็นต้องป้องกันไม่ให้อุปกรณ์เข้าสู่โหมดพัก เช่น การสื่อสารกับอุปกรณ์ภายนอกอย่างต่อเนื่อง ให้ดำเนินการต่อ
- มี API ที่ทำให้อุปกรณ์ตื่นอยู่แทนคุณอยู่แล้วใช่ไหม
- คุณใช้ประโยชน์จากเอกสารประกอบระบุการล็อกปลุกที่สร้างโดย API อื่นๆ เพื่อระบุสถานการณ์ที่การล็อกปลุกสร้างโดย API อื่นๆ เช่น LocationManager ได้
- หากไม่มี API ให้ไปยังคำถามสุดท้าย
- หากตอบคำถามเหล่านี้ทั้งหมดแล้วและพิจารณาว่าไม่มีทางเลือกอื่น คุณควรดำเนินการต่อด้วยการรับ Wake Lock ด้วยตนเอง
2. คุณตั้งชื่อ Wake Lock อย่างถูกต้องไหม
เมื่อได้รับ Wake Lock ด้วยตนเอง การตั้งชื่อที่เหมาะสมจะมีความสําคัญต่อการแก้ไขข้อบกพร่อง
- อย่าใส่ข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (PII) ในชื่อ เช่น อีเมล หากตรวจพบ PII ระบบจะบันทึก Wake Lock เป็น
_UNKNOWNซึ่งจะขัดขวางการแก้ไขข้อบกพร่อง - อย่าตั้งชื่อ Wake Lock โดยใช้ชื่อคลาสหรือชื่อเมธอดแบบเป็นโปรแกรม เนื่องจากเครื่องมืออย่าง Proguard อาจทำให้ชื่อเหล่านี้ปรับให้ยากต่อการอ่าน (Obfuscate) แต่ให้ใช้สตริงที่ฮาร์ดโค้ดแทน
- อย่าเพิ่มตัวนับหรือตัวระบุที่ไม่ซ้ำกันลงในแท็ก Wake Lock ควรใช้แท็กเดียวกันทุกครั้งที่ Wake Lock ทำงานเพื่อให้ระบบรวบรวมการใช้งานตามชื่อได้ ซึ่งจะช่วยให้ตรวจพบพฤติกรรมที่ผิดปกติได้ง่ายขึ้น
3. ระบบจะปล่อย Wake Lock ที่ได้มาเสมอใช่ไหม
หากคุณรับ Wake Lock ด้วยตนเอง ให้ตรวจสอบว่าการเผยแพร่ Wake Lock จะดำเนินการเสมอ การไม่ปล่อย Wake Lock อาจทำให้แบตเตอรี่หมดเร็ว
เช่น หากมีการส่งข้อยกเว้นที่ไม่ได้แคชระหว่างการประมวลผล processingWork() การเรียก release() อาจไม่เกิดขึ้นเลย แต่คุณสามารถใช้บล็อก try-finally เพื่อรับประกันว่าระบบจะปล่อย Wake Lock แม้ว่าจะเกิดข้อยกเว้นก็ตาม
นอกจากนี้ คุณยังเพิ่มการหมดเวลาให้กับ Wake Lock เพื่อให้แน่ใจว่าระบบจะปล่อย Wake Lock หลังจากระยะเวลาที่กำหนด ซึ่งจะป้องกันไม่ให้มีการถือ Wake Lock ไว้โดยไม่มีกำหนด
fun processingWork() {
wakeLock.apply {
try {
acquire(60 * 10 * 1000) // timeout after 10 minutes
doTheWork()
} finally {
release()
}
}
}
4. คุณลดความถี่ในการปลุกได้ไหม
สำหรับการขอข้อมูลเป็นระยะ การลดความถี่ที่แอปปลุกอุปกรณ์เป็นกุญแจสำคัญในการเพิ่มประสิทธิภาพแบตเตอรี่ ตัวอย่างการลดความถี่ในการปลุกมีดังนี้
- WorkManager: เพิ่มช่วงเวลาเป็นระยะๆ ใน PeriodicWorkRequest
- SensorManager: ใช้ประโยชน์จากการจัดกลุ่มโดยระบุ maxReportLatencyMs เมื่อลงทะเบียน Listener
- Fused Location Provider:
- ลดความถี่ในการดึงข้อมูลตำแหน่งโดยใช้ getLastLocation สำหรับตำแหน่งที่แคชล่าสุด
- ใช้ setPriority(PRIORITY_PASSIVE) สำหรับวิธีการอัปเดตที่ใช้แบตเตอรี่น้อยกว่า
- นอกจากนี้ คุณยังใช้ประโยชน์จากกลไกการจัดกลุ่มตำแหน่งได้โดยการตั้งค่าช่วงเวลาการอัปเดตขั้นต่ำด้วย setMinUpdateIntervalMillis
ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบเกี่ยวกับแนวทางปฏิบัติแนะนำสำหรับ Wake Lock
การแก้ไขข้อบกพร่องการใช้ Wake Lock มากเกินไป
แม้ว่าจะมีเจตนาดีที่สุด แต่ก็อาจมีการใช้ Wake Lock มากเกินไป หากแอปของคุณถูกแจ้งว่าไม่เหมาะสมใน Play Console ให้แก้ไขข้อบกพร่องโดยทำดังนี้
การระบุตัวตนครั้งแรกด้วย Play Console
แดชบอร์ด Wake Lock บางส่วนที่มากเกินไปของ Android Vitals จะแสดงรายละเอียดชื่อ Wake Lock ที่ไม่ได้รับการยกเว้นซึ่งเชื่อมโยงกับแอปของคุณ โดยจะแสดงเซสชันและระยะเวลาที่ได้รับผลกระทบ โปรดอย่าลืมใช้เอกสารประกอบเพื่อช่วยระบุว่าชื่อ Wake Lock เป็นของแอปหรือ API อื่น
แดชบอร์ด Wake Lock บางส่วนที่มากเกินไปของ Android Vitals เลื่อนลงไปที่ส่วนรายละเอียดเพื่อดูแท็ก Wake Lock ที่มากเกินไป
การแก้ไขข้อบกพร่องของ Wake Lock ที่มากเกินไปซึ่ง Worker/งานถือครองอยู่
คุณระบุ Wake Lock ที่ผู้ปฏิบัติงานถือไว้ได้ด้วยชื่อ Wake Lock นี้
*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
ดูรายการชื่อ Wake Lock ที่ผู้ปฏิบัติงานถือทั้งหมดได้ในเอกสารประกอบ หากต้องการแก้ไขข้อบกพร่องของ Wake Lock เหล่านี้ คุณสามารถใช้เครื่องมือตรวจสอบงานในเบื้องหลังเพื่อแก้ไขข้อบกพร่องในเครื่อง หรือใช้ประโยชน์จาก getStopReason เพื่อแก้ไขข้อบกพร่องในฟิลด์
เครื่องมือตรวจสอบงานในเบื้องหลังของ Android Studio
ภาพหน้าจอของเครื่องมือตรวจสอบงานในเบื้องหลัง ซึ่งสามารถระบุ Worker "WeatherSyncWorker" ที่ลองใหม่บ่อยครั้งและไม่สำเร็จ
สำหรับการแก้ไขข้อบกพร่องในเครื่องของปัญหา WorkManager ให้ใช้เครื่องมือนี้ในโปรแกรมจำลองหรืออุปกรณ์ที่เชื่อมต่อ (ระดับ API 26 ขึ้นไป) โดยจะแสดงรายการ Worker และสถานะ (เสร็จสิ้น กำลังดำเนินการ เข้าคิว) ซึ่งช่วยให้คุณตรวจสอบรายละเอียดและทำความเข้าใจเชน Worker ได้
เช่น สามารถแสดงให้เห็นว่าคนทำงานล้มเหลวหรือลองใหม่บ่อยๆ เนื่องจากระบบมีข้อจำกัดหรือไม่
ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบของเครื่องมือตรวจสอบงานในเบื้องหลัง
WorkManager getStopReason
หากต้องการแก้ไขข้อบกพร่องในฟิลด์ของ Worker ที่มี Wake Lock มากเกินไป ให้ใช้ WorkInfo.getStopReason() ใน WorkManager 2.9.0 ขึ้นไป หรือสำหรับ JobScheduler ให้ใช้ JobParameters.getStopReason() ที่พร้อมใช้งานใน SDK 31 ขึ้นไป
API นี้ช่วยบันทึกเหตุผลที่ Worker หยุดทำงาน (เช่น STOP_REASON_TIMEOUT, STOP_REASON_QUOTA) ซึ่งจะช่วยระบุปัญหาต่างๆ เช่น การหมดเวลาบ่อยครั้งเนื่องจากระยะเวลาการรันไทม์หมด
backgroundScope.launch {
WorkManager.getInstance(context)
.getWorkInfoByIdFlow(workRequest.id)
.collect { workInfo ->
logStopReason(workRequest.id, workInfo?.stopReason)
}
}
ดูรายละเอียดเพิ่มเติมได้ที่เพิ่มประสิทธิภาพการใช้แบตเตอรี่สำหรับ API การตั้งเวลางาน
การแก้ไขข้อบกพร่องของ Wake Lock ประเภทอื่นๆ ที่มากเกินไป
สำหรับสถานการณ์ที่ซับซ้อนมากขึ้นซึ่งเกี่ยวข้องกับการถือ Wake Lock ด้วยตนเองหรือ API ที่ถือ Wake Lock เราขอแนะนำให้คุณใช้การรวบรวม System Tracing เพื่อแก้ไขข้อบกพร่อง
การรวบรวมข้อมูลการติดตามของระบบ
การติดตามระบบ เป็นเครื่องมือแก้ไขข้อบกพร่องที่มีประสิทธิภาพซึ่งบันทึกกิจกรรมของระบบอย่างละเอียดในช่วงระยะเวลาหนึ่ง ทำให้ทราบข้อมูลเชิงลึกเกี่ยวกับสถานะ CPU, กิจกรรมของเธรด, กิจกรรมเครือข่าย และเมตริกที่เกี่ยวข้องกับแบตเตอรี่ เช่น ระยะเวลาของงานและการใช้ Wake Lock
คุณบันทึกการติดตามระบบได้หลายวิธี ดังนี้
- การใช้เครื่องมือบรรทัดคำสั่งการติดตามระบบ
- การใช้ เครื่องมือสร้างโปรไฟล์ CPU ของ Android Studio
- การใช้UI ของ Perfetto
- บันทึกการติดตามด้วยตนเองในอุปกรณ์จากตัวเลือกสำหรับนักพัฒนาแอปโดยตรง
เปิดใช้หมวดหมู่ Atrace "power:PowerManagement" ใน UI ของ Perfetto ในแท็บแอปและบริการของ Android
ไม่ว่าจะเลือกใช้วิธีใด สิ่งสำคัญคือคุณต้องตรวจสอบว่าได้รวบรวมหมวดหมู่ Atrace "power:PowerManagement" เพื่อเปิดใช้การดูแทร็กสถานะอุปกรณ์
การตรวจสอบ UI ของ Perfetto และการวิเคราะห์ SQL
คุณเปิดและตรวจสอบการติดตามระบบได้ใน UI ของ Perfetto เมื่อเปิดการติดตาม คุณจะเห็นภาพกระบวนการต่างๆ ในไทม์ไลน์ แทร็กที่เราจะมุ่งเน้นในคู่มือนี้คือแทร็กที่อยู่ใต้ "สถานะอุปกรณ์"
ปักหมุดแทร็กในส่วน "สถานะอุปกรณ์" เช่น แทร็ก "แอปยอดนิยม" "สถานะหน้าจอ" "Wake Lock ที่ทำงานนาน" และ "งาน" เพื่อระบุภาพรวมของ Wake Lock ที่ทำงานนาน
แต่ละบล็อกจะแสดงชื่อกิจกรรม เวลาที่กิจกรรมเริ่มต้น และเวลาที่กิจกรรมสิ้นสุด ใน Perfetto จะเรียกว่า Slice
หากต้องการวิเคราะห์การติดตามหลายรายการที่ปรับขนาดได้ คุณสามารถใช้การวิเคราะห์ SQL ของ Perfetto คําค้นหา SQL สามารถค้นหา Wake Lock ทั้งหมดที่จัดเรียงตามระยะเวลา ซึ่งจะช่วยระบุผู้ที่ทําให้มีการใช้งานมากเกินไป
ต่อไปนี้คือตัวอย่างการค้นหาที่รวมแท็ก Wake Lock ทั้งหมดที่เกิดขึ้นในการติดตามระบบ โดยเรียงตามระยะเวลารวม
SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms FROM slice JOIN track ON slice.track_id = track.id WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name ORDER BY total_dur_ms DESC
ใช้ ProfilingManager เพื่อรวบรวมการติดตามในฟิลด์
สำหรับปัญหาที่ทำซ้ำได้ยาก ProfilingManager (เพิ่มใน SDK 35) เป็น API แบบเป็นโปรแกรมที่ช่วยให้นักพัฒนาแอปสามารถรวบรวมการติดตามระบบในฟิลด์ด้วยทริกเกอร์เริ่มต้นและสิ้นสุด โดยจะช่วยให้คุณควบคุมจุดทริกเกอร์เริ่มต้นและสิ้นสุดสำหรับการรวบรวมโปรไฟล์ได้มากขึ้น และบังคับใช้การจำกัดอัตราคำขอที่ระดับระบบเพื่อป้องกันไม่ให้อุปกรณ์ได้รับผลกระทบด้านประสิทธิภาพ
ดูขั้นตอนเพิ่มเติมเกี่ยวกับวิธีติดตั้งใช้งานการรวบรวมการติดตามระบบภาคสนาม ซึ่งรวมถึงวิธีบันทึกการติดตาม วิเคราะห์ข้อมูลการทำโปรไฟล์ และใช้คำสั่งแก้ไขข้อบกพร่องในเครื่องได้ที่เอกสารประกอบ ProfilingManager
ร่องรอยของระบบที่รวบรวมโดยใช้ ProfilingManager จะมีลักษณะคล้ายกับร่องรอยที่รวบรวมด้วยตนเอง แต่ระบบจะปกปิดข้อมูลกระบวนการของระบบและกระบวนการของแอปอื่นๆ ในร่องรอย
บทสรุป
เมตริก Wake Lock บางส่วนที่มากเกินไปใน Android Vitals เป็นเพียงส่วนเล็กๆ ของความมุ่งมั่นอย่างต่อเนื่องของเราในการสนับสนุนนักพัฒนาแอปในการลดแบตเตอรี่หมดเร็วและปรับปรุงคุณภาพแอป
การทำความเข้าใจและการใช้ Wake Lock อย่างเหมาะสมจะช่วยเพิ่มประสิทธิภาพแบตเตอรี่ของแอปได้อย่างมาก การใช้ประโยชน์จาก API ทางเลือก การปฏิบัติตามแนวทางปฏิบัติแนะนำสำหรับ Wake Lock และการใช้เครื่องมือแก้ไขข้อบกพร่องที่มีประสิทธิภาพ เช่น เครื่องมือตรวจสอบงานในเบื้องหลัง, System Tracing และ ProfilingManager เป็นกุญแจสำคัญในการรับประกันความสำเร็จของแอปใน Google Play
อ่านต่อ
-
ข่าวสารผลิตภัณฑ์
Android กำลังเปลี่ยนจากระบบปฏิบัติการไปเป็นระบบอัจฉริยะ ซึ่งจะสร้างโอกาสในการมีส่วนร่วมกับแอปของคุณมากขึ้น โดยเราได้ประกาศเรื่องนี้ใน The Android Show วันนี้
Matthew McCullough • ใช้เวลาอ่าน 4 นาที
-
ข่าวสารผลิตภัณฑ์
ระบบนิเวศบนอุปกรณ์เคลื่อนที่พัฒนาอยู่เสมอ ซึ่งนำมาทั้งโอกาสใหม่ๆ และภัยคุกคามใหม่ๆ การเปลี่ยนแปลงเหล่านี้จะช่วยให้ Android และ Google Play ยังคงมุ่งมั่นที่จะดูแลให้ผู้ใช้หลายพันล้านคนสามารถใช้แอปได้อย่างมั่นใจและนักพัฒนาแอปสามารถสร้างสรรค์นวัตกรรมต่อไปได้
Vijaya Kaza • ใช้เวลาอ่าน 3 นาที
-
ข่าวสารผลิตภัณฑ์
Jetpack Compose เวอร์ชันเดือนเมษายน 2026 พร้อมให้ใช้งานอย่างเสถียรแล้ว รุ่นนี้มีโมดูลหลักของ Compose เวอร์ชัน 1.11 (ดูการแมป BOM แบบเต็ม), เครื่องมือแก้ไขข้อบกพร่องขององค์ประกอบที่แชร์, เหตุการณ์แทร็กแพด และอื่นๆ
Meghan Mehta • ใช้เวลาอ่าน 5 นาที
รับข่าวสาร
รับข้อมูลเชิงลึกด้านการพัฒนาแอป Android ล่าสุดส่งตรงถึงกล่องจดหมายของคุณทุกสัปดาห์