डेटा ट्रांसफ़र करने के लिए वायरलेस रेडियो का इस्तेमाल करना, आपके ऐप्लिकेशन की तेज़ी से बैटरी खर्च होने की सबसे अहम वजहों में से एक हो सकता है. नेटवर्क गतिविधि से जुड़ी तेज़ी से बैटरी खर्च होने की समस्या को कम करने के लिए, यह समझना ज़रूरी है कि कनेक्टिविटी मॉडल, रेडियो हार्डवेयर पर कैसे असर डालेगा.
इस सेक्शन में, वायरलेस रेडियो स्टेट मशीन के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि आपके ऐप्लिकेशन का कनेक्टिविटी मॉडल, इसके साथ कैसे इंटरैक्ट करता है. इसके बाद, यह कई तकनीकें उपलब्ध कराता है. इन तकनीकों का इस्तेमाल करके, बैटरी पर ऐप्लिकेशन के डेटा इस्तेमाल का असर कम किया जा सकता है.
रेडियो स्टेट मशीन
उपयोगकर्ता के डिवाइस पर मौजूद वायरलेस रेडियो में, बैटरी बचाने वाली सुविधाएं पहले से मौजूद होती हैं. इनसे, बैटरी की खपत को कम करने में मदद मिलती है. पूरी तरह से चालू होने पर, वायरलेस रेडियो बहुत ज़्यादा बैटरी खर्च करता है. हालांकि, बंद होने या स्टैंडबाय मोड में होने पर, यह बहुत कम बैटरी खर्च करता है.
एक ज़रूरी बात यह है कि रेडियो को स्टैंडबाय से पूरी तरह चालू होने में कुछ समय लगता है. रेडियो को "चालू करने" में कुछ समय लगता है. इसलिए, बैटरी ज़्यादा ऊर्जा वाली स्थिति से कम ऊर्जा वाली स्थिति में धीरे-धीरे बदलती है, ताकि इस्तेमाल न होने पर बिजली बचाई जा सके. साथ ही, रेडियो को "चालू करने" में लगने वाले समय को कम किया जा सके.
किसी सामान्य 3G नेटवर्क रेडियो के लिए, स्टेट मशीन में तीन एनर्जी स्टेट होती हैं:
- पूरी पावर: इसका इस्तेमाल तब किया जाता है, जब कनेक्शन चालू हो. इससे डिवाइस, ज़्यादा से ज़्यादा स्पीड पर डेटा ट्रांसफ़र कर पाता है.
- कम पावर: यह एक इंटरमीडिएट स्टेट है, जिसमें बैटरी की खपत करीब 50% तक कम हो जाती है.
- स्टैंडबाय: यह ऐसी स्थिति होती है, जिसमें डिवाइस सबसे कम बिजली खर्च करता है. इस दौरान, कोई नेटवर्क कनेक्शन चालू नहीं होता.
बैटरी कम होने और स्टैंडबाय मोड में होने पर, बैटरी की खपत काफ़ी कम होती है. हालांकि, इन मोड में नेटवर्क अनुरोधों में काफ़ी ज़्यादा समय लगता है. बैटरी के कम होने पर, उसे पूरी तरह से चार्ज होने में करीब डेढ़ सेकंड लगते हैं.वहीं, स्टैंडबाय मोड से पूरी तरह से चार्ज होने में दो सेकंड से ज़्यादा समय लग सकता है.
विलंबता को कम करने के लिए, स्टेट मशीन ट्रांज़िशन को कम ऊर्जा वाली स्थितियों में बदलने में देरी करती है. पहले डायग्राम में, सामान्य 3G रेडियो के लिए AT&T के समय का इस्तेमाल किया गया है.
पहली इमेज. यह 3G वायरलेस रेडियो स्टेट मशीन का सामान्य उदाहरण है.
हर डिवाइस पर रेडियो स्टेट मशीन अलग-अलग होती है. खास तौर पर, इससे जुड़ा ट्रांज़िशन डिले ("टेल टाइम") और स्टार्टअप लेटेंसी अलग-अलग होती है. यह इस बात पर निर्भर करती है कि वायरलेस रेडियो टेक्नोलॉजी (3G, LTE, 5G वगैरह) का इस्तेमाल किया गया है या नहीं. इसे मोबाइल और इंटरनेट सेवा देने वाली कंपनी के नेटवर्क के हिसाब से तय और कॉन्फ़िगर किया जाता है.
इस पेज पर, AT&T से मिले डेटा के आधार पर, सामान्य 3G वायरलेस रेडियो के लिए एक स्टेट मशीन के बारे में बताया गया है. हालांकि, सामान्य सिद्धांत और उनके आधार पर बने सबसे सही तरीके, सभी वायरलेस रेडियो सिस्टम पर लागू होते हैं.
यह तरीका, मोबाइल वेब ब्राउज़िंग के लिए खास तौर पर असरदार है. इसकी वजह यह है कि इससे उपयोगकर्ताओं को वेब ब्राउज़ करते समय, इंतज़ार के समय की समस्या नहीं होती. टेल-टाइम कम होने से यह भी पक्का होता है कि ब्राउज़िंग सेशन खत्म होने के बाद, रेडियो कम बैटरी खर्च करने वाली स्थिति में चला जाए.
हालांकि, इस तरीके से Android जैसे आधुनिक स्मार्टफ़ोन ऑपरेटिंग सिस्टम पर, ऐप्लिकेशन ठीक से काम नहीं कर पाते. Android पर ऐप्लिकेशन, फ़ोरग्राउंड (जहां कम समय में काम पूरा होना ज़रूरी है) और बैकग्राउंड (जहां बैटरी लाइफ़ को प्राथमिकता दी जानी चाहिए) दोनों में चलते हैं.
ऐप्लिकेशन, रेडियो स्टेट मशीन पर कैसे असर डालते हैं
हर बार नया नेटवर्क कनेक्शन बनाने पर, रेडियो पूरी तरह से चालू हो जाता है. ऊपर बताए गए सामान्य 3G रेडियो स्टेट मशीन के मामले में, डेटा ट्रांसफ़र होने तक यह पूरी पावर पर काम करेगा. इसके बाद, पांच सेकंड तक यह कम पावर पर काम करेगा. इसके बाद, 12 सेकंड तक यह कम ऊर्जा वाली स्थिति में रहेगा. इसलिए, सामान्य 3G डिवाइस के लिए, हर डेटा ट्रांसफ़र सेशन में रेडियो को कम से कम 18 सेकंड तक ऊर्जा की ज़रूरत होगी.
इसका मतलब यह है कि अगर कोई ऐप्लिकेशन, एक सेकंड में तीन बार डेटा ट्रांसफ़र करता है, तो वायरलेस रेडियो हमेशा चालू रहेगा. साथ ही, स्टैंडबाय मोड में जाने पर भी, यह हाई पावर मोड में वापस आ जाएगा.
दूसरी इमेज. एक सेकंड के लिए डेटा ट्रांसफ़र करने पर, वायरलेस रेडियो की पावर का इस्तेमाल. यह प्रोसेस हर मिनट में तीन बार होती है. इस आंकड़े में, दौड़ने के बीच "पावर अप" होने में लगने वाला समय शामिल नहीं है.
इसके उलट, अगर कोई ऐप्लिकेशन डेटा ट्रांसफ़र को बंडल करता है और हर मिनट में तीन सेकंड के लिए एक बार डेटा ट्रांसफ़र करता है, तो रेडियो हर मिनट में सिर्फ़ 20 सेकंड के लिए हाई-पावर स्टेट में रहेगा. इससे रेडियो हर मिनट में 40 सेकंड के लिए स्टैंडबाय मोड में रहेगा. इससे बैटरी की खपत में काफ़ी कमी आएगी.
तीसरी इमेज. तीन सेकंड के लिए डेटा ट्रांसफ़र करने पर, वायरलेस रेडियो की पावर का इस्तेमाल. यह हर मिनट में एक बार होता है.
ऑप्टिमाइज़ेशन की तकनीकें
अब आपको पता चल गया है कि नेटवर्क ऐक्सेस करने से बैटरी लाइफ़ पर क्या असर पड़ता है. इसलिए, आइए कुछ ऐसी चीज़ों के बारे में बात करते हैं जिनकी मदद से, तेज़ी से बैटरी खर्च होने की समस्या को कम किया जा सकता है. साथ ही, उपयोगकर्ताओं को बेहतर अनुभव दिया जा सकता है.
बंडल किए गए डेटा ट्रांसफ़र
पिछले सेक्शन में बताया गया है कि डेटा ट्रांसफ़र को बंडल करने से, बैटरी की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. इसका मतलब है कि आपको कम समय में ज़्यादा डेटा ट्रांसफ़र करना चाहिए.
हालांकि, ऐसा हमेशा नहीं किया जा सकता. ऐसा तब होता है, जब आपके ऐप्लिकेशन को उपयोगकर्ता की किसी कार्रवाई के जवाब में तुरंत डेटा पाना या भेजना होता है. इस समस्या को कम करने के लिए, डेटा प्रीफ़ेच करने की सुविधा का इस्तेमाल करें. अन्य स्थितियों में, बैचिंग और बंडलिंग का इस्तेमाल किया जा सकता है. जैसे, सर्वर को लॉग या Analytics भेजना और ऐप्लिकेशन से शुरू होने वाले अन्य डेटा को ट्रांसफ़र करना. हालांकि, यह डेटा तुरंत ट्रांसफ़र करने की ज़रूरत नहीं होती. बैकग्राउंड नेटवर्क ट्रांसफ़र शेड्यूल करने के बारे में सुझाव पाने के लिए, ऐप्लिकेशन से शुरू होने वाले टास्क को ऑप्टिमाइज़ करना लेख पढ़ें.
डेटा को प्रीफ़ेच करना
डेटा को पहले से फ़ेच करना, डेटा ट्रांसफ़र के उन सेशन की संख्या को कम करने का एक और असरदार तरीका है जिन्हें आपका ऐप्लिकेशन चलाता है. प्रीफ़ेचिंग की सुविधा का इस्तेमाल करने पर, जब उपयोगकर्ता आपके ऐप्लिकेशन में कोई कार्रवाई करता है, तो ऐप्लिकेशन यह अनुमान लगाता है कि उपयोगकर्ता की अगली कार्रवाइयों के लिए किस डेटा की ज़रूरत होगी. इसके बाद, ऐप्लिकेशन उस डेटा को एक ही बार में, एक ही कनेक्शन पर, पूरी क्षमता के साथ फ़ेच करता है.
ट्रांसफ़र को पहले से शेड्यूल करके, डेटा डाउनलोड करने के लिए ज़रूरी रेडियो ऐक्टिवेशन की संख्या कम की जा सकती है. इस वजह से, बैटरी की बचत तो होती ही है. साथ ही, लेटेन्सी कम होती है, बैंडविड्थ की ज़रूरत कम होती है, और डाउनलोड होने में कम समय लगता है.
प्रीफ़ेचिंग से, उपयोगकर्ता अनुभव को बेहतर बनाने में भी मदद मिलती है. ऐसा इसलिए, क्योंकि इससे ऐप्लिकेशन में होने वाली देरी कम हो जाती है. यह देरी, किसी कार्रवाई को पूरा करने या डेटा देखने से पहले, डाउनलोड पूरा होने का इंतज़ार करने की वजह से होती है.
यहां एक उदाहरण दिया गया है.
न्यूज़ रीडर
कई समाचार ऐप्लिकेशन, बैंडविड्थ को कम करने की कोशिश करते हैं. इसके लिए, वे किसी कैटगरी को चुनने के बाद ही हेडलाइन डाउनलोड करते हैं. पूरे लेख सिर्फ़ तब डाउनलोड किए जाते हैं, जब उपयोगकर्ता उन्हें पढ़ना चाहता है. इसके अलावा, थंबनेल सिर्फ़ तब डाउनलोड किए जाते हैं, जब वे स्क्रोल करके व्यू में आते हैं.
इस तरीके का इस्तेमाल करने पर, रेडियो को ज़्यादातर उपयोगकर्ताओं के लिए चालू रखना पड़ता है. ऐसा इसलिए, क्योंकि वे हेडलाइन स्क्रोल करते हैं, कैटगरी बदलते हैं, और लेख पढ़ते हैं. इतना ही नहीं, एनर्जी स्टेट के बीच लगातार स्विच करने से, कैटगरी स्विच करते समय या लेख पढ़ते समय काफ़ी देरी होती है.
बेहतर तरीका यह है कि स्टार्टअप के समय, कुछ डेटा प्रीफ़ेच किया जाए. इसकी शुरुआत, खबरों की हेडलाइन और थंबनेल के पहले सेट से की जाए. इससे स्टार्टअप में कम समय लगेगा. इसके बाद, बाकी हेडलाइन और थंबनेल के साथ-साथ, मुख्य हेडलाइन की सूची में मौजूद हर लेख का टेक्स्ट प्रीफ़ेच किया जाए.
एक और विकल्प यह है कि हर हेडलाइन, थंबनेल, लेख के टेक्स्ट, और शायद लेख की पूरी तस्वीरों को पहले से फ़ेच कर लिया जाए. आम तौर पर, ऐसा पहले से तय किए गए शेड्यूल के हिसाब से बैकग्राउंड में किया जाता है. इस तरीके से, ऐसे कॉन्टेंट को डाउनलोड करने में ज़्यादा बैंडविथ और बैटरी खर्च हो सकती है जिसका कभी इस्तेमाल नहीं किया जाता. इसलिए, इसे सावधानी से लागू किया जाना चाहिए.
ज़्यादा जानकारी
डेटा को पहले से फ़ेच करने के कई फ़ायदे हैं. हालांकि, इसका ज़्यादा इस्तेमाल करने से तेज़ी से बैटरी खर्च होने और बैंडविथ के इस्तेमाल के साथ-साथ डाउनलोड कोटा भी बढ़ सकता है. ऐसा इसलिए होता है, क्योंकि इस्तेमाल न किए गए डेटा को डाउनलोड किया जाता है. यह भी ज़रूरी है कि प्रीफ़ेचिंग की वजह से, ऐप्लिकेशन के शुरू होने में देरी न हो. ऐसा तब होता है, जब ऐप्लिकेशन प्रीफ़ेचिंग के पूरा होने का इंतज़ार करता है. इसका मतलब यह हो सकता है कि डेटा को धीरे-धीरे प्रोसेस किया जाए या लगातार ट्रांसफ़र शुरू किए जाएं, ताकि ऐप्लिकेशन शुरू करने के लिए ज़रूरी डेटा को पहले डाउनलोड और प्रोसेस किया जा सके.
डेटा को कितनी तेज़ी से प्रीफ़ेच किया जाए, यह इस बात पर निर्भर करता है कि डाउनलोड किया जा रहा डेटा कितना बड़ा है और उसके इस्तेमाल किए जाने की कितनी संभावना है. सामान्य तौर पर, ऊपर बताई गई स्टेट मशीन के आधार पर, ऐसे डेटा को प्रीफ़ेच किया जा सकता है जिसके मौजूदा उपयोगकर्ता सेशन में इस्तेमाल होने की संभावना 50% है. इसके लिए, आम तौर पर छह सेकंड (लगभग एक से दो मेगाबाइट) का समय लगता है. ऐसा तब तक किया जा सकता है, जब तक कि इस्तेमाल न किए गए डेटा को डाउनलोड करने की संभावित लागत, उस डेटा को डाउनलोड न करने से होने वाली संभावित बचत के बराबर न हो जाए.
आम तौर पर, डेटा को प्रीफ़ेच करना एक अच्छा तरीका है. इससे आपको हर दो से पांच मिनट में सिर्फ़ एक और डाउनलोड शुरू करना होगा. साथ ही, यह एक से पांच मेगाबाइट के क्रम में होगा.
इस सिद्धांत के मुताबिक, वीडियो फ़ाइलों जैसे बड़े डाउनलोड को नियमित अंतराल (हर दो से पांच मिनट) पर छोटे-छोटे हिस्सों में डाउनलोड किया जाना चाहिए. इससे, अगले कुछ मिनटों में देखे जाने वाले वीडियो डेटा को ही प्रीफ़ेच किया जा सकेगा.
इसका एक तरीका यह है कि पूरे डाउनलोड को सिर्फ़ तब शेड्यूल किया जाए, जब डिवाइस वाई-फ़ाई से कनेक्ट हो. साथ ही, ऐसा भी हो सकता है कि डाउनलोड सिर्फ़ तब हो, जब डिवाइस चार्ज हो रहा हो. WorkManager API इस इस्तेमाल के उदाहरण के साथ काम करता है. इससे, बैकग्राउंड में होने वाले काम को तब तक सीमित किया जा सकता है, जब तक डिवाइस डेवलपर की तय की गई शर्तों को पूरा नहीं करता. जैसे, डिवाइस चार्ज हो रहा हो और वाई-फ़ाई से कनेक्ट हो.
अनुरोध करने से पहले, कनेक्टिविटी की जांच करना
मोबाइल डिवाइस पर, सेल सिग्नल ढूंढना सबसे ज़्यादा बैटरी खर्च करने वाली कार्रवाइयों में से एक है. उपयोगकर्ता के अनुरोधों के लिए सबसे सही तरीका यह है कि पहले ConnectivityManager का इस्तेमाल करके कनेक्शन की जांच करें. इसके बारे में कनेक्टिविटी की स्थिति और कनेक्शन मीटरिंग की निगरानी करना लेख में बताया गया है.
अगर कोई नेटवर्क नहीं है, तो ऐप्लिकेशन बैटरी बचा सकता है. इसके लिए, वह मोबाइल रेडियो को खोज करने के लिए मजबूर नहीं करता. इसके बाद, अनुरोध को शेड्यूल किया जा सकता है. साथ ही, कनेक्शन बनने पर इसे अन्य अनुरोधों के साथ बैच में पूरा किया जा सकता है.
पूल कनेक्शन
बैचिंग और प्रीफ़ेचिंग के अलावा, एक और रणनीति है जो आपकी मदद कर सकती है. वह है, अपने ऐप्लिकेशन के नेटवर्क कनेक्शन को पूल करना.
नए नेटवर्क कनेक्शन शुरू करने के बजाय, मौजूदा नेटवर्क कनेक्शन का फिर से इस्तेमाल करना आम तौर पर ज़्यादा असरदार होता है. कनेक्शन का दोबारा इस्तेमाल करने से, नेटवर्क को कंजेशन और नेटवर्क डेटा से जुड़ी समस्याओं पर ज़्यादा बेहतर तरीके से प्रतिक्रिया देने में मदद मिलती है.
HttpURLConnection और ज़्यादातर एचटीटीपी क्लाइंट, जैसे कि OkHttp, डिफ़ॉल्ट रूप से कनेक्शन-पूलिंग की सुविधा चालू करते हैं. साथ ही, कई अनुरोधों के लिए एक ही कनेक्शन का फिर से इस्तेमाल करते हैं.
रीकैप और आगे के प्लान
इस सेक्शन में, आपको वायरलेस रेडियो और कुछ ऐसी रणनीतियों के बारे में जानकारी मिली जिन्हें बैटरी की खपत कम करते हुए, उपयोगकर्ताओं को तेज़ और रिस्पॉन्सिव अनुभव देने के लिए इस्तेमाल किया जा सकता है.
अगले सेक्शन में, हम तीन अलग-अलग तरह के नेटवर्क इंटरैक्शन के बारे में विस्तार से जानेंगे. ये इंटरैक्शन, ज़्यादातर ऐप्लिकेशन में आम तौर पर होते हैं. आपको इन सभी तरह के इंटरैक्शन के बारे में पता चलेगा. साथ ही, इन इंटरैक्शन को असरदार तरीके से मैनेज करने के लिए, आधुनिक तकनीकों और एपीआई के बारे में भी जानकारी मिलेगी.