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

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

डाउनलोड किए गए डेटा को कम करने का सबसे बुनियादी तरीका यह है कि आप सिर्फ़ वही डाउनलोड करें जिसकी आपको ज़रूरत है. डेटा के मामले में, इसका मतलब है कि ऐसे 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() का इस्तेमाल करके, मैनेज की गई और सुरक्षित ऐप्लिकेशन कैश मेमोरी में डेटा को कैश मेमोरी में सेव किया जा सकता है. ध्यान दें कि जब सिस्टम में उपलब्ध स्टोरेज कम हो, तो इस इंटरनल कैश मेमोरी को खाली किया जा सकता है.

डेटाबेस का इस्तेमाल करना

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