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