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

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

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

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

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