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

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

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

डेटा स्टोर करने की जगह का इस्तेमाल करना

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