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