졀니의 개발 공부✨

[iOS/WWDC23] SwiftData 마이그레이션

김졀니 — Tue, 25 Feb 2025 10:12:29 +0900

Migration

프로퍼티를 수정하거나 추가 및 삭제를 수행하게 되면 새 버전을 출시할 때 마이그레이션 과정을 거쳐야 한다.

SwiftData는 이러한 마이그레이션 과정을 간단하게 처리할 수 있는 도구를 제공한다.

마이그레이션 과정

1️⃣ VersionSchema를 통해 모델 캡슐화

SwiftData 모델이 변경된 앱의 새 버전을 출시할 때 마다 새로운 VersionedSchema를 정의한다.

enum TripSchemaV1: VersionedSchema {
    static var versionIdentifier: Schema.Version
    static var models: [any PersistentModel.Type]
}

VersionedSchema 는 각 버전의 스키마를 캡슐화 한다.
각 버전이 VersionedSchema 로 정의되어야 버전 사이에 어떤 변화가 있었는지 알 수 있다.
versionIdentifier 로 해당 버전 정보를 설정하고, models 에 현재 버전에 포함된 모델을 설정한다.
열거형 내부에 해당 버전의 스키마를 포함한다.

2️⃣ SchemaMigraionPlan 생성

SchemaMigrationPlan 을 통해 마이그레이션 과정을 정의한다.
SwiftData가 필요한 마이그레이션을 순서대로 수행하게 된다.

schemas 로 포함되어야 하는 모델을 정의한다.
stages 를 통해 두 버전 사이에 변경 사항을 처리한다.
Migration Stage
- Lightweight
  - 특정 프로퍼티에 originalName 을 추가하거나 관계에서 삭제규칙을 지정하는 등의 가벼운 변경에 적합
- Custom
  - 프로퍼티에 고유성 제약을 추가하는 등의 변경

3️⃣ ModelContainer 의 migrationPlan 매개변수에 마이그레이션 작업을 설정하면 완료된다.

let container = try? ModelContainer(for: Trip.self, migrationPlan: SampleMigrationPlan.self)

참고

https://developer.apple.com/videos/play/wwdc2023/10195

Model your schema with SwiftData - WWDC23 - Videos - Apple Developer

Learn how to use schema macros and migration plans with SwiftData to build more complex features for your app. We'll show you how to...

developer.apple.com

[iOS/WWDC23] SwiftData에 대해 알아보자

김졀니 — Thu, 20 Feb 2025 16:08:51 +0900

SwiftData는 데이터모델링과 관리 프레임워크이다.
다른 포멧은 제외하고 코드에만 집중하며 Swift 매크로를 통해 매끄러운 API를 만든다.

Schema 구성요소

@Model

스키마 정의하는 매크로
값 프로퍼티가 속성으로 사용되도록 적응시킨다.
기본 타입과 Struct, Enum Codable등 가능
@Attribute를 통해 제약조건 추가 가능
@Relationship으로 삭제 규칙 지정 가능
@Transient로 특정 프로퍼티를 포함하지 않도록 할 수 있음

import SwiftData

@Model
class Trip {
    var name: String
    var destination: String
    var startDate: Date
    var bucketList: [BucketListItem]? = []
    var livingAccommodation: LivingAccommodation?
}

@Attribute

✔️ .unique

기본 키를 지정하기 위해서는 Attribute의 .unique 옵션을 사용할 수 있다.

✔️ originalName

@Model
class Trip {
    @Attribute(.unique) var name: String
    var destination: String
    var start_Date: Date
    var end_Date: Date
}

위의 스키마에서 start_Date , end_Date 프로퍼티 이름의 밑줄을 없애고 싶어 변경하게 되면 이미 생성된 스키마에서 새로운 프로퍼티를 생성하게 된다.

이 프로퍼티를 유지하면서 이름을 변경하고싶다면 기존 이름과 프로퍼티 이름을 매핑해줄 수 있다.

@Model
class Trip {
    @Attribute(.unique) var name: String
    var destination: String
    @Attribute(originalName: "start_Date") var startDate: Date
    @Attribute(originalName: "end_Date") var endDate: Date
}

기존 이름을 매핑하여 데이터 손실을 막을 수 있고, 앱 업데이트 시 간단한 마이그레이션을 보장하게 된다.

@Relationship

스키마 간의 관계를 설정하고, deleteRule 을 통해 삭제 규칙을 적용할 수 있다.

.cascade
- 부모 객체가 삭제되면 관련된 자식 객체도 삭제된다.
.nullify
- 부모 객체가 삭제되면, 관계만 해제하고 자식 객체는 Nil이 된다.
.deny
- 자식 객체가 존재하면 부모 객체는 삭제될 수 없다.

@Relationship(deleteRule: .cascade)
var bucketList: [BucketListItem]? = []

@Relationship(deleteRule.cascade)
var livingAccommodation: LivingAccommodation?

@Transient

@Transient 로 지정된 프로퍼티는 데이터를 SwiftData에 저장하지 않고, 런타임 동안에만 유지된다.

@Transient
var tripView: Int = 0

반드시 기본 값이 지정되어 있어야 한다.

ModelContainer

데이터 저장소 관리

스키마와 저장 데이터간의 관계를 관리
데이터가 메모리 또는 디스크에 저장되도록 저장 방식 관리
버전 관리, 마이그레이션, 그래프 분리 같은 스토리지 운영 관리

let container = try ModelContainer(
    for: [ Trip.self, LivingAccommodation.self ],
    configuration: ModelConfiguration(url: URL("path"))
)

SwiftUI에서 .modelContainer(for: ) modifier를 사용하여 컨테이너를 쉽게 주입할 수 있다.
WindowGroup에 ModelContainer를 설정하면 그 안의 모든 뷰가 같은 컨테이너를 사용할 수 있다.

ModelConfiguration

데이터가 저장되는 위치를 제어
- 일시적인 데이터는 메모리에, 영구적인 데이터는 디스크에 저장
특정 파일의 URL을 사용하거나, 그룹 컨테이너 권한 등 응용프로그램의 권한을 통해 URL 생성
데이터를 읽기 전용 모드로 로드하여 민감한 데이터나 템플릿 데이터의 수정을 방지
두 개 이상의 CloudKit 컨테이너를 사용하는 응용프로그램은 ModelConfiguration의 일부로 지정할 수 있다.

let fullSchema = Schema([
    Trip.self,
    BucketListItem.self,
    LivingAccommodations.self,
    Person.self,
    Address.self
])

let trips = ModelConfiguration(
    schema: Schema([
        Trip.self,
        BucketListItem.self,
        LivingAccommodations.self
    ]),
    url: URL(filePath: "/path/to/trip.store"),
        cloudKitDatabase: .private("com.example.trips")
)

let people = ModelConfiguration(
    schema: Schema([Person.self, Address.self]),
    url: URL(filePath: "/path/to/people.store"),
    cloudKitDatabase: .private("com.example.people")
) 

let container = try? ModelContainer(
    for: fullSchema, 
    configurations: trips, people
)

fullSchema 를 통해 프로젝트 내에서 사용하기 위한 스키마를 정의한다.
ModelConfiguration 을 통해 서로 다른 저장 위치에서 스키마를 불러온다.
최종적으로 스키마와 configuration을 결합하여 ModelContainer를 구성할 수 있다.

위와 같이 형성한 ModelContainer는 modifier를 통해 SwiftUI 뷰에 주입할 수 있다.

var body: some Scene {
    WindowGroup {
        ContentView()
    }
    .modelContainer(container)
}

ModelContext

데이터 변경을 처리하는 컨텍스트

모델의 변경사항을 추적하고, 데이터를 저장하거나 삭제하는 기능을 제공한다.
컨테이너가 설정되면 ModelContext로 데이터를 가져와 저장할 준비를 할 수 있다.
rollback과 reset기능을 지원하여 캐싱된 상태를 지울 수 있다.
자동 저장

Context 주입

View나 Scene에서 .modelContainer 를 통해 주입하면, 컨테이너의 mainContext 에 modelContext 키를 바인딩 한다.

MainContext는 특수한 MainActor 정렬 모델 컨텍스트로, Scene이나 View에서 ModelObject와 함께 작동한다.

struct ContextView: View {
    @Environment(\.modelContext) private var context
}

Context 접근

@Environment(\.modelContext) 를 사용하여 SwiftUI View 코드에서 모델의 쿼리에 쓰인 컨텍스트에 쉽게 접근할 수 있다.

@Environment(\.modelContext) 는 기존 데이터의 변경사항을 추적할 수 있다.

struct ContentView: View {
    @Query var trips: [Trip]
    @Environment(\.modelContext) private var context
    var body: some View {
        ...
        Button {
            modelContext.delete(trip)
        } label: {
            Label("Delete", systemImage: "trash")
        }
    }
}

모델에 변경사항이 생기면 스냅샷으로 ModelContext에 기록된다. 계속해서 변경사항을 추적하다가 context.save() 를 호출하면 멈춘다.

→ 즉, 데이터를 삭제하더라도 context.save() 를 하기 전 까지는 ModelContext에 남아있게 된다.

@Query

@State와 비슷하게 동작하여, 모델에서 일어나는 모든 변화를 뷰에 업데이트한다.

@Query를 사용하여 정렬, 필터와 같은 간단한 구문을 처리한 후의 데이터를 받아올 수 있다.

@Query(sort: \.created) private var cards: [Card]

Undo/Redo

.modelContainer() 는 isUndoEnable 이라는 매개변수가 있다.

.modelContainer(for: Trip.self, isUndoEnabled: true)

true 값을 주면 MainContext에 undoManager를 바인딩하여, 추가 코드 없이 변경사항을 취소 또는 복귀를 수행할 수 있다.

자동 저장

자동저장 기능이 활성화되면 ModelContext는 시스템 이벤트(백그라운드 전환 또는 특정 주기) 발생 시 저장된다. 자동저장은 기본으로 활성화되어있어, 불필요 시 비활성화 할 수 있다.

.modelContainer(for: Trip.self, isAutosaveEnabled: false)

Model at scale

백그라운드에서 데이터를 다루거나 원격 서버, 다른 영구 메커니즘과의 동기화, 배치 프로세스는 모두 모델 객체를 필요로한다.

이러한 작업에서 필요한 객체 집합을 가져올 때 ModelContext의 .fetch() 메서드를 통해 가져온다.

FetchDescriptor

FetchDescriptor를 사용하여 복잡한 쿼리를 만들 수 있다.

#Predicate 매크로를 스키마와 결합하여 컴파일러가 검증한 쿼리를 사용할 수 있다.

파라미터로 offset, limt, faulting, perfetching 옵션을 사용할 수 있다.

✔️ #Predicate

특정 조건을 기반으로 데이터를 필터링 할 때 사용할 수 있다.

var predicate = #Predicate<Trip> { trip in
    trip.livingAccommodations.filter {
        hotelNames.contains($0.placeName)
    }.count > 0
}
var descriptor = FetchDescriptor(predicate: predicate)
var trips = try context.fetch(descriptor)

✔️ SortDescriptor

FetchDescriptor 와 함께 사용하여 데이터를 가져올 때 정렬을 수행한 후 값을 가져오도록 할 수 있다.

let descriptor = FetchDescriptor<Trip>(
    sortBy: SortDescriptor(\\Trip.name),
    perdicate: tripPredicate
    )
let trips = try context.fetch(descriptor)

Tuning Option

ModelContext의 enumerate함수에서 옵션들이 결합된다.

context.enumerate(FetchDescriptor<Trip>()) { trip in

}

✔️ batchSize 조절

enumerate함수를 통해 배치사이즈 크기를 조절할 수 있다.

context.enumerate(
    descriptor,
    batchSize: 1000) {}

배치 크기를 줄이면 메모리를 적게 사용하게 되지만 I/O가 증가한다.

✔️ mutation guard

데이터를 순회하는 동안 데이터가 변경됨을 감지하는 mutation guard를 내부적으로 포함하고 있다.

context.enumerate(descriptor) { trip in
    trip.name = "새로운 이름" // ❌ 예외 발생 가능!
}

기본적으로 ModelContext가 변형되는 것을 감지하여 예외를 발생시켜 데이터의 일관성으로 보장하려는 목적을 가지고 있다.

하지만, 의도적으로 일부 데이터를 변경하려고 할 수 있다. 이러한 경우 allowEscapingMutations 매개변수를 true로 설정하여 데이터의 변경을 허용할 수 있다.

context.enumerate(
    descriptor,
    batchSize: 500,
    allowEscapingMutations: true
) { trip in
    // Remind me to make reservations for trip
}

참고

https://developer.apple.com/videos/play/wwdc2023/10187

Meet SwiftData - WWDC23 - Videos - Apple Developer

SwiftData is a powerful and expressive persistence framework built for Swift. We'll show you how you can model your data directly from...

developer.apple.com

https://developer.apple.com/videos/play/wwdc2023/10195

Model your schema with SwiftData - WWDC23 - Videos - Apple Developer

Learn how to use schema macros and migration plans with SwiftData to build more complex features for your app. We'll show you how to...

developer.apple.com

https://developer.apple.com/videos/play/wwdc2023/10196

Dive deeper into SwiftData - WWDC23 - Videos - Apple Developer

Learn how you can harness the power of SwiftData in your app. Find out how ModelContext and ModelContainer work together to persist your...

developer.apple.com

[iOS/PointFree] 동시성프로그래밍: 구조적 프로그래밍과 MainActor

김졀니 — Tue, 21 Jan 2025 12:13:45 +0900

Structured programming

구조적 프로그래밍: 현대에 일반적으로 사용하고 있는 방식으로, 프로그램이 위에서 아래로 선형적으로 읽히도록 만드는 것을 목표로 하는 패러다임 프로그램의 일부를 블랙박스로 구성하여 항상 모든 세부사항을 알 필요 없게 된다. 기본 도구 - 조건문, 반복문, 함수 호출 및 재귀 등

예시로 Swift에는 for문이 없고, Jump문이 있다고 가정해보자.

만약 0부터 100 사이 모든 짝수를 출력하려면 아래와 같이 작성해볼 수 있다.

var x = 0
top: if x.isMultiple(of: 2) {
  print(x)
}
x += 1
if x <= 100 {
  continue top
}

특정 줄에 top: 과 같은 레이블을 붙이고, 실행 흐름을 해당 레이블로 이동시킬 수 있는 continue 를 사용한다고 가정해보자.

위와 같은 점프문은 저수준 어셈블리어에서 사용되던 방식이었다.

✔️ 점프문의 단점: 가독성

위와 같은 점프문은 가독성 측면에서 for문에 비해 좋지 않은 것을 볼 수 있다.

var x = 0
outer: var y = 0
inner: if x.isMultiple(of: 2) && y.isMultiple(of: 2) {
  print(x, y)
}
y += 1
if y <= 100 {
  continue inner
}
x += 1
if x <= 100 {
  continue outer
}

위와 같은 중첩 반복을 for문을 사용한다면,

for x in 0...100 {
  for y in 0...100 {
    if x.isMultiple(of: 2) && y.isMultiple(of: 2) {
      print(x, y)
    }
  }
}

훨씬 가독성이 좋다.

✔️ 점프문의 단점: 코드 영향 범위

점프문은 실행 지점을 코드 어느 줄로든 이동시킬 수 있다. 그렇기 때문에 특정 코드 줄을 이해하기 위해서는 해당 줄로 실행이 이동했을 가능성이 있는 모든 다른 코드들도 이해해야한다.

우리가 주로 사용하는 함수 호출과 동작 방식을 비교해보자면,

func add(_ lhs: Int, _ rhs: Int) -> Int {
  lhs + rhs
}

add(3, 4)

함수를 호출하면 해당 줄로 실행 이동하는 것 처럼 보이겠지만, add 함수가 접근할 수 있는 영역이 제한된다.

함수는 함수의 인수와 외부의 전역변수만 접근할 수 있으며, 함수가 완료되면 실행 흐름이 호출 시점으로 반환된다. 이러한 기능 덕분에 함수는 외부에서는 내부의 동작에 대해 신경쓰지 않아도 된다.

하지만, 점프문은 위와 같은 기능이 없다.

✔️ 점프문의 단점: 실행 흐름의 예측 불가능성

또 다른 문제점으로는 점프문이 있는 프로그램의 실행 흐름은 예측 불가능성이 너무 크고 이해하기 아려워 원하는 기능을 구현하기 어렵다.

예를들어 defer문을 생각해보자.

우리는 defer 문을 통해 함수 스코프의 끝에서 일부 로직을 실행하도록 할 수 있다.

defer { print("Outer loop finished") }
for x in 0...100 {
  defer { print("Inner loop finished for", x) }
  for y in 0...100 {
    if x.isMultiple(of: 2) && y.isMultiple(of: 2) {
      print(x, y)
    }
  }
}

위의 코드처럼 defer를 통해 내부, 외부 for문이 종료되었음을 출력할 수 있다.

하지만 점프문에서는 이러한 기능을 사용할 수 없다. defer문이 어느 스코프에 속하는지 알 수 없기 때문에 defer문을 실행할 수 없다.

위와 같은 코드를 사용하려면 조건문 뒤에 print문을 삽입하는 수밖에 없다.

var x = 0
outer: var y = 0
inner: if x.isMultiple(of: 2) && y.isMultiple(of: 2) {
  print(x, y)
}
y += 1
if y <= 100 {
  continue inner
}
print("Inner loop finished", x)
x += 1
if x <= 100 {
  continue outer
}
print("Outer loop finished")

만약 lock을 이용하여 내부를 잠근 후 count 변수를 증가시키는 작업을 할때, 점프 문을 사용하게 되면 다른 코드로 점프한 후 돌아오지 않을 가능성이 있다.

func increment() {
  self.lock.lock()
  self.count += 1
  continue somewhereElse
  self.lock.unlock()
}

위와 같은 경우 잠금이 해제되지 않아 increment()메서드는 영원히 잠긴 상태가 된다.

점프문은 더 다양한 문제점들을 가지고 있고, 이러한 이유들 때문에 현재 우리가 사용하는 구조적 프로그래밍 언어는 중요한 연구 분야가 되었었다.

✔️ 구조적 프로그래밍 툴을 벗어난 Swift도구

Swift는 점프문을 제공하지는 않지만, 구조적 프로그래밍 틀을 벗어난 몇가지 도구를 제공한다.

첫번째 예로 새로운 스레드를 생성할 때를 생각해보자.

print("Before")
Thread.detachNewThread {
  print(Thread.current)
}
print("After")

실행 흐름 앞 뒤에 print문을 추가하면

Before
After
<NSThread: 0x10071c760>{number = 2, name = (null)}

우리는 “After”가 출력 된 이후에 스레드 정보가 출력되는 것을 볼 수 있다.

이러한 경우는 코드가 위에서 아래로 흐르지 않는 것을 보여준다.

이렇게 위에서 아래로 흐르지 않는 방식은 Swift에서 익숙하게 사용하던 방식들이 깨지게 된다.

func thread() {
    defer { print("Finished") }
    print("Before")
    Thread.detachNewThread {
        print(Thread.current)
    }
    print("After")
}
thread()

Before
After
Finished
<NSThread: 0x100710d70>{number = 2, name = (null)}

스레드를 생성하기 전에 defer문을 추가하였을 때 스레드의 종료보다 defer문이 더 먼저 실행되는 것을 볼 수 있다.

스레드가 완전히 새로운 실행 흐름에서 동작하기 때문에 defer문은 스레드 작업이 끝나기를 기다릴 수 없다.

스레드 뿐만아니라 OperationQueue나 GCD 등에서도 마찬가지인데, 이는 스레드나 큐의 문제가 아니라 Escaping Closure와 관련된 문제이다.

Escaping Closure는 함수의 생명주기를 넘어 캡쳐되고 사용될 수 있는 클로저이다. Escaping Closure를 사용하게 되면 실행 흐름과 완전히 분리된 새로운 흐름을 만들어낼 수 있게 된다.

Structured Concurrency

구조적 동시성은 기존의 구조적 프로그래밍 방식처럼 동시성 컨텍스트에서도 코드를 작성할 수 있다.

이를 통해 비동기적이고 동시적인 작업을 하더라고 코드를 위에서 아래로 순차적으로 작성할 수 있으며, defer와 같은 기능을 사용할 수 있고, 코드의 실행 범위를 명확하게 구분하여 자원 정리와 같은 종료 작업을 쉽게 실행할 수 있다.

이전에 사용하였던 네트워크 통신 예제 코드를 통해 살펴보자.

requestId와 요청 시작 날짜 값을 TaskLocal 변수로 설정하여 작업 시 값에 접근하도록 할 수 있다.

enum RequestData {
  @TaskLocal static var requestId: UUID!
  @TaskLocal static var startDate: Date!
}

비동기 함수를 통해 데이터베이스 쿼리와 네트워크 요청 작업을 수행하고, requestId를 사용해 로그를 확인할 수 있다.

func databaseQuery() async throws {
  let requestId = RequestData.requestId!
  print(requestId, "Making database query")
  try await Task.sleep(nanoseconds: 500_000_000)
  print(requestId, "Finished database query")
}

func networkRequest() async throws {
  let requestId = RequestData.requestId!
  print(requestId, "Making network request")
  try await Task.sleep(nanoseconds: 500_000_000)
  print(requestId, "Finished network request")
}

그 다음 요청을 받아 처리하는 함수에서는 데이터베이스와 네트워크 요청을 처리하고 임시 응답값을 반환한다.

func response(_ request: URLRequest) async throws -> HTTPURLResponse {
  let requestId = RequestData.requestId!
  let start = RequestData.startDate!
  defer { print(requestId, "Request finished in", Date().timeIntervalSince(start)) }

  try await databaseQuery()
  try await networkRequest()

  return .init()
}

위의 코드는 데이터베이스 쿼리 작업이 완료된 후에 네트워크 요청을 처리하는 직렬 작업 방식으로 수행되고있다. 그렇기 때문에 응답 시간이 오래 걸리게 된다. 해당 작업을 병렬화 하여 속도를 높일 수 있다.

위에서 사용한 방식으로 두 비동기 함수를 병렬화 하기 위해 Task 를 사용하여 각각 새로운 작업을 시작하도록 한다.

Task {
  try await databaseQuery()
}
Task {
  try await networkRequest()
}

이러한 방식은 병렬적으로 작업을 수행하지만, 구조적 프로그래밍의 요소를 잃게 된다. Task를 사용하여 작업을 시작하게 되면 작업이 블로킹되지 않아 독립적으로 실행되므로 코드가 순차적으로 읽히지 않는다.

위에서 살펴본 Escaping closure를 사용하는 방식과 비슷한 구조인 것이다.

✔️ 구조적 동시성+병렬 작업 처리

두 작업이 병렬 작업으로 처리되면서 구조적 프로그래밍을 유지할 수 있는 방식에 대해 살펴보자.

Task 타입은 Task가 반환한 값에 접근할 수 있는 프로퍼티를 제공한다.

let task = Task {
  try await Task.sleep(nanoseconds: NSEC_PER_SEC)
  return 42
}
let number = try await task.value

task.value 를 통해 반환되는 값에 접근할 수 있으며 await을 통해 접근해야 한다.

위의 프로퍼티를 활용하여 수정해보면,

let databaseTask = Task {
  try await databaseQuery()
}
let networkTask = Task {
  try await networkRequest()
}
try await databaseTask.value
try await networkTask.value

각 작업을 변수에 할당하고, 반환하는 값을 await하면 된다.

코드가 직렬적으로 보이지만 실제로 두 작업은 병렬로 실행되고, 작업이 완료된 후 각 작업의 값에 접근하는 부분만 직렬로 수행된다. 그렇기 때문에 더 빠르게 작업을 완료할 수 있다.

실행해보면 약 0.5초의 시간만에 작업이 완료된다.

B2A20E2F-6389-4A0A-9BB0-9F6C2AB1FF86 Making database query
B2A20E2F-6389-4A0A-9BB0-9F6C2AB1FF86 Making network request
B2A20E2F-6389-4A0A-9BB0-9F6C2AB1FF86 Finished database query
B2A20E2F-6389-4A0A-9BB0-9F6C2AB1FF86 Finished network request
B2A20E2F-6389-4A0A-9BB0-9F6C2AB1FF86 Request finished in 0.552590012550354

비동기 작업을 동시에 실행하여도 구조적 프로그래밍의 틀을 벗어나지 않아도 된다.

하지만 이 코드는 간결하지 못하다. 두 작업을 완료할 때 까지 기다리기 위해 각각의 새로운 작업을 생성해야 하는 것이 좋아보이지 않는다.

미관적인 부분 뿐만아니라 취소 작업에서도 문제가 있다.

새로운 작업을 생성하게 되면 협력적인 취소를 수행하지 못하게 된다.

예를들어 위의 응답 작업을 시작하고 0.1초만에 취소한다고 해보자.

바로 실행 중인 두 작업이 취소되어 빠른 시간에 작업이 끝나길 원하지만 두 작업은 취소되지 않고 계속 작업을 수행하게 된다.

내부에서 새로운 Task를 생성하게되어 부모 작업과 독립적으로 실행을 하게되어 부모 작업의 취소를 전달받지 못하게 된다.

위와같이 동작하는 이유는 Apple의 구조적 동시성 설계 방식 때문이다. 작업을 생성하여 비구조적인 방식으로 동작하게 되면 해당 작업의 취소는 명시적으로 관리해야한다.

✔️ withTaskCancellationHandler

withTaskCancellationHandler 를 사용하여 비구조적 코드를 구조적 코드로 되돌리고, 취소도 우리가 원하는 대로 동작하도록 할 수 있다.

withTaskCancellationHandler(
    operation: () async throws -> T,
    onCancel: () -> Void
)

operation 에서 실행할 비동기 작업을 처리하고, 취소가 감지되었을 때 onCancel 에서 취소 작업을 수행하게 된다.

withTaskCancellationHandler 를 통해 내부 작업들이 취소 작업을 확인하게 된다.

하지만, 이 방법은 코드가 복잡해지는 문제점을 가지고 있다. 또, 위에서 아래로 읽히는 것 처럼 보이지만, 작업을 먼저 선언한 후, withTaskCancellationHandler 를 호출한 후 취소 로직과 작업 로직을 별도의 클로저로 구현해야 한다.

✔️ async let

더 간단하게 async let 을 사용해볼 수 있다.

async let 을 통해 여러 비동기 작업을 병렬로 실행하면서 코드가 선형적으로 읽히며 취소 작업도 전달할 수 있다.

async let databaseResponse = databaseQuery()
async let networkResponse = networkRequest()

만약, 두 비동기 함수가 각각의 데이터를 반환한다고 가정해보자.

struct User { var id: Int }
func fetchUser() async throws -> User { User(id: 42) }

struct StripeSubscription { var id: Int }
func fetchSubscription() async throws -> StripeSubscription { StripeSubscription(id: 1729) }

위의 예시에서 async let 을 통해 병렬로 데이터를 처리할 수 있다.

async let user = fetchUser()
async let subscription = fetchSubscription()

이와 같이 async let 을 통해 가져온 변수는 await 키워드를 사용하여 접근할 수 있다.

try await user.id

이 병렬 작업 결과를 JSON으로 묶어 응답을 만들 수 있다.

struct Response: Encodable {
  let user: User
  let subscription: StripeSubscription
}

try await JSONEncoder().encode(Response(user: user, subscription: subscription))

async let user = fetchUser()
async let subscription = fetchSubscription()

let jsonData = try await JSONEncoder().encode(
  Response(user: user, subscription: subscription)
)

async let 을 활용하여 간단하고 선형적으로 코드가 읽히는 것을 볼 수 있다.

✔️ task group

async let 은 병렬 작업의 개수가 정해져있는 경우에 효과적으로 사용할 수 있지만, 작업 단위의 개수가 동적으로 정해지는 경우에는 다른 도구가 필요하다.

withTaskGroup 을 통해 동적인 개수의 작업을 수행하는 동안 실행을 중지하고, 모든 작업이 완료된 후 다시 실행을 하도록 할 수 있다.

withTaskGroup(
  of: Sendable,
  returning: GroupResult.Type,
  body: (inout TaskGroup<Sendable>) async -> GroupResult
)

첫번째 매개변수 of는 각 하위 task의 반환 타입을 의미한다.
두번째 매개변수인 returning 은 task group의 최종 반환 타입을 의미하고,
body 는 task group에 task를 추가하고 실행하는 클로저이다.

예를들어, 1000개의 작업을 생성해 숫자를 모두 더하는 작업을 수행해보자.

먼저, 스레드를 기반으로 작업을 해보면

var sum = 0
for n in 1...1_000 {
  Thread.detachNewThread {
    Thread.sleep(forTimeInterval: 1)
    sum += n
  }
}

1000개의 새로운 스레드를 생성한 후 작업을 처리하는데, 스레드를 사용하면 모든 스레드가 종료될 때 까지 기다려야 결과를 확인할 수 있다. 스레드 자체에 기다리는 작업이 없기 때문에 수동으로 대기 시간을 설정하여 기다려야 한다.

Thread.sleep(forTimeInterval: 2)
print(sum)

위 코드를 수행하면 race condition 문제가 발생하게 되어 실행할 때 마다 다른 값을 출력하게 된다.

이 코드를 Task Group을 사용하는 방식으로 구현해보자.

withTaskGroup(of: Int.self, returning: Int.self) { group in
  group.addTask(operation: () async -> Int)
}

of와 returning에 Int 타입을 지정해주고, body에 task를 추가할 수 있다.

Task group에 task를 추가할 때는 addTask 메서드를 사용하게 된다.

추가되는 task는 매개변수가 없는 비동기 함수이며, of 에 지정한 타입을 반환해야 한다.

다음 코드는 1000개의 정수를 반복하며 1초동안 대기 후 반환하는 Task를 추가하는 코드이다.

Task {
  await withTaskGroup(of: Int.self) { group in
    for n in 1...1000 {
      group.addTask {
        try? await Task.sleep(nanoseconds: NSEC_PER_SEC)
        return n
      }
    }
    await group.waitForAll()
  }
}

모든 Task는 병렬로 실행되고, await group.waitForAll() 을 통해 모든 Task가 완료될 때 까지 기다릴 수 있다.

더 나아가서, 각 Task의 실행 결과를 수집할 수 있다. for await 을 이용하여 그룹 내에 있는 각 Task의 실행 결과에 접근할 수 있다.

var sum = 0
for await int in group {
  sum += int
}
return sum

Task group은 AsyncSequence 프로토콜을 준수한다. Sequence와 유사하지만 AsyncSequence는 next() 메서드를 사용하여 비동기적으로 작업의 결과를 순회하게 된다.

최종적으로, 1부터 1000까지의 숫자를 병렬적으로 계산하여 빠르게 수행하도록 하면

let sum = await withTaskGroup(of: Int.self, returning: Int.self) { group in
  for n in 1...1_000 {
    group.addTask {
      try? await Task.sleep(nanoseconds: NSEC_PER_SEC)
      return n
    }
  }

  var sum = 0
  for await int in group {
    sum += int
  }
  return sum
}
print(sum)

이와 같이 구현해 볼 수 있으며, 매 실행 마다 동일한 결과를 얻을 수 있다.

TaskGroup을 사용하여 Race Condition 문제를 해결할 수 있으며, 공유되는 가변 데이터에 동시적인 접근을 막기 위해 actor를 도입하지 않아도 된다.

✔️ TaskGroup의 작업 취소

TaskGroup은 협력적 취소를 지원한다. TaskGroup을 시작한 비동기 컨텍스트가 취소되었을 때 isCancelled 플래그를 통해 작업을 마무리하도록 할 수 있다.

addTaskUnlessCancelled 를 통해 상위 Task의 취소 여부를 확인하여 취소되었을 경우 Task를 추가하지 않도록 처리할 수 있다.

group.addTaskUnlessCancelled {
  // 작업 추가
}

✔️ TaskGroup의 예외처리

TaskGroup에서 withThrowingTaskGroup 을 통해 비동기 작업에서 예외가 발생하거나 취소될 경우를 처리할 수 있다.

let sum = await withThrowingTaskGroup(of: Int.self, returning: Int.self) { group in
  for n in 1...1_000 {
    group.addTask {
      try? await Task.sleep(nanoseconds: NSEC_PER_SEC)
      return n
    }
  }

  var sum = 0
  for try await int in group {
    sum += int
  }
  return sum
}
print(sum)

TaskGroup을 사용하여 여러 개의 Task를 병렬로 실행할 수 있고, 이러한 Task의 실행 결과를 모아 최종 결과로 누적하여 사용할 수 있다. 이러한 과정을 처리하면서도 구조적 프로그래밍을 유지하여 코드를 위에서부터 아래로 순차적으로 읽히도록 할 수 있다.

비동기 작업과 동시성 작업에서 구조적 프로그래밍 영역을 벗어나게 되는 도구들이 있지만, 가능한 구조적 프로그래밍을 유지할 수 있도록 노력해야 한다. async함수와 await문, async let, task group을 사용하면 복잡한 구조에서도 구조적 프로그래밍을 유지할 수 있게 된다.

✔️ 비동기 컨텍스트가 없을 때

그렇다면, 비동기 작업을 처리해야하는데 현재 비동기 컨텍스트에 있지 않다면 어떻게 해야할까. 새로운 Task를 생성하여 비동기 컨텍스트를 만들 수도 있지만, Task는 독립적인 흐름이 만들어지기 때문에 구조적 프로그래밍을 깨게 된다.

Swift는 계속해서 이러한 비구조적인 Task를 생성해야 하는 상황을 해결하기 위한 API를 추가하고 있다.

예를들어, SwiftUI는 뷰가 나타날 때 비동기 Task를 실행하고, 뷰가 사라질 때 Task를 취소하는 modifier를 제공한다.

import SwiftUI

Text("Hi")
  .task {
    let sum = try? await withThrowingTaskGroup(
      of: Int.self, returning: Int.self
    ) { group in
      // ...
    }
    print("sum", sum)
  }

.task 를 통해 비동기 작업을 실행할 수 있고, .task 내에서 실행되는 모든 하위 작업에 취소 신호가 전달된다. 이를 통해 구조적 프로그래밍을 유지할 수 있게 된다.

또 다른 예시로, 기존에는 Swift에서 최상위 레벨에서는 비동기 작업을 수행할 수 없었다.

try await Task.sleep(nanoseconds: NSEC_PER_SEC)
// Error: ‘async’ call in a function that does not support concurrency

이러한 문제를 해결하려면 @main 을 사용하여 Entry point를 설정해 비동기 컨텍스트를 실행할 수 있는 환경을 만들어야 했다.

@main
struct Main {
  static func main() async throws {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC)
    print("done!")
  }
}

Swift 5.7부터는 이러한 문제가 해결되어 최상위 코드에서 비동기 작업을 바로 사용할 수 있게 되었다.

Apple의 프레임워크가 Swift의 동시성 도구와 깊이 통합됨에 따라 비구조적 Task를 생성할 필요가 거의 없어질 것으로 보인다.

Unstructured Concurrency

구조적 프로그래밍을 최대한 유지하는 것이 좋지만 그러지 못하는 경우도 존재한다. 새로운 Task를 생성하면 구조적 프로그래밍을 벗어나게 되지만, 부모 컨텍스트로부터 몇몇 기능을 상속받아 사용할 수 있게 된다.

✔️ Task의 상속

Task는 아래와 같이 TaskLocals와 우선순위를 상속받는 것을 확인할 수 있다.

또, Task는 Actor를 상속받을 수 있다.

actor Counter {
  var count = 0

  func increment() {
    self.count += 1
  }

  func decrement() async throws {
    self.count -= 1
    try await Task.sleep(nanoseconds: NSEC_PER_SEC / 2)
    if self.count < 0 {
      self.count += 1
    }
  }
}

만일 위와 같이 decrement() 함수 내에서 count 가 0보다 작아질 경우 증가시켜주는 작업을 하고싶을 때, Task.sleep 을 이용하여 작업을 잠깐 중단하도록 하는 것은 바람직하지 않을 수 있다. 일단 값을 감소시키고 나중에 Actor가 자동으로 조정하도록 하고 싶을 수 있다.

이러한 경우 비 구조적 Task를 사용해볼 수 있다.

func decrement() {
  self.count -= 1
  Task {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC / 2)
    if self.count < 0 {
      self.count += 1
    }
  }
}

이렇게 작성한다면 원하는대로 동작하는데, 위 코드에서 놀라운 부분이 있다.

지금까지 Actor 메서드와 프로퍼티에 접근하려고 할 때는 Actor 외부에서는 await 을 사용하여 접근해야 했다.

decrement()에서 Task는 Actor 내부에 존재하지만, Task는 Actor와 독립적인 흐름을 시작하게 된다. 그럼에도 불구하고 Actor 내부에 있는 Task 블록에서 await없이 프로퍼티와 메서드에 접근할 수 있는 이유는 Task가 Actor의 컨텍스트를 상속받기 때문이다. 그렇기 때문에 Task 안에서도 Actor 내부에서 동작하는 것 처럼 접근할 수 있다.

이러한 기능은 구조적인 프로그래밍이 아니어도 쉽게 이해할 수 있게 만들어준다.

✔️ 분리된 Task에서의 Actor

반면에, 현재 컨텍스트에서 완전히 분리된 Task를 생성할 수 있다. 이는 우선순위, Task Local값, actor를 상속받지 않는다.

Task.detached {
}

이제는 await 을 통해 접근해야 한다.

func decrement() {
  self.count -= 1
  Task.detached {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC / 2)
    if await self.count < 0 {
      await self.increment()
    }
  }
}

분리된 Task는 완전히 초기화 된 상태에서 시작하게 된다. 뿐만아니라 구조적인 동시성을 위한 도구 중 일부도 현재 Task의 요소를 상속받지 않는 것이 있다.

@Sendable, async let, Taskgroup은 현재 actor의 컨텍스트를 상속받지 못한다.

예를들어, 동기 클로저 내부에서 actor 프로퍼티에 접근하는 것은 문제가 발생하지 않는다.

func increment() {
  self.count += 1
  let count = { self.count }()
}

하지만, @Sendable 을 적용하게 되면 컴파일 오류가 발생하게 된다.

이러한 문제를 해결하려면 비동기 컨텍스트를 제공하여 await 을 사용하여 접근해야 한다.

func increment() async {
  let count = await { @Sendable in await self.count }()
}

Task가 어떻게 Actor 컨텍스트를 상속받을까?

Task는 공개적으로 노출되지 않은 특수 컴파일러의 속성을 통해 actor 컨텍스트를 상속하게 된다.

public init(
  priority: TaskPriority? = nil,
  @_inheritActorContext
  @_implicitSelfCapture
  operation: __owned @Sendable @escaping () async -> Success
) {

Actor 컨텍스트를 상속 받는 것은 Task에 적용되어있는 내용이기 때문이다.

@Sendable 과 마찬가지로 async let 또한 상속받지 못한다.

async let은 비동기적으로 실행되는 작업을 동시에 실행하기 위해 사용된다. 다른 작업과 병렬적으로 실행되야 하기 때문에 클로저를 자동으로 @Sendable 속성으로 변환된다.

그렇기 때문에 async let은 actor 격리를 유지하지 않게 되어 actor의 프로퍼티에 접근할 수 없게 된다. 이 오류를 해결하기 위해서는 await 을 사용하여 접근하는 것이다.

func increment() async {
  async let count = { await self.count }()
}

Task group도 상속받지 못한다. 예시로 1000개의 작업을 생성하여 count를 증가 또는 감소시키는 메서드를 구현해보자.

오류가 발생하는 이유는 addTask 클로저는 @Sendable 클로저이기 때문에 현재 actor를 상속받지 못한다. 그렇기 때문에 비동기 컨텍스트를 사용하여 접근해야 한다.

group.addTask {
  if Bool.random() {
    await self.increment()
  } else {
    await self.decrement()
  }
}

MainActor

MainActor의 필요성

Swift 동시성 도구를 사용할 때 스레드에 대해 고려할 필요가 거의 없다. 하지만 특정 작업을 수행할 때 메인 스레드에서 실행되도록 해야 할 경우가 있다.

이전에 살펴본 바와 같이 작업을 Task.sleep 과 같이 중단한 이후 다시 작업을 재개할 경우 기존에 사용하던 스레드가 아닌 다른 스레드에서 시작하게 될 수 있다. 하지만 이전과 동일한 특정 스레드(예: 메인 스레드)에서 실행해야 할 경우는 어떻게 해야할까?

예를들어, count 변수를 가지고 있고, 복잡한 연산을 수행하는 비동기 메서드를 포함하고 있는 ObservableObject 가 있다고 가정해보자.

class ViewModel: ObservableObject {
  @Published var count = 0

  func perform() async throws {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC)
    self.count = .random(in: 1...1_000)
  }
}

위 코드는 경고 없이 컴파일되지만 잘못된 코드이다. self.count 를 변경하는 코드가 어떤 스레드에서 실행될 지 알 수 없다. 하지만 count 는 @Published 로 선언했고, @Published는 반드시 메인 스레드에서 변경되어야 한다.

메인 스레드에서 동작하도록 하기 위해 DispatchQueue.main.async 를 생각해볼 수 있을 것이다.

class ViewModel: ObservableObject {
  @Published var count = 0

  func perform() async throws {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC)
    DispatchQueue.main.async {
      self.count = .random(in: 1...1_000)
    }
  }
}

위 코드는 오류가 발생하는데, ViewModel이 Sendable 타입이 아니기 때문이다. 그렇기 때문에 self를 캡쳐할 수 없다. ViewModel은 가변 데이터를 포함하고 있기 때문에 쉽게 Sendable 로 만들 수 없다.

게다가, DispatchQueue 의 async는 전달되는 클로저가 Sendable 이어야 한다고 요구하기 때문에 Sendable 타입이 아닌 데이터를 캡쳐할 수 없다.

따라서, 이는 안전한 동시성 코드가 아니게 된다. 새로운 형태의 동시성을 비동기 코드와 섞어 사용하게되면서 Swift의 기본 동시성 도구가 제공하는 장점들을 사용하지 못하게 된다.

예를들어, 메인 큐로 Dispatch하게되면서 Task Locals를 상속할 수 없게 된다.

DispatchQueue.main.async 클로저 내에서 접근할 때 런타임 오류가 발생하는 것을 볼 수 있다.

이러한 문제가 발생하는 이유는 Task Local이 withValue 클로저의 수명 동안만 접근할 수 있기 때문이다. 이 클로저는 non-escaping이고, 동기적으로 호출되기 때문이다.

더 명확하게 실행 범위를 확인해보면,

withvalue 가 종료된 이후에 DispatchQueue.main.async 가 실행되는 것을 볼 수 있다.

MainActor

그래서 우리는 메인 스레드에서 강제로 실행하기 위한 안전한 방법을 찾아야 한다.

스레드가 메인 스레드라는 개념을 가지고 있고, DispatchQueue가 메인 큐를 가지고 있는 것 처럼, Actor에는 MainActor라는 개념이 존재한다.

MainActor 타입은 메인 스레드에서 동기적으로 클로저를 실행할 수 있는 Endpoint를 제공한다.

await MainActor.run {
    ...
}

MainActor의 run 메서드를 호출하려면 await키워드를 사용해야 한다. 다른 작업이 이미 메인 스레드에서 동작중일 경우 시간이 걸릴 수 있기 때문이다.

위와 같이 MainActor.run에서 count 를 변경하려 하면 오류가 발생한다. Non-Sendable 타입의 데이터를 수정해야 하기 때문에 race condition이 발생할 가능성이 있다.

await MainActor.run {
  self.count = .random(in: 1...1_000)
}
await MainActor.run {
  self.count = .random(in: 1...1_000)
}

이러한 문제를 해결하기 위해 메서드에 MainActor 속성을 부여할 수 있다.

메서드가 @MainActor 로 표시되었다고 해서 모든 것이 메인스레드에서 동작하는 것은 아니다. 다른 비동기 메서드를 호출하거나 Task.sleep 등 현재 작업의 일시 중단 지점에서는 다른 스레드에서 동작할 수 있다. @MainActor 로 표시된 메서드 내에서도 비동기적이고 병렬적인 작업을 수행할 수 있다.

또한, 메서드 내에서 sleep 을 호출한다고 해서 메인 스레드를 blocking하지는 않는다. sleep 이 실행되는 동안 다른 작업이 MainActor에서 실행될 수 있다.

하지만, 메인 스레드에서 많은 리소스를 사용하는 작업을 하게 되면 메인 스레드가 차단될 수 있는 문제가 있다.

메서드 뿐만아니라 클래스에도 @MainActor 를 적용해 볼 수 있다.

@MainActor
class ViewModel: ObservableObject {
     ...
}

클래스에 적용하면 모든 생성자, 메서드 프로퍼티가 모두 @MainActor 로 표시된다. 또한, 클래스 전체를 @Sendable로 만들며, 이 클래스가 병렬적인 컨텍스트에서도 안전하게 사용될 수 있음을 보장한다.

@MainActor 를 선언함으로써 모든 상호작용이 메인 스레드에서 직렬화되어 사용할 수 있게 된다.

Task를 사용하면 자동으로 Actor 컨텍스트를 상속받게 된다. 따라서 아래 코드는 메인스레드에서 실행된다.

@MainActor
func perform() async throws {
  Task {
    print(Thread.current)
  }
}

<_NSMainThread: 0x10600a9b0>{number = 1, name = main}

반면, Task.detached를 사용하면 Actor 컨텍스트를 상속받지 않으며, 백그라운드에서 실행된다.

@MainActor
func perform() async throws {
  Task.detached {
    print(Thread.current)
  }
}

비슷하게 async let 이나 Task Group과 같은 비동기 병렬 구조를 MainActor 코드에 도입하면 해당 작업은 메인스레드가 아닌 다른 스레드에서 실행된다.

@MainActor를 활용하면 메인 스레드에서의 안전한 작업 관리가 가능해지며, 병렬 실행과 적절한 조화를 이룰 수 있다.

✔️ 단일 스레드에서의 동시성

우리는 지금까지 어떤 작업이 어떤 스레드에서 실행 되는지 확인해왔다. 하지만 스레드에 대해 생각하지 않고 하나의 스레드에서 모든 작업을 실행할 수도 있다. 실제로 단일 스레드로 동작하고 있는 환경이 많다. 예를들어, 웹어셈블리와 몇몇 라즈베리파이 모델이 단일 스레드로 동작한다.

따라서 이러한 상황에도 비동기성과 동시성을 처리할 수 있는 방법이 있는 것은 강력한 기능이다.

이를 알아보기 위해 여러 작업을 실행하면서 모든 작업이 메인스레드에서 실행되도록 강제해보자.

0.25초마다 로그를 출력하는 작업을 수행하고,

await withThrowingTaskGroup(of: Void.self) { group in
  group.addTask { @MainActor in
    while true {
      try await Task.sleep(nanoseconds: NSEC_PER_SEC / 4)
      print(Thread.current, "Timer ticked")
    }
  }
}

동시에 2,000,000번째 소수를 계산하는 작업을 수행한다. 이 작업은 많은 시간을 소모하게 된다.

group.addTask { @MainActor in
  nthPrime(2_000_000)
}

또, 동시에 대용량 파일 1,000개 다운로드 작업을 수행한다.

for n in 0..<workCount {
  group.addTask { @MainActor in
    _ = try await URLSession.shared
      .data(from: .init(string: "http://ipv4.download.thinkbroadband.com/1MB.zip")!)
    print(Thread.current, "Download finished", n)
  }
}

위 작업을 수행하면 초기에는 로그가 출력되지 않다가, 약 6초 후에 로그가 출력된다. 소수를 계산하는 함수가 매우 강력한 연산을 수행하게되며 메인스레드를 묶어버리기 때문이다.

그렇다면 소수 계산 함수를 비동기로 변경하고, 1000번마다 다른 작업이 실행될 수 있도록 양보(yield)해보자.

실행 즉시 로그가 출력되고, 여러 작업이 동시에 실행된다. 그리고 약 6초 후 소수 계산 결과가 출력된다.

단일 스레드에서도 효율적인 비동기 작업 처리가 가능하며, 작업간 차단을 최소화하여 동시성을 극대화할 수 있다.

PointFree 강의를 듣고 정리한 내용입니다!

https://www.pointfree.co/episodes/ep194-concurrency-s-future-structured-and-unstructured

Episode #194: Concurrency's Future: Structured and Unstructured

There are amazing features of Swift concurrency that don’t quite fit into our narrative of examining it through the lens of past concurrency tools. Instead, we’ll examine them through the lens of a past programming paradigm, structured programming, and

www.pointfree.co

[iOS/Point-Free] 동시성프로그래밍: Sendable, Actor

김졀니 — Mon, 30 Dec 2024 14:27:54 +0900

PointFree 강의 정리 내용입니다!

https://www.pointfree.co/collections/concurrency/threads-queues-and-tasks/ep193-concurrency-s-future-sendable-and-actors

Episode #193: Concurrency's Future: Sendable and Actors

When working with concurrent code, you must contend with data synchronization and data races. While the tools of the past made it difficult to reason about these issues, Swift’s new tools make it a breeze, including the Sendable protocol, @Sendable closu

www.pointfree.co

이전 내용

1. 동시성의 과거: Thread

2. 동시성프로그래밍: OperationQueue, GCD, Combine

3. 동시성프로그래밍: Task

Concurrency's Future: Sendable and Actors

Sendable and @Sendable

데이터 동기화 및 Data Race 문제

✔️ 데이터 경쟁 문제

이전에 스레드와 DispatchQueue에 관련하여 다루었을 때 데이터 동기화 및 경쟁 문제가 있었다.

이전에 사용한 해결책을 살펴보자.

class Counter {
  let lock = NSLock()
  var count = 0
  func increment() {
    self.lock.lock()
    defer { self.lock.unlock() }
    self.count += 1
  }
}

NSLock 을 사용하여 count 변수를 증가시킬 때 여러 스레드가 동시에 작업하지 못하도록 막아줬다.

let counter = Counter()

for _ in 0..<1000 {
  Task {
    counter.increment()
  }
}

Thread.sleep(forTimeInterval: 2)
print("counter.count", counter.count)

// 출력:
// counter.count 1000

그 후 1,000개의 태스크를 만들어 count를 증가시키도록 하였다.

결과는 항상 1,000이 출력되는 것으로 보아 경쟁 상태를 해결한 것으로 볼 수 있다.

하지만 락을 사용하는 코드는 100% 안전을 보장할 수 없다. 코드가 복잡해지고 실수하기 쉬워 큰 문제를 발생시킬 가능성이 있다.

✔️ Swift의 제한

Swift는 이러한 동시성 컨텍스트에서 데이터 경쟁 상황을 방지하기 위해 컴파일러가 오류나 경고를 나타낸다.

제한된 사항 중 하나는 동시성 컨텍스트에서 가변 변수(var)를 캡쳐하는 것을 금지하고 있다.

func doSomething() {
  var count = 0
  Task {
    print(count) // Error
  }
}

Error: Reference to captured var ‘count’ in concurrently-executing code

가변 변수를 캡쳐할 때 오류가 발생하는 이유는 태스크 외부 또는 내부에서 값의 변경이 발생할 경우 경쟁 상태가 발생할 수 있기 때문이다.

count = 0
Task {
  count = 1
}
Thread.sleep(forTimeInterval: 1)
print(count) // 0? 1?

가변 캡쳐는 단순 탈출 클로저에서는 허용된다.

var count = 0
for _ in 0..<workCount {
  Thread.detachNewThread {
    count += 1
  }
}
Thread.sleep(forTimeInterval: 2)
print("count", count)

위와 같이 스레드 기반 코드에서는 컴파일러가 경쟁 상태임을 인지하지 못하기 때문에 오류가 발생하지 않고, 1,000보다 작은 값을 출력하게 된다.

✔️ Immutable capture

가변 캡쳐는 안되지만 불편 타입의 캡쳐는 문제가 발생하지 않는다.

let count = 0
Task {
  print(count)
}

let 을 사용하거나,

var count = 0
Task { [count] in
  print(count)
}

var 여도 명시적으로 캡쳐리스트로 캡쳐를 하게 된다면 외부 변수와 분리되므로 문제가 발생하지 않는다.

✔️ 컴파일러의 진단 활성화

컴파일러가 경쟁상태와 같은 동시성 문제를 진단할 수 있도록 플래그를 활성화 시킬 수 있다.

.executableTarget(
  name: "concurrency",
  dependencies: [],
  swiftSettings: [
    .unsafeFlags([
      "-Xfrontend", "-warn-concurrency",
    ]),
  ]
),

해당 설정을 통해 플래그를 활성화 하게 되면

for _ in 0..<1000 {
  Task {
    counter.increment() // warning
  }
}

위에서 예시로 사용했던 코드에서 경고가 발생하게 된다.

Capture of ‘counter’ with non-sendable type ‘Counter’ in a @Sendable closure

이 경고는 @Sendable 클로저 내에서 non-sendable 타입을 캡쳐할 때 발생한다.

먼저, Sendable 프로토콜에 대해 알아보자.

The Sendable protocol

/// Sendable 프로토콜은 특정 타입의 값이 
/// 동시성 코드에서 안전하게 사용될 수 있음을 나타냅니다.
public protocol Sendable {
}

Sendable 타입은 Sendable프로토콜을 준수하는 타입이다.

Sendable 프로토콜은 요구사항이 없는 프로토콜이지만 컴파일러가 내부적으로 Sendable 타입이 프로토콜을 준수하는지 확인하는 작업을 수행한다. 이를 통해 동시성 코드에서 안전하게 값을 전달할 수 있도록 한다.

어떠한 타입은 항상 안전하게 전달될 수 있다.

예를 들어,

var count = 0
Task { [count] in
  print(count)
}

위와 같은 경우는 문제가 발생하지 않는다. 오류가 없는 이유는 Int 타입이 Sendable 프로토콜을 준수하기 때문이다.

표준 라이브러리의 대부분의 타입은 값 타입으로 구성되어 있기 때문에 기본적으로 Sendable이다.

그렇기 때문에 필드가 모두 Sendable인 값 타입은 동시성 코드에서 안전하게 전달될 수 있다.

struct User {
  var id: Int
  var name: String
}
let user = User(id: 42, name: "Blob")
Task {
  print(user)
}

하지만, 데이터 타입이 더 복잡해지면 자동으로 Sendable을 준수하지 못하는 경우가 생길 수 있다.

예를 들어, AttributedString 타입의 필드를 추가하게 된다면

struct User {
  var id: Int
  var name: String
  var bio: AttributedString
}
let user = User(id: 42, name: "Blob", bio: "")
Task {
  print(user) // warning
}

Capture of ‘user’ with non-sendable type ‘User’ in a @Sendable closure

@Sendable 클로저 내에서 User 타입을 캡쳐하지 못한다는 경고가 발생한다. AttributedString타입은 Sendable이 아니기 때문에 User타입은 Sendable을 준수하지 않고있다.

위에서 다루었던 내용들은 값 타입이지만 참조타입도 Sendable로 만들 수 있다.

class User: Sendable { // warning 1
  var id: Int // warning 2
  var name: String
  init(id: Int, name: String) {
    self.id = id
    self.name = name
  }
}

경고:

1. Non-final class ‘User’ cannot conform to ‘Sendable’; use ’@unchecked Sendable’
2. Stored property ‘id’ of ‘Sendable’-conforming class ‘User’ is mutable

첫 번째 경고는 final이 아닌 클래스는 Sendable로 추론할 수 없다는 것을 나타낸다. 이는 서브클래스가 생성되어 가변 상태가 추가될 수 있기 때문이다.

두 번째 경고는 Sendable이 되려면 가변 필드가 포함될 수 없음을 나타낸다. 따라서 필드를 let으로 변경해야 한다.

final class User: Sendable {
  let id: Int
  let name: String
  init(id: Int, name: String) {
    self.id = id
    self.name = name
  }
}

다음과 같이 수정하면 Sendable을 준수하는 타입이 만들어지지만 User 클래스의 많은 기능이 제한된다. 내부 데이터를 변경할 수 없고, 구초제와 비슷한 동작을 하게 된다.

어떠한 타입은 Sendable임을 컴파일러에 증명할 수 없을 때가 있다.

이러한 경우 직접 문제를 해결하고, 컴파일러의 감시 범위에서 벗어나야 한다.

class Counter {
  let lock = NSLock()
  var count = 0
  func increment() {
    self.lock.lock()
    defer { self.lock.unlock() }
    self.count += 1
  }
}
let counter = Counter()
Task {
  counter.increment() // warning 
}

위의 코드는 Task 구문 내부에서 다음과 같은 경고가 나타난다.

Capture of ‘counter’ with non-sendable type ‘Counter’ in a @Sendable closure

위의 코드는 멀티 스레드 환경에서 안전하게 사용할 수 있도록 되어있는지 알 수 없다.

만약 Counter를 Sendable로 만들게 된다면

class Counter: Sendable { // warning 1
  let lock = NSLock() // warning 2
  var count = 0 // warning 3
  func increment() {
    self.lock.lock()
    defer { self.lock.unlock() }
    self.count += 1
  }
}

경고:

1. Non-final class ‘Counter’ cannot conform to ‘Sendable’; use ‘@unchecked Sendable’
2. Stored property ‘lock’ of ‘Sendable’-conforming class ‘Counter’ has non-sendable type ‘NSLock’
3. Stored property ‘count’ of ‘Sendable’-conforming class ‘Counter’ is mutable

NSLock은 우리가 제어할 수 있는 타입이 아니기 때문에 Sendable로 만들 수 없다.

위의 코드가 멀티 스레드 환경에서 안전하게 사용할 수 있다고 확신한다면 컴파일러에게 @unchecked로 알려줄 수 있다.

class Counter: @unchecked Sendable {
  let lock = NSLock()
  var count = 0
  func increment() {
    self.lock.lock()
    defer { self.lock.unlock() }
    self.count += 1
  }
}

이제 경고가 발생하지 않고 컴파일이 되지만 위의 코드는 컴파일러가 안전성을 체크하지 않기 때문에 조심해야 한다.

@Sendable closures

@Sendable 클로저는 클로저가 동시성 작업에서 사용되는 것을 나타낸다.

이를 이해하기 위해 먼저 @escaping 클로저에 대해 알아보자.

아래와 같은 클로저를 매개변수로 받는 함수는 함수 범위 내에서 해당 클로저를 호출할 수 있다.

func perform(work: () -> Void) {
  work()
}

그러나 클로저를 함수 범위를 벗어나 사용하려하면 컴파일러가 경고를 나타내게 된다.

예를들어, 네트워크 통신을 통해 다운로드 작업을 완료한 후 클로저를 호출해보면 경고가 나타난다.

func perform(work: () -> Void) {
  print("Begin")
  URLSession.shared.dataTask(
    with: .init(string: "<http://ipv4.download.thinkbroadband.com/1MB.zip>")!
  ) { _, _, _ in
    work()
  }
  print("End")
}

// Warning: Escaping closure captures non-escaping parameter ‘work’

Escaping 클로저는 함수 실행 범위가 끝난 후에도 참조되어야 하는 클로저이다. dataTask의 경우 호출 즉시 반환되기 때문에 클로저가 함수 실행 범위 이후까지 유효해야 한다.

때문에 Non-escaping 클로저를 호출하게 되면 컴파일러가 경고하게 된다.

Swift에서는 클로저가 함수 실행 범위를 벗어나는지에 대한 여부를 중요하게 생각한다.

이를 뒷받침 하기 위한 예시를 살펴보자면,

func incrementAfterOneSecond(value: inout Int) {
  DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
    value += 1
  }
}

1초 후에 값을 증가시키는 함수가 있다고 가정해보자.

var count = 0
incrementAfterOneSecond(value: &count)
assert(count == 0)
Thread.sleep(forTimeInterval: 2)
assert(count == 1)

위의 코드가 유효한 코드라고 가정했을 때, 첫번째 assert에서는 0일 것이다.

그러나 2초 대기 후 값이 자동으로 1로 업데이트가 된다면 뭔가 어색한 동작으로 보인다. 왜냐하면 count는 값 타입인데 참조타입처럼 동작하기 때문이다.

위와 같은 원격 조작(spooky action at a distance)은 값 타입의 본질을 무너뜨리기 때문에 Swift에서는 Escaping 클로저를 통해 이러한 동작을 방지하고자 한다.

그렇기 때문에 Swift에서는 inout 값을 Escaping 클로저 내부로 전달하는 것은 허용되지 않는다.

func perform(work: @escaping () -> Void) {
  print("Begin")
  DispatchQueue(label: "delay").asyncAfter(deadline: .now() + 1) {
    work()
  }
  print("End")
}
perform {
  print("Hello")
}

그래서 work클로저를 asyncAfeter 내에서 실행할 수 있도록 하기 위해서는 @escaping을 명시적으로 추가해야 한다. @escaping 을 통해 클로저가 함수의 생명주기 이후에도 호출될 수 있음을 알려주게 된다.

그치만 async 를 통해 @escaping이 필요하지 않은 클로저를 사용할 수 있다.

func perform(work: () -> Void) async throws {
  print("Begin")
  _ = try await URLSession.shared.data(from: .init(string: "<http://ipv4.download.thinkbroadband.com/1MB.zip>")!)
  work()
  print("End")
}

Task {
  try await perform {
    print("Hello")
  }
}

출력:

Begin
Hello
End

async 를 사용하게 되면서 work 클로저가 함수 범위 내에서만 호출된다. await 키워드를 통해 작업이 완료될 때 까지 대기하게되어 @escaping 키워드 없이도 문제가 발생하지 않게 된다.

그렇기 때문에 Escaping 클로저에서는 사용이 불가능했던 inout값 또한 처리할 수 있게 된다.

func perform(value: inout Int, work: () -> Void) async throws {
  print("Begin")
  let (data, _) = try await URLSession.shared.data(from: .init(string: "<http://ipv4.download.thinkbroadband.com/1MB.zip>")!)
  work()
  value += data.count
  print("End")
}

Task {
  var count = 0
  try await perform(value: &count) {
    print("Hello")
  }
  print("count", count)
}

출력:

Begin
Hello
End
count 1048576

다시말해, 모든 작업이 완료된 후 함수가 종료됨을 보장하기 때문이다.

✔️ 동시성 작업에서의 Non-escaping

하지만, work 클로저를 여러 번 동시에 실행하고싶어 두개의 Task를 생성하게 된다면 오류가 발생하게 된다.

Task{}는 클로저를 생성된 태스크 이후에 호출해야 하기 때문에 escaping 클로저여야 한다.

하지만 여전히 오류가 발생하는데, 그 이유는 @Sendable이 필요한 컨텍스트 내에서 @Sendable이 아닌 데이터를 사용하고 있기 때문이다.

클로저가 외부 데이터를 캡쳐하고 수정하게 된다면 race condition문제를 일으킬 수 있기 때문에 동시성 작업을 할 때는 안전한 클로저를 요구하게 된다. @Sendable이 필요한 이유이다.

func perform(work: @escaping @Sendable () -> Void) {
  …
}

@Sendable클로저는 외부의 가변 상태 데이터를 캡쳐하거나 변경하지 못하도록 한다.

@Sendable 클로저를 추가하게되면서 Swift는 클로저가 동시성 작업에서 사용된다는 것을 알게된다. 그렇기 때문에 count라는 가변 변수를 캡쳐하지 못하도록 제한한다.

@Sendable 속성은 함수가 여러 동시성 작업에서 안전하게 사용될 수 있음을 컴파일러에게 증명하는 역할을 한다.

@Sendable 은 내부에 클로저를 가지고 있는 타입이 Sendable프로토콜을 준수하도록 할 수 있다.

예를들어, 데이터베이스에 접근하는 작업을 추상화하여 설계한다고 가정해보자.

struct DatabaseClient {
  var fetchUsers: () async throws -> [User]
  var createUser: (User) async throws -> Void
}

위와 같은 구조체가 있다고 할 때 위의 구조체는 동시성 작업에서 안전하게 사용하지 못한다.

이는 DatabaseClient가 Sendable 타입이 아니기 때문이다.

그렇다면 명시적으로 DatabaseClient를 Sendable 을 준수하도록 한다면, 내부 프로퍼티가 Sendable 타입이 아니기 때문에 또 문제가 발생하게 된다.

내부 클로저는 sendable 타입이 아닌 어떠한 클로저든 가능하기 때문에 가변 데이터를 읽고 쓸 가능성이 있다.

struct DatabaseClient {
  var fetchUsers: @Sendable () async throws -> [User]
  var createUser: @Sendable (User) async throws -> Void
}

DatabaseClient가 Sendable타입을 충족하려면 내부 프로퍼티의 클로저를 @Sendable로 명시적으로 지정해야 한다.

@Sendable을 통해 사용할 수 있는 클로저의 종류를 제한하여 컴파일러에게 sendable 타입임을 증명할 수 있다.

Actor

@Sendable을 통해 동시성 작업에서의 안정성을 보장할 수 있게 되었다. Sendable을 만족하지 않을 경우 컴파일러가 문제를 알려주게 된다.

하지만 @unchecked Sendable은 Sendable을 준수하는지 컴파일러가 확인하지 않고 강제적으로 준수한다고 컴파일러에게 알려주게 된다.

class Counter: @unchecked Sendable {
  let lock = NSLock()
  var count = 0
  func increment() {
    self.lock.lock()
    defer { self.lock.unlock() }
    self.count += 1
  }
}

이러한 방식은 문제가 발생하더라도 컴파일러가 감지하지 못하기 때문에 신뢰성이 떨어지는 코드이다.

코드가 변경되어 Race Condition 문제가 발생하게 될 수 있기 때문이다.

이러한 Data Race 발생 위험성 문제를 해결하기 위해 Swift 5.5에서는 새로운 타입인 Actor가 도입되었다.

Actor는 구조체, 열거형, 클래스와 같이 새로운 타입이다.

actor counterActor {
}

클래스처럼 참조타입이지만, 데이터를 보호하고 메서드 호출을 동기화한다.

actor CounterActor {
  var count = 0
  var maximum = 0
  func increment() {
    self.count += 1
    self.maximum = max(self.count, self.maximum)
  }
  func decrement() {
    self.count -= 1
  }
}

위에서 사용한 코드와 같이 클래스로 구현할 경우 동시성 환경에서 count 변수에 대해 data race 발생 가능성이 존재했지만, actor 타입을 사용할 경우 이러한 문제가 해결된다.

Actor를 사용하게 되면 접근을 제한하기 위한 락을 사용할 필요가 없게 된다.

✔️ Actor의 DataRace 방지

여러 스레드를 생성하여 increment()메서드를 호출하려 하면 오류가 발생한다.

위의 오류는 Swift가 DataRace를 발생시킬 수 있는 작업을 하지 못하도록 막는 것이다.

Actor의 핵심 원칙은 내부 데이터를 보호이기 때문에 Actor 내부의 메서드는 비동기 컨텍스트에서만 호출할 수 있다.

여러 스레드에서 increment()메서드에 접근하려고 할 경우 이전 작업이 완료될 때 까지 다른 스레드는 기다려야 한다. 하지만 스레드가 대기 상태에 있으면 리소스가 낭비될 수 있다.

Actor는 락을 사용하지 않고 비동기 방식으로 동기화 처리를 한다. 스레드가 대기해야 할 경우 스레드를 차단하지 않고 다른 작업을 실행할 수 있도록 넘기게 된다.

그렇기 때문에 Actor내의 메서드를 호출하기 위해서는 비동기 컨텍스트에서 await 키워드를 통해 호출해야 한다.

for _ in 0..<1000 {
  Task {
    await counter.increment()
  }
}

Actor를 통해 데이터 보호와 시스템 효율성을 달성할 수 있게 된다.

Actor 내부에서는 increment() 메서드를 async로 선언하지 않았지만, await을 사용하여 호출해야 한다.

Actor 내부에서만 보면 increment()는 동기적이다. Actor 내부는 완전히 동기화 된 컨텍스트 내에 있기 때문에 가변 데이터를 자유롭게 읽고 쓸 수 있다.

func increment() {
  self.count += 1
  self.maximum = max(self.maximum, self.count)
}

그렇기 때문에 Actor 내에 있는 메서드 내에서도 프로퍼티나 또 다른 메서드를 호출할 때 await을 사용하지 않고도 접근할 수 있다.

하지만 Actor 외부에서는 여러 작업이 동시에 increment()메서드를 호출할 수 있기 때문에 동기적으로 호출할 수 없다.

Actor는 순차적으로 처리하기 위한 동기화 작업이 필요하고, 효율적으로 처리되기 위해서는 비동기 컨텍스트에서 작동해야 한다.

메서드 뿐만아니라 프로퍼티 접근 또한 비동기 환경에서 이루어져야 한다. 다른 작업에서 프로퍼티 수정을 할 경우 잘못된 값을 얻을 수 있기 때문이다.

Thread.sleep(forTimeInterval: 1)
Task {
  await print("counter.count", counter.count)
}

Actor를 통해 우리는 동기 코드처럼 코드를 작성할 수 있고, datarace 문제에 신경쓰지 않아도 된다. Actor 외부에서 Actor와 상호작용 할 때에만 비동기 컨텍스트를 신경쓰면 된다.

만약 1000 번의 증가, 감소 작업을 수행 중에 count와 maximum 값을 출력시키면 어떤 결과가 나올까?

같은 코드인데 maximum 값이 다르게 출력된다.

이는 race condition을 의미하는 것이 아니다. 이는 비 결정론적인 예시이다.

1000 번의 증가와 1000번의 감소 작업이 동시에 실행되고 있는데, 이 작업들의 실행 순서는 결정론적이지 않다.

즉, 어떠한 경우에는 increment 작업이 연속적으로 실행되어 maximum값이 높아질 수 있고, 다른 경우에는 increment와 decrement 작업이 번갈아 실행될 수 있다.

➡️ 작업의 순서는 예측할 수 없기 때문에 값이 달라질 수 있는 것이다.

별도로 작업의 우선순위를 어떻게 지정하느냐에 달려있기 때문에 비결정론이 도입되어있는 것을 의미한다.

Swift의 새로운 동시성 도구는 기존의 동시성 도구보다 훨씬 강력한 기능을 가지고 있다.

Swift 언어와의 통합
비동기와 동시성 개념이 언어에 직접적으로 통합되어있다. async 키워드를 통해 비동기 작업을 명확히 표현할 수 있으며, Sendable 프로토콜과 @Sendable 속성을 통해 동시성 환경에서 사용 가능한 데이터를 표현할 수 있게 되었다.
효율적인 작업 관리
명시적으로 스레드 풀이나 작업 큐를 관리하지 않더라도 Swift는 생성되는 스레드 수를 제한하며 수천개의 동시 작업을 수행할 수 있게 되었다.
향상된 Task
Task는 기존 도구들의 기능을 모두 가지고 있을 뿐만아니라 기능들이 더 향상되었다. 취소나 저장 기능은 하위 Task에도 전달이 가능해졌다.
효율적인 스레드 사용
Non-blocking 비동기 함수나 Task.yield와 같은 도구를 통해 스레드를 점유하지 않고 다른 작업이 스레드를 사용할 수 있도록 중단할 수 있다.
Actor
Swift는 Actor라는 새로운 타입을 통해 컴파일러가 Data race 문제를 감지할 수 있게 되었다. Actor를 통해 코드를 간단하고 동기 코드 처럼 작성할 수 있지만 내부적으로는 가변 데이터에 대한 접근을 제한하는 기능을 한다.

다음 내용

4. 동시성프로그래밍: Sendable, Actor

[iOS/Point-Free] 동시성프로그래밍: Task

김졀니 — Wed, 18 Dec 2024 16:00:22 +0900

PointFree 강의 정리 내용입니다!

https://www.pointfree.co/episodes/ep192-concurrency-s-future-tasks-and-cooperation#task-cooperation

Episode #192: Concurrency's Future: Tasks and Cooperation

Let’s look at what the future of concurrency looks like in Swift. A recent release of Swift came with a variety of tools with concurrency. Let’s examine its fundamental unit in depth, and explore how they “cooperate” in your applications.

www.pointfree.co

이전 내용

1. 동시성의 과거: Thread

2. 동시성프로그래밍: OperationQueue, GCD, Combine

Concurrency's Future: Tasks and Cooperation

Task Basic

Task

Task는 Swift 5.5부터 새로 출시된 동시성 도구이다. Task는 비동기작업을 실행하는 기본 단위이고, 다음과 같이 생성할 수 있다.

Task {
  print(Thread.current)
}

<NSThread: 0x1062040f0>{number = 2, name = (null)}

내부에서 실행되는 스레드의 정보를 출력해보면 새로운 스레드에서 실행되고 있는 것을 볼 수 있다.

이 내용은 Thread의 detachNewThread메서드와 유사하게 동작하지만 스레드 생성과 작업을 수행하는 방식을 자동으로 처리한다는 점에서 다르다.

Task의 타입은 다음과 같다.

Void와 Never 두 개의 제네릭을 반환하게 된다.

첫 번째 제네릭은 비동기 작업이 끝난 후 생성되는 값의 타입을 나타내고, 두 번째 제네릭은 클로저 내부에서 던질 수 있는 에러의 타입을 나타낸다.

다음과 같이 실행 결과의 타입과 에러 타입을 정의할 수 있다.

let task: Task<Int, Error> = Task {
  struct SomeError: Error {}
  throw SomeError()
  return 42
}

async/await

Task의 초기화 구문에 있는 클로저에는 async키워드가 포함되어 있다.

async는 해당 키워드가 붙은 함수에서 비동기 작업을 수행할 것임을 선언하는 것을 의미한다.

async키워드는 비동기 컨텍스트를 제공해야만 호출을 할 수 있다.

예를 들어, 다음과 같은 async로 선언된 함수가 있다.

func doSomethingAsync() async {
}

이 함수는 비동기 컨텍스트에 있지 않다면 이 함수를 직접 호출할 수 없다.

doSomethingAsync() // 컴파일 에러 발생

이 함수는 Task 컨텍스트 내부에서 호출할 수 있으며, await키워드를 붙여야 한다.

Task {
  await doSomethingAsync()
}

Task는 새로운 비동기 컨텍스트를 생성하기 때문에 위와 같이 비동기 함수 호출이 가능한 것이다.

await은 비동기 함수를 호출할 때 사용하는 것으로, 비동기 작업을 시작하며 현재 작업을 중단하고 다른 작업이 스레드를 사용할 수 있도록 현재 스레드를 포기하도록 한다. 비동기 작업이 완료되면 Task는 다시 실행을 재개하고, 재개 시에는 이전과 다른 스레드에서 실행될 수도 있다.

또, 다른 비동기 함수에서 비동기 함수를 다음과 같이 호출할 수 있다.

func doSomethingElseAsync() async {
  await doSomethingAsync()
}

이러한 방식은 이전에 스레드와 큐를 사용한 방식과 완전히 다르다. 이전에는 비동기 코드와 동기 코드 간에 컴파일러 단계에서 구분을 하지 않았다.

동기-비동기 코드의 구분

새로운 비동기 처리 도구에서는 동기코드와 비동기 코드를 컴파일 타임에 구분하게 된다.

이 내용은 Swift의 오류처리와 유사하다.

예를 들어, 오류를 던질 수 있는 함수는 throws로 명시해야하며, 호출 시 실패에 대한 처리를 해야 호출할 수 있다.

func doSomethingThatCanFail() throws {} // 오류 가능 함수

doSomethingThatCanFail() // 오류
try doSomethingThatCanFail() // try로 실패에 대한 처리 - 호출 성공

또, 새로운 함수 내에서 그냥 호출하면 문제가 발생한다.

func doSomething() {
  try doSomethingThatCanFail()
}

이를 해결하기 위해서는 함수를 실패할 수 있는 컨텍스트로 만들거나 do-catch 구문을 통해 실패 가능 컨텍스트를 생성하여 실패 시 오류를 처리할 수 있는 작업을 정의해야 한다.

func doSomethingElseThatCanFail() throws {
  try doSomethingThatCanFail()
}

// 또는 

func doSomething() {
  do {
    try doSomethingThatCanFail()
  } catch {
    // 오류 처리
  }
}

Task도 이와 유사하게 동작한다.

이러한 컴파일러 수준에서의 관리는 부적절한 컨텍스트에서 비동기 작업 또는 실패 가능한 작업을 수행하지 못하도록 방지한다.

syntactic sugar

함수에서 사용하는 키워드들은 복잡한 동작을 간단히 표현하는 syntactic sugar이다.

throws

오류를 던지는 throws 키워드를 가진 함수는 Result<> 타입을 반환하는 함수로 풀어 설명할 수 있다.

(A) throws -> B

(A) -> Result<B, Error>

async

비동기 함수에서 async 키워드를 제거하고 Task<> 타입을 반환하도록 할 수 있다.

(A) async -> B

(A) -> Task<B, Never>

Task 타입을 다음과 같이 풀어 설명할 수 있다.

(A) -> ((B) -> Void) -> Void

이를 언커리 하여 두개의 인수를 받는 형태로 만들 수 있다.

(A, (B)->Void) -> Void

위와 같은 형태는 콜백 핸들러의 기본 형태이다. 대부분의 Apple 비동기 api는 이러한 형태를 사용하였다.

// URLSession의 콜백 핸들러 예시
dataTask: (URL, (Data?, Response?, Error?) -> Void) -> Void

위와 같은 형태는 Swift 언어 자체에서 비동기를 지원하게 되며 async 키워드를 통해 복잡한 구문을 간단하게 나타낼 수 있게 되었다.

(A) async -> B

Task의 스레드 관리

Task에서 여러 개의 작업을 실행하면 여러 개의 스레드가 생성된다.

Task { print("1", Thread.current) }
Task { print("2", Thread.current) }
Task { print("3", Thread.current) }
Task { print("4", Thread.current) }
Task { print("5", Thread.current) }

2 <NSThread: 0x1062040f0>{number = 3, name = (null)}
1 <NSThread: 0x106004bd0>{number = 4, name = (null)}
3 <NSThread: 0x106105c90>{number = 5, name = (null)}
4 <NSThread: 0x106004430>{number = 6, name = (null)}
5 <NSThread: 0x106007f40>{number = 7, name = (null)}

그리고 Thread나 Operation Queue에서 처럼 실행 순서는 보장되지 않는다.

이는 DispatchQueue에서와 달리 기본적으로 동시성 모델을 사용하는 것을 의미한다.

그렇다면 1,000개의 작업을 생성할 때 마다 스레드가 생성될까?

for n in 0..<1000 {
  Task {
    print(n, Thread.current)
  }
}

1 <NSThread: 0x1011caaa0>{number = 2, name = (null)}
0 <NSThread: 0x101304100>{number = 3, name = (null)}
14 <NSThread: 0x101304100>{number = 3, name = (null)}
...
988 <NSThread: 0x1011caaa0>{number = 2, name = (null)}
804 <NSThread: 0x1015040f0>{number = 7, name = (null)}
923 <NSThread: 0x100710190>{number = 11, name = (null)}
989 <NSThread: 0x10070e380>{number = 5, name = (null)}

위의 결과로 보아 대략 10개 정도의 스레드만 생성된다.

Task는 스레드 풀을 활용하여 Thread Explosion문제를 해결할 수 있다.

기존 스레드나 큐에 비해 개선된 점은 스레드 관리를 직접 하지 않아도 된다는 부분이다.

또, Task는 일정 시간 대기 후 작업을 스케줄링 할 수 있다. 기존에는 sleep 을 사용하여 비효율적이게 처리하였는데, Task에서는 비동기로 동작하고 예외를 던질 수 있는 정적 메서드 sleep이 있다.

try await Task.sleep(nanoseconds: UInt64)

기존 스레드에서 사용하던 sleep과 매우 다른 메서드이다.

Task.sleep() 은 작업을 일정 시간동안 중단하지만, 스레드를 점유하고 있지 않는다.

예를 들어, 1000개의 작업을 생성하고 1초동안 중단하도록 하면

for n in 0..<1000 {
  Task {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC * 1000)
  }
}

대기하는 동안 작업은 중단되며 해당 스레드는 다른 작업에서 사용할 수 있도록 해제된다.

중단점을 통해 스레드를 확인해보면, 적은 수의 스레드가 생성되고, 단일 스택 프레임만 가지고 있음을 확인할 수 있다.

Thread 2#0        0x00000001a05ef604 in __workq_kernreturn ()
Thread 3#0        0x00000001a05ef604 in __workq_kernreturn ()
Thread 4#0        0x00000001a05ef604 in __workq_kernreturn ()
...

\_\_workq\_kernreturn() 함수는 GCD가 스레드를 작업이 스케줄링될 때 까지 대기상태로 유지하는 방식이다. 이는 스레드가 아무 작업을 하지 않는 상태에서 가벼운 방식으로 관리 되는 것을 의미하며, 다른 작업을 처리하는데 자유롭게 활용될 수 있다.

즉, Task.sleep 은 협력적 방식으로 동작하여 다른 작업이 실행될 수 있도록 한다. 시간이 지나 중단된 작업이 다시 실행되지만, 하나의 스레드를 점유하고 있지 않아 효율적이다.

또, 다시 작업이 재개될 때 이전과 다른 스레드에서 재개될 수 있다.

for _ in 1...workCount {
  Task {
    let current = Thread.current
    try await Task.sleep(nanoseconds: 1_000_000)
    if current != Thread.current {
      print("Thread changed from", current, "to", Thread.current)
    }
  }
}

944 Thread changed from <NSThread: 0x10648a790>{number = 2, name = (null)} to <NSThread: 0x1063044c0>{number = 3, name = (null)}
945 Thread changed from <NSThread: 0x1063044c0>{number = 3, name = (null)} to <NSThread: 0x10648a790>{number = 2, name = (null)}
...

그렇기 때문에 인접한 코드가 동일한 스레드에서 실행될 것이라고 가정해서는 안된다.

Task 우선순위와 취소

우선순위

Task는 다른 동시성 도구들 처럼 우선순위 개념을 지원한다.

Task(priority: .low) {
  print("low")
}
Task(priority: .high) {
  print("high")
}

high
low

우선순위를 통해 Task의 중요도를 전달할 수 있고, 런타임 시 여러 조건에 따라 작업마다 할당 시간을 적절히 부여할 수 있다.

취소

취소 또한 다른 도구들과 마찬가지로 지원하는 개념이다.

let task = Task {
  print(Thread.current)
}
task.cancel()

<NSThread: 0x106204290>{number = 2, name = (null)}

Task를 변수에 할당하고, 취소를 요청할 수 있다.

하지만 print구문이 그대로 출력된다.

Task는 생성 직후 바로 취소하더라도 작업이 시작되는 경우가 많다.

✔️ 협력적 취소

Task의 작업을 즉시 중단하기 위해서는 협력적인 방식으로 확인해야 한다.

취소가 요청되었다고 바로 종료되지 않기때문에, 개발자가 취소 상태를 확인하고 작업을 종료하는 방식으로 종료를 구현해야 한다.

이러한 이유는 열려있는 리소스를 닫아야 하는 경우에 안전성을 보장할 수 있기 때문이다.

Task의 취소 여부를 확인하기 위해 Task.isCancelled 를 통해 boolean 값을 확인할 수 있다.

let task = Task {
  guard !Task.isCancelled else {
    print("Cancelled!")
    return
  }
  print(Thread.current)
}
task.cancel()

Cancelled!

Task.isCancelled 는 현재 Task의 취소 상태를 나타낸다. 이는 전역변수가 아니라 Task에만 국한된 로컬 값이기 때문에 현재 실행중인 Task의 취소 여부는 Task 컨텍스트 내에서만 확인할 수 있다.

✔️ 현재 Task

Task에는 Thread.current 와 같이 Task.current 속성은 존재하지 않는다. 스레드와 달리 모든 코드가 Task 컨텍스트 내에서 실행되는 것이 아니기 때문이다.

현재 Task를 가져오기 위해서는 withUnsafeCurrentTask 를 활용해야 한다.

Task {
  withUnsafeCurrentTask { task in
    print(task)
  }
}

Optional(Swift.UnsafeCurrentTask(_task: (Opaque Value)))

위와 같이 사용하여 가져올 수 있다.

✔️ Task의 취소 여부: 예외처리

Task의 취소는 언어 레벨에서 더 깊이 통합되어 있다.

비동기 작업에서 작업이 실패할 가능성이 있는 경우, 취소 여부를 확인하는 방식으로 Task.isCancelled 를 통한 boolean값 검사 대신 예외처리를 사용하여 효과적으로 사용할 수 있다.

let task = Task {
  try Task.checkCancellation()
  print(Thread.current)
}
task.cancel()

Task.checkCancelled() 를 호출할 경우 Task가 취소된 상태라면 예외를 던지게 되고, 그 뒤의 나머지 코드는 실행되지 않는다.

✔️ 협력적 취소: 취소의 전달

Thread나 DispatchQueue에서는 스레드를 sleep상태로 만들거나 내부 작업이 생성되었을 때 취소가 전달되지 않는 문제가 있었다.

하지만 Task에서는 내부의 비동기 작업 또한 취소되는 협력적 취소 개념을 가지고 있다.

예를 들어, Task를 1초 동안 sleep 상태로 만든 후 0.1초 뒤에 취소해보자.

let task = Task {
  let start = Date()
  defer { print("Task finished in", Date().timeIntervalSince(start)) }
  try await Task.sleep(nanoseconds: NSEC_PER_SEC)
  print(Thread.current) // 스레드 정보 출력
}

Thread.sleep(forTimeInterval: 0.1)
task.cancel()

Task finished in 0.10534894466400146

위와 같은 결과는 Task.sleep이 취소 이벤트를 확인하고, sleep을 조기에 종료하였음을 의미한다.

즉, Task가 취소됨에 따라 나머지 작업이 즉시 중단되었다.

이번에는 비동기 함수 내부에서 sleep을 호출한 후 취소를 해보자.

func doSomething() async throws {
  try await Task.sleep(nanoseconds: NSEC_PER_SEC)
}

let task = Task {
  let start = Date()
  defer { print("Task finished in", Date().timeIntervalSince(start)) }

  try await doSomething()
  print(Thread.current)
}

Thread.sleep(forTimeInterval: 0.1)
task.cancel()

Task finished in 0.10534894466400146

결과는 동일하다.

스레드, OperationQueue, Dispatch Queue에서는 작업 단위의 취소 상태를 관찰하고 직접 취소를 구현해야 했지만 Task에서는 취소가 내부작업까지 전달된다.

또 다른 예시로, URLSession을 통해 큰 파일을 다운로드하고, 다운로드가 완료되기 전에 취소를 해보자.

let task = Task {
  let start = Date()
  defer { print("Task finished in", Date().timeIntervalSince(start)) }

  let (data, _) = try await URLSession.shared.data(
    from: URL(string: "<http://ipv4.download.thinkbroadband.com/1MB.zip>")!
  )
  print(Thread.current, "network request finished", data.count)
}

Thread.sleep(forTimeInterval: 0.5)
task.cancel()

Task finished in 0.5094579458236694

“network request finished”가 출력되지 않는 것으로 보아 Task는 네트워크 요청 진행 중일 때에도 취소를 감지하고 작업을 종료할 수 있다.

Task의 협력적 취소는 리소스를 절약할 수 있도록 동작하는 것을 볼 수 있다.

Task Locals

기존 스레드와 Dispatch Queue에서는 데이터를 저장하기 위해 스레드 딕셔너리와 specifics를 사용하였다.

해당 방식에는 몇가지 문제점이 있었다.

스레드 딕셔너리는 [AnyHashable: Any] 타입을 사용했기 때문에 타입 안정성이 부족했고, 강제 캐스팅을 사용해야 했다.
새로운 스레드를 생성하였을 때 기존의 스레드 딕셔너리를 상속할 수 없었다.
DispatchQueue에서 기존 큐를 타겟으로 설정하여 specifics를 전달할 수 있었지만, 이를 명시적으로 값을 전달하는 작업을 구현해야 하고, 모든 큐에서 공통으로 접근할 수 있는 “현재 큐”의 개념이 없다.

Task는 이러한 한계점을 보완하기 위해 Task Local Values라는 기능을 제공한다.

Task Local값을 사용하면 특정 값을 Task에 연결하고, 해당 Task 컨텍스트 내에서 어디든 해당 값을 쉽게 조회할 수 있다.

✔️ TaskLocal 정의

이전에 예시로 사용한 네트워크 통신 시 효율적인 로그 조회를 위한 요청 ID 할당을 사용해보자.

Task에 저장할 값을 보관하기 위한 타입을 정의한다.

enum MyLocals {
  @TaskLocal static var id: Int!
}

@TaskLocal property wrapper를 사용하여 정적 변수를 정의한다.

변수는 반드시 static이어야 하므로 기본 값을 설정해야 한다. 임의의 기본 값을 사용하는 것 보다 사용하기 전에 초기화를 반드시 해야하는 명시적 언래핑 옵셔널을 사용하는 것이 나은 선택이다.

✔️ TaskLocal 값 조회

print(MyLocals.id) // nil

MyLocals 타입에 직접 접근하여 확인할 수 있다.

✔️ 값 설정

withValue 메서드를 사용하여 값을 설정할 수 있다.

이 메서드는 설정하려는 값과 클로저를 매개변수로 가지고 있다.

MyLocals.$id.withValue(
  valueDuringOperation: Int?, operation: () throws -> R
)

이러한 방식은 기존 스레드나 DispatchQueue에서 직접 값을 수정할 수 있던 방식과 다르다.

클로저를 통해 값의 수명을 제어하는 방식으로 설계되어 클로저 실행 동안에만 값이 설정되고, withValue 실행이 끝나면 원래 값으로 복원된다.

매개변수 이름 valueDuringOperation 도 이러한 기능을 암시한다.

print("before:", MyLocals.id)
MyLocals.$id.withValue(42) {
  print("withValue:", MyLocals.id!)
}
print("after:", MyLocals.id)

before: nil
withValue: 42
after: nil

값을 설정하고 클로저 내부에서 값을 확인해보면 클로저 내부에서는 값이 변경되지만 클로저 실행이 끝나고 나면 다시 nil로 돌아간다.

변경된 값이 클로저 내부에서만 유효하지만 이 값을 더 오래 유지할 수 있는 방법이 있다.

새로운 Task를 시작하게되면 해당 시점의 모든 Task Local 값이 자동으로 상속된다.

✔️ 상속

print("before:", MyLocals.id)
MyLocals.$id.withValue(42) {
  print("withValue:", MyLocals.id!)
  Task {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC)
    Task {
      print("Task:", MyLocals.id!)
    }
  }
}
print("after:", MyLocals.id)

before: nil
withValue: 42
after: nil
Task: 42

내부에 새롭게 생성된 Task는 withValue가 종료된 이후에도 변경된 값을 유지하는 것을 볼 수 있다.

이러한 것이 가능한 이유는 새로운 Task를 생성하는 순간 현재 Task의 Task Local 값이 캡쳐되기 때문이다. 그렇기 때문에 withValue 클로저가 끝난 후 nil로 초기화 되어도 새로운 Task에서는 값이 유지가 된다.

다른 비동기 함수를 호출해도 캡쳐된 값이 함수 내에서도 사용 가능하다.

func doSomething() async {
  print("doSomething:", MyLocals.id!)
}

print("before:", MyLocals.id)
MyLocals.$id.withValue(42) {
  print("withValue:", MyLocals.id!)
  Task {
    try await Task.sleep(nanoseconds: NSEC_PER_SEC)
    Task {
      print("withValue Task:", MyLocals.id!)
      await doSomething()
    }
  }
}
print("after:", MyLocals.id)

before: nil
withValue: 42
after: nil
Task: 42
doSomething: 42

Task Local은 특정 범위의 생명주기를 기준으로 값을 설정하도록 설계되어있다.

이를 이용하여 이전의 스레드나 DispatchQueue 방식보다 비동기 작업 흐름 속에서 값을 전달할 수 있다.

Task Cooperation

여러 작업 단위를 동시에 실행하려 할 때 스레드는 Thread Explosion 문제가 발생하고, 모든 스레드가 CPU 시간을 놓고 경쟁을 하는 상황이 발생했다. 반면 Diapatch Queue는 스레드 풀을 사용하여 스레드의 수를 낮게 유지하여 과부하를 방지했지만, 풀 내의 스레드 수가 제한되어 있기 때문에 너무 많거나 긴 작업이 할당될 경우 작업 처리가 오래걸리게 된다.

for _ in 0..<1000 {
  Thread.detachNewThread {
    while true {}
  }
}

Thread.detachNewThread {
  print("Starting prime thread")
  nthPrime(50_000)
}

이전에 위와 같이 1000개의 스레드를 생성하여 무한 루프에 빠지게 하여 바쁘게 유지한 뒤 새로운 스레드를 생성하여 50,000번째 소수를 구하도록 하여 테스트를 해보았다.

작업 처리 시간이 오래 걸리거나 스레드 풀이 막혀 작업을 진행할 수 없는 상황이 발생했었다.

위와 같은 상황을 Task를 사용하도록 변경하여 살펴보자.

for _ in 0..<workCount {
  Task {
    while true {}
  }
}

Task {
  print("Starting prime task")
  nthPrime(primeN)
}

이 코드를 실행하면 아무 출력도 나타나지 않게 되는데, 중단점을 통해 스레드 상태를 확인해보면 10개의 스레드가 활성 상태에 있지만 모두 무한 루프에 의해 막혀있는 것을 볼 수 있게 된다.

이러한 제한이 발생하는 이유는 컴퓨터에는 결국 유한한 수의 코어가 있기 때문이다.

코어 수 보다 훨씬 더 많은 스레드를 생성할 수 있다고 하더라도 무분별하게 사용하게 되면 스레드와 리소스의 폭발적인 증가로 이어져 스레드가 실행 시간을 두고 싸우게 될 수 있다.

Swift는 작업을 처리하기 위해 무한히 많은 스레드를 생성할 수 있는 척하지 않고, 더 작고 합리적인 수의 스레드를 생성하도록 한다.

또, 비동기 작업을 처리할 대 모든 작업이 제한된 스레드를 함께 사용하도록 한다. 즉, 다른 작업도 실행할 수 있도록 각 작업이 협력해야 한다.

✔️ Non-Blocking API

Swift는 이 협력을 이루기 위해 Non-Blocking API를 사용한다. 비동기 컨텍스트에서 오랜 시간 동안 블로킹 하지 않는 것이 중요하기 때문이다.

이전에 살펴본 await 을 통해 Non-Blocking 작업을 수행할 수 있다.

for n in 0..<1000 {
  Task {
    let (data, _) = try await URLSession.shared.data(
      from: URL(
        string: "<http://ipv4.download.thinkbroadband.com/1MB.zip>"
      )!
    )
    print(n, data.count, Thread.current)
  }
}

위 코드는 네트워크 요청을 처리하면서 다른 작업도 동시에 진행할 수 있도록 한다.

✔️ Task.yield()

비동기 컨텍스트에서 await 을 통해 문제없이 Non-Blocking 작업을 수행할 수 있지만 때로는 어느정도 스레드를 점유해야 할 정도로 무거운 계산 작업을 수행해야 할 경우가 있다.

이러한 경우 Task의 스레드를 일시적으로 양보하여 다른 작업이 스레드를 사용할 수 있도록 하는 도구를 제공한다.

await Task.yield()

yield 메서드는 비동기 메서드로 await과 함께 사용해야 한다.

Task.yield()는 현재 태스크의 스레드를 중단하고 다른 태스크에서 사용할 수 있도록 한다. 이후 제어권이 다시 돌아오면 이어서 작업을 수행할 수 있다.

스레드를 양보함으로써 동시에 여러 작업을 실행하더라도 전체 스레드를 점유하지 않게 된다.

[iOS/Point-Free] 동시성 프로그래밍: OperationQueue, CGD와 Combine

김졀니 — Wed, 11 Dec 2024 17:13:34 +0900

다음 내용은 Point-Free의 Concurrency 강의를 듣고 정리한 내용입니다!

https://www.pointfree.co/episodes/ep191-concurrency-s-present-queues-and-combine

Episode #191: Concurrency's Present: Queues and Combine

Before developing Swift’s modern concurrency tools, Apple improved upon threads with several other abstractions, including operation queues, Grand Central Dispatch, and Combine. Let’s see what these newer tools brought to the table.

www.pointfree.co

이전 내용

1. 동시성의 과거: Thread

Concurrency’s Present: Queues and Combine

Operation Queue

Operation Queue는 스레드의 몇가지 문제를 해결하기 위해 도입되었다.

Operation Queue는 작업을 수행하는 시스템과 실제 작업을 분리한다. 스레드는 직접 스레드를 생성하고 해당 스레드에 수행할 작업을 제공해야 했다.

Operation Queue를 생성하고 실행 할 작업을 큐에 추가하면 시스템 내부에서 스레드를 생성하여 작업을 할당하게 된다.

// Thread:
let thread = Thread {
    // 스레드에서 수행할 작업
}
thread.start()

// Operation Queue:
let queue = OperationQueue()
queue.addOperaion{
    print(Thread.current)
}

출력:

<NSThread: 0x100904c20>{number = 2, name = (null)}

비동기로 실행하기 위해 스레드가 생성되었다.

스레드와의 공통점

실행 순서

스레드와 마찬가지로 여러 작업을 한 번에 요청 시 실행 순서가 보장되지 않는다.

Operation Queue가 추가 스레드를 생성하여 작업을 병렬로 처리한다.

우선순위

또, 스레드와 마찬가지로 작업의 우선순위를 지정할 수 있다.

let operation = BlockOperation {  
  print(Thread.current)  
}  
operation.qualityOfService = .background  

queue.addOperation(operation)

우선순위를 지정하기 위해서는 작업을 BlockOperation 을 통해 클로저로 정의해야 한다.

우선순위는 qualityOfService 필드를 통해 우선순위를 설정할 수 있다.

취소

스레드와 동일하게 취소 기능도 지원한다.

let operation = BlockOperation {  
  Thread.sleep(forTimeInterval: 1)  
  print(Thread.current)  
}  
Thread.sleep(forTimeInterval: 0.1)  
operation.cancel()

하지만 해당 코드를 실행하면 작업 내 print가 출력된다. 스레드와 마찬가지로 시스템 내부에서 취소 작업을 처리해주지 않는다. 직접 남은 작업이 취소되었는지 정기적으로 확인하여 중단 여부를 직접 정해야 한다.

스레드와의 차이점

현재 작업

스레드와 달리 Operation Queue에는 취소를 확인할 수 있는 현재 실행 중인 작업에 대한 개념이 없다. BlockOperation을 사용하여 작업 객체를 명시적으로 생성한 후에야 취소 여부를 확인할 수 있다.

let operation = BlockOperation()
operation.addExecutionBlock { [unowned operation] in
  Thread.sleep(forTimeInterval: 1)
  guard !operation.isCancelled else {
    print("Cancelled!")
    return
  }
  print(Thread.current)
}

BlockOperation에서 작업을 초기화 한 후 블록 내에서 참조하여 사용할 수 있다.

하지만 스레드에서 처럼 sleep 상태를 유지한 후 종료된다.

딕셔너리

스레드에서 사용한 스레드 딕셔너리와 같이 데이터를 저장하는 기능을 지원하지 않는다.

의존성(Dependencies)

Operation Queue는 의존성 개념을 지원한다.

이를 이용하여 한 작업이 완료된 후 다른 작업을 시작하도록 설정할 수 있다.

let queue = OperationQueue()

let operationA = BlockOperation {
  print("A")
  Thread.sleep(forTimeInterval: 1)
}
let operationB = BlockOperation {
  print("B")
}
operationB.addDependency(operationA)
queue.addOperation(operationA)
queue.addOperation(operationB)

// 출력:
// A
// B

operationB.addDependency(operationA) 를 통해 의존 관계를 설정할 수 있다.

스레드에서 동일한 방식으로 구현하기 위해서는 다른 스레드가 완료되었는지 확인하기 위해 while루프를 사용하여 지속적으로 확인해야 했다.

스레드가 가진 문제 해결: Thread Explosion 및 Starvation 문제

스레드는 작업을 수행할 때 마다 스레드를 생성하게 되면 수천개의 스레드가 동시에 실행되는 상황이 발생할 수 있다. CPU를 점유하기 위해 서로 경쟁 상태에 들어가게 되며 Thread Starvation이 발생할 수 있다.

Operation Queue는 현재 실행 중인 작업과 완료된 작업을 전체적으로 파악할 수 있기 때문에 효율적으로 처리할 수 있다.

for n in 0..<1000 {
  queue.addOperation { print(n, Thread.current) }
}

결과:

1000개의 작업을 요청했지만 60개 정도의 스레드만 생성되었다.

스레드 풀의 개념과 같이 동작한다. 새로운 작업을 수행할 때 매번 스레드를 생성하는 대신 풀에서 스레드를 요청하여 작업을 수행하도록 한다.

Operation Queue의 문제점

✔️ 비동기 작업에서의 Blocking 문제

Operation Queue는 비동기 작업에서 non-blocking방식으로 처리할 수 있는 도구가 없다.

특정 작업을 일정시간 기다렸다가 실행하려면 Thread.sleep을 사용해야 한다.

queue.addOperation {
  Thread.sleep(forTimeInterval: 1)
  print(n, Thread.current)
}

✔️ 비동기 작업 간 협력 부족

다른 작업과 자원을 효율적으로 공유하거나 협력할 방법을 제공하지 않는다.

예를 들어, 특정 작업이 대기 중일 경우 자원을 반환하고 다른 작업이 이를 활용하도록 할 방법이 없다. 이로 인해 작업들 간 경쟁이 발생하며 많은 자원을 소모하는 작업이 다른 작업의 수행을 방해할 수 있다.

for n in 0..<1000 {
  queue.addOperation {
    print(n, Thread.current)
    while true {} // CPU를 계속 사용

}
queue.addOperation {
  print("Starting prime operation")
  nthPrime(50_000) // 50,000번째 소수 계산
}

위의 경우 무한루프로 인해 일부 스레드를 계속 점유하고 있는 상태이기 때문에 소수 계산 작업이 실행되지 않는다.

✔️ 취소 제한

특정 작업을 취소하더라도 해당 작업에 의존성을 가진 다른 작업은 취소되지 않는다.

operationB.addDependency(operationA)
operationC.addDependency(operationA)
operationD.addDependency(operationB)
operationD.addDependency(operationC)

operationA.cancel()

이전에 사용하였던 의존성 코드를 예시로 사용해볼 때 operationA를 취소하더라도 나머지 B, C, D는 취소되지 않고 그대로 실행된다.

✔️ 복잡한 API 설계

Operation Queue는 OOP에서 영감을 받아 설계되었기에 비효율적인 모습이 발견된다.

let queue = OperationQueue()

let operationA = BlockOperation {
    print("A")
    Thread.sleep(forTimeInterval: 1)
}
let operationB = BlockOperation { print("B") }
let operationC = BlockOperation { print("C") }
let operationD = BlockOperation { print("D") }

operationB.addDependency(operationA)
operationC.addDependency(operationA)
operationD.addDependency(operationB)
operationD.addDependency(operationC)

queue.addOperation(operationA)
queue.addOperation(operationB)
queue.addOperation(operationC)
queue.addOperation(operationD)

위의 코드를 살펴보면

모든 작업 선언
작업간 의존성 설정
모든 작업을 큐에 추가

와 같은 과정으로 코드를 작성하게 된다. 이와 같은 코드는 직관적이지 못해 작업의 실행 흐름을 이해하기 어렵게 한다.

✔️ Race Condition(데이터 경쟁) 문제

멀티스레드 환경에서 발생할 수 있는 데이터 경쟁 문제를 해결하지 못한다.

스레드가 가진 몇가지 문제를 해결하긴 했지만 모든 문제를 해결하지 못해 GCD나 Swift Concurrecny를 사용해야 한다.

GCD(Grand Central Dispatch)

GCD는 스레드 관점에서의 동시성이 아닌 큐를 중심으로 동시성을 생각하도록 설계되었다.

GCD는 다음과 같이 생성하고 작업을 추가할 수 있다.

let queue = DispatchQueue(label: "my.queue")
queue.async {
    print(Thread.current)
}

출력:

<NSThread: 0x101012230>{number = 2, name = (null)}

GCD의 특징

✔️ Serial Queue

GCD는 기본적으로 Serial Queue로 설정되어 있다.

queue.async { print("1", Thread.current) }
queue.async { print("2", Thread.current) }
queue.async { print("3", Thread.current) }
queue.async { print("4", Thread.current) }
queue.async { print("5", Thread.current) }

출력:

1 <NSThread: 0x10601fd70>{number = 2, name = (null)}
2 <NSThread: 0x10601fd70>{number = 2, name = (null)}
3 <NSThread: 0x10601fd70>{number = 2, name = (null)}
4 <NSThread: 0x10601fd70>{number = 2, name = (null)}
5 <NSThread: 0x10601fd70>{number = 2, name = (null)}

기본으로 Serial Queue이기 때문에 동일한 스레드에서 작업이 순차적으로 실행된다. 이는 동시성 코드의 복잡성을 줄이기 위해 의도된 것이다.

Concurrent Queue를 사용하려면 명시적으로 설정해야 한다.

let queue = DispatchQueue(label: "my.queue", attributes: .concurrent)

✔️ Thread explosion 방지

GCD는 많은 작업을 큐에 추가해도 스레드가 많이 생성되지 않는다.

for n in 0..<workCount {
  queue.async {
    print(n, Thread.current)
  }
}

출력:

0 <NSThread: 0x101108070>{number = 2, name = (null)}
7 <NSThread: 0x101108070>{number = 2, name = (null)}
10 <NSThread: 0x101604330>{number = 10, name = (null)}
5 <NSThread: 0x1014996c0>{number = 7, name = (null)}
…
929 <NSThread: 0x101498d30>{number = 29, name = (null)}
116 <NSThread: 0x10070f940>{number = 57, name = (null)}
999 <NSThread: 0x101204d20>{number = 30, name = (null)}

✔️ Non-Blocking

GCD는 특정 시간이 지난 후 작업을 수행하도록 하는 기능을 제공한다.

GCD는 Thread.sleep 과 같이 스레드를 차단하여 리소스 낭비 문제를 해결하였다. asyncAfter 를 통해 일정 시간 지난 후 수행하도록 설정할 수 있다.

print("before scheduling")
queue.asyncAfter(deadline: .now() + 1) {
    print("1 second passed")
}
print("after scheduling")

// 출력
// before scheduling
// after scheduling
// 1 second passed

✔️ 우선순위(QoS)

GCD 또한 QoS(Quality of Service)를 사용하여 우선순위를 지정할 수 있다.

let queue = DispatchQueue(label: "my.queue", qos: .background)

✔️ DispatchWorkItem

GCD에서 작업 단위를 생성하기 위해 DispatchWorkItem 을 사용할 수 있다.

let item = DispatchWorkItem {
    print(Thread.current)
}
queue.async(execute: item)

✔️ 작업 취소

DispatchWorkItem 으로 생성한 작업 아이템은 실행 도중 작업 취소를 수행할 수 있다. GCD 또한 협력적으로 동작하기 때문에 실행 중 직접 취소 여부를 확인해야 한다.

스레드 처럼 현재 실행 중인 디스패치 큐를 확인할 수 있는 개념이 존재하지 않아 취소 여부를 확인하려면 해당 큐 자체에 접근해야 한다.

var item: DispatchWorkItem!
item = DispatchWorkItem {
  defer { item = nil }
  let start = Date()
  defer { print("Finished in", Date().timeIntervalSince(start)) }
  Thread.sleep(forTimeInterval: 1)
  guard !item.isCancelled else {
    print("Cancelled!")
    return
  }
  print(Thread.current)
}
queue.async(execute: item)

Thread.sleep(forTimeInterval: 0.5)
item.cancel()

출력:

Cancelled!  
Finished in 1.0974069833755493

0.5초 후에 취소를 요청했지만 완료 시간은 1초가 걸렸다. 시스템적으로 강제로 적용되는 것이 아니기 때문에 1초 동안 sleep을 유지하게 되고, 이 sleep을 중단할 수 없다.

✔️ Specifics

스레드의 딕셔너리와 유사하게 Specifics가 존재한다.

스레드 딕셔너리와 같은 방식으로 데이터를 저장하고 검색할 수 있다.

예시로 네트워크 요청을 처리하는 코드를 사용해보자.

func response(for request: URLRequest) -> HTTPURLResponse {
  // 요청을 응답으로 변환하는 작업을 수행

  return .init()
}

let item = DispatchWorkItem {
  response(for: .init(url: URL(string: "https://www.pointfree.co")!))
}

let requestId = UUID()
let queue = DispatchQueue(label: "request-\(requestId)")
queue.async(execute: item)

해당 코드에서 고유 요청 ID값을 통해 특정 로그를 쉽게 확인할 수 있도록 해보려 한다.

func response(for request: URLRequest) -> HTTPURLResponse {
  let requestId = DispatchQueue.getSpecific(key: requestIdKey)! // 값 검색
  print(requestId, "Making database query")
  Thread.sleep(forTimeInterval: 0.5)
  print(requestId, "Finished database query")
  print(requestId, "Making network request")
  Thread.sleep(forTimeInterval: 0.5)
  print(requestId, "Finished network request")

  return .init()
}

let item = DispatchWorkItem {
  response(for: .init(url: URL(string: "https://www.pointfree.co")!))
}

let requestIdKey = DispatchSpecificKey<UUID>() // Specific 키 생성 및 타입 설정
let requestId = UUID()
let queue = DispatchQueue(label: "request-\(requestId)")
queue.async(execute: item)
queue.setSpecific(key: requestIdKey, value: requestId) // 값 설정

스레드 딕셔너리와 달리 데이터의 타입을 명시적으로 지정할 수 있다.

✔️ Specific의 상속 문제

스레드 딕셔너리와 마찬가지로 내부에서 새로 생성된 디스패치 큐에 데이터를 자동으로 상속하지 않는다.

디스패치 큐에는 이러한 문제를 해결하기 위한 Targeting이라는 도구를 제공한다. 이를 통해 새 큐를 부모 큐에 타겟팅하면 Specific 데이터를 상속받을 수 있다.

let queue2 = DispatchQueue(label: "queue2", target: queue1) // 타겟팅
queue2.setSpecific(key: idKey, value: 1729)
queue2.async {
  print("queue2", "id", DispatchQueue.getSpecific(key: idKey))
  print("queue2", "date", DispatchQueue.getSpecific(key: dateKey))
}

출력:

queue1 id Optional(42)  
queue1 date Optional(2022-05-18 17:36:26 +0000)  
queue2 id Optional(1729)  
queue2 date Optional(2022-05-18 17:36:26 +0000)

✔️ 예제

데이터베이스 쿼리와 네트워크 요청을 병렬로 실행하도록 해보자.

func makeDatabaseQuery() {
  let requestId = DispatchQueue.getSpecific(key: requestIdKey)!
  print(requestId, "Making database query")
  Thread.sleep(forTimeInterval: 0.5)
  print(requestId, "Finished database query")
}

func makeNetworkRequest() {
  let requestId = DispatchQueue.getSpecific(key: requestIdKey)!
  print(requestId, "Making network request")
  Thread.sleep(forTimeInterval: 0.5)
  print(requestId, "Finished network request")
}

func response(for request: URLRequest) -> HTTPURLResponse {
  let databaseQueue = DispatchQueue(label: "database-query")
  databaseQueue.async {
    makeDatabaseQuery()
  }

  let networkQueue = DispatchQueue(label: "network-request")
  networkQueue.async {
    makeNetworkRequest()
  }

  return .init()
}
let item = DispatchWorkItem {
  response(for: .init(url: URL(string: "https://www.pointfree.co")!))
}

let requestIdKey = DispatchSpecificKey<UUID>() 
let requestId = UUID()
let queue = DispatchQueue(label: "request-\(requestId)")
queue.async(execute: item)
queue.setSpecific(key: requestIdKey, value: requestId)

response 메서드에서 각 작업을 실행하기 위한 큐를 생성한다. 비동기적으로 작업하기 위해 async 를 사용하는데 async 는 non-blocking작업이기 때문에 각 작업이 실행되기 전에 메서드가 종료된다.

두 작업이 완료될 때 까지 기다리지 않는 문제가 발생하게 된다.

✔️ DispatchGroup

이러한 문제를 해결하기 위해 DispatchGroup을 사용할 수 있다.

DispatchGroup을 통해 여러 작업을 하나의 작업처럼 동작하도록 한다.

func response(for request: URLRequest) -> HTTPURLResponse {
  let databaseQueue = DispatchQueue(label: "database-query")

  let group = DispatchGroup() // DispatchGroup 생성

    databaseQueue.async(group: group) { // group 부여
      makeDatabaseQuery()
    }

    networkQueue.async(group: group) {
      makeNetworkRequest()
    }
    group.wait()

  return .init()
}

DispatchGroup을 생성하고 각 비동기 작업을 하나의 그룹 내에서 작업을 처리하게 된다.

모든 작업이 끝날 때 까지 기다린 후 응답 값을 반환한다.

각 작업에 specific을 부여해줄 수 있다.

func response(
  for request: URLRequest, queue: DispatchQueue
) -> HTTPURLResponse {
  let group = DispatchGroup()

  let databaseQueue = DispatchQueue(
    label: "database-request", target: queue
  )
  databaseQueue.async(group: group) {
    makeDatabaseQuery()
  }

  let networkQueue = DispatchQueue(
    label: "network-request", target: queue
  )
  networkQueue.async(group: group) {
    makeNetworkRequest()
  }

  group.wait()

  return .init()
}

let queue = DispatchQueue(
  label: "request-\(requestId)", attributes: .concurrent
)
response(
  for: .init(url: URL(string: "https://www.pointfree.co")!),
  queue: queue
)

메서드의 인수로 상속 받을 큐의 정보를 넘기고, 새로운 큐를 생성할 때 target을 부여하도록 하였다. 해당 작업들을 병렬로 실행해야 하기 때문에 부모 큐의 타입을 concurrent로 설정한다.

결과:

48A7C5DD-5F02-4234-923C-F96315A42214 Making database query
48A7C5DD-5F02-4234-923C-F96315A42214 Making network request
48A7C5DD-5F02-4234-923C-F96315A42214 Finished database query
48A7C5DD-5F02-4234-923C-F96315A42214 Finished network request

위의 코드를 더 개선해보자면 현재는 각 요청마다 새로운 concurrent 큐를 생성하는데, 이는 비효율적이다.

서버가 시작될 때 하나의 concurrent 큐를 만들고 요청이 들어올 때 마다 해당 큐를 타겟으로 하는 새로운 큐를 만들도록 한다. 타겟팅을 하도록 하여 독립적인 큐를 생성하는 것이 아니라 연결된 큐를 생성하게 된다.

이를 통해 sepcific을 공유할 수 있고, 하나의 스레드 풀에서 작업이 분배되어 Thread Explosion 문제를 피할 수 있다.

let serverQueue = DispatchQueue(
  label: "server", attributes: .concurrent
)
let requestId = UUID()
let requestIdKey = DispatchSpecificKey<UUID>()
let queue = DispatchQueue(
  label: "request-\(requestId)",
  attributes: .concurrent,
  target: serverQueue
)
queue.setSpecific(key: requestIdKey, value: requestId)
queue.async {
  response(for: .init(url: URL(string: "https://www.pointfree.co")!))
}

GCD의 문제점

✔️ 상속 기능의 한계

기본 큐의 specifics를 상속받을 수 있는 기능은 유용하지만 한계가 있다.

response(
  for: .init(url: URL(string: "https://www.pointfree.co")!),
  queue: requestQueue
)

위와 같이 함수에 큐를 전달하여 상속 받도록 할 수 있지만 이는 데이터를 여러 계층에 걸쳐 전달하지 않으려는 목적에는 반하는 것이다.

새로운 큐를 생성할 때 부모 큐의 specific을 자동으로 상속받는 구조가 더 바람직하다.

✔️ 작업 취소의 한계

Dispatch Queue는 specific을 상속받을 수는 있지만 취소는 상속받지 못한다.

부모 작업이 취소되면 하위 작업도 취소되는 기능은 여전히 불가능하다.

✔️ Thread Explosion 문제

DispatchQueue는 과도한 스레드 생성 문제를 줄이긴 하지만 제대로 사용하지 않으면 여전히 문제가 발생할 수 있다.

for n in 0..<1000 {
  DispatchQueue(label: "queue-\(n)").async {
    print(Thread.current)
    while true {}
  }
}

Thread.sleep(forTimeInterval: 3)

다음과 같은 코드는 매번 DispatchQueue를 생성하기 때문에 과도한 스레드가 생성된다.

또, 스레드 폭발 문제를 해결하더라도 단일 큐에서 너무 많은 작업을 수행할 경우 다른 작업이 실행되지 않는 문제가 발생할 가능성이 존재한다.

✔️ 작업 간 협력 문제

DispatchQueue는 다른 작업과 협력할 수 있는 도구를 제공하지 않는다.

네트워크 요청이나 데이터베이스 요청과 같은 대기 시간이 긴 작업을 실행하는 동안 다른 작업이 동일한 스레드를 사용할 수 없다. 대기 중인 작업들은 CPU 시간을 두고 경쟁해야 하며, 리소스를 많이 사용하는 작업은 다른 작업의 실행 시간을 빼앗게 된다.

✔️ DataRace 문제

GCD는 데이터 접근을 동기화 할 수 있는 도구를 제공하지만 이는 이전에 사용한 Lock과 유사하다.

class Counter {
  var count = 0
  func increment() {
    self.count += 1
  }
}
let counter = Counter()

let queue = DispatchQueue(label: "concurrent-queue", attributes: .concurrent)

for _ in 0..<1000 {
  queue.async {
    counter.increment()
  }
}

Thread.sleep(forTimeInterval: 1)
print("counter.count", counter.count)

출력: counter.count 996

위의 코드를 실행하면 1000에 도달하지 못하지만 스레드를 사용할 때보다 data race 문제가 적게 발생함을 볼 수 있다.

여전히 data race 문제가 발생할 수 있고, 이러한 문제를 해결하기 위해 GCD는 “barrier”라는 도구를 제공한다.

barrier를 사용하여 큐가 현재 작업을 모두 완료한 후에만 다음 작업 단위를 실행하도록 할 수 있다.

class Counter {
  let queue = DispatchQueue(label: "counter", attributes: .concurrent)
  var count = 0
  func increment() {
    self.queue.sync(flags: .barrier) {
      self.count += 1
    }
  }
}

이제 동일한 1,000이라는 결과를 얻을 수 있지만 이는 시간이 매우 오래 걸린다.

동시성 환경에서 각각 락 작업을 수행해야 하기 때문에 작업이 느려지고, barrier는 NSLock보다 더 느리기 때문이다.

Combine

Combine은 시간에 따라 값의 스트림을 표현할 수 있는 라이브러리로 설계되었다. Combine은 동시성을 수행하거나 비동기 작업을 위한 라이브러리가 아니다.

해당 작업이 가능하지만, DispatchQueue, OperationQueue, Run Loop 등 동시성 도구에 의존하여 수행한다.

Combine을 사용하여 우리가 동시성을 다룰 때 발생하는 문제들을 해결하는데 도움을 준다.

먼저, 단일 값을 방출할 수 있는 Future Publisher를 생성해보자.

let publisher = Deferred {
  Future<Int, Never> { callback in
    print(Thread.current)
    callback(.success(42))
  }
}

Future 퍼블리셔는 생성 즉시 실행되기 때문에 구독 시점에 실행되도록 Deferred 퍼블리셔로 감싸야 한다.

let cancellable = publisher
  .sink {
    print("sink", $0, Thread.current)
  }

_ = cancellable

퍼블리셔에서 값을 얻기 위해 .sink를 통해 구독해야하고, 구독을 관리하기 위해 반환되는 Cancellable 객체를 저장한다.

출력:

<_NSMainThread: 0x10610a920>{number = 1, name = main}
publisher 42 <_NSMainThread: 0x10610a920>{number = 1, name = main}

위의 출력 결과로 보아 비동기 작업이 이루지지 않은 것을 볼 수 있다.

✔️ zip

Combine은 publisher를 시간에 따라 변하는 값의 시퀀스로 생각하고, 이를 다양한 연산자를 사용해서 결합하여 사용할 수 있는 기능을 제공한다.

다음은 두 퍼블리셔를 zip연산자를 사용하여 결합해 하나의 퍼블리셔를 생성하는 코드이다.

let publisher1 = Deferred {
  Future<Int, Never> { callback in
    print(Thread.current)
    callback(.success(42))
  }
}
let publisher2 = Deferred {
  Future<String, Never> { callback in
    print(Thread.current)
    callback(.success("Hello world"))
  }
}

let cancellable = publisher1
  .zip(publisher2)
  .sink {
    print("sink", $0, Thread.current)
  }

_ = cancellable

출력:

<_NSMainThread: 0x10100c890>{number = 1, name = main}
<_NSMainThread: 0x10100c890>{number = 1, name = main}
sink (42, "Hello world") <_NSMainThread: 0x10100c890>{number = 1, name = main}

이전에는 많은 코드로 두 작업을 결합했던 작업을 Combine을 사용하여 간단하게 수행할 수 있다.

✔️ flatMap

만약 첫 번째 퍼블리셔가 완료된 후 다음 퍼블리셔를 실행하도록 하고싶다면 flatMap을 사용할 수 있다.

let cancellable = publisher1
  .flatMap { integer in
    Deferred {
      Future<String, Never> { callback in
        print(Thread.current)
        callback(.success("\(integer)"))
      }
    }
  }
  .zip(publisher2)
  .sink {
    print("sink", $0, Thread.current)
  }

출력:

<_NSMainThread: 0x10100c890>{number = 1, name = main}
<_NSMainThread: 0x10100c890>{number = 1, name = main}
<_NSMainThread: 0x10100c890>{number = 1, name = main}
sink ("42", "Hello world") <_NSMainThread: 0x10100c890>{number = 1, name = main}

✔️ 비동기 작업

퍼블리셔에서 비동기 작업을 수행하려면 기존 동시성 도구를 활용할 수 있다.

let publisher1 = Deferred {
  Future<Int, Never> { callback in
    print(Thread.current)
    callback(.success(42))
  }
}
.subscribe(on: DispatchQueue(label: "publisher1"))

let publisher2 = Deferred {
  Future<String, Never> { callback in
    print(Thread.current)
    callback(.success("Hello"))
  }
}
.subscribe(on: DispatchQueue(label: "publisher2"))

let cancellable = publisher1
  .flatMap { integer in
    Deferred {
      Future<String, Never> { callback in
        print(Thread.current)
        callback(.success("\(integer)"))
      }
    }
    .subscribe(on: DispatchQueue(label: "publisher3"))
  }
  .zip(publisher2)
  .sink {
    print("sink", $0, Thread.current)
  }

Thread.sleep(forTimeInterval: 1)
_ = cancellable

출력:

<NSThread: 0x100711ba0>{number = 2, name = (null)}
<NSThread: 0x100711ba0>{number = 3, name = (null)}
<NSThread: 0x106004830>{number = 4, name = (null)}
sink ("42", "Hello") <NSThread: 0x1060052f0>{number = 4, name = (null)}

각 publisher가 DispatchQueue에서 작업하도록 설정하였다.

출력 결과를 보면 이제 메인 스레드가 아닌 다른 스레드에서 동작하고 있음을 볼 수 있다.

✔️ 복잡한 의존성 구조

이전에 OperationQueue와 DispatchQueue에서 다음과 같은 의존성을 만들었었다.

 A ➡️ B
⬇️    ⬇️
 C ➡️ D

이전에는 복잡한 코드를 사용하여야 다음과 같은 구조를 만들 수 있었지만 Combine에서는 간단하게 표현할 수 있다.

a
 .flatMap { a in zip(b(a), c(a)) }
 .flatMap { b, c in d(b, c) }

a 퍼블리셔를 시작하여 해당 결과 값을 통해 b와 c 작업을 수행하고, 두 작업의 결과를 활용하여 d 작업을 수행한다.

이러한 스트림을 통해 관계를 간단하게 표현할 수 있지만 이러한 체이닝 방식이 익숙하지 않다면 어려운 방식이다.

Swift의 새로운 동시성 도구인 async/await을 사용한다면 더 간단하게 표현할 수 있다.

let a = await f()
async let b = g(a)
async let c = h(a)
let d = await i(b, c)

다음 내용

3. 동시성프로그래밍: Task

[iOS/Point-Free] 동시성 프로그래밍의 과거 - 스레드

김졀니 — Mon, 25 Nov 2024 21:37:08 +0900

다음 내용은 Point-Free의 Concurrency 강의를 듣고 정리한 내용입니다!

https://www.pointfree.co/episodes/ep190-concurrency-s-past-threads

Episode #190: Concurrency's Past: Threads

To better understand Swift’s concurrency tools, let’s first look to the past, starting with threads. Threads are a tool most developers don’t reach for these days, but are important to understand, and the way they solve problems reverberate even in t

www.pointfree.co

Thread Basics

Operation Queue나 GCD 등 스레드를 고려하지 않고 비동기 코드를 작성하도록 발전해왔다.

동시성 코드를 잘 이해하기 위해서는 동시성 코드의 시작인 Thread에 대해 공부해야 한다.

운영체제는 수십, 수백개의 논리적 스레드를 관리한다.

Thread 는 클래스타입으로 정의되어있다. POSIX 스레드를 기반으로 만들어져서 사용자가 해당 내용에 대해 알지 못해도 스레드를 쉽게 다룰 수 있도록 애플에서 Thread 클래스를 제공한다.

Thread.detachNewThread{
    Thread.sleep(forTimeInterval: 1)    
    print(Thread.current)
}

위의 내용을 실행시키면 출력되지 않고 프로그램이 종료된다.

detachNewThread 를 통해 메인 스레드가 아닌 새로운 스레드를 생성하게 되었고, 그 내부에서 동작하기 때문에 sleep 을 기다리지 않고 프로그램이 종료되는 것.

그렇기 때문에

Thread.detachNewThread{
    Thread.sleep(forTimeInterval: 1)    
    print(Thread.current) // 1
}
Thread.sleep(forTimeIntervar: 1.1)
print(Thread.current) // 2

위의 코드를 실행시킨 후 현재 실행되고있는 범위의 스레드 정보를 출력시키면 서로 다른 정보를 출력하게 된다.

<NSThread: 0x106404d00>{number = 2, name = (null)} // 1
<_NSMainThread: 0x10600aa90>{number = 1, name = main} // 2

스레드의 순서는 보장되지 않는다.

Thread.detachNewThread{
    print("1", Thread.current)
}
Thread.detachNewThread{
    print("2", Thread.current)
}
Thread.detachNewThread{
    print("3", Thread.current)
}

여러 개의 스레드를 생성할 때, 스레드의 생성 순서대로 실행되지 않을 수 있다.

운영체제는 스레드에 실행시간을 할당하는 복잡한 로직을 처리하기 때문에 실행 순서를 예측할 수 없다.

detachNewThread를 통해 다른 스레드를 방해하지 않고 작업을 수행할 수 있다. 이론적으로는 컴퓨터에 유한한 수의 코어가 존재한다. 하지만 운영체제 내부적으로 복잡한 작업을 처리하여 여러 스레드가 각자 작업을 수행하고 다른 스레드로 넘어가도록 하여 여러 작업이 교대로 이루어질 수 있도록 한다.

Priority and Cancellation

우선순위

Thread의 초기화 함수로 스레드를 생성하여 스레드의 우선순위를 설정할 수 있다.

let thread = Thread {
  Thread.sleep(forTimeInterval: 1)
  print(Thread.current)
}
thread.start()
thread.threadPriority = 0.75

우선순위는 0에서 1 사이의 double 값으로, 운영체제가 해당 스레드를 더 빨리 실행하도록 권장할 수 있지만 보장 되진 않는다.

취소

thread.cancel()

cancel() 을 호출하여 실행 중인 스레드를 중지 요청을 보낼 수 있다.

cancel()로 스레드의 실행을 멈출 수 있는 것이 아니라 스레드 종료 요청을 보내 내부의 플래그를 변경하도록 한다.

취소를 통해 더 우선순위가 높은 작업을 수행할 때 현재 작업을 취소하고 다음 작업을 수행하도록 할 수 있다.

let thread = Thread {
  Thread.sleep(forTimeInterval: 1)
  guard !Thread.current.isCancelled else {
    print("Cancelled")
    return
  }
  print(Thread.current)
}

Thread.current.isCancelled 플래그를 사용하여 스레드 내부에 플래그를 확인하는 코드를 넣어주는 것이 좋다.

플래그를 자주 확인하여 불필요한 작업을 빠르게 종료할 수 있도록 하는 것이 좋다.

다만, 취소 매커니즘이 다른 스레드 작업들과 완전히 결합되어있다.

Thread.sleep() 이 동작하고 있을 동안 취소 플래그를 확인하지 않는다.

let thread = Thread {
  Thread.sleep(forTimeInterval: 1)
  print(Thread.current)
}
thread.start()
Thread.sleep(forTimeInterval: 0.01)
thread.cancel()

Thread.sleep 에서 취소된 스레드를 인지하지 못하고 취소가 되더라도 지정된 시간이 지날 때 까지 기다리게 된다.

이러한 이유는 아마도 CPU에서 오버헤드를 피하기 위한 의도로 보여진다.

우선순위와 취소는 스레드에서 Cooperative(협조)의 특성을 보여주는 기능이다. 스레드에서 낮은 우선순위를 설정하여 다른 스레드들이 CPU에서 더 많은 작업을 할 수 있도록 하고, 스레드 취소를 감지하게 되면 스레드의 작업을 중단하여 불필요한 작업을 빠르게 끝낼 수 있도록 할 수 있다.

Problems: Coordination

✔️ 딕셔너리 사용의 안정성

Thread Dictionary는 말 그대로 딕셔너리 타입이기 때문에 안정성 부분에서 떨어지게 된다. 키 이름을 잘못 입력했을 경우 컴파일러가 해당 문제를 잡을 수 없기 때문에 런타임 시 문제가 발생할 가능성이 있다.

✔️ 스레드 딕셔너리 전달 문제

스레드 딕셔너리를 통해서 데이터를 쉽게 전달할 수 있지만 문제는 단일 스레드에 한해서만 동작한다는 것이다. 기존 스레드 내부에서 새로 스레드를 생성하더라도 기존 딕셔너리 데이터를 전달할 수 없다.

예시) 병렬 처리

func makeDatabaseQuery() {
  let requestId = Thread.current.threadDictionary["requestId"] as! UUID
  print(requestId, "Making database query")
  Thread.sleep(forTimeInterval: 0.5)
  print(requestId, "Finished database query")
}

func makeNetworkRequest() {
  let requestId = Thread.current.threadDictionary["requestId"] as! UUID
  print(requestId, "Making network request")
  Thread.sleep(forTimeInterval: 0.5)
  print(requestId, "Finished network request")
}

func response(for request: URLRequest) -> HTTPURLResponse {
  let start = Date()
  let requestId = Thread.current.threadDictionary["requestId"] as! UUID

  let databaseQueryThread = Thread { makeDatabaseQuery() }
  databaseQueryThread.start()

  let networkRequestThread = Thread { makeNetworkRequest() }
  networkRequestThread.start()

  // TODO: join threads somehow

  print(requestId, "Completed in", Date().timeIntervalSince(start))
  return .init()
}

// 새 스레드에서 네트워크 요청
let thread = Thread {
  response(for: .init(url: .init(string: "<https://www.pointfree.co>")!))
}
thread.threadDictionary["requestId"] = UUID()
thread.start()

makeDatabaseQuery() 와 makeNetworkRequest() 가 내부에서 생성된 스레드를 통해서 병렬적으로 실행된다.

위의 코드는 오류가 발생하는데 그 이유는 외부에서 생성된 스레드 딕셔너리의 데이터가 내부에서 생성된 스레드에 전달이 되지 않아 requestId값을 찾는데에 오류가 발생한다.

→ 내부에서 스레드를 생성하였지만 스레드는 자식 스레드의 개념이 없기 때문에 별도의 스레드가 생성된다.

위의 코드가 원하는대로 동작하려면 새로 생성한 딕셔너리에 데이터를 복사해야 한다.

let databaseQueryThread = Thread { makeDatabaseQuery() }
databaseQueryThread.threadDictionary.addEntries(
  from: Thread.current.threadDictionary as! [AnyHashable: Any]
)
databaseQueryThread.start()

✔️ 스레드 조인

위의 예시 코드에서 databaseQueryThread() 와 networkRequestThread() 는 서로 다른 비동기 작업을 수행하게 된다. 그렇기 때문에 두 작업이 끝나기 전에 함수가 종료된다. 두 작업의 완료를 기다리는 매커니즘이 스레드에는 존재하지 않는다.

while !databaseQueryThread.isFinished || !networkRequestThread.isFinished {
  Thread.sleep(forTimeInterval: 0.1)
}

해당 코드처럼 임시로 while루프를 통해 스레드 종료 여부를 판단하는 방법 뿐이다.

이 방식은 비효율적인 방식이다.

✔️ 스레드 취소 전달

위의 스레드 딕셔너리 문제와 유사하게 스레드 취소 작업 또한 내부 스레드에 전달되지 않는다.

let thread = Thread {
    print("Outer thread started")
    Thread.sleep(forTimeInterval: 1) // 1초 동안 대기
    print("Outer thread is cancelled:", Thread.current.isCancelled)

    // 외부 스레드에서 새 스레드를 만듦
    let innerThread = Thread {
        print("Inner thread started")
        print("Inner thread is cancelled:", Thread.current.isCancelled)
        Thread.sleep(forTimeInterval: 2)
        print("Inner thread finished")
    }
    innerThread.start() // 내부 스레드 실행

    guard !Thread.current.isCancelled else {
        print("Outer thread was cancelled")
        return
    }
    print("Outer thread finished")
}

thread.start()
Thread.sleep(forTimeInterval: 0.5) // 0.5초 대기 후
thread.cancel() // 외부 스레드를 취소함

// 출력:
// Outer thread started
// Inner thread started
// Outer thread is cancelled: true
// Inner threa is cancelled: false

위의 코드에서 스레드를 실행하게 된다면 외부 스레드(Outer thread)는 thread.cancel() 로 인해 종료되지만 내부에서 생성된 스레드(Inner thread)는 종료되지 않는다.

즉, 외부 스레드를 취소하더라도 취소 상태가 내부에 전달되지 않아 내부 스레드는 계속 작업을 진행하게 된다.

위와 같은 문제들은 비동기 작업을 효율적으로 관리하는 데에 불편함을 야기한다.

Problems: Expensiveness

만약 우리가 처리해야 할 내용이 많을 경우 스레드의 비용 측면에서 문제가 발생할 수 있다.

✔️ 스레드 생성 비용과 경쟁

스레드를 생성하는데에 많은 비용이 든다. 스레드를 생성하게 되면 운영체제가 작업을 빨리 처리할 수 있도록 스케줄링하지만, 그러기 위해 다른 스레드와 경쟁을 하게 된다.

만약 1000개의 스레드를 만들게 되면 많은 스레드가 서로 경쟁해서 운영체제가 시간을 적절히 할당하기 어려워진다.

그렇기 때문에 작업이 느려지고 시스템이 비효율적으로 작동하게 된다.

✔️ 스레드 호출 스택의 메모리 사용 문제

각 스레드는 고유한 호출 스택(작업을 처리하기 위해 필요한 메모리 공간)을 가지고 있으며, 이 스택의 크기는 0.5MB이다. 그렇기 때문에 1000개의 스레드를 생성하면 호출 스택만으로 500MB의 메모리가 필요하게 된다.

✔️ 스레드 경쟁으로 인한 성능 문제

많은 스레드가 생성되어 각 스레드가 CPU를 사용하는 시간이 줄어들게 된다면 각 스레드가 작업을 처리할 수 있는 시간이 줄어들게 된다.

예를 들어, 1,000개의 스레드를 생성한 채로 다른 스레드에서 50,000번째 소수 구하기 작업을 수행한다고 해보자. 다른 경쟁 스레드가 없는 상황이라면 50,000번째 소수를 계산하는데는 0.025초가 걸리지만 경쟁 스레드가 1,000개가 있는 경우 2.93초로 100배 이상 처리 속도가 느려진다.

✔️ Non-blocking 작업

non-blocking 작업은 비동기 작업을 수행할 때 CPU가 실제로 작업을 수행하고 있지 않은 대기 시간에 다른 작업을 처리할 수 있도록 처리하는 방식을 의미한다. 예를 들어, 어떠한 작업을 지연시키거나, 네트워크 요청 시 서버로부터 데이터를 받을 때 까지 기다리는 경우 CPU는 처리할 작업이 많지 않기 때문에 non-blocking이 필요하게 된다.

이러한 경우 다른 스레드가 작업을 처리할 수 있도록 잠시 스레드를 포기했다가 준비가 되었을 때 다시 작업을 처리할 수 있어야 하지만 스레드에서는 이러한 처리를 하기 어렵다. 스레드는 CPU와 밀접하게 연결되어있고, CPU 코어에서는 연속적으로 작업을 처리하도록 설계되어 있기 때문에 잠시 멈추거나 다른 작업을 위해 대기하는 것이 어렵다.

스레드에서 대기를 하기 위해 Thread.sleep 을 사용해볼 수 있는데 해당 방식은 매우 비효율적이다. 스레드 리소스를 사용하고 있지만, 실제로는 작업을 하고있지 않기 때문이다.

이 보다 더 효율적인 대기 방식은 스레드를 멈추는 대신 운영체제에 일정 시간이 지나면 알려달라고 요청하는 것이다. 하지만 스레드 만으로는 이러한 작업을 수행할 수 없고, 스케쥴 된 작업을 확인하는 도구가 추가적으로 필요할 것이다.

✔️ Thread pool

스레드 기아 문제나 스레드 과잉 생성 문제를 해결하기 위해 스레드 풀을 만드는 방식을 주로 사용하게 된다.

- 스레드 기아 문제: 한정된 수의 스레드가 많은 작업을 처리하려 할 때, 일부 스레드가 오래 기다려야 하는 경우. 즉, 작업이 완료되지 않은 채로 계속 대기하는 상황
- 스레드 과잉 생성 문제: 너무 많은 스레드가 생성되어 CPU 사용 시간 할당이 어려워 성능이 저하되고, 비효율적으로 작동하는 문제.

스레드 풀은 일정 수의 스레드를 미리 생성하고 관리하는 방식이다. 스레드가 필요할 때 새로 생성하는 대신 스레드 풀에 준비되어 있는 스레드를 요청하여 작업을 처리하게 된다. 스레드가 모두 사용 중일 경우에는 하나가 완료될 때 까지 기다리게 된다.

스레드 풀은 몇가지 단점을 가지고 있다.

차단 작업에 도움 되지 않는다.
여전히 타이머나 네트워크 요청 등의 대기 상태의 경우 CPU에서 다른 작업을 처리할 수 없는 상태가 된다.
국소적 해결책
스레드 풀은 스레드를 과도하게 생성되지 않도록 할 수 있지만 직접 관리하는 코드 내에서만 가능하다. 외부 라이브러리나 프레임워크에서 자체적으로 스레드 풀을 사용하고 있을 수 있어 독립적인 스레드 풀이 여러 개 존재할 수 있다. 이는 결국 스레드 과잉 생성 문제를 다시 일으킬 수 있다.
협력적 동시성(cooperative concurrency)의 부족
협력적 동시성은 여러 스레드가 자원을 공유하며 효율적으로 사용하는 방식을 의미하는데 스레드는 이러한 기능을 기본적으로 제공하지 않는다. 사용하기 위해서는 직접 만들어야 하며 글로벌한 협력적 솔루션을 제공하기 어렵다.

Problems: Data Races

스레드를 생성하여 작업을 하게되면 Race Condition이라는 문제를 마주하게 된다.

Race Condition: 여러 스레드가 동일한 데이터를 동시에 읽거나 수정할 때 발생하는 문제

애플 프레임워크는 이러한 문제를 동기화하여 방지할 수 있도록 제공하는 도구가 있지만 스레드와 밀접하게 통합되어 있지 않아 개발자가 올바르게 사용해야 한다.

✔️ 데이터레이스 발생 원인

다음과 같은 클래스에서 가변 상태의 값을 여러 스레드에서 읽거나 수정하려고 한다.

class Counter {
  var count = 0
}
let counter = Counter()

그 후 1000개의 스레드를 생성하여 값을 증가시키게 되면

for _ in 0..<1_000 {
  Thread.detachNewThread {
    Thread.sleep(forTimeInterval: 0.01)
    counter.count += 1
  }
}

출력 값은 1000보다 작은 값이 실행할 때 마다 다르게 나올 것이다.

이러한 결과가 나오는 이유는 값을 변경하는 작업이 단일 원자적 연산이 아니기 때문이다.

counter.count += 1 은

현재 count값 가져오기
값 증가시키기
값을 count에 할당하기

이렇게 세 단계로 동작하고 있다.

우리가 원하는 동작 방식은 아래와 같다.

스레드 1: var count1 = counter.count  // 0
스레드 1: count1 += 1                 // 1
스레드 1: counter.count = count1      // 1
스레드 2: var count2 = counter.count  // 1
스레드 2: count2 += 1                 // 2
스레드 2: counter.count = count2      // 2

하지만 실제로는 순서가 아래와 같이 섞여 실행될 가능성이 있다.

스레드 1: var count1 = counter.count  // 0
스레드 2: var count2 = counter.count  // 0
스레드 1: count1 += 1                 // 1
스레드 2: count2 += 1                 // 1
스레드 1: counter.count = count1      // 1
스레드 2: counter.count = count2      // 1

스레드 2는 count의 값을 가져올 때 1이 아닌 0의 값을 가져오게 된다.

이러한 data race 문제를 해결하기 위해서는 접근을 동기화해야 한다.

값을 변경하기 시작할 때 다른 스레드는 접근을 하지 못하고 수정이 완료된 후에 접근할 수 있도록 락(lock)을 사용해야 한다.

✔️ 락(lock)

락은 코드의 일부가 실행되는 동안 다른 스레드들이 해당 부분을 실행하지 못하도록 막는 기능을 한다.

NSLock() 을 이용하여 변경 작업 전 후에 락을 걸고 푸는 작업을 추가하는 메서드를 구현하여 해결할 수 있다.

class Counter {
  let lock = NSLock()
  private(set) var count = 0

  func increment() {
    self.lock.lock()
    defer { self.lock.unlock() }
    self.count += 1
  }
}

for _ in 0..<1_000 {
  Thread.detachNewThread {
    Thread.sleep(forTimeInterval: 0.01)
    counter.increment() // 증가 메서드 호출
  }
}

이렇게 실행하면 항상 일관된 1,000이라는 값을 얻을 수 있다.

위의 코드는 값을 변경하기 위해 락을 걸고 푸는 메서드를 따로 만들어야 하기 때문에 클로저를 통해 modify 메서드를 만들어 볼 수도 있다.

func modify(work: (Counter) -> Void) {
  self.lock.lock()
  defer { self.lock.unlock() }
  work(self)
}
counter.modify {
  $0.count += 1
}

위와 같은 코드도 좋지만 다음과 같이 getter, setter를 사용하는 것이 변경하려는 데이터를 더 명시적으로 표기할 수 있을 것이다.

private var _count = 0
var count: Int {
  get {
    self.lock.lock()
    defer { self.lock.unlock() }
    return self._count
  }
  set {
    self.lock.lock()
    defer { self.lock.unlock() }
    self._count = newValue
  }
}

for _ in 0..<1_000 {
  Thread.detachNewThread {
    Thread.sleep(forTimeInterval: 0.01)
      counter.count += 1
  }
}
// count = 539

하지만 위의 코드를 실행하면 또 다시 1,000이하의 값이 나오게 된다.

위의 코드는 값을 읽고 쓰는 get과 set 부분에만 락이 걸리게 되며 전체 트랜잭션에는 락이 걸리지 않기 때문에 발생하는 문제이다.

✔️ read-modify

(비공식 지원 기능?)

read-modify는 동시성 관련 작업을 처리하는 기능으로, 속성의 읽기 및 수정 작업을 안전하게 처리할 수 있는 기능이다.

위의 코드를 read-modify를 사용하여 다음과 같이 수정해 볼 수 있다.

var count: Int {
  _read {
    self.lock.lock()
    defer { self.lock.unlock() }
    yield self._count
  }
  _modify {
    self.lock.lock()
    defer { self.lock.unlock() }
    yield &self._count
  }
}

counter.count += 1

해당 코드는 정확히 1,000의 값을 가지게 된다.

counter.count += 1 과 같은 연산은 단일 트랜잭션으로 처리하게 된다.

하지만, read-modify에서도 문제가 발생할 가능성이 있다.

counter.count += 1 + counter.count / 100

counter.count를 여러 번 참조하는 경우 문제가 발생하게 된다.

읽기와 쓰기에 별도로 락이 걸리게 되면서 읽기와 쓰기 사이에 다른 스레드가 개입할 수 있게 된다. 그렇게 되면 해당 연산을 단일 트랜잭션으로 묶지 못하게 된다.

위의 문제를 해결하기 위해선 결국 위에서 사용하였던 modify 메서드를 사용하여 연산 자체를 단일 트랜잭션을 묶어야 한다. 동기화 문제를 완전히 해결하기 위해서는 결국 상태를 변경하는 전용 메서드를 활용해야 한다.

이러한 문제점들은 멀티스레딩과 데이터레이스 문제의 까다로움을 보여준다.

락은 스레드와 분리되어 있는 도구라는 문제점이 있다. Swift의 새로운 동시성 도구는 스레드와 밀접하게 통합되어 있어서 더 쉽게 문제를 해결할 수 있다.

Thread의 한계

과거 애플 플랫폼에서 스레드는 동시성과 비동기 작업을 처리하기 위한 주요 도구였다. 하지만 스레드는 다음과 같은 한계를 가지고 있다.

스레드는 자식스레드를 지원하지 않기 때문에 우선순위, 취소, 딕셔너리 등의 데이터가 하위 스레드에 전달되지 않는다.
스레드의 수가 과도하게 증가될 수 있다.
코드의 가독성이 떨어진다.
스레드 간 동기화를 위한 툴이 제한적이다.

다음내용

2. 동시성프로그래밍: OperationQueue, GCD, Combine

[RxSwift] Rx 를 사용하여시스템 권한 요청받기 (카메라, 앨범, 알림)

김졀니 — Wed, 6 Nov 2024 14:42:31 +0900

다음과 같은 시스템 권한 얼럿을 RxSwift를 이용하여 띄워보자!

PermissionManager 라는 이름을 가진 싱글톤 클래스를 만들어 권한 확인 및 요청 관련 메서드를 관리

public final class PermissionManager {

  public static let shared = PermissionManager()
  private init() { }
  private let disposeBag = DisposeBag()

  ...
}

권한 요청

RxSwift를 사용하여 구현하려고 하기 때문에 Observable 타입을 리턴하도록 구현

리턴되는 Bool타입의 데이터는 해당 권한을 허용했는지 여부이다.

알림 권한 요청

알림 권한 얼럿의 메세지는 시스템 내부에 정해져있다.

알림에 대한 얼럿과 소리 뱃지 등의 옵션만 설정하면 얼럿 메세지가 만들어진다!

func requestNotificationPermission() -> Observable<Bool> {
  return Observable<Bool>.create { observable in
    UNUserNotificationCenter.current()
      .requestAuthorization(options: [.alert, .sound, .badge]) { isAllow, _ in
        observable.onNext(isAllow)
        observable.onCompleted()
      }
    return Disposables.create()
  }
}

사용 예시

특정 버튼을 탭했을 때 권한 요청

button.rx.tap
  .flatMap {
      PermissionManager().checkPermission(for: .camera)
  }
  .subscribe(with: self) { owner, status in
      // 권한 상태에 따라 적절한 액션 구현
  }
  .disposed(by: disposBag())

카메라, 앨범 권한 요청

info.plist에서 권한 메세지 설정이 필요

privacy - NSCameraUsageDescription

privacy - Photo Library Description

import AVFoundation
import Photos

// ...

func requestCameraPermission() -> Observable<Bool> {
  Observable<Bool>.create { observable in
    AVCaptureDevice.requestAccess(for: .video) { granted in
      observable.onNext(granted)
      observable.onCompleted()
    }
    return Disposables.create()
  }
}

func requestPhotoPermission() -> Observable<Bool> {
  Observable<Bool>.create { observable in
    PHPhotoLibrary.requestAuthorization(for: .addOnly) { state in
      if state == .authorized {
        observable.onNext(true)
        observable.onCompleted()
      } else {
        observable.onNext(false)
        observable.onCompleted()
      }
    }
    return Disposables.create()
  }
}

모든 권한 한 번에 요청하기

앱을 처음 진입했다면 처음에 필요한 권한을 모두 요청받는게 필요할 수 있다.

필요한 권한을 하나씩 요청하는 메서드를 구현해보자

func requestAllPermission() -> Observable<Void> {
  return requestNotificationPermission()
    .map { _ in Void() }
    .flatMap { _ in
      self.requestCameraPermission()
        .map { _ in Void()}
    }
    .flatMap {
      self.requestPhotoPermission()
        .map { _ in Void() }
    }
}

알림-카메라-앨범 순서로 권한 요청 얼럿을 띄울 수 있다.

권한 상태 확인

.notDetermined: 권한 요청 받은 적 없음을 의미

해당 경우라면 위에서 구현한 권한 요청 메서드를 호출하여 허용 여부를 불러올 수 있다.

알림권한

// 알림 권한
var notificationPermission: Observable<Bool> {
  return Observable<Bool>.create { observable in
    UNUserNotificationCenter.current().getNotificationSettings { settings in
      switch settings.authorizationStatus {
      case .notDetermined:
        self.requestNotificationPermission()
          .subscribe(onNext: { isAllowed in
            observable.onNext(isAllowed)
            observable.onCompleted()
          })
          .disposed(by: self.disposeBag)
      case .authorized:
        observable.onNext(true)
        observable.onCompleted()
      default:
        observable.onNext(false)
        observable.onCompleted()
      }
    }
    return Disposables.create()
  }
}

카메라 권한

var cameraPermission: Observable<Bool> {
  return Observable<Bool>.create { observable in
    let status = AVCaptureDevice.authorizationStatus(for: .video)
    switch status {
    case .notDetermined:
      self.requestCameraPermission()
        .subscribe { isAllowed in
          observable.onNext(isAllowed)
          observable.onCompleted()
        }
        .disposed(by: self.disposeBag)
    case .authorized:
      observable.onNext(true)
      observable.onCompleted()
    default:
      observable.onNext(false)
      observable.onCompleted()
    }

    return Disposables.create()
  }
}

앨범 권한

// 앨범 권한  
var photoPermission: Observable<Bool> {
  return Observable<Bool>.create { observable in
    let status = PHPhotoLibrary.authorizationStatus(for: .addOnly)
    switch status {
    case .notDetermined:
      self.requestPhotoPermission()
        .subscribe { isAllowed in
          observable.onNext(isAllowed)
          observable.onCompleted()
        }
        .disposed(by: self.disposeBag)
    case .authorized:
      observable.onNext(true)
      observable.onCompleted()
    default:
      observable.onNext(false)
      observable.onCompleted()
    }

    return Disposables.create()
  }
}

권한 상태 확인을 보다 깔끔하게 사용하기

각각의 다른 프로퍼티를 호출하여 사용하는 것 보다 하나의 메서드를 사용하는게 더 간단하고 가독성이 좋을 것 같다.

권한 타입 정의

enum PermissionType {
  case notification, camera, photo
}

권한 확인 메서드 구현

파라미터로 확인하고자 하는 권한 타입을 넣어 확인할 수 있다!

func checkPermission(for type: PermissionType) -> Observable<Bool> {
  switch type {
  case .notification:
    return notificationPermission
  case .camera:
    return cameraPermission
  case .photo:
    return photoPermission
  }
}

사용 예시

button.rx.tap
    .flatMap {
        PermissionManager().checkPermission(for: .camera)
    }
    .subscribe(with: self) { owner, status in
        ...
    }
    .disposed(by: disposBag)

[iOS/Swift] 인앱에서 앱스토어 리뷰 팝업 띄우기

김졀니 — Thu, 24 Oct 2024 15:14:43 +0900

인앱리뷰

최대 3번 노출 가능

리뷰 요청을 자주 띄우는 것은 오히려 사용자에게 부정적 인식을 가져다 줄 수 있기 때문에 요청의 텀을 충분히 줘야한다.

그렇기 때문에 시스템 내부적으로 365일 내에 최대 3번만 노출되도록 제한이 되어있다.

시스템에서 팝업 노출을 제한하기 때문에 리뷰 팝업을 띄우는 코드가 심어져있다고 무조건 팝업이 뜨는 것은 아니다!

단, 시스템에서 제어하는 경우는 앱스토어에 릴리즈 된 앱의 경우에만 해당된다. 디버그 모드에서는 리뷰 팝업이 설계한 대로 무조건 노출되고, 테스트플라이트에서는 노출되지 않는다.

적절한 타이밍에 노출해야 한다.

리뷰 요청 팝업을 띄울 때는 적절한 타이밍을 찾아야한다.

앱에 진입하자마자 또는 온보딩 과정은 적절하지 않은 타이밍이다. 사용자가 앱에 대해 충분한 사용 경험이 없기 때문이다.

사용자가 앱 내에서 작업을 수행하는 과정 중에 노출시키는 것 또한 적절하지 않은 타이밍이다. 사용자의 앱 사용을 방해하면 안된다.

또, 리뷰를 했을 경우 보상이 주어지는 대가성 리뷰의 경우에는 심사 리젝 대상이라고 한다.

사용자가 충분히 앱을 사용하고 좋은 경험이 쌓였을 시점에 노출하도록 하자.

StoreKit

인앱 구매나 앱스토어와의 인터렉션 관련 기능을 지원하는 프레임워크

인앱 리뷰 요청 팝업을 띄우기 위해서는 StoreKit 의 `SKStoreReviewController`를 사용할 수 있다.

`SKStoreReviewController.reqeustReview(in: )` 을 호출하게 되면 리뷰 팝업이 나타나게 된다.

코드

guard let scene = UIApplication.shared.connectedScenes.first(where: {
  $0.activationState == .foregroundActive
}) as? UIWindowScene else {
  return
}
SKStoreReviewController.requestReview(in: scene)

참고 자료

[iOS] 사용자에게 어떻게 리뷰를 받을 수 있을까? (+ SKStoreReviewController)

Ratings and reviews | Apple Developer Documentation

[iOS/SwiftUI] Text 더보기 버튼 만들기 - ViewThatFits

김졀니 — Fri, 19 Apr 2024 16:42:42 +0900

스유 초보이기 때문에 틀린 내용이 있을 수 있습니다!

❓ViewThatFits

ViewThatFits 는 iOS 16.0이상부터 사용 가능하다.

ViewThatFits를 채택한 뷰는 부모 뷰가 크기를 정하는 것이 아니라 자신의 크기에 맞게 뷰의 크기를 조절할 수 있다.

https://developer.apple.com/documentation/swiftui/viewthatfits

공식문서에 코드와 함께 예시로 설명이 되어있는데

struct UploadProgressView: View {
    var uploadProgress: Double

    var body: some View {
        ViewThatFits(in: .horizontal) {
            HStack {
                Text("\(uploadProgress.formatted(.percent))")
                ProgressView(value: uploadProgress)
                    .frame(width: 100)
            }
            ProgressView(value: uploadProgress)
                .frame(width: 100)
            Text("\(uploadProgress.formatted(.percent))")
        }
    }
}

UploadProgressView의 body가 ViewThatFits로 만들어져있다.

예시 코드는 수평 길이에 따라 텍스트와 ProgressView 모두 보여주거나, PorgressView만 보여주거나 텍스트만 보여주도록 한다.

VStack {
    UploadProgressView(uploadProgress: 0.75)
        .frame(maxWidth: 200)
    UploadProgressView(uploadProgress: 0.75)
        .frame(maxWidth: 100)
    UploadProgressView(uploadProgress: 0.75)
        .frame(maxWidth: 50)
}

뷰 내부에 들어갈 데이터가 모두 들어갈 충분한 공간을 가지고 있다면 첫번째 HStack 내부의 뷰를 보여주고, 그 다음 크기에 맞도록 알맞게 뷰가 그려진다.

이러한 것으로 보아..
ViewThatFits는 뷰 내부에 들어갈 컨텐츠의 크기를 계산하고, 해당 컨텐츠가 모두 수용 가능한 크기의 뷰를 골라 그려주는 방식이다.

전체코드

import SwiftUI

struct TruncatedTextView: View {
    private var text: String = ""
    private var lineLimit: Int = 1

    @State private var isTruncated: Bool? = nil
    @State private var isExpended: Bool = false

    init(text: String, lineLimit: Int) {
        self.text = text
        self.lineLimit = lineLimit
    }

    private func calculateTruncation() -> some View {
        ViewThatFits(in: .vertical) {
            Text(text)
                .font(.caption)
                .hidden()
                .onAppear {
                    guard isTruncated == nil else { return }
                    isTruncated = false
                }

            Color.clear
                .hidden()
                .onAppear {
                    guard isTruncated == nil else { return }
                    isTruncated = true
                }
        }
    }

    var body: some View {
        Text(text)
            .font(.caption)
            .lineLimit(isExpended ? nil : lineLimit)
            .background(calculateTruncation())
            .overlay(alignment: .bottomTrailing) {
                if isTruncated == true && !isExpended {
                    Text(" ..더보기")
                        .font(.caption)
                        .foregroundStyle(.blue)
                        .underline()
                        .onTapGesture {
                            self.isExpended.toggle()
                        }
                        .background {
                            RoundedRectangle(cornerRadius: 8)
                                .fill(
                                    LinearGradient(gradient: Gradient(colors: [Color(white: 1, opacity: 0.8), .white]), startPoint: .leading, endPoint: .trailing)
                                )
                        }
                }


            }
    }
}