नियमित अपडेट के असर को कम करें

आपका ऐप्लिकेशन नेटवर्क से जो अनुरोध करता है वे बैटरी खर्च होने की मुख्य वजह होते हैं. ऐसा इसलिए होता है, क्योंकि ये अनुरोध, ज़्यादा बिजली खर्च करने वाले सेल्युलर या वाई-फ़ाई रेडियो को चालू करते हैं. ताकत से परे पैकेट भेजने और पाने के लिए, ये रेडियो ज़्यादा पावर की बचत करते हैं चालू कर रही हूँ और जागे रहोगी. हर 15 में नेटवर्क अनुरोध जैसा आसान तरीका कुछ सेकंड में मोबाइल रेडियो लगातार चालू रखा जा सकता है और बैटरी का तेज़ी से इस्तेमाल किया जा सकता है पावर.

सामान्य अपडेट तीन तरह के होते हैं:

• उपयोगकर्ता की ओर से शुरू किया गया. उपयोगकर्ताओं के व्यवहार के आधार पर अपडेट करना, जैसे कि पुल-टू-रीफ़्रेश जेस्चर का इस्तेमाल करें.
• ऐप्लिकेशन ने शुरू किया हो. बार-बार अपडेट किया जा रहा है.
• सर्वर से शुरू किया गया. इनसे मिली सूचना के जवाब में अपडेट किया जा रहा है सर्वर.

इस विषय में, इन सभी पहलुओं के बारे में जानकारी दी गई है. साथ ही, उन तरीकों के बारे में चर्चा की गई है जिनका इस्तेमाल बैटरी को तेज़ी से खर्च होने को कम करने के लिए ऑप्टिमाइज़ किया गया है.

उपयोगकर्ता के शुरू किए गए अनुरोध ऑप्टिमाइज़ करें

उपयोगकर्ता के अनुरोध, आम तौर पर कुछ उपयोगकर्ता व्यवहार की वजह से होते हैं. उदाहरण के लिए, नए समाचार लेख पढ़ने के लिए इस्तेमाल किए जाने वाले ऐप्लिकेशन में, उपयोगकर्ता को नए लेख देखने के लिए, पुल-टू-रिफ़्रेश जेस्चर करने की अनुमति दी जा सकती है. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए जो उपयोगकर्ता के भेजे गए अनुरोधों के जवाब देने की तकनीक को ऑप्टिमाइज़ करते हैं. नेटवर्क का इस्तेमाल.

उपयोगकर्ता के अनुरोधों को कम करना

अगर उपयोगकर्ता के कुछ अनुरोधों की ज़रूरत नहीं है, तो उन्हें अनदेखा किया जा सकता है. जैसे, मौजूदा डेटा के अपडेट होने के बावजूद, कुछ समय के अंदर कई बार 'पुल-टू-रिफ़्रेश' जेस्चर का इस्तेमाल करके नया डेटा देखने के लिए. हर अनुरोध पर कार्रवाई करने से, रेडियो को चालू रखने पर काफ़ी बिजली खर्च हो सकती है. उपयोगकर्ता से मिले अनुरोधों को कम करना, एक बेहतर तरीका है. इससे, किसी तय समयावधि में सिर्फ़ एक अनुरोध किया जा सकता है. इससे रेडियो का इस्तेमाल कम होता है.

कैश मेमोरी का इस्तेमाल करना

अपने ऐप्लिकेशन के डेटा को कैश मेमोरी में सेव करके, जानकारी की एक लोकल कॉपी बनाई जाती है की ज़रूरत होती है. इससे आपका ऐप्लिकेशन उसी लोकल डिवाइस पर मौजूद डेटा को ऐक्सेस कर पाएगा कोई नेटवर्क खोले बिना जानकारी को कई बार कॉपी करें ताकि नए अनुरोध किए जा सकें.

आपको डेटा को स्टैटिक (स्टैटिक) के साथ-साथ ज़्यादा से ज़्यादा कैश मेमोरी में सेव करना चाहिए संसाधन और मांग पर डाउनलोड, जैसे कि फ़ुल साइज़ की इमेज. एचटीटीपी कैश मेमोरी हेडर का इस्तेमाल करके, यह पक्का किया जा सकता है कि कैश मेमोरी सेव करने की रणनीति की वजह से, आपका ऐप्लिकेशन पुराना डेटा न दिखाए. नेटवर्क रिस्पॉन्स को कैश मेमोरी में सेव करने के बारे में ज़्यादा जानकारी के लिए, देखें गैर-ज़रूरी काम से बचें डाउनलोड.

Android 11 और उसके बाद वाले वर्शन पर, आपका ऐप्लिकेशन उन्हीं बड़े डेटासेट का इस्तेमाल कर सकता है जो इन ऐप्लिकेशन का इस्तेमाल मशीन लर्निंग और मीडिया प्लेबैक जैसे इस्तेमाल के उदाहरणों के लिए किया जाता है. जब आपके ऐप्लिकेशन को शेयर किए गए डेटासेट को ऐक्सेस करना होता है, तो वह पहले कैश मेमोरी में सेव किए गए वर्शन की जांच कर सकता है कॉपी करने से पहले. शेयर किए गए डेटासेट के बारे में ज़्यादा जानने के लिए, शेयर किए गए डेटासेट ऐक्सेस करना देखें.

कम समय में ज़्यादा डेटा डाउनलोड करने के लिए, ज़्यादा बैंडविड्थ का इस्तेमाल करना

वायरलेस रेडियो से कनेक्ट होने पर, आम तौर पर ज़्यादा बैंडविड्थ के लिए ज़्यादा बैटरी खर्च होती है. इसका मतलब है कि 5G, आम तौर पर LTE के मुकाबले ज़्यादा एनर्जी खर्च करता है. साथ ही, 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 Cloud Messaging (FCM) एक हल्का प्रोसेस है. इसका इस्तेमाल, किसी सर्वर से किसी खास ऐप्लिकेशन इंस्टेंस पर डेटा भेजने के लिए किया जाता है. FCM का इस्तेमाल करके, आपका सर्वर किसी खास डिवाइस पर आपके ऐप्लिकेशन को चलने की सूचना दे सकता है तो इसके लिए नया डेटा उपलब्ध है.

पोलिंग की तुलना में, जहां आपके ऐप्लिकेशन को सर्वर पर क्वेरी करने के लिए नियमित रूप से पिंग करना होता है नया डेटा है, तो इवेंट-ड्रिवन मॉडल की मदद से आपका ऐप्लिकेशन नया कनेक्शन बना सकता है वह सिर्फ़ तब काम कर सकता है, जब उसे पता हो कि डाउनलोड करने के लिए डेटा मौजूद है. यह मॉडल, ऐप्लिकेशन में जानकारी अपडेट करते समय, ग़ैर-ज़रूरी कनेक्शन को कम करता है और इंतज़ार का समय कम करता है.

FCM को स्थायी टीसीपी/आईपी कनेक्शन का इस्तेमाल करके लागू किया जाता है. इससे से लगातार कनेक्शन बनाने में मदद मिलती है. साथ ही, इससे प्लैटफ़ॉर्म को बैंडविथ को ऑप्टिमाइज़ करने में मदद मिलती है और बैटरी लाइफ़ पर उसके असर को कम किया जा सकता है.