WHOOP ने पार्शियल वेक लॉक के ज़्यादा इस्तेमाल वाले सेशन को 90% से ज़्यादा कैसे कम किया

वियरेबल डिवाइस के लिए Android ऐप्लिकेशन बनाने का मतलब है कि स्क्रीन बंद होने पर असली काम शुरू होता है. WHOOP के सदस्यों को यह समझने में मदद मिलती है कि ट्रेनिंग, रिकवरी, नींद, और तनाव के दौरान उनके शरीर पर क्या असर पड़ता है. Android का इस्तेमाल करने वाले WHOOP के कई सदस्यों के लिए, बैकग्राउंड में डेटा सिंक करने और कनेक्टिविटी की भरोसेमंद सुविधा से ही ये अहम जानकारी मिल पाती है.

इस साल की शुरुआत में, Google Play ने Android की ज़रूरी जानकारी में एक नई मेट्रिक रिलीज़ की थी: पार्शियल वेक लॉक का ज़्यादा इस्तेमाल. यह मेट्रिक, उपयोगकर्ता के उन सेशन का प्रतिशत मेज़र करती है जिनमें 24 घंटे की अवधि में, कुल मिलाकर दो घंटे से ज़्यादा समय तक वेक लॉक का इस्तेमाल किया गया हो. हालांकि, इसमें वेक लॉक के इस्तेमाल से जुड़ी कुछ शर्तों को पूरा करने वाले सेशन शामिल नहीं होते. इस मेट्रिक का मकसद, तेज़ी से बैटरी खर्च होने की वजहों का पता लगाने और उन्हें ठीक करने में आपकी मदद करना है. इससे लोगों को बेहतर उपयोगकर्ता अनुभव देने में मदद मिलती है.

1 मार्च, 2026 से, क्वालिटी थ्रेशोल्ड को पूरा न करने वाले ऐप्लिकेशन को Google Play के डिस्कवरी प्लैटफ़ॉर्म से हटाया जा सकता है. Google Play Store पर मौजूद ऐप्लिकेशन की जानकारी वाले पेज पर, एक चेतावनी भी दिख सकती है. इसमें बताया जाएगा कि ऐप्लिकेशन, अनुमान से ज़्यादा बैटरी इस्तेमाल कर सकता है.

WHOOP के सीनियर Android इंजीनियर, मयंक सैनी के मुताबिक,  Android की ज़रूरी जानकारी देने वाली सुविधा ने ऐप्लिकेशन के पार्शियल वेक लॉक के ज़्यादा प्रतिशत को 15% के तौर पर फ़्लैग किया था. यह 5% के सुझाए गए थ्रेशोल्ड से ज़्यादा था. इसलिए, “इससे टीम को Android की परफ़ॉर्मेंस को बेहतर बनाने का मौका मिला.”

टीम ने Android की ज़रूरी जानकारी की मेट्रिक को एक साफ़ सिग्नल के तौर पर देखा. इससे पता चला कि बैकग्राउंड में चल रहे काम की वजह से, सीपीयू ज़रूरत से ज़्यादा समय तक चालू रहता है. इस समस्या को हल करने से, उन्हें उपयोगकर्ताओं को बेहतर अनुभव देने में मदद मिलेगी. साथ ही, बैकग्राउंड में होने वाले काम में लगने वाला समय कम होगा. इसके अलावा, ब्लूटूथ कनेक्टिविटी और सिंक करने की सुविधा भरोसेमंद तरीके से और समय पर काम करेगी.

समस्या का पता लगाना

यह पता लगाने के लिए कि कहां से शुरुआत करनी है, टीम ने सबसे पहले Android की ज़रूरी जानकारी का इस्तेमाल किया. इससे उन्हें इस बारे में ज़्यादा जानकारी मिली कि कौनसे वेक लॉक, मेट्रिक पर असर डाल रहे हैं. Android की ज़रूरी जानकारी में, बहुत ज़्यादा पार्शियल वेक लॉक वाले ऐप्लिकेशन के डैशबोर्ड को देखकर, उन्हें पता चला कि WorkManager के किसी वर्कर (डैशबोर्ड में androidx.work.impl.background.systemjob.SystemJobService के तौर पर दिखाया गया) की वजह से, बहुत ज़्यादा पार्शियल वेक लॉक हो रहे हैं. WHOOP के “हमेशा चालू रहने वाले अनुभव” को बेहतर बनाने के लिए, ऐप्लिकेशन WorkManager का इस्तेमाल करता है. इससे बैकग्राउंड में टास्क किए जाते हैं. जैसे, समय-समय पर सिंक करना और पहनने लायक डिवाइस को बार-बार अपडेट भेजना. 

टीम को पता था कि बैकग्राउंड में टास्क एक्ज़ीक्यूट करते समय, WorkManager वेक लॉक हासिल करता है. हालांकि, Android की ज़रूरी जानकारी में आंशिक वेक लॉक की मेट्रिक के ज़्यादा इस्तेमाल की जानकारी मिलने से पहले, टीम को यह नहीं पता था कि WorkManager के अलावा, बैकग्राउंड में किए जाने वाले सभी काम कैसे डिस्ट्रिब्यूट किए जाते हैं.

डैशबोर्ड से यह पता चला कि WorkManager की वजह से सबसे ज़्यादा बैटरी खर्च हो रही है. इसके बाद, टीम ने इस बात पर फ़ोकस किया कि उनके कौनसे वर्कर की वजह से सबसे ज़्यादा बैटरी खर्च हो रही है. साथ ही, उन्होंने इस समस्या को हल करने के लिए काम किया.

समस्या की वजह का पता लगाने के लिए, इंटरनल मेट्रिक और डेटा का इस्तेमाल करना

WHOOP ने WorkManager की मेट्रिक को मॉनिटर करने के लिए, पहले से ही इंटरनल इन्फ़्रास्ट्रक्चर सेट अप किया हुआ था. ये कुकी समय-समय पर इन चीज़ों की निगरानी करती हैं:

1. औसत रनटाइम: वर्कर कितने समय तक चलता है?
2. टाइम आउट: वर्कर कितनी बार टास्क पूरा करने के बजाय टाइम आउट हो रहा है?
3. फिर से कोशिश करना: अगर काम पूरा होने में ज़्यादा समय लगता है या काम पूरा नहीं होता है, तो वर्कर कितनी बार फिर से कोशिश करता है?
4. रद्द किए गए काम: काम कितनी बार रद्द किया गया?

सिर्फ़ वर्कर की कामयाबियों और कमज़ोरियों को ट्रैक करने के बजाय, टीम को यह भी देखना चाहिए कि वर्कर कितने असरदार तरीके से काम कर रहा है.

आंतरिक मेट्रिक ने कुछ वर्कर के लिए, औसत रनटाइम ज़्यादा होने का फ़्लैग किया. इससे उन्हें जांच को और भी ज़्यादा सटीक बनाने में मदद मिली. 

टीम ने अपनी इंटरनल मेट्रिक के अलावा, Android Studio के बैकग्राउंड टास्क इंस्पेक्टर का इस्तेमाल किया. इससे, टीम को काम के वर्कर की जांच करने और उन्हें डीबग करने में मदद मिली. साथ ही, Android की ज़रूरी जानकारी में फ़्लैग की गई मेट्रिक के साथ अलाइन करने के लिए, टीम ने वेक लॉक पर खास तौर पर ध्यान दिया.

जांच: वर्कर के अलग-अलग वैरिएंट के बीच अंतर करना

WHOOP, कुछ कर्मचारियों के लिए एक बार और समय-समय पर शेड्यूल करने की सुविधा का इस्तेमाल करता है. इससे ऐप्लिकेशन को एक जैसे टास्क के लिए, एक ही वर्कर लॉजिक का फिर से इस्तेमाल करने की अनुमति मिलती है. इन टास्क के पूरा होने की शर्तें भी एक जैसी होती हैं. हालांकि, इनके समय में अंतर होता है.

अपनी इंटरनल मेट्रिक का इस्तेमाल करके, वे किसी खास वर्कर के लिए खोज को सीमित कर सके. हालांकि, वे यह नहीं बता सके कि गड़बड़ी तब हुई, जब वर्कर ने एक बार काम किया था, समय-समय पर काम किया था या दोनों बार काम किया था. इसलिए, उन्होंने WorkManager के setTraceTag method का इस्तेमाल करने के लिए एक अपडेट रोल आउट किया. इससे एक ही वर्कर के एक बार और समय-समय पर होने वाले वैरिएंट के बीच अंतर किया जा सकता है.

इस अतिरिक्त जानकारी से, उन्हें यह पता लगाने में मदद मिलेगी कि वर्कर के किस वैरिएंट (समय-समय पर या एक बार) की वजह से, सेशन में पार्शियल वेक लॉक की संख्या सबसे ज़्यादा थी. हालांकि, टीम को यह देखकर हैरानी हुई कि डेटा से पता चला कि दोनों वैरिएंट में से कोई भी, दूसरे वैरिएंट से ज़्यादा योगदान नहीं दे रहा है.

WHOOP में Android Engineer II के तौर पर काम करने वाले मनमीत तुतेजा ने कहा, “इस स्प्लिट से हमें यह पुष्टि करने में भी मदद मिली कि समस्या दोनों वैरिएंट में हो रही है. इससे हमें यह पता चला कि समस्या, शेड्यूल करने के कॉन्फ़िगरेशन से जुड़ी नहीं है. इसके बजाय, यह वर्कर के लागू करने से जुड़ी एक सामान्य कारोबारी नियम समस्या है.”

वर्कर के व्यवहार के बारे में ज़्यादा जानकारी और समस्या की जड़ को ठीक करना

टीम को यह जानकारी थी कि उसे वर्कर के अंदर मौजूद लॉजिक को देखना है. इसलिए,  टीम ने उन वर्कर के व्यवहार की फिर से जांच की जिन्हें जांच के दौरान फ़्लैग किया गया था. खास तौर पर, वे ऐसे उदाहरणों की तलाश कर रहे थे जिनमें काम पूरा नहीं हो रहा था.

इन सभी वजहों से, वेक लॉक के बहुत ज़्यादा इस्तेमाल की असल वजह का पता चला:

यह एक CoroutineWorker है, जिसे WHOOP सेंसर से कनेक्ट होने के लिए इंतज़ार करने के लिए डिज़ाइन किया गया है. 

अगर काम शुरू करते समय कोई सेंसर कनेक्ट नहीं किया गया था, तो whoopSensorFlow–जो यह दिखाता है कि सेंसर कनेक्ट है या नहीं– null था. SensorWorker ने इसे शुरुआती तौर पर बंद होने की स्थिति के तौर पर नहीं माना और यह चलता रहा. इस वजह से, यह कनेक्शन के लिए अनिश्चित काल तक इंतज़ार करता रहा. इस वजह से, WorkManager ने काम पूरा होने तक पार्शियल वेक लॉक को चालू रखा. इससे बैकग्राउंड में वेक लॉक का इस्तेमाल ज़्यादा हुआ और SensorWorker को बार-बार, अनचाहे तरीके से फिर से शेड्यूल किया गया.

इस समस्या को हल करने के लिए, WHOOP की टीम ने वर्कर लॉजिक को अपडेट किया है. इससे मुख्य कारोबार के लॉजिक को लागू करने से पहले, कनेक्शन की स्थिति की जांच की जा सकेगी.

अगर सेंसर उपलब्ध नहीं है, तो वर्कर बंद हो जाता है. इससे टाइम आउट की समस्या नहीं होती और वेक लॉक भी हट जाता है. नीचे दिए गए कोड स्निपेट में, इस समस्या का समाधान दिखाया गया है:

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()
            }
}

पार्शियल वेक लॉक का ज़्यादा इस्तेमाल करने वाले सेशन में 90% की गिरावट

समस्या को ठीक करने के बाद, टीम ने Android की ज़रूरी जानकारी वाले डैशबोर्ड पर नज़र रखना जारी रखा. इससे यह पुष्टि की जा सकी कि बदलावों का क्या असर हुआ. 

आखिरकार, WHOOP ने अपने वर्कर में बदलाव लागू करने के 30 दिनों के अंदर, पार्शियल वेक लॉक के ज़्यादा इस्तेमाल के प्रतिशत को 15% से घटाकर 1%से भी कम कर दिया. 

बदलावों की वजह से, टीम को ऐसे कम उदाहरण मिले हैं जिनमें काम पूरा होने से पहले ही टाइम आउट हो गया हो. इससे औसत रनटाइम कम हो गया है. 

WHOOP टीम ने अन्य डेवलपर को सलाह दी है कि वे बैकग्राउंड में काम करने वाले अपने ऐप्लिकेशन की परफ़ॉर्मेंस को बेहतर बनाएं:

शुरू करें

अगर आपको अपने ऐप्लिकेशन में पार्शियल वेक लॉक का इस्तेमाल कम करना है या वर्कर की परफ़ॉर्मेंस को बेहतर बनाना है, तो Android की ज़रूरी जानकारी में जाकर, अपने ऐप्लिकेशन में पार्शियल वेक लॉक के ज़्यादा इस्तेमाल की मेट्रिक देखें. साथ ही, बेहतर तरीके से काम करने के लिए, वेक लॉक के दस्तावेज़ पढ़ें. इसमें डीबग करने की रणनीतियां भी शामिल हैं.