วิธีที่ WHOOP ลดเซสชัน Wake Lock บางส่วนที่มากเกินไปได้กว่า 90%

การสร้างแอป Android สำหรับอุปกรณ์สวมใส่หมายความว่างานที่แท้จริงจะเริ่มต้นเมื่อหน้าจอปิด WHOOP ช่วยให้สมาชิกเข้าใจว่าร่างกายตอบสนองต่อการฝึก การฟื้นฟู การนอนหลับ และความเครียดอย่างไร และสำหรับสมาชิก WHOOP จำนวนมากที่ใช้ Android การซิงค์และการเชื่อมต่อที่เชื่อถือได้ในเบื้องหลังคือสิ่งที่ทำให้เกิดข้อมูลเชิงลึกเหล่านั้น

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

ตั้งแต่วันที่ 1 มีนาคม 2026 เป็นต้นไป เราอาจยกเว้นแอปที่ยังคงไม่เป็นไปตามเกณฑ์คุณภาพออกจากพื้นที่การค้นพบใน Google Play นอกจากนี้ เรายังอาจแสดงคำเตือนในข้อมูลสินค้าใน Google Play Store เพื่อระบุว่าแอปอาจใช้แบตเตอรี่มากกว่าที่คาดไว้

Mayank Saini วิศวกร Android อาวุโสของ WHOOP กล่าวว่า "เมตริกนี้เป็นโอกาสให้ทีมได้ยกระดับประสิทธิภาพของ Android" หลังจากที่ Android Vitals แจ้งว่าเปอร์เซ็นต์ Wake Lock บางส่วนที่มากเกินไปของแอปอยู่ที่ 15% ซึ่งเกินเกณฑ์ที่แนะนำที่ 5%

ทีมมองว่าเมตริก Android Vitals เป็นสัญญาณที่ชัดเจนว่างานเบื้องหลังของแอปทำให้ CPU ทำงานนานกว่าที่จำเป็น การแก้ไขปัญหานี้จะช่วยให้ทีมมอบประสบการณ์การใช้งานที่ยอดเยี่ยมให้แก่ผู้ใช้ต่อไปได้ พร้อมทั้งลดเวลาเบื้องหลังที่สูญเปล่า และรักษาการเชื่อมต่อและการซิงค์บลูทูธที่เชื่อถือได้และทันเวลา

การระบุปัญหา

ทีมได้ใช้ Android Vitals เป็นแหล่งข้อมูลแรกเพื่อดูข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับ Wake Lock ที่ส่งผลต่อเมตริก เพื่อหาจุดเริ่มต้นในการแก้ไขปัญหา การปรึกษาแดชบอร์ด Wake Lock บางส่วนที่มากเกินไปของ Android Vitals ช่วยให้ทีมระบุได้ว่าตัวการสำคัญที่ทำให้เกิด Wake Lock บางส่วนที่มากเกินไปคือ Worker ของ WorkManager รายหนึ่ง (ระบุในแดชบอร์ดเป็นandroidx.work.impl.background.systemjob.SystemJobService) แอปใช้ WorkManager สำหรับงานเบื้องหลัง เช่น การซิงค์เป็นระยะและการส่งการอัปเดตที่เกิดขึ้นซ้ำๆ ไปยังอุปกรณ์สวมใส่ เพื่อรองรับ "ประสบการณ์การใช้งานแบบเปิดตลอดเวลา" ของ WHOOP

แม้ว่าทีมจะ ทราบ ว่า WorkManager จะขอ Wake Lock ขณะทำงานเบื้องหลัง แต่ก่อนหน้านี้ทีมไม่สามารถมองเห็นภาพรวมของงานเบื้องหลังทั้งหมด (นอกเหนือจาก WorkManager) จนกว่าจะมีการเปิดตัวเมตริก Wake Lock บางส่วนที่มากเกินไปใน Android Vitals

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

การใช้ประโยชน์จากเมตริกและข้อมูลภายในเพื่อจำกัดสาเหตุให้แคบลง

WHOOP ได้ตั้งค่าโครงสร้างพื้นฐานภายในเพื่อตรวจสอบเมตริก WorkManager อยู่แล้ว โดยจะตรวจสอบสิ่งต่อไปนี้เป็นระยะ

1. เวลาทำงานเฉลี่ย: Worker ทำงานนานเท่าใด
2. การหมดเวลา: Worker หมดเวลาแทนที่จะทำงานเสร็จบ่อยเพียงใด
3. การลองใหม่: Worker ลองใหม่บ่อยเพียงใดหากงานหมดเวลาหรือล้มเหลว
4. การยกเลิก: งานถูกยกเลิกบ่อยเพียงใด

การติดตามมากกว่าแค่ความสำเร็จและความล้มเหลวของ Worker ช่วยให้ทีมมองเห็นประสิทธิภาพของงาน

เมตริกภายในแจ้งว่า Worker บางรายมีเวลาทำงานเฉลี่ยสูง ซึ่งช่วยให้ทีมจำกัดการตรวจสอบให้แคบลงได้มากยิ่งขึ้น

นอกเหนือจากเมตริกภายในแล้ว ทีมยังใช้ Android Studio’s เครื่องมือตรวจสอบงานในเบื้องหลัง เพื่อตรวจสอบและแก้ไขข้อบกพร่องของ Worker ที่สนใจ โดยมุ่งเน้นไปที่ Wake Lock ที่เชื่อมโยง เพื่อให้สอดคล้องกับเมตริกที่แจ้งใน Android Vitals

การตรวจสอบ: การแยกความแตกต่างระหว่าง Worker แต่ละรูปแบบ

WHOOP ใช้การกำหนดเวลาแบบ ครั้งเดียว และแบบ เป็นระยะ สำหรับ Worker บางราย ซึ่งช่วยให้แอปใช้ตรรกะ Worker เดียวกันซ้ำสำหรับงานที่เหมือนกันซึ่งมีเกณฑ์ความสำเร็จเดียวกัน โดยแตกต่างกันเพียงเวลาเท่านั้น

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

รายละเอียดเพิ่มเติมนี้จะช่วยให้ทีมระบุได้อย่างชัดเจนว่า Worker รูปแบบใด (แบบเป็นระยะหรือแบบครั้งเดียว) มีส่วนทำให้เกิดเซสชันที่มี Wake Lock บางส่วนที่มากเกินไปมากที่สุด อย่างไรก็ตาม ทีมรู้สึกประหลาดใจเมื่อข้อมูลเผยให้เห็นว่าไม่มีรูปแบบใดที่มีส่วนทำให้เกิดปัญหามากกว่าอีกรูปแบบหนึ่ง

Manmeet Tuteja วิศวกร Android ระดับ II ของ WHOOP กล่าวว่า "การแยกรูปแบบยังช่วยให้เรายืนยันได้ว่าปัญหาเกิดขึ้นใน Worker ทั้งสอง รูปแบบ ซึ่งชี้ให้เห็นว่าปัญหาไม่ได้เกิดจากการกำหนดค่าการกำหนดเวลา แต่เกิดจากปัญหาตรรกะทางธุรกิจที่ใช้ร่วมกันภายในโค้ดของ Worker"

การเจาะลึกพฤติกรรมของ Worker และการแก้ไขสาเหตุที่แท้จริง

เมื่อทราบว่าต้องดูตรรกะ ภายใน Worker ทีมจึงตรวจสอบพฤติกรรมของ Worker อีกครั้งสำหรับ Worker ที่ถูกแจ้งระหว่างการตรวจสอบ โดยเฉพาะอย่างยิ่ง ทีมกำลังมองหาอินสแตนซ์ที่งานอาจติดขัดและไม่เสร็จสมบูรณ์

การตรวจสอบทั้งหมดนี้สรุปได้ว่าสาเหตุที่แท้จริงของ Wake Lock ที่มากเกินไปคือ

CoroutineWorker ที่ออกแบบมาให้รอการเชื่อมต่อกับเซ็นเซอร์ WHOOP ก่อนดำเนินการต่อ 

หากงานเริ่มต้นโดยไม่มีเซ็นเซอร์เชื่อมต่อ whoopSensorFlow ซึ่งบ่งบอกว่าเซ็นเซอร์เชื่อมต่ออยู่หรือไม่ จะเป็น null SensorWorker ไม่ถือว่านี่เป็นเงื่อนไขการออกก่อนกำหนดและยังคงทำงานต่อไป ซึ่งเป็นการรอการเชื่อมต่ออย่างไม่มีกำหนด ด้วยเหตุนี้ WorkManager จึงเก็บ Wake Lock บางส่วนไว้จนกว่างานจะหมดเวลา ซึ่งนำไปสู่การใช้ Wake Lock เบื้องหลังสูงและการกำหนดเวลา SensorWorker ใหม่ที่ไม่ต้องการบ่อยครั้ง

ทีม WHOOP ได้อัปเดตตรรกะของ Worker เพื่อตรวจสอบสถานะการเชื่อมต่อก่อนที่จะพยายามดำเนินการตรรกะทางธุรกิจหลัก เพื่อแก้ไขปัญหานี้

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

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

การลดเซสชันที่มี Wake Lock บางส่วนที่มากเกินไปได้ 90%

หลังจากเปิดตัวการแก้ไขแล้ว ทีมยังคงตรวจสอบแดชบอร์ด Android Vitals เพื่อยืนยันผลกระทบของการเปลี่ยนแปลง

ท้ายที่สุด WHOOP พบว่าเปอร์เซ็นต์ Wake Lock บางส่วนที่มากเกินไปลดลงจาก 15% เหลือไม่ถึง 1% เพียง 30 วัน หลังจากใช้การเปลี่ยนแปลงกับ Worker

การเปลี่ยนแปลงนี้ส่งผลให้ทีมเห็นอินสแตนซ์ที่งานหมดเวลาโดยไม่เสร็จสมบูรณ์น้อยลง ซึ่งส่งผลให้เวลาทำงานเฉลี่ยลดลง

คำแนะนำจากทีม WHOOP สำหรับนักพัฒนาแอปรายอื่นๆ ที่ต้องการปรับปรุงประสิทธิภาพของงานเบื้องหลัง

เริ่มต้นใช้งาน

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