我希望用戶在離開應用程式時繼續在前臺啟動的上傳操作。Apple 的文章Extending Your App's Background Execution Time有以下代碼清單
func sendDataToServer( data : NSData ) {
// Perform the task on a background queue.
DispatchQueue.global().async {
// Request the task assertion and save the ID.
self.backgroundTaskID = UIApplication.shared.
beginBackgroundTask (withName: "Finish Network Tasks") {
// End the task if time expires.
UIApplication.shared.endBackgroundTask(self.backgroundTaskID!)
self.backgroundTaskID = UIBackgroundTaskInvalid
}
// Send the data synchronously.
self.sendAppDataToServer( data: data)
// End the task assertion.
UIApplication.shared.endBackgroundTask(self.backgroundTaskID!)
self.backgroundTaskID = UIBackgroundTaskInvalid
}
}
呼叫self.sendAppDataToServer( data: data)方式不清楚。這是上傳操作會去的地方Dispatch.global().sync { }嗎？
uj5u.com熱心網友回復：
您在 Apple 的檔案中偶然發現了一個不太出色的代碼示例。
首先，如果您執行同步網路請求，您絕對應該將其分派到后臺佇列。如果不這樣做，您就有可能讓看門狗行程殺死您的應用程式。但是你不應該同步地將網路請求分派到全域佇列，而是異步地，否則你最終會遇到同樣的問題，即阻塞主執行緒。
話雖如此，人們真的不應該同步執行網路請求。您應該異步執行它們并在完成處理程式中結束后臺任務。
在那個例子中，他們使用
NSData，我們不再使用它。也
UIBackgroundTaskInvalid已經不存在了。現在是UIBackgroundTaskIdentifier.invalid。在 Apple 的辯護中，此代碼示例的重點是后臺任務，而不是網路代碼。他們真的不想陷入這個網路代碼實作的雜草中，并試圖讓它保持簡單。話雖如此，這確實是一個可怕且過時的代碼示例。
有關如何使用后臺任務的更好示例，請參閱此答案。此外，如果上傳可能需要超過 30 秒，我們根本不會使用后臺任務，而是使用適當（但更復雜）的背景URLSession。（請參閱在后臺下載檔案。上傳任務遵循那里概述的相同基本模式，但請確保從檔案上傳，而不是從Data.）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/362666.html