簡體   English   中英

URLSession.shared.dataTask vs dataTaskPublisher,什么時候用?

[英]URLSession.shared.dataTask vs dataTaskPublisher, when to use which?

我最近遇到了兩個數據獲取(下載)API,它們對我執行看似相同的事情。 我不知道什么時候應該使用一個而不是另一個。

我可以使用URLSession.shared.dataTask

    var tasks: [URLSessionDataTask] = []

    func loadItems(tuple : (name : String, imageURL : URL)) {
        let task = URLSession.shared.dataTask(with: tuple.imageURL, completionHandler :
        { data, response, error in
            guard let data = data, error == nil else { return }
            DispatchQueue.main.async() { [weak self] in
                self?.displayFlag(data: data, title: tuple.name)
            }
        })
        tasks.append(task)
        task.resume()
    }

    deinit {
        tasks.forEach {
            $0.cancel()
        }
    }

或者我可以使用URLSession.shared.dataTaskPublisher

    var cancellables: [AnyCancellable] = []

    func loadItems(tuple : (name : String, imageURL : URL)) {
        URLSession.shared.dataTaskPublisher(for: tuple.imageURL)
            .sink(
                receiveCompletion: {
                    completion in
                    switch completion {
                    case .finished:
                        break
                    case .failure( _):
                        return
                    }},
                receiveValue: { data, _ in DispatchQueue.main.async { [weak self] in self?.displayFlag(data: data, title: tuple.name) } })
            .store(in: &cancellables)
    }

    deinit {
        cancellables.forEach {
            $0.cancel()
        }
    }

我沒有看到它們的明顯區別,因為兩者都可以獲取,並且都為我們提供了輕松取消任務的能力。 有人可以闡明他們在何時使用哪個方面的差異嗎?

第一個是經典。 它已經存在了很長一段時間,並且大多數(如果不是全部)開發人員都熟悉它。

第二個是第一個的包裝器,並允許將其與其他發布者組合(例如,僅在執行前兩個請求時才執行某些請求)。 使用第一種方法組合數據任務要困難得多。

所以在一個要點中:將第一個用於一次性請求。 當需要更多邏輯來將結果與/傳遞給其他發布者(不僅來自 URLSession)時,請使用第二個。 這基本上是Combine 框架背后的想法——您可以組合不同方式的異步機制(利用回調的數據任務就是其中之一)。

更多信息可以在去年的 WWDC 視頻中找到,介紹聯合收割機。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM