आईओएस। जब अनुप्रयोग नहीं चल रहा हो तो नेटवर्किंग

उपयोगकर्ताओं को उम्मीद है कि नेटवर्क "जादुई रूप से" काम करेगा और किसी का ध्यान नहीं जाएगा। यह जादू सिस्टम और एप्लिकेशन के डेवलपर्स पर निर्भर करता है। सिस्टम को प्रभावित करना मुश्किल है, इसलिए हम खुद को आवेदन तक सीमित रखेंगे।

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

शुरू करने के लिए, आइए शब्दावली से निपटें।

डेटा ट्रांसफर दो दिशाओं में होता है:

• डाउनलोड (डाउनलोड करना, सर्वर से डेटा डाउनलोड करना),
• अपलोड (सर्वर पर डेटा भेजना)।

एप्लिकेशन सक्रिय हो सकता है, लेकिन पृष्ठभूमि में काम कर सकता है। औपचारिक रूप से, उनके पास अन्य राज्य हैं , लेकिन हम केवल इन में रुचि रखते हैं:

• पृष्ठभूमि (जब आवेदन कम से कम हो),
• सक्रिय (जब अनुप्रयोग स्क्रीन पर सक्रिय है)।

उपयोगी पैटर्न: कॉलबैक , प्रतिनिधि ( कोको डिजाइन पैटर्न , विकिपीडिया पर कॉलबैक के बारे में )। आपको यह भी जानना होगा URLSession (लेख में, लिंक में नेटवर्क के साथ पृष्ठभूमि के काम का भी उल्लेख है, लेकिन पारित होने में)।

सभी उदाहरण स्विफ्ट 5 में लिखे गए हैं, iOS 11 और नए (iOS 11 और 12 पर परीक्षण किए गए) पर काम करते हैं और नियमित HTTP अनुरोधों का उपयोग करते हैं। अधिकांश भाग के लिए, यह सब काम करेगा, iOS 9 के साथ शुरू होगा, लेकिन "बारीकियों" हैं।

नेटवर्क के साथ काम करने की सामान्य योजना। URLSession

नेटवर्क के साथ काम करना विशेष रूप से कठिन नहीं है:

• URLSessionConfiguration कॉन्फ़िगरेशन बनाएं;
• URLSession का एक कॉन्फ़िगरेशन उदाहरण URLSession ;
• एक कार्य बनाएं ( session.dataTask(…) और इसी तरह के तरीकों का उपयोग करके;
• कार्य अपडेट के लिए सदस्यता लें। अद्यतन असिंक्रोनस रूप से आते हैं, वे प्रतिनिधि के पास आ सकते हैं , जो तब बनाया जाता है जब सत्र बनाया जाता है, या वे कॉलबैक में हो सकते हैं , जो तब बनाया जाता है जब कार्य बनाया जाता है;
• जब हमने देखा कि कार्य पूरा हो गया है, तो हम एप्लिकेशन लॉजिक पर लौट आते हैं।

एक साधारण उदाहरण इस तरह दिखता है:

 let session = URLSession(configuration: .default) let url = URL(...) let dataTask = session.dataTask(with: url) { data, response, error in ... //     //  callback,    } 

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

मैं तुरंत ध्यान देता हूं कि इस परिदृश्य में भी बहुत सारी दिलचस्प चीजें हैं। कभी-कभी आपको मुश्किल पुनर्निर्देशन के साथ काम करने की आवश्यकता होती है, कभी-कभी आपको प्राधिकरण, एसएसएल-पिनिंग, या एक साथ सभी की आवश्यकता होती है। आप इस बारे में बहुत कुछ पढ़ सकते हैं। किसी कारण से, पृष्ठभूमि राज्य में नेटवर्क के साथ काम करना बहुत कम वर्णित है।

पृष्ठभूमि में काम करने के लिए एक सत्र बनाना

पृष्ठभूमि URLSession और सामान्य के बीच अंतर क्या है? यह आवेदन प्रक्रिया के बाहर काम करता है, सिस्टम के अंदर कहीं। इसलिए, आवेदन प्रक्रिया पूरी होने पर यह "मर" नहीं जाता है। इसे बैकग्राउंड सेशन (साथ ही एप्लिकेशन की स्थिति, जो थोड़ा भ्रमित करने वाला है) कहा जाता है और इसके लिए विशिष्ट सेटिंग्स की आवश्यकता होती है। उदाहरण के लिए, यह:

 let configuration = URLSessionConfiguration.background(withIdentifier: "com.my.app") configuration.sessionSendsLaunchEvents = true configuration.isDiscretionary = true configuration.allowsCellularAccess = true configuration.shouldUseExtendedBackgroundIdleMode = true configuration.waitsForConnectivity = true URLSession(configuration: configuration, delegate: self, delegateQueue: nil) 

कॉन्फ़िगरेशन में कई अन्य पैरामीटर हैं, लेकिन ये सीधे पृष्ठभूमि सत्रों से संबंधित हैं:

• पहचानकर्ता (इनिशियलाइज़र में पारित) एक स्ट्रिंग है जो एप्लिकेशन के पुनरारंभ होने पर पृष्ठभूमि सत्र से मेल खाने के लिए उपयोग की जाती है। यदि अनुप्रयोग पुनरारंभ होता है और आप एक पहचानकर्ता के साथ एक पृष्ठभूमि सत्र बनाते हैं जो पहले से ही दूसरे पृष्ठभूमि सत्र में उपयोग किया जाता है, तो नए में पिछले एक के कार्यों तक पहुंच होगी। इससे निष्कर्ष सरल है। सही संचालन के लिए, आपको इस पहचानकर्ता को अपने आवेदन के लिए विशिष्ट होना चाहिए और स्थायी (आप उपयोग कर सकते हैं, उदाहरण के लिए, बंडल के एक व्युत्पन्न अनुप्रयोग);
• sessionSendsLaunchEvents इंगित करता है कि क्या डेटा ट्रांसफर पूरा होने पर पृष्ठभूमि सत्र को आवेदन शुरू करना चाहिए। यदि यह पैरामीटर false, सेट है false, तो ट्रिगर नहीं होगा, और एप्लिकेशन को अगली बार लॉन्च होने पर सभी ईवेंट प्राप्त होंगे। यदि पैरामीटर true , तो डेटा ट्रांसफर पूरा होने के बाद, सिस्टम एप्लिकेशन को लॉन्च करेगा और संबंधित AppDelegate: application(_:handleEventsForBackgroundURLSession:completionHandler:) विधि को कॉल करेगा AppDelegate: application(_:handleEventsForBackgroundURLSession:completionHandler:) ;
• isDiscretionary सिस्टम को कार्यों को शायद ही कभी निर्धारित करने में सक्षम बनाता है। यह, एक ओर, बैटरी जीवन को बेहतर बनाता है, और दूसरी ओर, यह कार्य को धीमा कर सकता है। या शायद इसे गति दें। उदाहरण के लिए, यदि बड़ी मात्रा में डाउनलोड किया जाता है, तो सिस्टम वाईफाई से कनेक्ट होने तक कार्य को रोक सकता है, और फिर धीमी मोबाइल इंटरनेट खर्च किए बिना जल्दी से सब कुछ डाउनलोड कर सकता है (यदि इसकी अनुमति है, तो आगे क्या है)। यदि कार्य तब बनाया जाता है जब एप्लिकेशन पहले से ही पृष्ठभूमि में होता है, तो यह पैरामीटर स्वचालित रूप से true सेट हो जाता true ;
• AllowCellularAccess - एक पैरामीटर जो दिखाता है कि आप नेटवर्क के साथ काम करने के लिए सेलुलर संचार का उपयोग कर सकते हैं। मैं उसके साथ सावधानी से नहीं खेलता था, लेकिन समीक्षाओं के अनुसार, वहाँ (एक समान सिस्टम स्विच के साथ) बड़ी संख्या में रेक रखी जाती हैं;
• shouldUseExtendedBackgroundIdleMode। एक उपयोगी पैरामीटर जो दिखाता है कि सिस्टम को बैकग्राउंड में जाने पर सर्वर से लंबे समय तक संबंध बनाए रखना चाहिए। नहीं तो कनेक्शन तोड़ दिया जाएगा।
• waitsForConnectivity एक मोबाइल डिवाइस में, कम समय के लिए संचार गायब हो सकता है। इस समय बनाए गए कार्य या तो तब तक निलंबित किए जा सकते हैं जब तक कि कोई कनेक्शन दिखाई न दे, या तुरंत "कोई कनेक्शन नहीं" त्रुटि वापस कर दें। पैरामीटर आपको इस व्यवहार को नियंत्रित करने की अनुमति देता है। यदि यह false, तो संचार की अनुपस्थिति में कार्य तुरंत एक त्रुटि के साथ टूट जाएगा। यदि true , तो एक लिंक दिखाई देने तक प्रतीक्षा करें।
• अंतिम पंक्ति (सत्र आरंभीकरण) में एक महत्वपूर्ण पैरामीटर, प्रतिनिधि होता है। उसके बारे में - थोड़ा और।

डेलिगेट बनाम कॉलबैक

जैसा कि मैंने ऊपर कहा था, एक कार्य / सत्र से घटनाओं को प्राप्त करने के दो तरीके हैं। पहला कॉलबैक है:

 session.dataTask(with: request) { data, response, error in ...   } 

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

एक सत्र के साथ काम करने का दूसरा विकल्प प्रतिनिधि के माध्यम से है । इस स्थिति में, हमें एक वर्ग बनाना होगा जो URLSessionDataDelegate प्रोटोकॉल और (या) अन्य को पास में लागू करता है (विभिन्न प्रकार के कार्यों के लिए प्रोटोकॉल थोड़ा अलग हैं)। इस वर्ग के एक उदाहरण का संदर्भ एक सत्र में रहता है, और इसके तरीकों को बुलाया जाता है जब घटनाओं को प्रतिनिधि को पास किया जाता है। लिंक को इनिशियलाइज़र द्वारा सत्र में पंजीकृत किया जा सकता है। उदाहरण में, self.

 URLSession(configuration: configuration, delegate: self, delegateQueue: nil) 

नियमित सत्रों के लिए, दोनों विधियाँ उपलब्ध हैं। पृष्ठभूमि सत्र केवल एक प्रतिनिधि द्वारा उपयोग किया जा सकता है।

तो, हमने सत्र की स्थापना की, इसे बनाया, आइए देखें कि कुछ कैसे डाउनलोड किया जाए।

पृष्ठभूमि में डेटा डाउनलोड करने की सामान्य योजना

डेटा डाउनलोड करने के लिए, आपको आमतौर पर एक (URLRequest) बनाने की आवश्यकता होती है, इसमें आवश्यक पैरामीटर / हेडर / डेटा दर्ज करते हुए, URLSessionDownloadTask और इसे निष्पादन के लिए चलाएं। कुछ इस तरह:

 var request = URLRequest(...) //  request,   let task = session.downloadTask(with: request) if #available(iOS 11, *) { task.countOfBytesClientExpectsToSend = [approximate size of request] task.countOfBytesClientExpectsToReceive = [approximate size of response] } task.resume() 

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

resume() बाद resume() कार्य निष्पादन पर जाएगा। डेटा ट्रांसफर के दौरान, प्रगति प्रसारित होगी (इसके बारे में - नीचे पढ़ें, वहां भी विकल्प हैं), और पूरा होने के बाद कई प्रतिनिधि तरीकों को निष्पादित किया जाएगा। उनमें से, एक बहुत महत्वपूर्ण है:

 urlSession(_:downloadTask:didFinishDownloadingTo:) 

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

इस महत्वपूर्ण विधि के बाद, एक और विधि को बुलाया जाएगा जहां त्रुटि तब होगी जब यह होती है। यदि कोई error नहीं error , तो error nil. होगी nil.

 urlSession(_:task:didCompleteWithError:) 

और अंत में क्या होता है, अगर आवेदन पृष्ठभूमि में चला गया या पूरा हो गया? डेलिगेट के तरीकों को कैसे कहें? यह यहाँ आसान नहीं है।

यदि एप्लिकेशन द्वारा लॉन्च की गई किसी चीज़ का डाउनलोड समाप्त हो गया है और sessionSendsLaunchEvents फ्लैग सेशन कॉन्फ़िगरेशन में है, तो सिस्टम एप्लिकेशन (पृष्ठभूमि में) लॉन्च करेगा और एप्लिकेशन को कॉल करेगा (_: handleEventsForBorgroundurLSLSession: completeHandler :) विधि AppDelegate, ।

इस विधि में, आवेदन करना चाहिए:

• पूर्णहैंडलर को बचाएं (इसे कुछ समय बाद, अतुल्यकालिक और मुख्य धागे में कॉल करने की आवश्यकता होगी);
• पहले की तरह एक ही पहचानकर्ता के साथ एक पृष्ठभूमि सत्र को फिर से बनाएं (और कई पृष्ठभूमि सत्र होने की स्थिति में इस पद्धति को पारित किया जाता है);
• एक नए बनाए गए सत्र में, प्रतिनिधि (विशेष रूप से, बहुत महत्वपूर्ण urlSession(_:downloadTask:didFinishDownloadingTo:) ) में urlSession(_:downloadTask:didFinishDownloadingTo:) , आपको उन्हें संसाधित करने की ज़रूरत है, जहाँ आप चाहते हैं, फ़ाइलों की प्रतिलिपि बनाएँ;
• सभी विधियों को कॉल करने के बाद, एक और प्रतिनिधि विधि को कहा जाता है, जिसे urlSessionDidFinishEvents(forBackgroundURLSession:) कहा जाता है और जिसमें आपको पहले urlSessionDidFinishEvents(forBackgroundURLSession:) को कॉल करना होगा completionHandler.

यह महत्वपूर्ण है। DispatchQueue.main.async(...) का उपयोग करके मुख्य थ्रेड में DispatchQueue.main.async(...) को कॉल करना आवश्यक है।

उसी समय, आपको यह याद रखना होगा कि यह सब उस एप्लिकेशन में होता है जो पृष्ठभूमि में काम करता है। और इसका मतलब यह है कि संसाधन (निष्पादन समय) सीमित हैं। उन फ़ाइलों को जल्दी से सहेजें जहाँ आपको ज़रूरत है, आवेदन में आवश्यक अवस्थाओं को बदलें और बंद करें - यह सब किया जा सकता है। यदि आप अधिक करना चाहते हैं, तो आप UIApplication.beginBackgroundTask() या नए बैकग्राउंड UIApplication.beginBackgroundTask() उपयोग कर सकते हैं।

सामान्य पृष्ठभूमि डेटा भेजने की योजना

सर्वर पर फाइलें अपलोड करना भी प्रतिबंधों के साथ काम करता है। हालाँकि, यह सभी एक समान तरीके से शुरू होता है: हम एक अनुरोध बनाते हैं, एक कार्य बनाते हैं (अब यह URLSessionUploadTask) होगा URLSessionUploadTask) , कार्य चलाएँ। क्या समस्या है?

समस्या यह है कि हम अनुरोध कैसे बनाते हैं। आमतौर पर हम भेजे गए डेटा को डेटा के रूप में बनाते हैं। पृष्ठभूमि URLSession, यह नहीं जानता कि इसके साथ कैसे काम किया जाए। और एक स्ट्रीमिंग अनुरोध ( uploadTask(withStreamedRequest:) ) के साथ यह भी नहीं पता कि कैसे। यह सब कुछ लिखना आवश्यक है जो एक फ़ाइल को भेजने की आवश्यकता है, और फ़ाइल से एक भेजें कार्य बनाएं। यह इस तरह से किसी भी तरह बाहर निकलता है:

 var fileUrl = methodThatSavesFileAndRetursItsUrl(...) var request = URLRequest(...) let task = session.uploadTask(with: request, fromFile: fileUrl) task.resume() 

लेकिन आकार को पंजीकृत करने की आवश्यकता नहीं है, URLSession इसे स्वयं देख सकता है। भेजने के बाद, वही प्रतिनिधि विधि urlSession(_:task:didCompleteWithError:) डाउनलोड करते समय urlSession(_:task:didCompleteWithError:) । और ठीक उसी तरह, यदि एप्लिकेशन भेजने की प्रक्रिया के दौरान बैकग्राउंड में चला गया या चला गया, तो application(_:handleEventsForBackgroundURLSession:completionHandler:), आ जाएगा application(_:handleEventsForBackgroundURLSession:completionHandler:), जिसे डेटा डाउनलोड करते समय समान नियमों के अनुसार ही संसाधित करना होगा।

एक आवेदन पूरा क्या है?

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

• सबसे पहले, केवल एप्लिकेशन को बंद करना (होम बटन दबाकर या एक उचित इशारा करके) काम नहीं करेगा। यह एप्लिकेशन को नहीं मारेगा, लेकिन केवल इसे पृष्ठभूमि पर भेजें। पृष्ठभूमि सत्र के साथ काम करने का अर्थ यह है कि यह तब भी काम करता है जब आवेदन "पूरी तरह से, पूरी तरह से" मारा गया हो;
• दूसरी बात, यह असंभव है कि एक डिबगर (AppCode, Xcode या सिर्फ LLDB) जुड़ा हुआ है, यह "बंद" होने के कुछ समय बाद भी एप्लिकेशन को मरने नहीं देगा;
• तीसरा, आप टास्कबार (कार्य प्रबंधक, डबल होम या धीमी गति से "ऊपर") से आवेदन को नहीं मार सकते। इस प्रकार, एक मारे गए एप्लिकेशन को "स्थायी रूप से" मारा जाना माना जाता है और सिस्टम बंद हो जाता है, इस तरह की कार्रवाई के साथ, आवेदन से जुड़े पृष्ठभूमि सत्र;
• चौथा, आपको एक वास्तविक डिवाइस पर इस प्रक्रिया का परीक्षण करने की आवश्यकता है। लॉगिंग (नीचे देखें) के साथ कोई समस्या नहीं है और यह अधिक डीबग किया गया है। यह तर्क दिया जाता है कि सिम्युलेटर को भी उसी तरह काम करना चाहिए जैसा वह करना चाहिए। लेकिन मैंने अकथनीय विषमताओं पर ध्यान दिया कि मैं किसी चीज़ के साथ व्याख्या नहीं कर सकता लेकिन सिम्युलेटर की गड़बड़ है। सामान्य तौर पर, डिवाइस पर परीक्षण;
• एकमात्र उचित तरीका है कि आप जो चाहते हैं वह exit(int) फ़ंक्शन के साथ है। जैसा कि सभी जानते हैं, आप इसे सर्वर पर अपलोड नहीं कर सकते हैं ( यह सीधे आवश्यकताओं का खंडन करता है ), लेकिन अभी के लिए हम सिर्फ परीक्षण कर रहे हैं - यह डरावना नहीं है। मैं इस फ़ंक्शन का उपयोग करने के लिए दो उचित विकल्प जानता हूं:
  
  • इसे स्वचालित रूप से AppDelegate.applicationDidEnterBackground(_:) विधि में कॉल करें ताकि स्प्रिंगबोर्ड से बाहर निकलने के तुरंत बाद आवेदन को मार दिया जाए;
  • इंटरफ़ेस में एक घटक बनाएं (उदाहरण के लिए, एक बटन, या एक इशारे पर एक क्रिया लटकाएं), जिस पर क्लिक करके, exit(...).
    इस मामले में, एप्लिकेशन को मार दिया जाएगा, और नेटवर्क के साथ पृष्ठभूमि का काम जारी रहना चाहिए। और, कुछ समय बाद, हमें application(_:handleEventsForBackgroundURLSession:completionHandler:). कॉल करना चाहिए application(_:handleEventsForBackgroundURLSession:completionHandler:).

यदि आप Xcode डिबग कंसोल का उपयोग नहीं कर सकते हैं तो आवेदन कैसे लॉग करें?

खैर, यह असंभव है। आप कर सकते हैं, यदि आप वास्तव में चाहते हैं। आप Xcode से शुरू नहीं कर सकते हैं, और यदि अनुप्रयोग, उदाहरण के लिए, पहले से ही सिस्टम ईवेंट के कारण पुनरारंभ हो गया है, तो आप एप्लिकेशन को संलग्न कर सकते हैं (प्रक्रिया के लिए संलग्न कर सकते हैं)। लेकिन यह समाधान इतना है, तो आपको किसी भी तरह खुद को पुनरारंभ करने की प्रक्रिया का परीक्षण करने की आवश्यकता है।

आप प्रोटोकॉल (लॉग, लॉग) का उपयोग कर सकते हैं। उनके कार्यान्वयन के लिए कई विकल्प हैं:

• print. इसका उपयोग अक्सर "चलो जल्दी से कुछ पाने दो" के रूप में किया जाता है। हमारे मामले में, इसका उपयोग करना असंभव है, क्योंकि हमारे पास डिवाइस पर कंसोल तक पहुंच नहीं है, एप्लिकेशन को मार दिया गया है।
• NSLog. यह काम करेगा, क्योंकि यह तीसरी विधि का उपयोग करता है।
• os_log. सबसे सही विधि जो आपको लॉग को ठीक से कॉन्फ़िगर करने की अनुमति देती है, उन्हें वांछित प्रकार से चिपकाएं, डिबगिंग के बाद अक्षम करें, कोड को स्वयं काटे बिना, और इसी तरह।

चेतावनी! os_log साथ समस्याएं हैं (उदाहरण के लिए, डिबग लॉग की कमी) जो केवल सिम्युलेटर में खेला जाता है, लेकिन इस डिवाइस पर नहीं खेला जाता है। डिवाइस का उपयोग करें।

os_log, का उपयोग कैसे करें os_log, इसे Apple दस्तावेज़ीकरण में सही तरीके से कॉन्फ़िगर करने का तरीका पढ़ें। विशेष रूप से, आपको debug और info लॉग को सक्षम करना चाहिए, डिफ़ॉल्ट रूप से वे छिपे हुए हैं।

डेटा डाउनलोड करने या भेजने की प्रगति पर नज़र रखना

डेटा ट्रांसफर की प्रक्रिया में, मैं समझना चाहता हूं कि कितना भेजा जा चुका है, कितना बाकी है। ऐसा करने के दो तरीके हैं। पहला प्रतिनिधि विधियों का उपयोग करना है:

• भेजने के लिए, आपको urlSession(_:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:) का उपयोग करने की आवश्यकता है
• डाउनलोड करने के लिए एक समान urlSession(_:downloadTask:didWriteData:totalBytesWritten:totalBytesExpectedToWrite:) विधि है urlSession(_:downloadTask:didWriteData:totalBytesWritten:totalBytesExpectedToWrite:)

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

दूसरी विधि अधिक रोचक है। तथ्य यह है कि प्रत्येक कार्य टाइप Progress की वस्तु प्रदान करता है (यह फील्ड task.progress में निहित है), जो डेटा ट्रांसफर प्रक्रिया सहित एक मनमानी प्रक्रिया की निगरानी करने की क्षमता प्रदान करता है। वह कैसे दिलचस्प है? दो बातें:

• Progress वस्तुओं से आप एक कार्य निष्पादन ट्री बना सकते हैं, जिसमें से प्रत्येक नोड दिखाएगा कि इसमें शामिल सभी कार्य कितने उन्नत हैं। उदाहरण के लिए, यदि आपको पांच फाइलें भेजने की आवश्यकता है, तो आप प्रत्येक के लिए प्रगति ले सकते हैं, सामान्य प्रगति कर सकते हैं, इसमें पांच अन्य जोड़ सकते हैं, और एक की निगरानी कर सकते हैं, माता-पिता की प्रगति, इसके अपडेट को कुछ इंटरफ़ेस तत्व से जोड़ सकते हैं;
• आप इस पेड़ में अपनी प्रगति जोड़ सकते हैं, और आप अतिरिक्त प्रगति के साथ जुड़े कार्यों को रोक और रद्द भी कर सकते हैं।

यह पृष्ठभूमि डाउनलोड करने या डेटा भेजने से कैसे संबंधित है? कोई रास्ता नहीं। प्रतिनिधि विधियों को नहीं बुलाया जाता है, और जब अनुप्रयोग समाप्त हो जाता है, तो प्रगति की वस्तु मर जाती है। पृष्ठभूमि सत्रों के लिए, यह विधि उपयुक्त नहीं है।

एक नियमित सत्र से एक पृष्ठभूमि सत्र के लिए "स्थानांतरण" कार्य

वैसे, पृष्ठभूमि सत्रों के साथ काम करना अधिक कठिन है। लेकिन यह सुविधाजनक है! एक भी कार्य खो नहीं जाएगा, क्या हम कभी भी हमारे द्वारा अनुरोधित सभी डेटा प्राप्त करेंगे, हमेशा पृष्ठभूमि सत्र का उपयोग क्यों नहीं करते हैं?

दुर्भाग्य से, उसकी खामियां हैं, और गंभीर हैं। उदाहरण के लिए, एक पृष्ठभूमि सत्र धीमा है। मेरे प्रयोगों में, गति कई बार भिन्न हुई। दूसरे, किसी कार्य की पृष्ठभूमि निष्पादन में देरी हो सकती है (विशेष रूप से यदि isDiscretionary पैरामीटर isDiscretionary , जो, जैसा कि मैंने उल्लेख किया है, पृष्ठभूमि में एप्लिकेशन चलने के दौरान बनाए गए कार्यों के लिए हमेशा true होता true ।

इसलिए, हर बार जब आप कोई कार्य बनाते हैं, तो आपको यह समझने की आवश्यकता होती है कि इसके कार्य के लिए क्या मापदंड हैं, जहां इसे जोड़ना है, नियमित या पृष्ठभूमि सत्र के लिए। सामान्य तेजी से चलता है, तुरंत शुरू होता है। पृष्ठभूमि - अब, तुरंत नहीं, लेकिन उपयोगकर्ता द्वारा एप्लिकेशन को बंद करने पर उसे नहीं मारा जाएगा।

यदि कोई स्पष्ट समझ नहीं है कि कार्य पृष्ठभूमि सत्र में किया जाना चाहिए (उदाहरण के लिए, बहुत बड़ी मात्रा में डेटा का गैर-महत्वपूर्ण हस्तांतरण, जैसे कि सिंक्रनाइज़ेशन या बैकअप), तो यह निम्नानुसार करने योग्य है:

• कार्य को नियमित सत्र में शुरू करें। इस स्थिति में, पृष्ठभूमि को चलाएं ताकि सिस्टम समझता है कि हमें कार्य पूरा करने के लिए समय की आवश्यकता है। यह कुछ समय (कई मिनट तक) देता है, लेकिन iOS 13 में कुछ टूट गया था और यह स्पष्ट नहीं है कि इसके साथ क्या हो रहा है) ताकि कार्य पूरा हो सके।
• यदि इसके पास समय नहीं है, तो पृष्ठभूमि के अंत में हम कार्य को एक नियमित सत्र से एक पृष्ठभूमि पर स्थानांतरित करते हैं, जहां यह काम करना जारी रखता है, और जब यह समाप्त हो सकता है।

ट्रांसफर कैसे करें? कोई रास्ता नहीं। बस सामान्य कार्य को मारें (रद्द करें), और समान (समान अनुरोध के साथ) पृष्ठभूमि बनाएं। इसे "स्थानांतरण" क्यों कहा जाता है? और उद्धरण चिह्नों में क्यों?

डेटा भेजने के लिए कोई हस्तांतरण नहीं है। जैसा वर्णित है वैसा ही है। उन्होंने एक कार्य को मार दिया, दूसरे को लॉन्च किया, पहली बार भेजे गए सभी डेटा खो गए थे।

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

यहाँ नमूना कोड है जो यह करता है:

 let request = URLRequest(url: url) let task = foregroundSession.downloadTask(with: request) let backgroundId = UIApplication.shared.beginBackgroundTask { task.cancel() let task = backgroundSession.downloadTask(with: request) task.resume() } task.resume() 

यदि expirationHandler से पहले कार्य समाप्त हो जाता है, तो आपको UIApplication.shared.endBackgroundTask(backgroundId) को कॉल करना याद रखना चाहिए। यह प्रलेखन में अधिक विस्तार से वर्णित है।

सिस्टम को डाउनलोड करना जारी रखने में मदद करने के लिए (उदाहरण के लिए, रद्द करना अस्थायी फ़ाइल को पृष्ठभूमि डाउनलोड फिर से शुरू होने से पहले हटा दिया जा सकता है), वहाँ विशेष तरीके हैं:

• नवीनीकरण के लिए आवश्यक डेटा प्राप्त करने के लिए, आपको पिछले कार्य को रद्द करने की विधि का उपयोग करके रद्द करना होगा (byProducingResumeData :) ;
• , : downloadTask(withResumeData:) -> URLSessionDownloadTask , - :

 let request = URLRequest(url: url) let task = foregroundSession.downloadTask(with: request) let backgroundId = UIApplication.shared.beginBackgroundTask { task.cancel { data in let task: URLSessionDownloadTask if let data = data { task = backgroundSession.downloadTask(withResumeData: data) } else { task = backgroundSession.downloadTask(with: request) } task.resume() } } 

,

लॉग

— , . — , . background , .

, , background -, , , ( UI, ). , , — . , — , , os_log. ( NSLog)

-

- , . , - . , , , ( ) . , , -, , . — — , . — , - ( ), , .

. ( ), . , , , .

प्रतिबंध

:

• , ;
• — , ;
• , (, …);

• , (task.taskIdentifier) , (Dictionary). , 1, .
• , URLSession.getAllTasks . , background . , . , . ¯\_(ツ)_/¯
• , , , , .

, background , . , - . : https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple_ref/doc/uid/TP40014214-CH21-SW1 . , :

If your app extension initiates a background NSURLSession task, you must also set up a shared container that both the extension and its containing app can access. Use the sharedContainerIdentifier property of the NSURLSessionConfiguration class to specify an identifier for the shared container so that you can access it later.