वियरेबल डिवाइस के लिए 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 vitals में फ़्लैग की गई मेट्रिक के साथ अलाइन करने के लिए, टीम ने वेक लॉक पर खास तौर पर ध्यान दिया.

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

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