ข่าวสารเกี่ยวกับผลิตภัณฑ์

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

ใช้เวลาอ่าน 7 นาที
Alice Yuan
วิศวกรนักพัฒนาซอฟต์แวร์สัมพันธ์

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

การใช้ Wake Lock บางส่วนมากเกินไปใน Android Vitals

ตอนนี้ Play Console จะตรวจสอบแบตเตอรี่หมดเร็ว โดยเน้นที่การใช้ Wake Lock บางส่วนมากเกินไป เป็นตัวบ่งชี้ประสิทธิภาพหลัก

ฟีเจอร์นี้จะเพิ่มความสำคัญของประสิทธิภาพแบตเตอรี่ควบคู่ไปกับตัวบ่งชี้ความเสถียรของเมตริกหลักที่มีอยู่ ได้แก่ การขัดข้องที่ผู้ใช้รับรู้ได้และ ANR มากเกินไปเราได้กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องสำหรับ Wake Lock ที่มากเกินไป. ตั้งแต่วันที่ 1 มีนาคม 2026 เป็นต้นไป หากชื่อแอปไม่เป็นไปตามเกณฑ์คุณภาพนี้ เราอาจยกเว้นชื่อแอปจากพื้นที่การค้นพบที่โดดเด่น เช่น คำแนะนำ ในบางกรณี เราอาจแสดงคำเตือนในข้อมูลสินค้าใน Store เพื่อแจ้งให้ผู้ใช้ทราบว่าแอปของคุณอาจทำให้แบตเตอรี่หมดเร็วเกินไป

warning.png

ประกาศเตือน 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 และระบบจะระบุแหล่งที่มาของ Wake Lock เป็นแอปเนื่องจากการใช้งาน API ดูข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในส่วนแนวทางปฏิบัติแนะนำ

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

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

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

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


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

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

wakelock.png

โฟลว์ชาร์ตเพื่อตัดสินใจว่าจะรับ Wake Lock ด้วยตนเองเมื่อใด

  1. หน้าจอต้องเปิดอยู่ไหม
    • ใช่: โปรดดูเอกสารประกอบ Keep Screen On แทน
  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 มากเกินไปได้ หากระบบแจ้งว่าแอปของคุณมีการใช้ Wake Lock มากเกินไปใน Play Console ให้แก้ไขข้อบกพร่องดังนี้

การระบุเบื้องต้นด้วย Play Console

แดชบอร์ด Wake Lock บางส่วนที่มากเกินไปของ Android Vitals จะแสดงรายละเอียดของชื่อ Wake Lock ที่ไม่ได้รับการยกเว้นซึ่งเชื่อมโยงกับแอปของคุณ โดยจะแสดงเซสชันและระยะเวลาที่ได้รับผลกระทบ โปรดใช้เอกสารประกอบเพื่อช่วยระบุว่าชื่อ Wake Lock เป็นชื่อที่แอปเก็บไว้หรือ API อื่นเก็บไว้

breakdowns2.png

แดชบอร์ด 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

taskinspector.png


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

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

เช่น เครื่องมือนี้สามารถแสดงให้เห็นว่า Worker ล้มเหลวหรือลองใหม่บ่อยครั้งเนื่องจากข้อจำกัดของระบบหรือไม่

ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบเครื่องมือตรวจสอบงานในเบื้องหลัง

getStopReason ของ WorkManager

หากต้องการแก้ไขข้อบกพร่องในภาคสนามของ 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

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

powermgmt.png

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

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

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

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

perfetto.png


ปักหมุดแทร็กในส่วน "สถานะอุปกรณ์" เช่น "แอปที่ทำงานอยู่เบื้องหน้า" "สถานะหน้าจอ" "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 ซึ่งรวมถึงวิธีบันทึกการติดตามด้วยโปรแกรม capture a trace analyze profiling data และใช้ local debug commands

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

บทสรุป

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

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

เขียนโดย

อ่านต่อ