เพิ่มประสิทธิภาพแบตเตอรี่ของแอปโดยใช้เมตริก Wake Lock ของ Android Vitals

ระยะเวลาการใช้งานแบตเตอรี่เป็นปัจจัยสำคัญของประสบการณ์ของผู้ใช้ และ Wake Lock ก็มีบทบาทสำคัญในเรื่องนี้ คุณใช้ 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 บางส่วนมากเกินไปในกรณีต่อไปนี้

• มีการเก็บ Wake Lock ไว้เป็นเวลาอย่างน้อย 2 ชั่วโมงภายในระยะเวลา 24 ชั่วโมง
• ส่งผลกระทบต่อเซสชันของแอปมากกว่า 5% โดยเฉลี่ยในช่วง 28 วัน

ระบบจะยกเว้น Wake Lock ที่สร้างโดย API ที่ผู้ใช้เริ่มใช้สำหรับเสียง ตำแหน่ง และJobScheduler จากการคำนวณ Wake Lock

ทำความเข้าใจ Wake Lock

Wake Lock เป็นกลไกที่ช่วยให้แอปสามารถทำให้ CPU ของอุปกรณ์ทำงานต่อไปได้แม้ว่าผู้ใช้จะไม่ได้ใช้งานอุปกรณ์อยู่ก็ตาม

Wake Lock บางส่วนจะทำให้ CPU ทำงานต่อไปแม้ว่าหน้าจอจะปิดอยู่ ซึ่งจะป้องกันไม่ให้ CPU เข้าสู่สถานะ "พัก" ที่ใช้พลังงานต่ำ Wake Lock แบบเต็มจะทำให้ทั้งหน้าจอและ CPU ทำงานต่อไป

Wake Lock บางส่วนได้รับมา 2 วิธี ดังนี้

• แอปจะรับและปล่อย Wake Lock ด้วยตนเองโดยใช้ PowerManager API สำหรับ Use Case ที่เฉพาะเจาะจง ซึ่งมักจะได้รับมาพร้อมกับ บริการที่ทำงานอยู่เบื้องหน้า ซึ่งเป็น API วงจรการทำงานของแพลตฟอร์มที่ออกแบบมาสำหรับการทำงานที่ผู้ใช้รับรู้ได้
• หรือ Wake Lock ได้รับมาโดย API อื่นและระบุแหล่งที่มาเป็นแอปเนื่องจากการใช้งาน API ดูข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในส่วนแนวทางปฏิบัติแนะนำ

แม้ว่า Wake Lock จะจำเป็นสำหรับงานต่างๆ เช่น การดาวน์โหลดไฟล์ขนาดใหญ่ที่ผู้ใช้เริ่มดาวน์โหลด แต่การใช้ Wake Lock มากเกินไปหรือใช้ไม่ถูกต้องอาจทำให้แบตเตอรี่หมดเร็วขึ้นอย่างมาก เราพบกรณีที่แอปเก็บ Wake Lock ไว้เป็นชั่วโมงๆ หรือปล่อย Wake Lock ไม่ถูกต้อง ซึ่งทำให้ผู้ใช้ร้องเรียนว่าแบตเตอรี่หมดเร็วขึ้นอย่างมากแม้ว่าผู้ใช้จะไม่ได้ใช้งานแอปอยู่ก็ตาม

แนวทางปฏิบัติแนะนำสำหรับการใช้ Wake Lock

ก่อนที่จะไปดูวิธีแก้ไขข้อบกพร่องของการใช้ Wake Lock มากเกินไป โปรดตรวจสอบว่าคุณทำตามแนวทางปฏิบัติแนะนำสำหรับ Wake Lock แล้ว

พิจารณาคำถามสำคัญ 4 ข้อต่อไปนี้

1. คุณได้พิจารณาตัวเลือก Wake Lock อื่นๆ แล้วหรือยัง

ก่อนที่จะพิจารณาการรับ Wake Lock บางส่วนด้วยตนเอง ให้ทำตามแผนผังลำดับงานการตัดสินใจต่อไปนี้

แผนผังลำดับงานเพื่อตัดสินใจว่าจะรับ Wake Lock ด้วยตนเองเมื่อใด

1. หน้าจอต้องเปิดอยู่ไหม
   • ใช่: โปรดดูเอกสารประกอบเรื่องการเปิดหน้าจอไว้แทน
2. แอปพลิเคชันกำลังเรียกใช้บริการที่ทำงานอยู่เบื้องหน้าไหม
   • ไม่: คุณไม่จำเป็นต้องรับ Wake Lock ด้วยตนเอง
3. การที่อุปกรณ์พักการทำงานจะส่งผลเสียต่อประสบการณ์ของผู้ใช้ไหม
   • ไม่: เช่น การอัปเดตการแจ้งเตือนหลังจากที่อุปกรณ์ตื่นขึ้นมาไม่จำเป็นต้องใช้ Wake Lock
   • ใช่: หากการป้องกันไม่ให้อุปกรณ์พักการทำงานเป็นสิ่งสำคัญ เช่น การสื่อสารกับอุปกรณ์ภายนอกอย่างต่อเนื่อง ให้ดำเนินการต่อ
4. มี API ที่ทำให้เครื่องตื่นอยู่เสมอในนามของคุณอยู่แล้วไหม
   • คุณสามารถใช้ประโยชน์จากเอกสารประกอบเรื่องการระบุ Wake Lock ที่สร้างโดย API อื่นเพื่อระบุสถานการณ์ที่ Wake Lock สร้างโดย API อื่นเพื่อระบุสถานการณ์ที่ Wake Lock สร้างโดย API อื่น เช่น LocationManager
   • หากไม่มี API ให้ดำเนินการต่อที่คำถามสุดท้าย
5. หากคุณตอบคำถามทั้งหมดเหล่านี้แล้วและพบว่าไม่มีตัวเลือกอื่น คุณควรดำเนินการรับ Wake Lock ด้วยตนเอง

2. คุณตั้งชื่อ Wake Lock อย่างถูกต้องไหม

เมื่อรับ Wake Lock ด้วยตนเอง การตั้งชื่อที่เหมาะสมมีความสำคัญต่อการแก้ไขข้อบกพร่อง โดยมีแนวทางดังนี้

• อย่าใส่ข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (PII) เช่น อีเมลในชื่อ หากระบบตรวจพบ PII ระบบจะบันทึก Wake Lock เป็น _UNKNOWN ซึ่งจะขัดขวางการแก้ไขข้อบกพร่อง
• อย่าตั้งชื่อ Wake Lock โดยใช้ชื่อคลาสหรือชื่อเมธอดแบบเป็นโปรแกรม เนื่องจากเครื่องมือต่างๆ เช่น Proguard อาจทำให้ชื่อเหล่านี้อ่านไม่ออก แต่ให้ใช้สตริงที่ฮาร์ดโค้ดไว้แทน
• อย่าเพิ่มตัวนับหรือตัวระบุที่ไม่ซ้ำกันลงในแท็ก Wake Lock คุณควรใช้แท็กเดียวกันทุกครั้งที่ Wake Lock ทำงานเพื่อให้ระบบรวบรวมการใช้งานตามชื่อได้ ซึ่งจะช่วยให้ตรวจพบลักษณะการทำงานที่ผิดปกติได้ง่ายขึ้น

3. มีการปล่อย Wake Lock ที่ได้รับมาเสมอไหม

หากคุณรับ Wake Lock ด้วยตนเอง โปรดตรวจสอบว่ามีการเรียกใช้การปล่อย Wake Lock เสมอ การไม่ปล่อย Wake Lock อาจทำให้แบตเตอรี่หมดเร็วขึ้นอย่างมาก

ตัวอย่างเช่น หากมีการขว้างข้อยกเว้นที่ไม่ได้จัดการระหว่างการประมวลผล Work() การเรียกใช้ 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 อย่างเหมาะสม แต่ก็อาจมีการใช้ 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/Job

คุณสามารถระบุ Wake Lock ที่ Worker เก็บไว้ได้ด้วยชื่อ Wake Lock นี้

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

รายการรูปแบบชื่อ Wake Lock ที่ Worker เก็บไว้ทั้งหมดมีอยู่ใน เอกสารประกอบ หากต้องการแก้ไขข้อบกพร่องของ Wake Lock เหล่านี้ คุณสามารถใช้เครื่องมือตรวจสอบงานในเบื้องหลังเพื่อแก้ไขข้อบกพร่องในเครื่อง หรือใช้ประโยชน์จาก getStopReason เพื่อแก้ไขข้อบกพร่องในภาคสนาม

เครื่องมือตรวจสอบงานในเบื้องหลังของ Android Studio

การจับภาพหน้าจอของเครื่องมือตรวจสอบงานในเบื้องหลัง ซึ่งระบุ Worker "WeatherSyncWorker" ที่ลองใหม่และล้มเหลวบ่อยครั้งได้

หากต้องการแก้ไขข้อบกพร่องของ WorkManager ในเครื่อง ให้ใช้เครื่องมือนี้ในโปรแกรมจำลองหรืออุปกรณ์ที่เชื่อมต่อ (ระดับ API 26 ขึ้นไป) เครื่องมือนี้จะแสดงรายการ Worker และสถานะของ Worker (เสร็จสิ้น กำลังดำเนินการ เข้าคิว) ซึ่งช่วยให้คุณตรวจสอบรายละเอียดและทำความเข้าใจเชนของ 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 ไว้ เราขอแนะนำให้คุณใช้การรวบรวมข้อมูลการติดตามระบบเพื่อแก้ไขข้อบกพร่อง

การรวบรวมข้อมูลการติดตามระบบ

การติดตามระบบ  เป็นเครื่องมือแก้ไขข้อบกพร่องที่มีประสิทธิภาพซึ่งบันทึกกิจกรรมของระบบอย่างละเอียดในช่วงเวลาหนึ่ง โดยให้ข้อมูลเชิงลึกเกี่ยวกับสถานะ CPU, กิจกรรมของเธรด, กิจกรรมเครือข่าย และเมตริกที่เกี่ยวข้องกับแบตเตอรี่ เช่น ระยะเวลาของงานและการใช้ Wake Lock

คุณสามารถบันทึกการติดตามระบบได้หลายวิธี ดังนี้

• ใช้เครื่องมือบรรทัดคำสั่งการติดตามระบบ
• ใช้ เครื่องมือสร้างโปรไฟล์ CPU ของ Android Studio
• ใช้ UI ของ Perfetto
• บันทึกการติดตามด้วยตนเองในอุปกรณ์ โดยตรงจากตัวเลือกสำหรับนักพัฒนาแอป

เปิดใช้หมวดหมู่ "power:PowerManagement" Atrace ใน UI ของ Perfetto ในแท็บ Android apps & svcs 

ไม่ว่าคุณจะเลือกใช้วิธีใด สิ่งสำคัญคือต้องตรวจสอบว่าคุณได้รวบรวม"power:PowerManagement" หมวดหมู่ Atrace เพื่อให้ดูแทร็กสถานะอุปกรณ์ได้

การตรวจสอบ UI ของ Perfetto และการวิเคราะห์ SQL

คุณสามารถเปิดและตรวจสอบการติดตามระบบได้ในUI ของ Perfetto เมื่อเปิดการติดตาม คุณจะเห็นภาพการแสดงข้อมูลของกระบวนการต่างๆ ในไทม์ไลน์ แทร็กที่เราจะเน้นในคู่มือนี้คือแทร็กในส่วน "สถานะอุปกรณ์"

ปักหมุดแทร็กในส่วน "สถานะอุปกรณ์" เช่น "แอปยอดนิยม" "สถานะหน้าจอ" "Wake Lock แบบยาว" และแทร็ก "งาน" เพื่อระบุส่วน Wake Lock ที่ทำงานเป็นเวลานานด้วยภาพ

แต่ละบล็อกจะแสดงชื่อเหตุการณ์ เวลาที่เหตุการณ์เริ่มต้น และเวลาที่เหตุการณ์สิ้นสุด ใน Perfetto เราเรียกบล็อกนี้ว่าส่วน

หากต้องการวิเคราะห์การติดตามหลายรายการในแบบที่ปรับขนาดได้ คุณสามารถใช้การวิเคราะห์ 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 แบบเป็นโปรแกรมที่ช่วยให้นักพัฒนาแอปสามารถรวบรวมข้อมูลการติดตามระบบในภาคสนามด้วยทริกเกอร์เริ่มต้นและสิ้นสุด API นี้ช่วยให้ควบคุมจุดทริกเกอร์เริ่มต้นและสิ้นสุดสำหรับการรวบรวมโปรไฟล์ได้มากขึ้น และบังคับใช้การจำกัดอัตราคำขอที่ระดับระบบเพื่อป้องกันไม่ให้ประสิทธิภาพของอุปกรณ์ได้รับผลกระทบ

ดูขั้นตอนเพิ่มเติมเกี่ยวกับวิธีใช้การรวบรวมข้อมูลการติดตามระบบในภาคสนามได้ในเอกสารประกอบ ProfilingManager ซึ่งรวมถึงวิธี บันทึกการติดตามแบบเป็นโปรแกรม วิเคราะห์ข้อมูลการสร้างโปรไฟล์ และใช้ คำสั่งแก้ไขข้อบกพร่องในเครื่อง

ข้อมูลการติดตามระบบที่รวบรวมโดยใช้ ProfilingManager จะมีลักษณะคล้ายกับข้อมูลที่รวบรวมด้วยตนเอง แต่ระบบจะแก้ไขข้อมูลกระบวนการของระบบและกระบวนการของแอปอื่นๆ จากการติดตาม

บทสรุป

เมตริก Wake Lock บางส่วนที่มากเกินไปใน Android Vitals เป็นเพียงส่วนเล็กๆ ของความมุ่งมั่นอย่างต่อเนื่องของเราในการสนับสนุนนักพัฒนาแอปให้ลดแบตเตอรี่หมดเร็วและปรับปรุงคุณภาพของแอป

การทำความเข้าใจและใช้ Wake Lock อย่างเหมาะสมจะช่วยเพิ่มประสิทธิภาพแบตเตอรี่ของแอปได้อย่างมาก การใช้ประโยชน์จาก API อื่นๆ การปฏิบัติตามแนวทางปฏิบัติแนะนำสำหรับ Wake Lock และการใช้เครื่องมือแก้ไขข้อบกพร่องที่มีประสิทธิภาพ เช่น เครื่องมือตรวจสอบงานในเบื้องหลัง, System Tracing และ ProfilingManager เป็นสิ่งสำคัญที่จะช่วยให้แอปของคุณประสบความสำเร็จใน Google Play