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