आपको बस URL की आवश्यकता है

VKontakte उपयोगकर्ता प्रतिदिन 10 बिलियन संदेशों का आदान-प्रदान करते हैं। वे एक-दूसरे के फोटो, कॉमिक्स, मेम्स और अन्य अटैचमेंट भेजते हैं। हम आपको बताएंगे कि URLProtocol का उपयोग करके छवियों को अपलोड करने के लिए हम एक iOS एप्लिकेशन के साथ कैसे आए, और चरण दर चरण हम यह पता लगाएंगे कि हम अपने स्वयं के कार्यान्वयन कैसे करें।

लगभग डेढ़ साल पहले, आईओएस के लिए वीके एप्लिकेशन में एक नया संदेश अनुभाग का विकास पूरे जोरों पर था। यह पहला खंड है जो पूरी तरह से स्विफ्ट में लिखा गया है। यह एक अलग मॉड्यूल vkm (VK संदेश) में स्थित है, जो मुख्य एप्लिकेशन के डिवाइस के बारे में कुछ भी नहीं जानता है। इसे एक अलग परियोजना में भी चलाया जा सकता है - संदेश पढ़ने और भेजने की मूल कार्यक्षमता काम करना जारी रखेगी। मुख्य अनुप्रयोग में, संदेश नियंत्रक को संबंधित कंटेनर व्यू कंट्रोलर के माध्यम से प्रदर्शित किया जाता है, उदाहरण के लिए, वार्तालाप में वार्तालाप या संदेशों की सूची।

संदेश VKontakte मोबाइल एप्लिकेशन के सबसे लोकप्रिय वर्गों में से एक है, इसलिए यह महत्वपूर्ण है कि यह घड़ी की तरह काम करे। messages परियोजना में, हम कोड की प्रत्येक पंक्ति के लिए लड़ते हैं। हमें हमेशा यह पसंद आया कि संदेशों को एप्लिकेशन में बड़े करीने से बनाया गया है, और हम यह सुनिश्चित करने का प्रयास करते हैं कि सब कुछ समान रहे।

नए कार्यों के साथ अनुभाग को धीरे-धीरे भरते हुए, हमने निम्नलिखित कार्य से संपर्क किया: हमें यह सुनिश्चित करना था कि संदेश से जुड़ी हुई तस्वीर को पहले मसौदे में प्रदर्शित किया गया था, और इसे भेजने के बाद, संदेशों की सामान्य सूची में। हम PHImageManager साथ काम करने के लिए एक मॉड्यूल जोड़ सकते हैं, लेकिन अतिरिक्त स्थितियों ने कार्य को और अधिक कठिन बना दिया है।



स्नैपशॉट चुनते समय, उपयोगकर्ता इसे प्रोसेस कर सकता है: फ़िल्टर, रोटेट, क्रॉप आदि लागू करें। वीके एप्लिकेशन में, इस तरह की कार्यक्षमता को एक अलग AssetService घटक में लागू किया जाता है। अब संदेश परियोजना से उसके साथ काम करना सीखना आवश्यक था।

ठीक है, कार्य काफी सरल है, हम इसे करेंगे। यह लगभग औसत समाधान है, क्योंकि इसमें बहुत भिन्नताएं हैं। हम प्रोटोकॉल लेते हैं, इसे संदेशों में डंप करते हैं और इसे तरीकों से भरना शुरू करते हैं। हम एसेट सेवा में जोड़ते हैं, प्रोटोकॉल को अनुकूलित करते हैं और हमारे कैश कार्यान्वयन को जोड़ते हैं! चिपचिपाहट के लिए। फिर हम कार्यान्वयन को संदेशों में डालते हैं, इसे कुछ सेवा या प्रबंधक में जोड़ते हैं जो इस सब के साथ काम करेगा, और इसका उपयोग करना शुरू कर देगा। उसी समय, एक नया डेवलपर अभी भी आता है और यह पता लगाने की कोशिश करते हुए, वह कानाफूसी में निंदा करता है ... (ठीक है, आप समझते हैं)। उसी समय, उसके माथे पर पसीना दिखाई देता है।

यह फैसला हमारी पसंद का नहीं था। नई संस्थाएँ प्रकट करती हैं कि संदेश घटकों को AssetService छवियों के साथ काम करने के बारे में जानना AssetService । डेवलपर को यह पता लगाने के लिए भी अतिरिक्त काम करने की आवश्यकता है कि यह सिस्टम कैसे काम करता है। अंत में, मुख्य परियोजना के घटकों के लिए एक अतिरिक्त अंतर्निहित लिंक था, जिससे हम बचने की कोशिश करते हैं ताकि संदेश खंड एक स्वतंत्र मॉड्यूल के रूप में काम करना जारी रखे।

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

तो हम एक बहुत ही सरल विचार के साथ आए: क्या होगा यदि स्थानीय संपत्ति को URL माध्यम से लोड करने के लिए सीखा जा सकता है? ऐसा लगता है कि थानोस की उंगलियों पर एक क्लिक से, यह हमारी सभी समस्याओं को हल कर देगा: आपको AssetService बारे में कुछ भी जानने की ज़रूरत नहीं है, नए डेटा प्रकारों को जोड़ना और व्यर्थ में एंट्रॉपी बढ़ाना, एक नई प्रकार की छवि को लोड करना सीखना, डेटा कैशिंग का ध्यान रखना। एक योजना की तरह लगता है।

हमें बस एक URL चाहिए

हमने इस विचार पर विचार किया और URL प्रारूप को परिभाषित करने का निर्णय लिया जिसका उपयोग हम स्थानीय परिसंपत्तियों को लोड करने के लिए करेंगे:

 asset://?id=123&width=1920&height=1280 

हम PHObject रूप में localIdentifier के localIdentifier संपत्ति के मूल्य का उपयोग करेंगे, और हम वांछित आकार की छवियों को लोड करने के लिए width और height मापदंडों को पारित करेंगे। हम crop , filter , rotate जैसे कुछ और पैरामीटर भी जोड़ते rotate , जो आपको संसाधित छवि की जानकारी के साथ काम करने की अनुमति देगा।

इन URL को संभालने के लिए URL हम एक AssetURLProtocol :

 class AssetURLProtocol: URLProtocol { } 

इसका कार्य AssetService माध्यम से छवि को लोड करना और पहले से उपयोग के लिए तैयार डेटा को वापस करना है।

यह सब हमें URL प्रोटोकॉल और URL Loading System के काम को लगभग पूरी तरह से सौंपने की अनुमति देगा।

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

यह काम किया? यदि, इस लेख को पढ़ते हुए, आप गैलरी से संदेश को VKontakte एप्लिकेशन पर संदेश में संलग्न कर सकते हैं, तो हाँ :)


यह स्पष्ट करने के लिए कि आपके URLProtocol को कैसे लागू किया URLProtocol , मैं एक उदाहरण के साथ इस पर विचार करने का प्रस्ताव करता हूं।

हम खुद को कार्य निर्धारित करते हैं: एक साधारण एप्लिकेशन को एक सूची के साथ लागू करने के लिए जिसमें आपको दिए गए निर्देशांक पर मैप स्नैपशॉट की एक सूची प्रदर्शित करने की आवश्यकता होती है। स्नैपशॉट डाउनलोड करने के लिए, हम MapKit से मानक MKMapSnapshotter उपयोग करेंगे, और हम कस्टम URLProtocol माध्यम से डेटा लोड करेंगे। परिणाम कुछ इस तरह दिख सकता है:


सबसे पहले, हम URL द्वारा डेटा लोड करने के लिए तंत्र को लागू करते हैं। नक्शा स्नैपशॉट प्रदर्शित करने के लिए, हमें बिंदु के निर्देशांक को जानना होगा - इसका अक्षांश और देशांतर ( latitude , longitude )। कस्टम URL प्रारूप को परिभाषित करें जिसके द्वारा हम जानकारी लोड करना चाहते हैं:

 map://?latitude=59.935634&longitude=30.325935 

अब हम URLProtocol लागू URLProtocol , जो इस तरह के लिंक को संसाधित करेगा और वांछित परिणाम उत्पन्न करेगा। चलिए MapURLProtocol क्लास बनाते हैं, जिसे हम बेस क्लास URLProtocol से इनहेरिट करेंगे। इसके नाम के बावजूद, URLProtocol एक अमूर्त वर्ग है, हालांकि। हमें शर्मिंदा नहीं होना चाहिए, यहां हम अन्य अवधारणाओं का उपयोग करते हैं - URLProtocol बिल्कुल URL प्रोटोकॉल का प्रतिनिधित्व करता है और इसका URLProtocol शर्तों से कोई संबंध नहीं है। तो MapURLProtocol :

 class MapURLProtocol: URLProtocol { } 

अब हम कुछ आवश्यक तरीकों को फिर से परिभाषित करते हैं जिनके बिना URL प्रोटोकॉल काम नहीं करेगा:

1. canInit(with:)

 override class func canInit(with request: URLRequest) -> Bool { return request.url?.scheme == "map" } 

हमारे URL प्रोटोकॉल के किस प्रकार के अनुरोधों को इंगित करने के लिए canInit(with:) विधि के canInit(with:) आवश्यक है। इस उदाहरण के लिए, मान लीजिए कि प्रोटोकॉल केवल URL में एक map योजना के साथ अनुरोधों को संसाधित करेगा। किसी भी अनुरोध को शुरू करने से पहले, URL Loading System सत्र के लिए पंजीकृत सभी प्रोटोकॉल से गुजरता है और इस पद्धति को कॉल करता है। पहला पंजीकृत प्रोटोकॉल, जो इस पद्धति में true लौटेगा, का उपयोग अनुरोध को संसाधित करने के लिए किया जाएगा।

canonicalRequest(for:)

 override class func canonicalRequest(for request: URLRequest) -> URLRequest { return request } 

canonicalRequest(for:) विधि कैनोनिकल फॉर्म के अनुरोध को कम करने के लिए है। प्रलेखन का कहना है कि प्रोटोकॉल का कार्यान्वयन खुद तय करता है कि इस अवधारणा की परिभाषा के रूप में क्या विचार किया जाए। यहां आप योजना को सामान्य कर सकते हैं, यदि आवश्यक हो तो हेडर को अनुरोध पर जोड़ सकते हैं, और इस तरह से काम करने के लिए एकमात्र आवश्यकता यह है कि प्रत्येक आने वाले अनुरोध के लिए हमेशा एक ही परिणाम होना चाहिए, क्योंकि इस पद्धति का उपयोग कैश्ड उत्तरों की खोज के लिए भी किया जाता है। URLCache में अनुरोध करता है।

3. startLoading()

startLoading() विधि आवश्यक डेटा लोड करने के लिए सभी तर्क का वर्णन करती है। इस उदाहरण में, आपको अनुरोध URL को पार्स करने की आवश्यकता है और, इसके latitude और longitude मापदंडों के मूल्यों के आधार पर, MKMapSnapshotter ओर MKMapSnapshotter और वांछित मानचित्र स्नैपशॉट लोड करें।

 override func startLoading() { guard let url = request.url, let components = URLComponents(url: url, resolvingAgainstBaseURL: false), let queryItems = components.queryItems else { fail(with: .badURL) return } load(with: queryItems) } func load(with queryItems: [URLQueryItem]) { let snapshotter = MKMapSnapshotter(queryItems: queryItems) snapshotter.start( with: DispatchQueue.global(qos: .background), completionHandler: handle ) } func handle(snapshot: MKMapSnapshotter.Snapshot?, error: Error?) { if let snapshot = snapshot, let data = snapshot.image.jpegData(compressionQuality: 1) { complete(with: data) } else if let error = error { fail(with: error) } } 

डेटा प्राप्त करने के बाद, प्रोटोकॉल को सही ढंग से बंद करना आवश्यक है:

 func complete(with data: Data) { guard let url = request.url, let client = client else { return } let response = URLResponse( url: url, mimeType: "image/jpeg", expectedContentLength: data.count, textEncodingName: nil ) client.urlProtocol(self, didReceive: response, cacheStoragePolicy: .allowed) client.urlProtocol(self, didLoad: data) client.urlProtocolDidFinishLoading(self) } 

सबसे पहले, URLResponse प्रकार की एक वस्तु बनाएँ। इस ऑब्जेक्ट में अनुरोध का जवाब देने के लिए महत्वपूर्ण मेटाडेटा है। तब हम URLProtocolClient ऑब्जेक्ट के लिए तीन महत्वपूर्ण विधियों को निष्पादित URLProtocolClient । इस प्रकार की client प्रॉपर्टी में URL प्रोटोकॉल की प्रत्येक इकाई होती है। यह URL प्रोटोकॉल और URL Loading System के पूरे URL Loading System बीच एक प्रॉक्सी के रूप में कार्य करता है, जो इन विधियों को कॉल करते समय, डेटा के साथ क्या करने की आवश्यकता के बारे में निष्कर्ष निकालता है: कैश, पूर्णहैंडलर के लिए अनुरोध भेजें, किसी तरह प्रोटोकॉल बंद करने की प्रक्रिया करें, आदि। और इन विधियों को कॉल की संख्या प्रोटोकॉल के कार्यान्वयन के आधार पर भिन्न हो सकती है। उदाहरण के लिए, हम नेटवर्क से डेटा को बैचों के साथ डाउनलोड कर सकते हैं और समय-समय पर URLProtocolClient को इंटरफ़ेस में डेटा लोडिंग की प्रगति दिखाने के लिए इस बारे में सूचित कर सकते हैं।

यदि प्रोटोकॉल के संचालन में कोई त्रुटि होती है, तो इसके बारे में URLProtocolClient को सही ढंग से संसाधित करने और सूचित करने के लिए भी आवश्यक है:

 func fail(with error: Error) { client?.urlProtocol(self, didFailWithError: error) } 

यह यह त्रुटि है जो तब अनुरोध के completionHandler को भेजी जाएगी, जहां इसे संसाधित किया जा सकता है और उपयोगकर्ता को एक सुंदर संदेश प्रदर्शित किया जा सकता है।

4. stopLoading()

जब किसी कारणवश प्रोटोकॉल ऑपरेशन पूरा हो जाता है तो stopLoading() विधि को कहा जाता है। यह या तो एक सफल समापन, या त्रुटि पूर्णता या अनुरोध रद्द करने का हो सकता है। कब्जे वाले संसाधनों को मुक्त करने या अस्थायी डेटा को हटाने के लिए यह एक अच्छी जगह है।

 override func stopLoading() { } 

यह URL प्रोटोकॉल के कार्यान्वयन को पूरा करता है; इसे एप्लिकेशन में कहीं भी उपयोग किया जा सकता है। हमारे प्रोटोकॉल को लागू करने के लिए कुछ और चीजें जोड़ने के लिए।

URLImageView

 class URLImageView: UIImageView { var task: URLSessionDataTask? var taskId: Int? func render(url: URL) { assert(task == nil || task?.taskIdentifier != taskId) let request = URLRequest(url: url) task = session.dataTask(with: request, completionHandler: complete) taskId = task?.taskIdentifier task?.resume() } private func complete(data: Data?, response: URLResponse?, error: Error?) { if self.taskId == task?.taskIdentifier, let data = data, let image = UIImage(data: data) { didLoadRemote(image: image) } } func didLoadRemote(image: UIImage) { DispatchQueue.main.async { self.image = image } } func prepareForReuse() { task?.cancel() taskId = nil image = nil } } 

यह एक साधारण वर्ग है, UIImageView का वंशज है, इसी तरह का कार्यान्वयन जिसे आप शायद किसी भी एप्लिकेशन में करते हैं। यहां हम केवल render(url:) विधि में URL द्वारा छवि को लोड करते हैं और इसे image संपत्ति में लिखते हैं। सुविधा यह है कि आप किसी भी छवि को http / https URL या हमारे कस्टम URL द्वारा अपलोड कर सकते हैं।

छवियों को लोड करने के अनुरोधों को निष्पादित करने के लिए, आपको URLSession प्रकार की एक वस्तु की भी आवश्यकता होगी:

 let config: URLSessionConfiguration = { let c = URLSessionConfiguration.ephemeral c.protocolClasses = [ MapURLProtocol.self ] return c }() let session = URLSession( configuration: config, delegate: nil, delegateQueue: nil ) 

सत्र विन्यास विशेष रूप से यहाँ महत्वपूर्ण है। URLSessionConfiguration हमारे लिए एक महत्वपूर्ण प्रॉपर्टी है - protocolClasses । यह URL प्रोटोकॉल के प्रकारों की एक सूची है जिसे इस कॉन्फ़िगरेशन वाला एक सत्र संभाल सकता है। डिफ़ॉल्ट रूप से, सत्र http / https प्रोटोकॉल के प्रसंस्करण का समर्थन करता है, और यदि कस्टम समर्थन की आवश्यकता होती है, तो उन्हें निर्दिष्ट किया जाना चाहिए। हमारे उदाहरण के लिए, MapURLProtocol निर्दिष्ट करें।

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

यहाँ परिणाम है:

कैशिंग के बारे में क्या?

सब कुछ अच्छी तरह से काम करने लगता है - एक महत्वपूर्ण बिंदु को छोड़कर: जब हम सूची को आगे और पीछे स्क्रॉल करते हैं, तो स्क्रीन पर सफेद धब्बे दिखाई देते हैं। ऐसा लगता है कि स्नैपशॉट को किसी भी तरह से कैश नहीं किया गया है और render(url:) विधि के लिए प्रत्येक कॉल के लिए, हम MKMapSnapshotter माध्यम से डेटा को MKMapSnapshotter । यह समय लगता है, और इसलिए लोडिंग में इस तरह के अंतराल। यह एक डेटा कैशिंग तंत्र को लागू करने के लायक है ताकि पहले से ही बनाए गए स्नैपशॉट फिर से डाउनलोड न हों। यहां हम URL Loading System की शक्ति का उपयोग करते हैं, जिसमें पहले से ही इसके लिए उपलब्ध URLCache लिए एक कैशिंग तंत्र है।

इस प्रक्रिया पर अधिक विस्तार से विचार करें और कैश के साथ काम को दो महत्वपूर्ण चरणों में विभाजित करें: पढ़ना और लिखना।

पढ़ना

कैश्ड डेटा को सही ढंग से पढ़ने URL Loading System के URL Loading System को कई महत्वपूर्ण सवालों के जवाब पाने में मदद चाहिए:

1. क्या URLCache का उपयोग करने के लिए?

बेशक, URLCache.shared पहले से ही समाप्त हो URLCache.shared , लेकिन URL Loading System हमेशा इसका उपयोग नहीं कर सकता है - आखिरकार, डेवलपर अपनी खुद की URLCache इकाई बनाना और उपयोग करना चाह सकता है। इस प्रश्न का उत्तर देने के लिए, URLSessionConfiguration session URLSessionConfiguration में urlCache गुण है। यह अनुरोधों को पढ़ने और रिकॉर्डिंग प्रतिक्रियाओं के लिए उपयोग किया जाता है। हम अपने मौजूदा कॉन्फ़िगरेशन में इन उद्देश्यों के लिए कुछ URLCache करेंगे।

 let config: URLSessionConfiguration = { let c = URLSessionConfiguration.ephemeral c.urlCache = ImageURLCache.current c.protocolClasses = [ MapURLProtocol.self ] return c }() 

2. क्या मुझे कैश्ड डेटा का उपयोग करने या फिर से डाउनलोड करने की आवश्यकता है?

इस प्रश्न का URLRequest अनुरोध पर निर्भर करता है जिसे हम निष्पादित करने वाले हैं। अनुरोध बनाते समय, हमारे पास URL अतिरिक्त cachePolicy तर्क में कैश पॉलिसी को निर्दिष्ट करने का अवसर होता है।

 let request = URLRequest( url: url, cachePolicy: .returnCacheDataElseLoad, timeoutInterval: 30 ) 

डिफ़ॉल्ट मान .useProtocolCachePolicy , जिसे दस्तावेज़ में भी लिखा गया है। इसका अर्थ है कि इस संस्करण में, अनुरोध की कैश्ड प्रतिक्रिया खोजने और इसकी प्रासंगिकता निर्धारित करने का कार्य पूरी तरह से URL प्रोटोकॉल के कार्यान्वयन के साथ है। लेकिन एक आसान तरीका है। यदि आप मूल्य .returnCacheDataElseLoad सेट करते हैं, तो अगली इकाई URLProtocol URL Loading System को कुछ काम पर ले जाएगा: यह कैश्ड रेस्पॉन्स का उपयोग करके वर्तमान अनुरोध urlCache कैश्ड रिस्पांस के लिए cachedResponse(for:) विधि के लिए। यदि कैश्ड डेटा है, तो CachedURLResponse URLProtocol आरंभीकृत किया जाता है और cachedResponse प्रॉपर्टी में संग्रहीत किया जाता है, तो CachedURLResponse की एक वस्तु को तुरंत स्थानांतरित कर दिया जाएगा:

 override init( request: URLRequest, cachedResponse: CachedURLResponse?, client: URLProtocolClient?) { super.init( request: request, cachedResponse: cachedResponse, client: client ) } 

CachedURLResponse एक सरल वर्ग है जिसमें डेटा ( Data ) और उनके लिए मेटा-जानकारी ( URLResponse ) है।

हम केवल startLoading विधि को startLoading बदल सकते हैं और इसके अंदर इस संपत्ति के मूल्य की जांच कर सकते हैं - और इस डेटा के साथ प्रोटोकॉल को तुरंत समाप्त कर सकते हैं:

 override func startLoading() { if let cachedResponse = cachedResponse { complete(with: cachedResponse.data) } else { guard let url = request.url, let components = URLComponents(url: url, resolvingAgainstBaseURL: false), let queryItems = components.queryItems else { fail(with: .badURL) return } load(with: queryItems) } } 

अभिलेख

कैश में डेटा खोजने के लिए, आपको इसे वहां रखना होगा। URL Loading System इस काम का भी ध्यान रखता है। हमारे लिए जो कुछ भी आवश्यक है, उसे यह बताना है कि हम उस डेटा को कैश करना चाहते हैं जब प्रोटोकॉल cacheStoragePolicy कैश पॉलिसी cacheStoragePolicy का उपयोग करके cacheStoragePolicy । यह निम्नलिखित मूल्यों के साथ एक सरल गणना है:

 enum StoragePolicy { case allowed case allowedInMemoryOnly case notAllowed } 

उनका मतलब है कि मेमोरी और डिस्क पर कैशिंग की अनुमति है, केवल मेमोरी में या निषिद्ध है। हमारे उदाहरण में, हम संकेत देते हैं कि कैशिंग को मेमोरी और डिस्क पर अनुमति दी जाती है, क्योंकि क्यों नहीं।

 client.urlProtocol(self, didReceive: response, cacheStoragePolicy: .allowed) 

इसलिए, कुछ सरल चरणों का पालन करके, हमने स्नैपशॉट को मैप करने की क्षमता का समर्थन किया। और अब आवेदन इस तरह काम करता है:


जैसा कि आप देख सकते हैं, कोई और अधिक सफेद धब्बे नहीं हैं - कार्ड एक बार लोड किए जाते हैं और फिर कैश से पुन: उपयोग किए जाते हैं।

हमेशा आसान नहीं होता

URL प्रोटोकॉल को लागू करते समय, हमें क्रैश की एक श्रृंखला का सामना करना पड़ा।

पहले अनुरोधों का जवाब URLCache समय URLCache साथ URL Loading System के इंटरैक्शन के आंतरिक कार्यान्वयन से संबंधित था। प्रलेखन में कहा गया है : URLCache के URLCache सुरक्षा के URLCache , cachedResponse(for:) और storeCachedResponse(_:for:) अनुरोधों को पढ़ने / लिखने के लिए तरीकों के संचालन से राज्यों की एक दौड़ हो सकती है, इसलिए इस बिंदु को URLCache उपवर्गों में ध्यान में रखा जाना चाहिए। हमें उम्मीद थी कि URLCache.shared का उपयोग URLCache.shared यह समस्या हल हो जाएगी, लेकिन यह गलत निकला। इसे ठीक करने के लिए, हम एक अलग ImageURLCache कैश, ImageURLCache वंशज का URLCache , जिसमें हम निर्दिष्ट विधियों को एक अलग कतार में सिंक्रोनाइज़ करते हैं। एक सुखद बोनस के रूप में, हम कैश की क्षमता को मेमोरी में और डिस्क पर अन्य URLCache संस्थाओं से अलग से कॉन्फ़िगर कर सकते हैं।

 private static let accessQueue = DispatchQueue( label: "image-urlcache-access" ) override func cachedResponse(for request: URLRequest) -> CachedURLResponse? { return ImageURLCache.accessQueue.sync { return super.cachedResponse(for: request) } } override func storeCachedResponse(_ response: CachedURLResponse, for request: URLRequest) { ImageURLCache.accessQueue.sync { super.storeCachedResponse(response, for: request) } } 

केवल iOS 9 के साथ उपकरणों पर एक और समस्या को फिर से प्रस्तुत किया गया था। URL प्रोटोकॉल के लोडिंग को शुरू करने और समाप्त करने के तरीकों को विभिन्न थ्रेड्स पर किया जा सकता है, जिससे दुर्लभ लेकिन अप्रिय क्रैश हो सकता है। समस्या को हल करने के लिए, हम वर्तमान थ्रेड को startLoading करने की विधि में startLoading और फिर इस थ्रेड पर सीधे डाउनलोड पूरा करने वाले कोड को निष्पादित करते हैं।

 var thread: Thread! override func startLoading() { guard let url = request.url, let components = URLComponents(url: url, resolvingAgainstBaseURL: false), let queryItems = components.queryItems else { fail(with: .badURL) return } thread = Thread.current if let cachedResponse = cachedResponse { complete(with: cachedResponse) } else { load(request: request, url: url, queryItems: queryItems) } } 

 func handle(snapshot: MKMapSnapshotter.Snapshot?, error: Error?) { thread.execute { if let snapshot = snapshot, let data = snapshot.image.jpegData(compressionQuality: 0.7) { self.complete(with: data) } else if let error = error { self.fail(with: error) } } } 

URL प्रोटोकॉल कब काम आ सकता है?

नतीजतन, हमारे iOS के लगभग हर उपयोगकर्ता एक तरह से या किसी अन्य तत्व से सामना करता है जो URL प्रोटोकॉल के माध्यम से काम करता है। मीडिया को गैलरी से डाउनलोड करने के अलावा, URL प्रोटोकॉल के विभिन्न कार्यान्वयन हमें मानचित्र और चुनावों को प्रदर्शित करने में मदद करते हैं, साथ ही साथ अपने प्रतिभागियों की तस्वीरों से बना चैट अवतार भी दिखाते हैं।





किसी भी समाधान की तरह, URLProtocol के अपने फायदे और नुकसान हैं।

URLProtocol नुकसान

• सख्त टाइपिंग का अभाव - URL बनाते समय URL स्ट्रिंग के माध्यम से स्कीम और लिंक पैरामीटर मैन्युअल रूप से निर्दिष्ट किए जाते हैं। यदि आप एक टाइपो बनाते हैं, तो वांछित पैरामीटर संसाधित नहीं किया जाएगा। यह अनुप्रयोग के डीबगिंग और इसके संचालन में त्रुटियों की खोज को जटिल कर सकता है। VKontakte एप्लिकेशन में, हम विशेष URLBuilder उपयोग करते हैं जो पारित किए गए मापदंडों के आधार पर अंतिम URL बनाते हैं। यह निर्णय बहुत सुंदर नहीं है और कुछ हद तक अतिरिक्त संस्थाओं का उत्पादन नहीं करने के लक्ष्य के विपरीत है, लेकिन अभी तक कोई बेहतर विचार नहीं है। लेकिन हम जानते हैं कि यदि आपको किसी प्रकार का कस्टम URL बनाने की आवश्यकता है, तो निश्चित रूप से इसके लिए एक विशेष URLBuilder है जो आपको गलती न करने में मदद करेगा।
• गैर-स्पष्ट क्रैश - मैंने पहले ही कुछ परिदृश्यों का वर्णन किया है जो URLProtocol का उपयोग करके क्रैश होने का कारण बन सकते हैं। शायद और भी हैं। लेकिन इस तरह की समस्याओं, हमेशा की तरह, या तो प्रलेखन के अधिक विचारशील पढ़ने, या स्टैक ट्रेस का गहराई से अध्ययन करके और समस्या की जड़ को खोजने के द्वारा हल किया जाता है।

URLProtocol के लाभ

• कमजोर घटक कनेक्टिविटी - डेटा लोड करने की पहल करने वाले एप्लिकेशन का हिस्सा यह नहीं जानता है कि यह कैसे आयोजित किया जाता है: इसके लिए किन घटकों का उपयोग किया जाता है, कैशिंग की व्यवस्था कैसे की जाती है। हम केवल एक निश्चित प्रारूप के बारे में जानते हैं URL- और केवल इसके साथ बातचीत करते हैं।
• कार्यान्वयन की सादगी - URLप्रोटोकॉल के सही संचालन के लिए , यह कई सरल तरीकों को लागू करने और प्रोटोकॉल को पंजीकृत करने के लिए पर्याप्त है। उसके बाद, यह आवेदन में कहीं भी इस्तेमाल किया जा सकता है।
• — , , URL -. URL , URLSession , URLSessionDataTask .
• — URL - URL -, URL Loading System .
• * API — . , API, - , URL -. , API , . URL - http / https .

URL - — . . - , - , , , — , . , , — URL .

GitHub