ऑप्टिमाइज़ न किए गए डाउनलोड से बचें

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

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

इसी तरह, इमेज डाउनलोड करते समय, सर्वर साइड पर इमेज का साइज़ कम करना सबसे सही तरीका है. इसके बजाय, फ़ुल साइज़ वाली इमेज डाउनलोड करके, क्लाइंट पर उनका साइज़ कम करना सही तरीका नहीं है.

एचटीटीपी रिस्पॉन्स को कैश मेमोरी में सेव करना

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

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

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

Kotlin

// url represents the website containing the content to place into the cache.
val conn: HttpsURLConnection = url.openConnection() as HttpsURLConnection
val currentTime: Long = System.currentTimeMillis()
val lastModified: Long = conn.getHeaderFieldDate("Last-Modified", currentTime)

// lastUpdateTime represents when the cache was last updated.
if (lastModified < lastUpdateTime) {
    // Skip update
} else {
    // Parse update
    lastUpdateTime = lastModified
}

Java

// url represents the website containing the content to place into the cache.
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
long currentTime = System.currentTimeMillis();
long lastModified = conn.getHeaderFieldDate("Last-Modified", currentTime);

// lastUpdateTime represents when the cache was last updated.
if (lastModified < lastUpdateTime) {
    // Skip update
} else {
    // Parse update
    lastUpdateTime = lastModified;
}

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

Kotlin

val cacheDir = Context.getCacheDir()
val cacheSize = 10L * 1024L * 1024L // 10 MiB
val client: OkHttpClient = OkHttpClient.Builder()
    .cache(Cache(cacheDir, cacheSize))
    .build()

Java

File cacheDir = Context.getCacheDir();
long cacheSize = 10L * 1024L * 1024L; // 10 MiB
OkHttpClient client = new OkHttpClient.Builder()
    .cache(new Cache(cacheDir, cacheSize))
    .build();

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

Context.getExternalCacheDir() का इस्तेमाल करके, बिना मैनेज की गई बाहरी कैश मेमोरी डायरेक्ट्री में, संवेदनशील न होने वाले डेटा को कैश मेमोरी में सेव किया जा सकता है. इसके अलावा, मैनेज की गई सुरक्षित ऐप्लिकेशन कैश मेमोरी में डेटा को कैश मेमोरी में सेव किया जा सकता है. इसके लिए, Context.getCacheDir() का इस्तेमाल करें. ध्यान दें कि सिस्टम में स्टोरेज कम होने पर, इस इंटरनल कैश मेमोरी को मिटाया जा सकता है.

किसी रिपॉज़िटरी का इस्तेमाल करना

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