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

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

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

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

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