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