आपके ऐप्लिकेशन से नेटवर्क पर किए जाने वाले अनुरोध, बैटरी के तेज़ी से खर्च होने की मुख्य वजह हैं क्योंकि वे बिजली की खपत करने वाले सेल्युलर या वाई-फ़ाई रेडियो चालू करते हैं. ताकत से परे पैकेट भेजने और पाने के लिए, ये रेडियो ज़्यादा पावर की बचत करते हैं चालू कर रही हूँ और जागे रहोगी. हर 15 में नेटवर्क का अनुरोध करने जितना आसान है कुछ सेकंड में मोबाइल रेडियो लगातार चालू रखा जा सकता है और बैटरी का तेज़ी से इस्तेमाल किया जा सकता है पावर.
सामान्य अपडेट तीन तरह के होते हैं:
- उपयोगकर्ता की ओर से शुरू किया गया. उपयोगकर्ताओं के व्यवहार के आधार पर अपडेट करना, जैसे कि पुल-टू-रीफ़्रेश जेस्चर का इस्तेमाल करें.
- ऐप्लिकेशन ने शुरू किया हो. बार-बार अपडेट किया जा रहा है.
- सर्वर से शुरू किया गया. इनसे मिली सूचना के जवाब में अपडेट किया जा रहा है सर्वर.
इस विषय में, इन सभी पहलुओं के बारे में जानकारी दी गई है. साथ ही, उन तरीकों के बारे में चर्चा की गई है जिनका इस्तेमाल बैटरी को तेज़ी से खर्च होने को कम करने के लिए ऑप्टिमाइज़ किया गया है.
उपयोगकर्ता के शुरू किए गए अनुरोध ऑप्टिमाइज़ करें
उपयोगकर्ता के अनुरोध, आम तौर पर कुछ उपयोगकर्ता व्यवहार की वजह से होते हैं. इसके लिए उदाहरण के लिए, ताज़ा समाचार पढ़ने के लिए इस्तेमाल किया जाने वाला ऐप्लिकेशन, उपयोगकर्ता को इन कामों की अनुमति दे सकता है नए लेख देखने के लिए पुल-टू-रीफ़्रेश करें जेस्चर का इस्तेमाल करें. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए जो उपयोगकर्ता के भेजे गए अनुरोधों के जवाब देने की तकनीक को ऑप्टिमाइज़ करते हैं. नेटवर्क का इस्तेमाल.
उपयोगकर्ता के अनुरोधों को थ्रॉटल करें
अगर आपको ऐसा करने की ज़रूरत नहीं है, तो हो सकता है कि आप उपयोगकर्ता की ओर से किए गए कुछ अनुरोधों को अनदेखा करना चाहें जैसे कि एक छोटी समयावधि में एक से ज़्यादा पुल-टू-रीफ़्रेश जेस्चर जब तक कि मौजूदा डेटा नया हो, तब तक नए डेटा की जांच कर लें. हर एक पर कार्रवाई की जा रही है रेडियो को चालू रखकर, बड़ी मात्रा में बिजली बर्बाद करने से रोका जा सकता है. ऐप्लिकेशन ज़्यादा असरदार तरीका, उपयोगकर्ता के किए गए अनुरोधों को कम करना है, ताकि एक समय में सिर्फ़ एक अनुरोध किया जा सकता है. इससे रेडियो का इस्तेमाल होता है.
कैश मेमोरी का इस्तेमाल करना
अपने ऐप्लिकेशन के डेटा को कैश मेमोरी में सेव करके, जानकारी की एक लोकल कॉपी बनाई जाती है की ज़रूरत होती है. इससे आपका ऐप्लिकेशन उसी लोकल डिवाइस पर मौजूद डेटा को ऐक्सेस कर पाएगा कोई नेटवर्क खोले बिना जानकारी को कई बार कॉपी करें ताकि नए अनुरोध किए जा सकें.
आपको डेटा को स्टैटिक (स्टैटिक) के साथ-साथ ज़्यादा से ज़्यादा कैश मेमोरी में सेव करना चाहिए संसाधन और मांग पर डाउनलोड, जैसे कि फ़ुल साइज़ की इमेज. आप एचटीटीपी का इस्तेमाल कर सकते हैं कैश मेमोरी हेडर, ताकि यह पक्का किया जा सके कि कैश मेमोरी की रणनीति की वजह से, ऐप्लिकेशन पर पुराना डेटा दिखा रहा है. नेटवर्क रिस्पॉन्स को कैश मेमोरी में सेव करने के बारे में ज़्यादा जानकारी के लिए, देखें गैर-ज़रूरी काम से बचें डाउनलोड.
Android 11 और उसके बाद वाले वर्शन पर, आपका ऐप्लिकेशन उन्हीं बड़े डेटासेट का इस्तेमाल कर सकता है जो इन ऐप्लिकेशन का इस्तेमाल मशीन लर्निंग और मीडिया प्लेबैक जैसे इस्तेमाल के उदाहरणों के लिए किया जाता है. जब आपके ऐप्लिकेशन को शेयर किए गए डेटासेट को ऐक्सेस करना होता है, तो वह पहले कैश मेमोरी में सेव किए गए वर्शन की जांच कर सकता है कॉपी करने से पहले. शेयर किए गए डेटासेट के बारे में ज़्यादा जानने के लिए, शेयर किए गए डेटासेट ऐक्सेस करना देखें.
कम बार, ज़्यादा डेटा डाउनलोड करने के लिए ज़्यादा बैंडविड्थ का इस्तेमाल करें
जब किसी वायरलेस रेडियो पर कनेक्ट किया जाता है, तो उच्च बैंडविड्थ आम तौर पर ज़्यादा बैटरी खर्च की वजह से, 5G नेटवर्क ज़्यादा ऊर्जा की खपत करता है LTE की तुलना में, जो कि 3G से ज़्यादा महंगा है.
इसका मतलब है कि रेडियो की स्थिति रेडियो टेक्नोलॉजी के तहत, आम तौर पर किसी राज्य में होने वाली बैटरी के असर के बारे में बताया जाता है. ज़्यादा बैंडविथ वाले रेडियो के लिए, टेल-टाइम में बदलाव करना ज़्यादा होता है. अगर आपको ज़्यादा जानकारी चाहिए, तो टेल-टाइम, रेडियो की स्थिति देखें मशीन.
साथ ही, ज़्यादा बैंडविड्थ का मतलब है कि ज़्यादा प्रीफ़ेच किए जा सकते हैं तेज़ी से, एक ही समय में ज़्यादा डेटा डाउनलोड करना. शायद कम काफ़ी आसानी से हो जाता है, क्योंकि टेल-टाइम बैटरी की लागत तुलनात्मक रूप से ज़्यादा है, इसलिए इसे इससे हर बार ट्रांसफ़र के दौरान, रेडियो को ज़्यादा देर तक चालू रखा जा सकेगा अपडेट की फ़्रीक्वेंसी कम करने के लिए, एक सेशन.
उदाहरण के लिए, अगर किसी LTE रेडियो में बैंडविथ और ऊर्जा की लागत दोगुनी होती है, तो तो आपको हर सेशन के दौरान चार गुना ज़्यादा डेटा डाउनलोड करना होगा—या 10 एमबी तक हो सकता है. इतना डेटा डाउनलोड करते समय, यह ज़रूरी है कि उपलब्ध लोकल स्टोरेज और फ़्लश पर आपकी प्रीफ़ेचिंग के असर को ध्यान में रखें समय-समय पर प्रीफ़ेच कैश मेमोरी का इस्तेमाल करें.
Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए
रजिस्टर करने के लिए ConnectivityManager
डिफ़ॉल्ट नेटवर्क का लिसनर और
रजिस्टर करने के लिए TelephonyManager
PhoneStateListener
से
अपने डिवाइस के कनेक्शन का मौजूदा टाइप तय करें. कनेक्शन का टाइप पता होने के बाद,
प्रीफ़ेच करने के रूटीन में बदलाव किया जा सकता है:
Kotlin
val cm = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager val tm = getSystemService(Context.TELEPHONY_SERVICE) as TelephonyManager private var hasWifi = false private var hasCellular = false private var cellModifier: Float = 1f private val networkCallback = object : ConnectivityManager.NetworkCallback() { // Network capabilities have changed for the network override fun onCapabilitiesChanged( network: Network, networkCapabilities: NetworkCapabilities ) { super.onCapabilitiesChanged(network, networkCapabilities) hasCellular = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) hasWifi = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_WIFI) } } private val phoneStateListener = object : PhoneStateListener() { override fun onPreciseDataConnectionStateChanged( dataConnectionState: PreciseDataConnectionState ) { cellModifier = when (dataConnectionState.networkType) { TelephonyManager.NETWORK_TYPE_LTE or TelephonyManager.NETWORK_TYPE_HSPAP -> 4f TelephonyManager.NETWORK_TYPE_EDGE or TelephonyManager.NETWORK_TYPE_GPRS -> 1/2f else -> 1f } } private class NetworkState { private var defaultNetwork: Network? = null private var defaultCapabilities: NetworkCapabilities? = null fun setDefaultNetwork(network: Network?, caps: NetworkCapabilities?) = synchronized(this) { defaultNetwork = network defaultCapabilities = caps } val isDefaultNetworkWifi get() = synchronized(this) { defaultCapabilities?.hasTransport(TRANSPORT_WIFI) ?: false } val isDefaultNetworkCellular get() = synchronized(this) { defaultCapabilities?.hasTransport(TRANSPORT_CELLULAR) ?: false } val isDefaultNetworkUnmetered get() = synchronized(this) { defaultCapabilities?.hasCapability(NET_CAPABILITY_NOT_METERED) ?: false } var cellNetworkType: Int = TelephonyManager.NETWORK_TYPE_UNKNOWN get() = synchronized(this) { field } set(t) = synchronized(this) { field = t } private val cellModifier: Float get() = synchronized(this) { when (cellNetworkType) { TelephonyManager.NETWORK_TYPE_LTE or TelephonyManager.NETWORK_TYPE_HSPAP -> 4f TelephonyManager.NETWORK_TYPE_EDGE or TelephonyManager.NETWORK_TYPE_GPRS -> 1 / 2f else -> 1f } } val prefetchCacheSize: Int get() = when { isDefaultNetworkWifi -> MAX_PREFETCH_CACHE isDefaultNetworkCellular -> (DEFAULT_PREFETCH_CACHE * cellModifier).toInt() else -> DEFAULT_PREFETCH_CACHE } } private val networkState = NetworkState() private val networkCallback = object : ConnectivityManager.NetworkCallback() { // Network capabilities have changed for the network override fun onCapabilitiesChanged( network: Network, networkCapabilities: NetworkCapabilities ) { networkState.setDefaultNetwork(network, networkCapabilities) } override fun onLost(network: Network?) { networkState.setDefaultNetwork(null, null) } } private val telephonyCallback = object : TelephonyCallback(), TelephonyCallback.PreciseDataConnectionStateListener { override fun onPreciseDataConnectionStateChanged(dataConnectionState: PreciseDataConnectionState) { networkState.cellNetworkType = dataConnectionState.networkType } } connectivityManager.registerDefaultNetworkCallback(networkCallback) telephonyManager.registerTelephonyCallback(telephonyCallback) private val prefetchCacheSize: Int get() { return when { hasWifi -> MAX_PREFETCH_CACHE hasCellular -> (DEFAULT_PREFETCH_CACHE * cellModifier).toInt() else -> DEFAULT_PREFETCH_CACHE } } }
Java
ConnectivityManager cm = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE); TelephonyManager tm = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE); private boolean hasWifi = false; private boolean hasCellular = false; private float cellModifier = 1f; private ConnectivityManager.NetworkCallback networkCallback = new ConnectivityManager.NetworkCallback() { @Override public void onCapabilitiesChanged( @NonNull Network network, @NonNull NetworkCapabilities networkCapabilities ) { super.onCapabilitiesChanged(network, networkCapabilities); hasCellular = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR); hasWifi = networkCapabilities .hasTransport(NetworkCapabilities.TRANSPORT_WIFI); } }; private PhoneStateListener phoneStateListener = new PhoneStateListener() { @Override public void onPreciseDataConnectionStateChanged( @NonNull PreciseDataConnectionState dataConnectionState ) { switch (dataConnectionState.getNetworkType()) { case (TelephonyManager.NETWORK_TYPE_LTE | TelephonyManager.NETWORK_TYPE_HSPAP): cellModifier = 4; Break; case (TelephonyManager.NETWORK_TYPE_EDGE | TelephonyManager.NETWORK_TYPE_GPRS): cellModifier = 1/2.0f; Break; default: cellModifier = 1; Break; } } }; cm.registerDefaultNetworkCallback(networkCallback); tm.listen( phoneStateListener, PhoneStateListener.LISTEN_PRECISE_DATA_CONNECTION_STATE ); public int getPrefetchCacheSize() { if (hasWifi) { return MAX_PREFETCH_SIZE; } if (hasCellular) { return (int) (DEFAULT_PREFETCH_SIZE * cellModifier); } return DEFAULT_PREFETCH_SIZE; }
ऐप्लिकेशन से भेजे गए अनुरोधों को ऑप्टिमाइज़ करना
ऐप्लिकेशन से भेजे जाने वाले अनुरोध, आम तौर पर एक शेड्यूल पर किए जाते हैं. जैसे, ऐसा ऐप्लिकेशन जो लॉग या Analytics से कनेक्ट कर सकती हैं. ऐप्लिकेशन से शुरू किए गए काम करते समय पर विचार करें, उन अनुरोधों की प्राथमिकता पर विचार करें, कि क्या उन्हें बैच बनाया जा सकता है साथ-साथ और क्या उन्हें डिवाइस के चार्ज होने तक टाला जा सकता है या किसी ऐसे नेटवर्क से कनेक्ट है जिसका डेटा इस्तेमाल करने की सीमा तय नहीं है. इन अनुरोधों को सावधानी से ऑप्टिमाइज़ किया जा सकता है शेड्यूल करना और लाइब्रेरी का इस्तेमाल करना, जैसे कि WorkManager.
बैच नेटवर्क अनुरोध
मोबाइल डिवाइस पर रेडियो चालू करने, कनेक्ट करने, और रेडियो को चालू रखने के लिए बहुत ज़्यादा ऊर्जा का इस्तेमाल होता है. इस वजह से, हर अनुरोध को बिना किसी क्रम के प्रोसेस करने से बहुत ज़्यादा बिजली खर्च हो सकती है और बैटरी लाइफ़ कम हो जाती है. ज़्यादा कारगर तरीका, नेटवर्क के सेट को सूची में जोड़ना है एक साथ प्रोसेस करते हैं. इससे सिस्टम को बिजली के लिए पेमेंट करना पड़ता है बस एक बार रेडियो चालू करने में खर्च हो जाता है, और फिर भी आपसे वे सारे डेटा मिल जाते हैं जिनका अनुरोध किया गया है एक ऐप्लिकेशन.
WorkManager का इस्तेमाल करना
बेहतर शेड्यूल के हिसाब से काम करने के लिए, WorkManager
लाइब्रेरी का इस्तेमाल किया जा सकता है
जो इस बात पर विचार करता है कि खास शर्तें पूरी होती हैं या नहीं, जैसे कि नेटवर्क की उपलब्धता
और पावर की स्थिति दिखेगी. उदाहरण के लिए, मान लें कि आपके पास
Worker
सब-क्लास कॉल की गई
DownloadHeadlinesWorker
जो ताज़ा खबरें फिर से दिखाता है. यह कर्मचारी
को हर घंटे चलने के लिए शेड्यूल किया जा सकता है, बशर्ते डिवाइस किसी
फिर से कोशिश करने की कस्टम रणनीति का इस्तेमाल करके, ऐसे नेटवर्क और डिवाइस की बैटरी कम नहीं की गई है जिस पर डेटा इस्तेमाल की सीमा न हो
अगर डेटा वापस पाने में कोई समस्या आ रही है, तो जैसा कि नीचे दिखाया गया है:
Kotlin
val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresBatteryNotLow(true) .build() val request = PeriodicWorkRequestBuilder<DownloadHeadlinesWorker>(1, TimeUnit.HOURS) .setConstraints(constraints) .setBackoffCriteria(BackoffPolicy.LINEAR, 1L, TimeUnit.MINUTES) .build() WorkManager.getInstance(context).enqueue(request)
Java
Constraints constraints = new Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresBatteryNotLow(true) .build(); WorkRequest request = new PeriodicWorkRequest.Builder(DownloadHeadlinesWorker.class, 1, TimeUnit.HOURS) .setBackoffCriteria(BackoffPolicy.LINEAR, 1L, TimeUnit.MINUTES) .build(); WorkManager.getInstance(this).enqueue(request);
WorkManager के अलावा, Android प्लैटफ़ॉर्म कई अन्य टूल उपलब्ध कराता है ताकि आप नेटवर्किंग टास्क को पूरा करने के लिए एक असरदार शेड्यूल तैयार कर सकें, जैसे कि पोलिंग के तौर पर. इन टूल का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, यह देखें बैकग्राउंड प्रोसेसिंग के लिए गाइड.
सर्वर से शुरू किए गए अनुरोध ऑप्टिमाइज़ करें
सर्वर से किए गए अनुरोध, आम तौर पर सर्वर. उदाहरण के लिए, नए समाचार लेख पढ़ने के लिए इस्तेमाल किए जाने वाले ऐप्लिकेशन को लेखों के नए बैच के बारे में सूचना जो उपयोगकर्ता की ज़रूरतों के हिसाब से सही हो कॉन्टेंट को मनमुताबिक बनाने से जुड़ी प्राथमिकताएं, जिसे इसके बाद डाउनलोड किया जाता है.
Firebase क्लाउड से मैसेज की मदद से सर्वर के अपडेट भेजें
Firebase क्लाउड से मैसेज भेजकर, (FCM) एक लाइटवेट वर्शन है डेटा को सर्वर से किसी ऐप्लिकेशन इंस्टेंस पर भेजने के लिए इस्तेमाल किया जाता है. FCM का इस्तेमाल करके, आपका सर्वर किसी खास डिवाइस पर आपके ऐप्लिकेशन को चलने की सूचना दे सकता है तो इसके लिए नया डेटा उपलब्ध है.
पोलिंग की तुलना में, जहां आपके ऐप्लिकेशन को सर्वर पर क्वेरी करने के लिए नियमित रूप से पिंग करना होता है नया डेटा है, तो इवेंट-ड्रिवन मॉडल की मदद से आपका ऐप्लिकेशन नया कनेक्शन बना सकता है वह सिर्फ़ तब काम कर सकता है, जब उसे पता हो कि डाउनलोड करने के लिए डेटा मौजूद है. मॉडल गै़र-ज़रूरी चीज़ों को कम करता है और आपके ऐप्लिकेशन में जानकारी अपडेट करते समय इंतज़ार का समय कम करता है.
FCM को स्थायी टीसीपी/आईपी कनेक्शन का इस्तेमाल करके लागू किया जाता है. इससे से लगातार कनेक्शन बनाने में मदद मिलती है. साथ ही, इससे प्लैटफ़ॉर्म को बैंडविथ को ऑप्टिमाइज़ करने में मदद मिलती है और बैटरी लाइफ़ पर उसके असर को कम किया जा सकता है.