केस स्टडी
WHOOP ने पार्शियल वेक लॉक वाले सेशन को 90% से ज़्यादा कैसे कम किया
पढ़ने में 4 मिनट लगेंगे
वियरेबल डिवाइस के लिए 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 की मेट्रिक की निगरानी करने के लिए पहले से ही इंटरनल इन्फ़्रास्ट्रक्चर सेट अप था. वे समय-समय पर इन चीज़ों की निगरानी करते हैं:
- औसत रनटाइम: वर्कर कितने समय तक चलता है?
- टाइम आउट: वर्कर, टास्क पूरा करने के बजाय कितनी बार टाइम आउट होता है?
- फिर से कोशिश करना: अगर वर्कर का काम टाइम आउट हो जाता है या वह फ़ेल हो जाता है, तो वह कितनी बार फिर से कोशिश करता है?
- टास्क रद्द करना: वर्कर का काम कितनी बार रद्द किया गया?
टीम को सिर्फ़ वर्कर के टास्क के सफल और फ़ेल होने के बारे में जानकारी नहीं मिलती. इससे उन्हें अपने काम की परफ़ॉर्मेंस के बारे में भी पता चलता है.
इंटरनल मेट्रिक में, चुनिंदा वर्कर के लिए औसत रनटाइम ज़्यादा होने की जानकारी मिली. इससे टीम को जांच को और भी सटीक बनाने में मदद मिली.
टीम ने अपनी इंटरनल मेट्रिक के अलावा, 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 की ज़रूरी जानकारी में अपने ऐप्लिकेशन के पार्शियल वेक लॉक का ज़्यादा इस्तेमाल करने की मेट्रिक देखें. साथ ही, सबसे सही तरीकों और डीबग करने की रणनीतियों के बारे में ज़्यादा जानने के लिए, वेक लॉक से जुड़ा दस्तावेज़ पढ़ें.
पढ़ना जारी रखें
-
केस स्टडी
Karrot, एक हाइपरलोकल, कम्यूनिटी-ड्रिवन पीयर-टू-पीयर मार्केटप्लेस ऐप्लिकेशन है. इसकी मदद से, उपयोगकर्ता पुष्टि किए गए अन्य उपयोगकर्ताओं के साथ आइटम खरीद, बेच, और ट्रेड कर सकते हैं. इस प्लैटफ़ॉर्म को 2015 में दक्षिण कोरिया में लॉन्च किया गया था. इसके बाद, यह दुनिया भर के बाज़ारों में फैल गया है. इसके 4.3 करोड़ से ज़्यादा रजिस्टर किए गए उपयोगकर्ता हैं.
Thomas Ezan, Tracy Agyemang • पढ़ने में 2 मिनट लगेंगे
-
केस स्टडी
Monzo, यूके का एक डिजिटल बैंक है. इसके 1.5 करोड़ ग्राहक हैं और इनकी संख्या बढ़ती जा रही है. ऐप्लिकेशन के बढ़ने के साथ-साथ, इंजीनियरिंग टीम ने ऐप्लिकेशन के स्टार्टअप टाइम को बेहतर बनाने के लिए एक अहम क्षेत्र के तौर पर पहचाना. हालांकि, उन्हें चिंता थी कि इसके लिए, उनके कोडबेस में बड़े बदलाव करने पड़ेंगे.
Ben Weiss • पढ़ने में 2 मिनट लगेंगे
-
केस स्टडी
TikTok, दुनिया भर में शॉर्ट-वीडियो प्लैटफ़ॉर्म के तौर पर जाना जाता है. इसके उपयोगकर्ताओं की संख्या बहुत ज़्यादा है और इसमें नए-नए फ़ीचर उपलब्ध हैं.
Ben Trengrove, Ajesh Pai • पढ़ने में 2 मिनट लगेंगे
अप-टू-डेट रहें
Android डेवलपमेंट से जुड़ी नई अहम जानकारी, हर हफ़्ते अपने इनबॉक्स में पाएं.