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