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

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

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

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

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

ระบุปัญหา

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

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

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

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

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

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

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

เมตริกภายในที่แจ้งว่ารันไทม์เฉลี่ยสูงสำหรับผู้ปฏิบัติงานบางราย ทำให้ผู้ปฏิบัติงานจำกัดการตรวจสอบให้แคบลงได้อีก 

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

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

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

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

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

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

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

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

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

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