केस स्टडी
WHOOP ने पार्शियल वेक लॉक वाले सेशन की संख्या को 90% से ज़्यादा कैसे कम किया
पढ़ने में 4 मिनट लगेंगे
पहनने वाले डिवाइस के लिए Android ऐप्लिकेशन बनाने का मतलब है कि स्क्रीन बंद होने के बाद असली काम शुरू होता है. WHOOP , सदस्यों को यह समझने में मदद करता है कि उनका शरीर ट्रेनिंग, रिकवरी, नींद, और तनाव पर कैसी प्रतिक्रिया देता है. Android पर WHOOP का इस्तेमाल करने वाले सदस्यों के लिए, बैकग्राउंड में भरोसेमंद तरीके से सिंक होने और कनेक्टिविटी की सुविधा, अहम जानकारी पाने में मदद करती है.
इस साल की शुरुआत में, Google Play ने Android की ज़रूरी जानकारी में एक नई मेट्रिक जोड़ी है: पार्शियल वेक लॉक का ज़्यादा इस्तेमाल. इस मेट्रिक से, उपयोगकर्ता के उन सेशन का प्रतिशत मेज़र किया जाता है जिनमें 24 घंटे की अवधि में, कुल मिलाकर दो घंटे से ज़्यादा समय तक वेक लॉक का इस्तेमाल किया गया हो. हालांकि, इसमें उन वेक लॉक को शामिल नहीं किया जाता जिन्हें इस्तेमाल करने की अनुमति मिली हुई है. इस मेट्रिक का मकसद, बैटरी खत्म होने की संभावित वजहों की पहचान करने और उन्हें ठीक करने में आपकी मदद करना है. उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, यह ज़रूरी है.
1 मार्च, 2026 से, क्वालिटी थ्रेशोल्ड को पूरा न करने वाले ऐप्लिकेशन को Google Play पर खोज के नतीजों से हटाया जा सकता है. Google Play Store पर, ऐप्लिकेशन की लिस्टिंग में चेतावनी भी दिखाई जा सकती है. इससे पता चलता है कि ऐप्लिकेशन, उम्मीद से ज़्यादा बैटरी इस्तेमाल कर सकता है.
WHOOP में सीनियर Android इंजीनियर, Mayank Saini के मुताबिक, Android की ज़रूरी जानकारी में, ऐप्लिकेशन के पार्शियल वेक लॉक के ज़्यादा इस्तेमाल का प्रतिशत 15% के तौर पर फ़्लैग किए जाने के बाद, “टीम को Android की परफ़ॉर्मेंस को बेहतर बनाने का मौका मिला.” यह प्रतिशत, सुझाए गए 5% के थ्रेशोल्ड से ज़्यादा था.
टीम ने Android की ज़रूरी जानकारी की मेट्रिक को इस बात का साफ़ तौर पर संकेत माना कि बैकग्राउंड में होने वाला काम, सीपीयू को ज़रूरत से ज़्यादा समय तक चालू रखता है. इस समस्या को हल करने से, उन्हें उपयोगकर्ताओं को बेहतर अनुभव देने में मदद मिलेगी. साथ ही, बैकग्राउंड में होने वाले काम में लगने वाले समय को कम करने, ब्लूटूथ कनेक्टिविटी को भरोसेमंद और समय पर बनाए रखने, और सिंक करने में मदद मिलेगी.
समस्या की पहचान करना
यह पता लगाने के लिए कि कहां से शुरुआत की जाए, टीम ने सबसे पहले Android की ज़रूरी जानकारी देखी. इससे उन्हें यह समझने में मदद मिली कि कौनसे वेक लॉक, मेट्रिक पर असर डाल रहे थे. Android की ज़रूरी जानकारी में, पार्शियल वेक लॉक के ज़्यादा इस्तेमाल की जानकारी देने वाले डैशबोर्ड को देखकर, उन्हें पता चला कि पार्शियल वेक लॉक के ज़्यादा इस्तेमाल की सबसे बड़ी वजह, उनके WorkManager वर्कर में से एक है. डैशबोर्ड में इसकी पहचान androidx.work.impl.background.systemjob.SystemJobService के तौर पर की गई है. WHOOP के “हमेशा चालू रहने वाले अनुभव” को बेहतर बनाने के लिए, ऐप्लिकेशन, WorkManager का इस्तेमाल करके बैकग्राउंड में काम करता है. जैसे, समय-समय पर सिंक करना और पहनने वाले डिवाइस के लिए बार-बार होने वाले अपडेट उपलब्ध कराना.
टीम को इस बात की जानकारी थी कि WorkManager, बैकग्राउंड में टास्क पूरा करते समय वेक लॉक हासिल करता है. हालांकि, Android की ज़रूरी जानकारी में, पार्शियल वेक लॉक के ज़्यादा इस्तेमाल की मेट्रिक के शामिल होने से पहले, उन्हें यह नहीं पता था कि WorkManager के अलावा, बैकग्राउंड में होने वाला उनका सारा काम कैसे डिस्ट्रिब्यूट किया जाता था.
डैशबोर्ड में WorkManager को मुख्य वजह के तौर पर दिखाने के बाद, टीम ने इस बात पर फ़ोकस किया कि उनके कौनसे वर्कर, सबसे ज़्यादा योगदान दे रहे थे. साथ ही, उन्होंने इस समस्या को हल करने की कोशिश की.
समस्या की वजह का बेहतर तरीके से पता लगाने के लिए, इंटरनल मेट्रिक और डेटा का इस्तेमाल करना
WHOOP के पास, WorkManager की मेट्रिक की निगरानी करने के लिए पहले से ही इंटरनल इन्फ़्रास्ट्रक्चर सेट अप था. वे समय-समय पर इन चीज़ों की निगरानी करते हैं:
- औसत रनटाइम: वर्कर कितने समय तक चलता है?
- टाइम आउट: वर्कर, काम पूरा करने के बजाय कितनी बार टाइम आउट होता है?
- फिर से कोशिशें: अगर वर्कर का काम टाइम आउट हो जाता है या वह काम नहीं कर पाता है, तो वह कितनी बार फिर से कोशिश करता है?
- रद्द किए गए काम: काम कितनी बार रद्द किया गया?
टीम को, वर्कर के काम करने और न कर पाने की जानकारी के अलावा, उसके काम की परफ़ॉर्मेंस की जानकारी भी मिलती है.
इंटरनल मेट्रिक में, चुनिंदा वर्कर के लिए औसत रनटाइम ज़्यादा फ़्लैग किया गया. इससे टीम को जांच को और सटीक बनाने में मदद मिली.
टीम ने अपनी इंटरनल मेट्रिक के अलावा, Android Studio केबैकग्राउंड टास्क इंस्पेक्टर का इस्तेमाल करके, काम के वर्कर की जांच की और उन्हें डीबग किया. साथ ही, Android की ज़रूरी जानकारी में फ़्लैग की गई मेट्रिक के हिसाब से, इससे जुड़े वेक लॉक पर खास तौर पर फ़ोकस किया.
जांच: वर्कर के अलग-अलग वैरिएंट के बीच अंतर करना
WHOOP, कुछ वर्कर के लिए एक बार और समय-समय पर शेड्यूल करने की सुविधा, दोनों का इस्तेमाल करता है. इससे ऐप्लिकेशन, एक जैसे टास्क के लिए एक ही वर्कर लॉजिक का इस्तेमाल कर पाता है. साथ ही, सफलता के मानदंड भी एक जैसे होते हैं. इनमें सिर्फ़ समय का अंतर होता है.
अपनी इंटरनल मेट्रिक का इस्तेमाल करके, टीम ने अपनी खोज को किसी खास वर्कर तक सीमित कर लिया. हालांकि, उन्हें यह नहीं पता था कि गड़बड़ी, वर्कर के एक बार, समय-समय पर, या दोनों तरह से शेड्यूल होने पर हुई थी. इसलिए, उन्होंने WorkManager के setTraceTag तरीके का इस्तेमाल करके, एक ही वर्कर के एक बार और समय-समय पर शेड्यूल होने वाले वैरिएंट के बीच अंतर करने के लिए, एक अपडेट रोल आउट किया.
इस अतिरिक्त जानकारी से, उन्हें यह पक्का करने में मदद मिलेगी कि पार्शियल वेक लॉक के ज़्यादा इस्तेमाल वाले सेशन में, वर्कर का कौनसा वैरिएंट (समय-समय पर या एक बार) सबसे ज़्यादा योगदान दे रहा था. हालांकि, डेटा से पता चला कि दोनों वैरिएंट में से कोई भी, दूसरे से ज़्यादा योगदान नहीं दे रहा था. इससे टीम हैरान रह गई.
WHOOP में Android इंजीनियर II, Manmeet Tuteja ने कहा कि “इस बंटवारे से हमें यह पुष्टि करने में भी मदद मिली कि समस्या, दोनों वैरिएंट में हो रही थी. इससे यह पता चला कि समस्या, शेड्यूल करने की सेटिंग की वजह से नहीं, बल्कि वर्कर के लागू करने के तरीके में, शेयर किए गए बिज़नेस लॉजिक की वजह से हो रही थी.”
वर्कर के व्यवहार के बारे में ज़्यादा जानकारी पाना और समस्या की असली वजह को ठीक करना
टीम को पता था कि उन्हें वर्कर के अंदर मौजूद लॉजिक को देखना होगा. इसलिए, उन्होंने जांच के दौरान फ़्लैग किए गए वर्कर के व्यवहार की फिर से जांच की. खास तौर पर, वे उन उदाहरणों की तलाश कर रहे थे जिनमें काम अटक गया हो और पूरा न हो पाया हो.
इन सभी की वजह से, वेक लॉक के ज़्यादा इस्तेमाल की असली वजह का पता चला:
एक 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 की ज़रूरी जानकारी में अपने ऐप्लिकेशन के पार्शियल वेक लॉक के ज़्यादा इस्तेमाल की मेट्रिक देखें. साथ ही, बेहतर तरीकों और डीबग करने की रणनीतियों के बारे में ज़्यादा जानने के लिए, वेक लॉक से जुड़ा दस्तावेज़ पढ़ें.
पढ़ना जारी रखें
-
केस स्टडी
Karrot, कम्यूनिटी पर आधारित, पीयर-टू-पीयर मार्केटप्लेस ऐप्लिकेशन है. इसकी मदद से, उपयोगकर्ता पुष्टि किए गए अन्य उपयोगकर्ताओं के साथ आइटम खरीद, बेच, और ट्रेड कर सकते हैं. इस प्लैटफ़ॉर्म को 2015 में दक्षिण कोरिया में लॉन्च किया गया था. इसके बाद, यह दुनिया भर के बाज़ारों में फैल गया है. इसके 4.3 करोड़ से ज़्यादा रजिस्टर किए गए उपयोगकर्ता हैं.
Thomas Ezan, Tracy Agyemang • पढ़ने में 2 मिनट लगेंगे
-
केस स्टडी
Monzo, यूके का एक डिजिटल बैंक है. इसके 1.5 करोड़ ग्राहक हैं और इनकी संख्या बढ़ती जा रही है. ऐप्लिकेशन के बढ़ने के साथ-साथ, इंजीनियरिंग टीम ने ऐप्लिकेशन के स्टार्टअप टाइम को बेहतर बनाने के लिए एक अहम क्षेत्र के तौर पर पहचाना. हालांकि, उन्हें चिंता थी कि इसके लिए, उनके कोडबेस में बड़े बदलाव करने पड़ेंगे.
Ben Weiss, Tracy Agyemang • पढ़ने में 2 मिनट लगेंगे
-
केस स्टडी
सोशल मीडिया की डाइनैमिक दुनिया में, उपयोगकर्ता का ध्यान तुरंत जीता या खोया जा सकता है. Meta के ऐप्लिकेशन (Facebook और Instagram) दुनिया के सबसे बड़े सोशल प्लैटफ़ॉर्म में से हैं. इनका इस्तेमाल दुनिया भर में अरबों लोग करते हैं.
Mayuri Khinvasara Khabya, Tracy Agyemang • पढ़ने में 4 मिनट लगेंगे
अप-टू-डेट रहें
हर हफ़्ते, Android डेवलपमेंट से जुड़ी नई जानकारी अपने इनबॉक्स में पाएं.