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

ระบุปัญหา

ทีมได้ดูข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับ Wake Lock ที่ส่งผลต่อเมตริกจาก Android Vitals เพื่อดูว่าจะเริ่มต้นจากตรงไหน โดยการดูแดชบอร์ด 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 บางตัวมีเวลาทำงานเฉลี่ยสูง ซึ่งช่วยให้ทีมจำกัดการตรวจสอบให้แคบลงได้มากยิ่งขึ้น

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

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

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

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

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

Manmeet Tuteja วิศวกร Android ระดับ II ของ WHOOP กล่าวว่า "การแยกรูปแบบยังช่วยให้เรายืนยันได้ว่าปัญหาเกิดขึ้นใน Worker ทั้ง 2 รูปแบบ ซึ่งชี้ให้เห็นว่าปัญหาไม่ได้เกิดจากการกำหนดค่าการกำหนดเวลา แต่เกิดจากปัญหาตรรกะทางธุรกิจที่ใช้ร่วมกันภายในโค้ดของ 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 เพื่อดูแนวทางปฏิบัติแนะนำและกลยุทธ์การแก้ไขข้อบกพร่องเพิ่มเติม