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

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

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

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

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

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

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

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

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

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