आईओएस में नेटवर्क कैशिंग। NSURLCache

नेटवर्क के साथ इंटरैक्ट करने वाले किसी भी एप्लिकेशन को विकसित करते समय यह विषय महत्वपूर्ण है। यहां, सिस्टम क्षमताओं का सक्षम उपयोग प्रोग्राम के साथ उपयोगकर्ता की बातचीत में काफी सुधार कर सकता है।

NSURLCache रैम या डिस्क पर नेटवर्क अनुरोधों को कैशिंग करने के लिए एक व्यापक समाधान है। Apple के प्रलेखन के अनुसार, NSURLConnection का उपयोग करने वाले किसी भी अनुरोध को NSURLCache माध्यम से "पारित" किया NSURLCache ।

कैशिंग नेटवर्क को आवश्यक कॉल की संख्या कम कर देता है, इंटरनेट की पूर्ण अनुपस्थिति के दौरान कार्यक्रम के साथ काम करने की धारणा में सुधार या नेटवर्क कनेक्शन के साथ समस्याएं।

सर्वर रिस्पॉन्स डाउनलोड होने के बाद, इसकी एक कॉपी लोकल कैश में सेव हो जाती है। अगली बार जब आप एक ही अनुरोध भेजते हैं, तो प्रतिक्रिया नेटवर्क से एक्सेस किए बिना, तुरंत वापस आ जाएगी। NSURLCache पारदर्शी रूप से उपयोगकर्ता को कैश्ड डेटा लौटाएगा।

NSURLCache उपयोग करने के लिए NSURLCache आपको sharedURLCache पर sharedURLCache मान सेट करने की sharedURLCache । यह application:didFinishLaunchingWithOptions: में किया जा सकता है application:didFinishLaunchingWithOptions: iOS पर या applicationDidFinishLaunching: में विधि application:didFinishLaunchingWithOptions: applicationDidFinishLaunching: - Mac OS X पर:

 -(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024 diskCapacity:20 * 1024 * 1024 diskPath:nil]; [NSURLCache setSharedURLCache:URLCache]; } 

आप कैश सेटिंग्स - क्लाइंट साइड और सर्वर साइड दोनों पर प्रबंधित कर सकते हैं। विकल्पों का एक बुद्धिमान विकल्प आपके आवेदन को अनुकूलित करने में उपयोगी हो सकता है।

NSURLRequestCachePolicy

सर्वर-साइड अनुरोध पर, कैश पॉलिसी cachePolicy ऑब्जेक्ट की cachePolicy संपत्ति का उपयोग करके सेट की गई है। आप निम्न विकल्पों में से एक चुन सकते हैं:

• NSURLRequestUseProtocolCachePolicy - डिफ़ॉल्ट मान। कैशिंग लॉजिक अनुरोध में उपयोग किए जाने वाले नेटवर्क प्रोटोकॉल के कार्यान्वयन से निर्धारित होता है।
• NSURLRequestReloadIgnoringLocalCacheData - डेटा हमेशा सर्वर से लोड किया जाता है, कैश की सामग्री को पूरी तरह से अनदेखा कर दिया जाता है।
• NSURLRequestReloadIgnoringLocalAndRemoteCacheData - स्थानीय कैश की सामग्रियों को अनदेखा किया जाता है। इसके अलावा, प्रॉक्सी सर्वर और अन्य मध्यवर्ती बुनियादी ढांचे को निर्देश दिया जाना चाहिए कि यदि संभव हो तो डेटा की कैश्ड कॉपी का उपयोग न करें।
• NSURLRequestReturnCacheDataElseLoad - जानकारी कैश से वापस आ जाती है, जबकि इसकी प्रासंगिकता के बारे में जानकारी का ध्यान नहीं रखा जाता है। यदि कैश में कोई डेटा नहीं है, तो वे नेटवर्क से लोड किए गए हैं।
• NSURLRequestReturnCacheDataDontLoad - डेटा को कैश से लिया जाता है, उनके अप्रचलन के बारे में जानकारी को अनदेखा किया जाता है। हालांकि, अगर कोई संग्रहीत जानकारी नहीं है, तो अनुरोध को तुरंत सर्वर से प्राप्त करने की कोशिश किए बिना पारित नहीं माना जाता है।
• NSURLRequestReloadRevalidatingCacheData - सर्वर द्वारा इसकी वैधता की प्रारंभिक पुष्टि के बाद ही कैश्ड डेटा का उपयोग किया जाता है। डेटा जो अप्रासंगिक हो गया है उसे नेटवर्क से बाहर पंप किया जाता है।

इन विकल्पों के बीच के अंतर हमेशा स्पष्ट नहीं होते हैं और अक्सर भ्रम की स्थिति पैदा करते हैं। न ही यह स्पष्टता जोड़ता है कि NSURLRequestReloadIgnoringLocalAndRemoteCacheData और NSURLRequestReloadRevalidatingCacheData सिद्धांत रूप में लागू नहीं किए गए हैं।

NSURLRequestCachePolicy बारे में आपको वास्तव में क्या जानने की जरूरत है:

• UseProtocolCachePolicy - डिफ़ॉल्ट व्यवहार
• ReloadIgnoringLocalCacheData - कैश का उपयोग न करें
• ReloadIgnoringLocalAndRemoteCacheData - कैश का उपयोग न करें। सब
• ReturnCacheDataElseLoad - कैश का उपयोग करें। इसकी प्रासंगिकता के बारे में जानकारी पर ध्यान न दें
• ReturnCacheDataDontLoad - ऑफ़लाइन मोड। इसकी "ताजगी" की परवाह किए बिना, केवल कैश्ड डेटा का उपयोग करें
• ReloadRevalidatingCacheData - सर्वर से यह पूछने से पहले कि कैश कितना प्रासंगिक है

HTTP कैशिंग

चूंकि NSURLConnection वर्ग NSURLConnection विभिन्न नेटवर्क प्रोटोकॉल (FTP और HTTP / HTTPS सहित) के साथ काम करने के लिए डिज़ाइन किया गया है, इसलिए कैशिंग को दस्तावेज़ में प्रोटोकॉल-स्वतंत्र तरीके से वर्णित किया गया है। इस लेख में, हम इसे HTTP प्रोटोकॉल के संदर्भ में विचार करेंगे।

HTTP में, सर्वर अनुरोधों और प्रतिक्रियाओं के हेडर का उपयोग एन्कोडिंग, माइम प्रकार, कैशिंग, आदि के बारे में मेटा-जानकारी के आदान-प्रदान के लिए किया जाता है।

अनुरोध हेड

डिफ़ॉल्ट रूप से, NSURLRequest वर्तमान समय का उपयोग यह निर्धारित करने के लिए करता है कि कैश्ड जानकारी वापस करनी है या नहीं। बेहतर ट्यूनिंग के लिए, आप निम्न हेडर का उपयोग कर सकते हैं:

• If-Modified-Since - यह हेडर सर्वर से प्रतिक्रिया के Last-Modified हेडर से मेल खाता है। इसका मान अंतिम कॉल से Last-Modified इस सेवा के लिए सेट किया जाना चाहिए।
• If-None-Match - प्रतिक्रिया के Etag मेल खाता है। यहां आपको पिछले प्राप्त Etag मान को पास करने की आवश्यकता है।

रिस्पांस हेडर

NSHTTPURLResponse साथ, कैशिंग हेडर भी लौटाए जा सकते हैं:

• Cache-Control - क्लाइंट पर HTTP कैशिंग को सक्षम करने के लिए यह शीर्ष लेख मौजूद होना चाहिए। इसके मूल्य में कैश में डेटा स्टोरेज की अवधि के बारे में जानकारी हो सकती है, साथ ही उन तक पहुंच का स्तर भी हो सकता है। विस्तृत जानकारी यहाँ उपलब्ध है ।

Cache-Control अलावा, सर्वर सशर्त रूप से डेटा प्राप्त करने के लिए उपयोग किए गए अतिरिक्त हेडर भेज सकता है (पिछले अनुभाग को देखें):

• Last-Modified - अनुरोधित संसाधन के अंतिम परिवर्तन का समय। उदाहरण के लिए, किसी फोटो एल्बम के बारे में जानकारी प्राप्त करते समय, Last-Modified हेडर को अंतिम फोटो की तारीख के बराबर मूल्य पर सेट किया जा सकता है।
• Etag - आवश्यक वस्तु की सामग्री का पहचानकर्ता। व्यवहार में, यह हो सकता है, उदाहरण के लिए, संसाधन की स्थिति का MD5 हैश । यह गतिशील रूप से उत्पन्न डेटा के लिए उपयोगी है जिसके लिए Last-Modified की परिभाषा समस्याग्रस्त है।

NSURLConnectionDelegate

अनुरोध के परिणाम को संसाधित करते समय, NSURLConnection प्रतिनिधि के पास connection:willCacheResponse: का उपयोग करके कैश्ड प्रतिक्रिया को बदलने की क्षमता होती है connection:willCacheResponse: विधि। इस कॉल के लिए एक NSCachedURLResponse ऑब्जेक्ट पास किया जाता है, जिसमें NSURLResponse में स्रोत NSURLResponse और कैश्ड डेटा का संदर्भ होता है। यह ऑब्जेक्ट नेटवर्क कनेक्शन से प्राप्त जानकारी के आधार पर बनाया गया है। चूंकि आप किसी भी पैरामीटर को संपादित करने के लिए NSCachedURLResponse वर्ग के उदाहरणों को संशोधित नहीं कर सकते हैं, इसलिए आपको NSCachedURLResponse initWithResponse:data:userInfo:storagePolicy: का उपयोग करके एक नई ऑब्जेक्ट बनाने की आवश्यकता है initWithResponse:data:userInfo:storagePolicy: उदाहरण के लिए:

 -(NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse { NSMutableDictionary *mutableUserInfo = [[cachedResponse userInfo] mutableCopy]; NSMutableData *mutableData = [[cachedResponse data] mutableCopy]; NSURLCacheStoragePolicy storagePolicy = NSURLCacheStorageAllowedInMemoryOnly; // ... return [[NSCachedURLResponse alloc] initWithResponse:[cachedResponse response] data:mutableData userInfo:mutableUserInfo storagePolicy:storagePolicy]; } 

यदि connection:willCacheResponse: विधि रिटर्न nil , तो प्रतिक्रिया बिल्कुल भी कैश नहीं होगी।

 - (NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse { return nil; } 

connection:willCacheResponse: विधि वैकल्पिक है। यदि इसे प्रतिनिधि में लागू नहीं किया जाता है, तो NSCachedURLResponse की स्वचालित रूप से निर्मित आवृत्ति का उपयोग किया जाएगा।

नुकसान

NSURLCache साथ काम करते समय कई विशेषताएं हैं:

• IOS 5 में, HTTP का उपयोग करते समय डिस्क कैशिंग केवल संभव है, लेकिन HTTPS नहीं । यह समर्थन केवल iOS 6 में लागू किया गया है।
• सर्वर के साथ बातचीत करते समय कुछ बारीकियां भी होती हैं जो कैशिंग हेडर का उपयोग नहीं करती हैं ।

निष्कर्ष

NSURLCache उदाहरण एक बार फिर हमें दिखाता है कि आपके द्वारा काम कर रहे सिस्टम की क्षमताओं को जानना कितना महत्वपूर्ण है।

कई डेवलपर्स कैशिंग को व्यवस्थित करने के लिए अपनी बाइक का आविष्कार करते हैं, क्योंकि उन्हें NSURLCache की क्षमताओं के बारे में पता नहीं है, जिसके आरंभ में कोड की केवल 2 लाइनें लगती हैं और काम को 100 गुना अधिक कुशल बनाता है। और भी नेटवर्क कैशिंग के लाभों के बारे में नहीं सोचते हैं और इसका उपयोग नहीं करते हैं, अपने सर्वर को भारी मात्रा में अनावश्यक अनुरोधों के साथ लोड कर रहे हैं।

इस प्रकार, अपने आवेदन के इष्टतम प्रदर्शन के लिए, हमेशा application:didFinishLaunchingWithOptions: में NSURLCache को इनिशियलाइज़ करें application:didFinishLaunchingWithOptions: विधि।