WHOOP ने पार्शियल वेक लॉक वाले सेशन की संख्या 90% से ज़्यादा कैसे कम की

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

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

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

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

टीम ने 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 तरीके का इस्तेमाल करने के लिए एक अपडेट रोल आउट किया. इससे, एक ही वर्कर के एक बार और समय-समय पर शेड्यूल करने वाले वैरिएंट के बीच अंतर किया जा सकता है.

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

WHOOP में Android इंजीनियर 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 की ज़रूरी जानकारी में अपने ऐप्लिकेशन के पार्शियल वेक लॉक का ज़्यादा इस्तेमाल होने की मेट्रिक देखें. साथ ही, ज़्यादा सही तरीके और डीबग करने की रणनीतियों के लिए, वेक लॉक के दस्तावेज़ देखें.