음 저번에 DispatchQueue는 왜 사용했냐는 질문 받고, 내가 잘못 사용한 부분이 있는거 같아. 확인해 보았다. 백그라운드에서 돌리려고 해서 사용한거긴한데, configuration 방법이 있긴하더라 찾아보니.
DispatchQueue.global(qos: .utility).async( execute: {
if let url = URL(string : urlAddress){
var request = URLRequest(url: url)
request.httpMethod = "GET"
URLSession.shared.dataTask(with : request){ data ,res ,err in
Dispatchqueue.gloabal이 없어도 되지 않냐는 질문이였는데, 내가 다른 부분이랑 햇갈려서 추가했다. 안드로이드는 확실히 UI 작업을 제외한 작업은 백그라운드에서 해야했다 생각한다.
하지만 어쨌든 스위프트도 UI 작업 자체는 메인에서 하도록 되어있긴하다.
그런데 아래처럼 했더니 됐다.
//DispatchQueue(label: "com.gcd.simpleQueue", qos: .userInitiated, attributes: .concurrent).async( execute: {
if let url = URL(string : urlAddress){
var request = URLRequest(url: url)
request.httpMethod = "GET"
URLSession.shared.dataTask(with : request){ data ,res ,err in
그리고 UrlSession에 대해 더찾아 봤다.
[https://devmjun.github.io/archive/URLsession]
URLSession HTTP 요청을 보내고 받는 핵심 객체 입니다. 제공되는 URLSessionConfiguration을 통해 다음 세가지 유형의 URL을 생성합니다.
- .default: 디스크 지속(disk-persisted) 전역 캐시, 자격 증명(credential) 과 쿠기 저장 객체를 사용하는 기본 구성 객체(default configuration object)를 생성합니다.
- .ephemeral: 모든 세션관련 데이터가 메모리에 저장된다는 점을 제외하고는 기본 구성(default configuration)과 다릅니다. 비공개(private) 새션이라고 생각하세요.
- .background: 새션은 업로드와 다운로드를 백그라운드에서 이행합니다. 앱 그 자체가 일시중지(suspended) 되거나 시스템에 의해 종료되는(terminated by the system) 경우에도 전송이 계속됩니다.
또한 URLSessionConfiguration은 시간 초과(timeout)값, 캐싱 정책, HTTP 헤더와 같은 세션 속성을 구성할수 있습니다. configuration의 옵션을 documentation을 참조해주세요
URLSessionTask는 작업 객체(task object)를 나타내는 추상 클래스 입니다. 세션은 데이터를 가져오거나 파일을 업로드, 다운로드 하는 실제 작업을 수행하는 하나 이상의 테스크를 생성합니다.
세가지 유형의 구체적인 session tasks가 있습니다.
- URLSessionDataTask: 서버에서 메모리로 데이터를 검색하는 HTTP GET요청에 이 테스크를 사용합니다.
- URLSessionUploadTask: 전형적으로 HTTP POST, PUT 매소드를 통해서 디스크에서 웹서버로 파일을 전송할때 이 테스크를 사용하세요.
- URLSessionDownloadTask: 임시의 파일 위치로 원격 서버에서 파일을 다운로드할때 이 테스크를 사용하세요
테스크를 일시정지(suspend), 재개(resume), 취소(cancel) 할수 있습니다. URLSessionDownloadTask는 향후에 재개(resumeption) 하기 위해 일시 정지(pause) 할수 있는 추가기능이 있습니다.
일반적으로, URLSession두개의 방법으로 데이터를 반환합니다: 성공 또는 실패 작업이 끝낫을때 completion handler를 통해서 전달하거나, 세션을 만들때 설정했던 delegate 매소드를 호출하여 데이터를 반환합니다
내가 사용한 shared가 뭔지 잘 모르고 사용한거 같아서 다시 찾아봤다.
[https://developer.apple.com/documentation/foundation/urlsession/1409000-shared]
Type Property
shared
The shared singleton session object.
Declaration
class var shared: URLSession { get }
Discussion
For basic requests, the URLSession class provides a shared singleton session object that gives you a reasonable default behavior for creating tasks. Use the shared session to fetch the contents of a URL to memory with just a few lines of code.
Unlike the other session types, you don’t create the shared session; you merely access it by using this property directly. As a result, you don’t provide a delegate or a configuration object.
기본 요청들에 대해, URLSession 클래스는 공유되는 싱글톤 세션 객체를 제공합니다, 세션 객체는 타스크를 생성하는데 합리적인 초기 행동을 제공합니다. 공유되는 세션을 사용해서 url의 콘텐트를 메모리로 가져오도록 합니다. 다른 세션 타입들과 다르게, 우리는 공유 세션을 만들지 않습니다; 우리는 단순히 이 프로퍼티를 사용해 직접적으로 접근합니다. 결과적으로 우리는 델리게이트 또는 설정 객체를 제공하지 않아도 됩니다.
음 그러니까 싱글톤 공유 세션 객체를 사용할 수 있게 해준다는거 같다. 세션 객체를 다른식으로 만들고 사용해도 되나보다.
Limitations of the Shared Session
Because the shared session has neither a delegate nor a customizable configuration object, the shared session has important limitations:
-
You can’t obtain data incrementally as it arrives from the server.
-
You can’t significantly customize the default connection behavior.
-
Your ability to perform authentication is limited.
-
You can’t perform background downloads or uploads when your app isn’t running.
The shared session uses the shared URLCache, HTTPCookieStorage, and URLCredentialStorage objects, uses a shared custom networking protocol list (configured with registerClass(_:) and unregisterClass(_:)), and is based on a default configuration.
In general, when working with a shared session, you should avoid customizing the cache, cookie storage, or credential storage (unless you are already doing so with NSURLConnection). There’s a good chance that you’ll outgrow the capabilities of the default session, at which point you’ll have to rewrite all of those customizations to work with your custom URL sessions.
In other words, if you’re doing anything with caches, cookies, authentication, or custom networking protocols, you should probably be using a default session instead of the shared session.
음 URLSession과 URLSessionTask를 구분할 필요가 있는거 같다.
shared와 URLSessionConfiguration들은 URLSession에서 설정하는것이고
URLSessionTask에서는 URLSessionDataTask, URLSessionloadTask, URLSessionDownloadTask인 3가지 session tasks가 있따. 그리고 URLSessionTask에서 resume,cancel,suspend 등이 진행되는 것이다.
URLSession HTTP 요청을 보내고 받는 핵심 객체 입니다. 제공되는 URLSessionConfiguration을 통해 다음 세가지 유형의 URL을 생성합니다.
URLSessionTask는 작업 객체(task object)를 나타내는 추상 클래스 입니다. 세션은 데이터를 가져오거나 파일을 업로드, 다운로드 하는 실제 작업을 수행하는 하나 이상의 테스크를 생성합니다.
클래스의 책임 범위를 완벽히 이해하지 못하겠다. 음 그보다는 URLSession과 URLSessionTask가 백그라운드 상에서 어떻게 관리될지 잘 모르겠다.??
이 부분은 URLSessionTask가 내부적으로 어떻게 작동하는지 더 알아봐야 할거같다. 그리고 멀티 타스킹 관점에서 어떻게 작동되는지 이 두가지를 알아봐야 할거 같다.
[https://developer.apple.com/documentation/foundation/url_loading_system/fetching_website_data_into_memory] 애플 문서에 fetching website data into memory라는 문서가 있다. 이걸 먼저 볼걸
그리고 해당 검색어로 urlsessiondatatask and multi tasking 검색하니 세션 타스크를 멀티타스킹하려는 시도들이 많이 보인다. [https://www.google.com/search?q=urlsessiondatatask+and+multi+tasking&rlz=1C5CHFA_enKR834KR834&oq=urlsessiondatatask+and+multi+tasking&aqs=chrome..69i57.10909j0j9&sourceid=chrome&ie=UTF-8]
그리고 내가 약간 생각한 방법은 , 진행도가 내장 변수로 있던데, 진행도에 따라 취소를 결정하면 더 효율적일것 같다. 취소해도 다음 타스크가 바로 안되는거 같다는게 문제지만. suspend만 할게 아니라 resume도 해야되나.
'ios개발' 카테고리의 다른 글
<ios개발> 프레임워크, 라이브러리, sdk 구분. (0) | 2020.04.28 |
---|---|
<WWDC> 2014 - Swift Introduction (0) | 2020.04.22 |
<디자인 패턴> 디자인 패턴이란? 2편 (0) | 2020.04.20 |
<ios 운영체제> GCD - grand central disptach queue (0) | 2020.04.09 |
<ios framework> ios 이미지 최적화, UIKit (0) | 2020.04.07 |