lyhonghwa Blog

FUNCTIONAL PROGRAMMING

2019-09-23T14:00:00+00:00

함수형 프로그래밍

3가지로 구분된 프로그래밍 패러다임

저사양 컴퓨터 -> 최적화가 필요 -> 중복된 코드 제거, 메모리 재사용
컴퓨터 보급화 -> 많은 소프트 웨어 생산 -> 코드의 재사용 필요 -> OOP
고성능 컴퓨터(다수의 CPU(다수의 Core를 가진 CPU)) -> 병렬 처리(동시성) -> FP(외부에서 값을 변경하는 것을 제거하고 새로운 값을 만들자)

FP의 오해

map, reduce, higher order fuction, immutable data 이런 건 프로그래밍 기법이지 FP가 아니다.
FP의 가장 큰 특징은 side effect를 없이 코드를 작성하는 것이다.

순수함수(Pure Function)

함수형 프로그램은 함수의 조합으로 프로그래밍 하는데, 여기서 말하는 함수는 기존 함수 또는 메서드와 구분 하기 위해 순수함수라고 말한다.
이 순수함수는 ‘특정 input에 대해서 항상 동일한 output을 반환하는 함수’를 의미한다.

var sum = 0
func 순수함수_만들기(_ nums: [Int]) -> Int {
    for i in nums {
        sum += i
    }
    return sum
}

func 순수함수_만들기_결과(_ nums: [Int]) -> Int {
    return nums.reduce(0, +)
}

//질문:
func 이건_순수힘수_일까(_ num: Int) -> Int {
    return Int.random(in: 0...100) % num
}

//답: No

고차함수(higher-order function)

함수를 파라미터로 받거나 함수를 리턴하는 함수를 고차함수 라고 한다.

Composition

함수의 반환값이 다른 함수의 입력값으로 사용되는 것을 함수의 합성. 함수의 조합을 도와줌

func compose<A, B, C>(_ 합성_요소_1: @escaping (A) -> B, _ 합성_요소_2: @escaping (B) -> C) -> (A) -> C {
    return {
        return 합성_요소_2(합성_요소_1($0))
    }
}

func 짝수(_ A: [Int]) -> [Int] {
    return A.filter { $0 % 2 == 0 }
}

func 더하기(_ B: [Int]) -> Int {
    return B.reduce(0, +)
}

print("[filter even + sum] = \(compose(짝수, 더하기)([1, 2, 3, 4]))")

Currying

여러개의 파라미터를 받는 함수를 하나의 파라미터를 받는 여러 개의 함수로 쪼개는 것 == 다항으로 이루어진 함수를 단항으로 실행 시킬 수 있는 함수.
결국 함수의 합성을 원활하게 하기 위해서 커링을 사용하는 것. OOP는 객체의 상호작용이라 하면 FP는 함수의 조합 이라고 생각한다.

func curry<A, B, C>(실행될_함수: @escaping (A, B) -> C) -> (A) -> (B) -> C {
    return { (a: A) -> (B) -> C in
        { (b: B) -> C in
            return 실행될_함수(a, b)
        }
    }
}

func 배수(_ 추가된_파라미터: Int, _ A: [Int]) -> [Int] {
    return A.filter { $0 % 추가된_파라미터 == 0 }
}

//질문: compose(배수, 더하기) 이렇게 합성 하고 싶으면?

//답:
print("[(filter_다른_파라미터 > curry) + sum] = \(compose(curry(실행될_함수: 배수)(5), 더하기)([1, 5, 10]))")

Memoization

순수 함수를 유지하면서 기존 사용했던 연산을 캐시 하여 동일한 연산을 하지 않아도 되게끔 하는 기법.

[기존]

enum 뷰_타입: Hashable {
    case feed
    case posting
    case discovery
}

extension String {
    var height: CGFloat { return CGFloat(count) }
}

struct 모델 {
    let feedText: String
    let postingText: String
    let discoveryText: String
}

class 유동적인_높이를_가진_뷰_일반 {
    private var heights: [뷰_타입: CGFloat] = [:]
    
    func setupHeights(with model: 모델) {
        heights[.feed] = model.feedText.height
        heights[.posting] = model.postingText.height
        heights[.discovery] = model.discoveryText.height
    }
    
    func heights(with type: 뷰_타입) -> CGFloat {
        return heights[type] ?? 0
    }
}

[메모이제이션]

class 유동적인_높이를_가진_뷰_메모이제이션 {
    typealias HeightCacheType = [뷰_타입: CGFloat]
    
    enum CallType {
        case setup(모델)
        case get(뷰_타입)
    }
    
    static private func memoizeHeightsProcessing(with initHeights: HeightCacheType) -> (CallType) -> CGFloat? {
        var heights = initHeights
        return { callType in
            switch callType {
            case let .setup(model):
                heights[.feed] = model.feedText.height
                heights[.posting] = model.postingText.height
                heights[.discovery] = model.discoveryText.height
                return nil
            case let .get(viewType) :
                return heights[viewType]
            }
        }
    }
    
    let processHeights = 유동적인_높이를_가진_뷰_메모이제이션.memoizeHeightsProcessing(with: [:])
    
    func setupHeights(with model: 모델) {
        _ = processHeights(.setup(model))
    }
    
    func heights(with type: 뷰_타입) -> CGFloat {
        return processHeights(.get(type)) ?? 0
    }
}

Iterable

순회 가능한 값
IteratorProtocol: next라는 함수를 가지고 있는 프로토콜
Sequence: next가 nil이 될 때 까지 for in을 할 수 있는 프로토콜

struct 거꾸로_실행되는_모델_Sequence: Sequence {
    let elements: [Int]
    
    func makeIterator() -> 거꾸로_실행되는_모델_Iterator {
        return 거꾸로_실행되는_모델_Iterator(sequence: self)
    }
}

struct 거꾸로_실행되는_모델_Iterator: IteratorProtocol {
    private let sequence: 거꾸로_실행되는_모델_Sequence
    private var elements: [Int] {
        return sequence.elements
    }
    var nextIndex: Int
    
    init(sequence: 거꾸로_실행되는_모델_Sequence) {
        self.sequence = sequence
        self.nextIndex = sequence.elements.count - 1
    }
    
    mutating func next() -> Int? {
        guard nextIndex >= 0 else { return nil }
        defer { nextIndex -= 1 }
        return elements[nextIndex]
    }
}

let reversedModelSequence = 거꾸로_실행되는_모델_Sequence(elements: [1, 2, 3, 4, 5])
for element in reversedModelSequence {
    print("[Reversed model 1]: \(element)")
}

//질문: 위 next에서 nextIndex를 초기화 해주지 않았는데 아래 처럼 한 번 더 실행하면 예상치 못한 결과가 나오지 않을까?
//답: for in 에서 새로운 iterator를 만들기 때문에 괜찮다.
for element in reversedModelSequence {
    print("[Reversed model 2]: \(element)")
}

Lazy

지연 연산자
즉시 연산을 하는게 아니라서 불필요한 연산을 막아준다
원리는 아래 처럼 base.next를 호출함으로 가능하다.

(filter(map(next())))

Lazy Map 구현

struct FakeLazyMapSequence<Base: Sequence, Element> {
    let _base: Base
    let _transform: (Base.Element) -> Element
    
    init(_base base: Base, _ transform: @escaping (Base.Element) -> Element) {
        self._base = base
        self._transform = transform
    }
}

extension FakeLazyMapSequence {
    struct Iterator {
        var _base: Base.Iterator
        let _transform: (Base.Element) -> Element

        init(_base: Base.Iterator, _transform: @escaping (Base.Element) -> Element) {
            self._base = _base
            self._transform = _transform
        }
    }
}

extension FakeLazyMapSequence.Iterator: IteratorProtocol, Sequence {
    mutating func next() -> Element? {
        return _base.next().map(_transform)
    }

    func makeIterator() -> FakeLazyMapSequence<Base, Element>.Iterator {
        return self
    }
}

extension FakeLazyMapSequence: Sequence {
    func makeIterator() -> Iterator {
        return Iterator(_base: _base.makeIterator(), _transform: _transform)
    }
}

Lazy Filter 구현

struct FakeLazyFilterSequence<Base: Sequence> {
    let _base: Base
    let _predicate: (Base.Element) -> Bool
    
    init(_base: Base, _isIncluded: @escaping (Base.Element) -> Bool) {
        self._base = _base
        self._predicate = _isIncluded
    }
}

extension FakeLazyFilterSequence {
    struct Iterator {
        var _base: Base.Iterator
        let _predicate: (Base.Element) -> Bool
        
        init(_base: Base.Iterator, _ isIncluded: @escaping (Base.Element) -> Bool) {
            self._base = _base
            self._predicate = isIncluded
        }
    }
}

extension FakeLazyFilterSequence.Iterator: IteratorProtocol, Sequence {
    typealias Element = Base.Element
    
    mutating func next() -> Element? {
        while let n = _base.next() {
            if _predicate(n) {
                return n
            }
        }
        return nil
    }
    
    func makeIterator() -> FakeLazyFilterSequence<Base>.Iterator {
        return self
    }
}

extension FakeLazyFilterSequence: Sequence {
    typealias Element = Base.Element
    
    func makeIterator() -> Iterator {
        return Iterator(_base: _base.makeIterator(), _predicate)
    }
}

결과

extension LazySequence {
    func fakeFilter(_ isIncluded: @escaping (Base.Element) -> Bool) -> FakeLazyFilterSequence<Base> {
        return FakeLazyFilterSequence<Base>(_base: self.elements, _isIncluded: isIncluded)
    }
}

extension FakeLazyFilterSequence {
    func fakeMap<U>(_ transform: @escaping (Base.Element) -> U) -> FakeLazyMapSequence<FakeLazyFilterSequence<Base>, U> {
        return FakeLazyMapSequence<FakeLazyFilterSequence<Base>, U>(_base: self, transform)
    }
}

[1, 2, 3, 4, 5]
    .lazy
    .fakeFilter { $0 % 2 == 0 }
    .fakeMap { "\($0 * 2)" }
    .forEach { print($0) }

[곰튀김 유료강의] 참고

Codable

2018-05-22T03:00:00+00:00

Codable 사용해보기

Codable

Concurrency Programming Guide를 공부 할 차례인데
회사 프로젝트에 Codable을 사용하고 싶어 이렇게 Codable을 먼저 하게 됐어요!
(같은 값인데 API에 따라 key 값도 value 타입도 달라서 하나씩 다 캐스팅해줬었는데 이걸 Codable로 하면 어떻게 할 수 있을까 궁금해졌어요)

공부 방법은

Encoding and Decoding Custom Types 문서를 읽고
단순히 property의 key 값을 맞춰주는 정도가 아닌 제가 사용할 수 있는 예제 코드를 만들어 보려고 해요

문서 부터 시작을 하겠습니다.

Encoding and Decoding Custom Types

Codable 프로토콜을 채택하면 JSON 같은 타입을 내가 만든 model로 encoding decoding 가능하게 만들어준다.

Overview

요즘 프로그램들이 encode와 decode를 자주 하니깐 swift library에서는
Encodable, Decodable이라는 표준화된 접근 방식(프로토콜)을 정의해놨다.

이 프로토콜을 채택하면 프로토콜의 구현

1. Encodable: public func encode(to encoder: Encoder) throws
2. Decodable: public init(from decoder: Decoder) throws

을 통해서 encoding 혹은 decoding 할 수 있다.
encoding, decoding 둘 다 지원하려면 Codable 프로토콜을 준수하면 된다.

Encode and Decode Automatically

model type을 Codable하게 만드는 가장 쉬운 방법은
기본 library(String, Int, Double…), foundation(Date, Data, URL…) 같은 이미 Codable이 가능한 타입을 property로 선언하는 방법이다.
이러한 타입의 property를 가진 타입에 Codable을 채택하면 프로토콜에 정의된 메서드가 자동으로 구현된다.

아래 코드를 살펴보면
Codable을 준수하고 property들이 기본 library type이므로 자동으로 Encodable, Decodable을 준수하게 된다.

struct Landmark: Codable {
    var name: String
    var foundingYear: Int
    
    // Landmark now supports the Codable methods init(from:) and encode(to:), 
    // even though they aren't written as part of its declaration.
}

그리고 PropertyListEncoder, Decoder나 JSONEncoder, Decoder 같은 Encoder, Decoder Type들은
Codable protocol에 정의된 메서드를 사용해서 decode 혹은 encode를 한다.

아래처럼 custom type(A)이 Codable protocol을 준수한다면 custom type(A)을 proeprty로 가지는 다른 custom type(B)에서도 codable 가능 하다.

struct Coordinate: Codable {
    var latitude: Double
    var longitude: Double
}

struct Landmark: Codable {
    // Double, String, and Int all conform to Codable.
    var name: String
    var foundingYear: Int
    
    // Adding a property of a custom Codable type maintains overall Codable conformance.
    var location: Coordinate
}

Array, Dictionary 및 Optional과 같은 Built-in type은 Codable을 준수한다, 따라서 아래처럼 코드를 작성해도 codable 가능 하다.

struct Landmark: Codable {
    var name: String
    var foundingYear: Int
    var location: Coordinate
    
    // Landmark is still codable after adding these properties.
    var vantagePoints: [Coordinate]
    var metadata: [String: String]
    var website: URL?
}

Encode or Decode Exclusively

Codable은 Encodable, Decodable을 둘 다 준수하는 protocol이지만 한가지 기능만 필요하다면 아래 코드처럼 Codable이 아닌 Encodable, Decodable 둘 중 하나만 준수해도 된다.

struct Landmark: Encodable {
    var name: String
    var foundingYear: Int
}

struct Landmark: Decodable {
    var name: String
    var foundingYear: Int
}

Choose Properties to Encode and Decode Using Coding Keys

CodingKey protocol을 준수하고
rawValue가 String인 CodingKeys라는 이름을 가진 enum을 사용해 
아래 코드처럼 custom type의 property와 매칭 시켜줄 수 있다.

JSON 형식을 예로 들었을 때 포함하고 싶지 않은 값은 custom type의 property를 없애고 CodingKeys도 없애면 된다.

struct Landmark: Codable {
    var name: String
    var foundingYear: Int
    var location: Coordinate
    var vantagePoints: [Coordinate]
    
    enum CodingKeys: String, CodingKey {
        case name = "title"
        case foundingYear = "founding_date"
        
        case location
        case vantagePoints
    }
}

Encode and Decode Manually

데이터 형식의 구조(예를 들어 JSON의 구조)가 custom type의 구조와 다를 경우
수동으로 decode와 econde를 통해 원하는 결과를 얻을 수 있다.

아래에 살펴볼 예제는 다른 레벨에 있는 데이터를 가지고 같은 레벨의 데이터를 만드는 과정을 설명한다.

{
    "A": 1,
    "B": 2,
    "C": {
        "D": 3
    }
}

예를들어 이러한 JSON 데이터를 가지고
1, 2, 3을 value값으로 가지는 custom type을 만든다고 가정하고
아래 글을 읽으면 좋을것 같다.

아래 예제는 C(additionalInfo) 안에 있는 D(elevation)를 property로 지원하기 위해서 codingkey를 두 개 만든 코드이다.
각각 자신의 레벨에서 해당하는 key 를 가지고 있다.

struct Coordinate {
    var latitude: Double
    var longitude: Double
    var elevation: Double

    enum CodingKeys: String, CodingKey {
        case latitude
        case longitude
        case additionalInfo
    }
    
    enum AdditionalInfoKeys: String, CodingKey {
        case elevation
    }
}

아래 예제는 init(from decoder: Decoder)를 수동으로 구현한 예제이다.

extension Coordinate: Decodable {
    init(from decoder: Decoder) throws {
        let values = try decoder.container(keyedBy: CodingKeys.self)
        latitude = try values.decode(Double.self, forKey: .latitude)
        longitude = try values.decode(Double.self, forKey: .longitude)
        
        let additionalInfo = try values.nestedContainer(keyedBy: AdditionalInfoKeys.self, forKey: .additionalInfo)
        elevation = try additionalInfo.decode(Double.self, forKey: .elevation)
    }
}

decoder 파라미터를 사용해 각 proeprty를 채워 넣는 방식으로 인스턴스 오브젝트를 초기화한다.

아래 예제는 func encode(to encoder: Encoder)를 수동으로 구현한 예제이다.

extension Coordinate: Encodable {
    func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: CodingKeys.self)
        try container.encode(latitude, forKey: .latitude)
        try container.encode(longitude, forKey: .longitude)
        
        var additionalInfo = container.nestedContainer(keyedBy: AdditionalInfoKeys.self, forKey: .additionalInfo)
        try additionalInfo.encode(elevation, forKey: .elevation)
    }
}

encode(to:) 구현은 init(from decoder: Decoder)와 반대로 하면 된다.

문서는 여기까지고요. 아래에 예제 코드를 작성해봤습니다.

위에서 언급했듯이

1. 같은 값을 나타내는 필드이지만 key 값이 다르고
2. 심지어 value의 타입도 다른 경우

를 위해 작성해 봤고요. 혹시나 더 좋은 방법 있으면 알려주세요! 꼭 부탁드려요!

사용

let json = """
{
    "user": [
        {
            "name": "사용자A",
            "age": "28",
            "job": "developer",
            "force_app_version": "Y"
        },
        {
            "NAME": "사용자B",
            "age": 26,
            "job": "designer",
            "force_app_version": false
        }
    ]
}
""".data(using: .utf8)!

//user container
struct UserList: Decodable {
    let list: [User]
    
    private enum CodingKeys: String, CodingKey {
        case list = "user"
    }
}

//user
struct User {
    enum JobType: String, Decodable {
        case developer
        case designer
        case none
    }
    
    let name: String        //json의 key 값이 다르다. (uppercase, lowercase)
    let age: Int            //json의 value type 이 다르다. (String, Int -> Int)
    let job: JobType        //이건 그냥 해봤어요
    let forceUpdate: Bool   //json의 value type 이 다르다. (String, Bool -> Bool)
}

//coding key
extension User {
    struct CodingKeys: CodingKey {
        var stringValue: String
        init?(stringValue: String) {
            self.stringValue = stringValue
        }
        
        var intValue: Int? { return nil }
        init?(intValue: Int) { return nil }
        
        private static let baseName = "name"
        static func name(letterCase: String.LetterCase) -> CodingKeys {
            return CodingKeys(stringValue: baseName.changedString(letterCase))!
        }
        static let age = CodingKeys(stringValue: "age")!
        static let job = CodingKeys(stringValue: "job")!
        static let forceUpdate = CodingKeys(stringValue: "force_app_version")!
    }
}

//decode
extension User: Decodable {
    typealias LetterCase = String.LetterCase
    
    public init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        name = try [LetterCase.lower, LetterCase.upper].extractOneElement(type: String.self) { letterCase -> String? in
            return try? container.decode(String.self, forKey: .name(letterCase: letterCase))
        }
        age = try container.decode(type: Int.self, forKey: .age)
        job = try container.decode(type: JobType.self, forKey: .job)
        forceUpdate = try container.decode(type: Bool.self, forKey: .forceUpdate)
    }
}

do {
    let decoder = JSONDecoder()
    let products = try decoder.decode(UserList.self, from: json)
    dump(products.list)
    /*
     ▿ 2 elements
     
     ▿ Codable.User
     - name: "사용자A"
     - age: 28
     - job: Codable.User.JobType.developer
     - forceUpdate: true
     
     ▿ Codable.User
     - name: "사용자B"
     - age: 26
     - job: Codable.User.JobType.designer
     - forceUpdate: false
     */
} catch {
    print("Decode Error: \(error.localizedDescription)")
}

Extension

//error
public struct DecodeError: Error, LocalizedError {
    let description: String
    
    public var errorDescription: String? {
        return description
    }
}

//decoder
extension KeyedDecodingContainer {
    public func decode<T>(type: T.Type, forKey key: KeyedDecodingContainer.Key) throws -> T where T : Decodable {
        switch type {
        case is Int.Type:
            do {
                let value =  try intDecode(forKey: key)
                return value as! T
            } catch {
                throw error
            }
        case is Bool.Type:
            do {
                let value =  try boolDecode(forKey: key)
                return value as! T
            } catch {
                throw error
            }
        default:
            do {
                return try decode(type, forKey: key)
            } catch {
                throw DecodeError(description: "Decode Error")
            }
        }
    }
    //int
    public func intDecode(forKey key: KeyedDecodingContainer.Key) throws-> Int? {
        do {
            return try [Int.self, String.self].extractOneElement(type: Int.self) { convertibleType -> Int? in
                switch convertibleType {
                case is Int.Type:
                    return try? decode(Int.self, forKey: key)
                case is String.Type:
                    guard let value = try? decode(String.self, forKey: key) else { return nil }
                    return Int(value)
                default:
                    return nil
                }
            }
        } catch {
            throw error
        }
    }
    //bool
    public func boolDecode(forKey key: KeyedDecodingContainer.Key) throws-> Bool? {
        do {
            return try [Bool.self, String.self].extractOneElement(type: Bool.self) { convertibleType -> Bool? in
                switch convertibleType {
                case is Bool.Type:
                    return try? decode(Bool.self, forKey: key)
                case is String.Type:
                    guard let value = try? decode(String.self, forKey: key) else { return nil }
                    return value.asBool
                default:
                    return nil
                }
            }
        } catch {
            throw error
        }
    }
}

extension Array {
    public func extractOneElement<T>(type: T.Type, _ body: (Element) -> T?) throws -> T {
        for element in self {
            let decodedElement = body(element)
            guard decodedElement == nil else { return decodedElement! }
        }
        throw DecodeError(description: "Extract One Element Empty Error")
    }
}

extension String {
    enum LetterCase {
        case upper
        case lower
    }
    
    func changedString(_ letterCase: LetterCase) -> String {
        switch letterCase {
        case .lower:
            return lowercased()
        case .upper:
            return uppercased()
        }
    }
}

extension String {
    var asBool: Bool {
        return self == "1" || self == "OK" || self == "true" || self == "Y"
    }
}

느낀점

1. 데이터 형식의 key와 value가 일정할 때 사용하면 정말 좋을 것 같다.(대부분은 일정하니 정말 좋은 기능이다.)
2. 그렇지 않다면 기존에 수동(JSON -> Dictionary -> Casting)으로 해주는 것과 비슷하게 처리해 줘야 한다.

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

Thread Management(1-3)

2018-05-04T01:00:00+00:00

왜 나는 GCD를 썼을까?(Dispatch)

iOS에서 Thread 관리하기 1-3 (Dispatch)

이번 블로그는 Dispatch의 문서를 보도록 하겠습니다.

Dispatch

dispatch queue에게 작업을 주면 multicore에서 동시에 작업을 실행할 수 있게 만들어준다.

개요

multicore에서 동시에 작업을 실행할 수 있는 엄청난 일을 내가(apple님) 다 알아서 해줄 테니 잘 사용해라.

Topics

Managing Dispatch Queues

GCD는 FIFO queue를 관리하고 제공한다. 그리고 그 queue들은 block 형태의 작업을 등록할 수 있으며
등록된 작업은 알아서(시스템에게) 관리되는 thread pool 방식으로 실행된다.
thread pool 이란 thread를 여러개 만들어서 작업이 시작되면 thread에게 작업을 할당해 주는 방식이다.
너무 많이 만들어 놨다던가 만들어 놓은 thread가 골고루 일을 못하면 관리를 해줘야하는데 그걸 알아서 시스템이 해준다는 말이다.

Synchronous and Asynchronous Execution

sync: 모든게 멈추고 실행 구문 안에 있는 작업이 다 끝난 후 반환.
async: 실행 구문 메서드를 즉각 반환.

Serial and Concurrent Queues

FIFO 순서로 처리하되 serial은 한 개씩 순서대로 끝나고, concurrent는 순서에 상관없이 끝난다. 잘 와닿지 않다면 serial(single thread), concurrent(multi thread)라고 생각하면 되지만 concurrent 에 등록된 work item에 따라서 single thread가 될 수도 있다는 점을 명시하자.

System-Provided Queues

app을 실행하면 자동으로 main queue를 만든다. 이 queue는 serial queue이며 순차적으로 작동되고 DispatchQueue.main 이렇게 호출할 수 있다.

중요한점
sync 하게 main queue에게 작업을 시도하면 deadlock이 걸린다. 왜 걸릴까? 

잘생각해보면 

main queue는 serial이고
현재 main thread에서 실행중인 코드가 있고
그 밑에 main queue에 sync로 작업을 등록하는 코드가 있다고 치자(실제로는 안되지만)
그러면 현재 실행중인 코드가 진행하면서 작업을 main queue에 등록하고
그리고 등록된 작업을 하기 위해서 program이 멈추고
현재 실행 중이었던 작업도 그럼 멈춘다.
서로 언제 끝날까?

시스템은 main queue 외에도 global queue를 만드는데 이건 concurrent queue이며 multi thread를 지원한다. DispatchQueue.global(qos:) 이렇게 qos를 지정하여 사용하는 게 좋다.

위의 내용을 코드로 한번 보면 좀 더 이해하기 쉬울 수 있어서 아래 코드를 준비했습니다.

 let serialQueue1 = DispatchQueue(label: "io.github.lyhonghwa.serial1",
                                                qos: .default,
                                                autoreleaseFrequency: .inherit,
                                                target: nil)
                
                let serialQueue2 = DispatchQueue(label: "io.github.lyhonghwa.serial2",
                                                qos: .default,
                                                autoreleaseFrequency: .inherit,
                                                target: nil)
                
                let concurrentQueue1 = DispatchQueue(label: "io.github.lyhonghwa.concurrent1",
                                                    qos: .default,
                                                    attributes: .concurrent,
                                                    autoreleaseFrequency: .inherit,
                                                    target: nil)
                
                let concurrentQueue2 = DispatchQueue(label: "io.github.lyhonghwa.concurrent2",
                                                     qos: .default,
                                                     attributes: .concurrent,
                                                     autoreleaseFrequency: .inherit,
                                                     target: nil)
                 */
                
                //4가지 조합
                
                /*
                1. (serial + sync) (총 1개 thread)
                 순차적으로 실행이 되고 main thread에서 실행이 됨. queue가 마음대로 thread pool 방식으로 관리를 하는 것 같다.
                 
                print("1")
                serialQueue1.sync {
                    print("\(Thread.current), 2")
                }
                serialQueue1.sync {
                    print("\(Thread.current), 3")
                }
                print("4")
                serialQueue2.sync {
                    print("\(Thread.current), 5")
                }
                serialQueue2.sync {
                    print("\(Thread.current), 6")
                }
                print("7")
                 */
                
                
                /*
                2. (serial + async) (총 2개 thread)
                 각각의 queue는 single thread를 가지고 task가 끝나면 다음 work item을 진행한다.
                 즉 1, 2번의 작업순서는 다를 수 있지만 각 queue에서 처리되는 work item은 순서가 같다.
                 
                print("1")
                serialQueue1.async {
                    print("\(Thread.current), 2")
                }
                serialQueue1.async {
                    print("\(Thread.current), 3")
                }
                print("4")
                serialQueue2.async {
                    print("\(Thread.current), 5")
                }
                serialQueue2.async {
                    print("\(Thread.current), 6")
                }
                print("7")
                 */
                
                /*
                3. (concurrent + sync) (총 1개 thread)
                 순차적으로 실행이 되고 main thread에서 실행이됨. queue가 마음대로 thread pool방식으로 관리를 하는것같다.
                 공부하기 전에는 1번과 2번이 번갈아가면서 실행될 줄 알았으나 1번이 끝난뒤에 2번이 실행된다. 또한 main thread에서 실행이되서 UI가 굳어버렸다.
                 그 이유는 sync는 work item이 끝날때 까지 program은 기다리기 때문이다.
 
                print("1")
                concurrentQueue1.sync {
                    print("\(Thread.current), 2")
                }
                concurrentQueue1.sync {
                    for int in 0...100000 {
                        print("\(Thread.current), 1 for: \(int)")
                    }
                    print("\(Thread.current), 3")
                }
                print("4")
                concurrentQueue2.sync {
                    for int in 0...100000 {
                        print("\(Thread.current), 2 for: \(int)")
                    }
                    print("\(Thread.current), 5")
                }
                concurrentQueue2.sync {
                    print("\(Thread.current), 6")
                }
                print("7")
                 */
                

                /*
                4. (concurrent + async) (총 4개 thread)
                 각각의 queue는 multi thread를 가지고 작업당 하나의 thread를 가지고 작업을 실행한다.
                 각기 다른 순서대로 실행된다.
                 
                print("1")
                concurrentQueue1.async {
                    print("\(Thread.current), 2")
                }
                concurrentQueue1.async {
                    print("\(Thread.current), 3")
                }
                print("4")
                concurrentQueue2.async {
                    print("\(Thread.current), 5")
                }
                concurrentQueue2.async {
                    print("\(Thread.current), 6")
                }
                print("7")
                 */
                
                /*
                 정리
                 queue: serial vs concurrent == single thread vs multi thread
                 work item: sync vs async == 모든게 멈추고 실행 구문안에 있는 작업이 다 끝난 후 반환 vs 실행 구문 메서드를 즉각 반환
                 */

코드를 안보실 수도 있으므로 정리를 해보겠습니다.

4가지 조합

1. (serial + sync) (총 1개 thread)

순차적으로 실행이 되고 main thread에서 실행이 됨. queue가 마음대로 thread pool 방식으로 관리를 하는 것 같다.

2. (serial + async) (총 2개 thread)

각각의 queue는 single thread를 가지고 task가 끝나면 다음 task를 진행한다.
즉 1, 2번의 작업순서는 다를 수 있지만 각 queue에서 처리되는 task의 순서가 같다.

3. (concurrent + sync) (총 1개 thread)

순차적으로 실행이 되고 main thread에서 실행이됨. queue가 마음대로 thread pool방식으로 관리를 하는것같다.
공부하기 전에는 1번과 2번이 번갈아가면서 실행될 줄 알았으나 1번이 끝난뒤에 2번이 실행된다. 또한 main thread에서 실행이되서 UI가 굳어버렸다.
그 이유는 sync는 work item이 끝날때 까지 program은 기다리기 때문이다.

4. (concurrent + async) (총 4개 thread)

각각의 queue는 multi thread를 가지고 작업당 하나의 thread를 가지고 작업을 실행한다.
각기 다른 순서대로 실행된다.

정리

queue: serial vs concurrent == single thread vs multi thread<br>
work item: sync vs async == 모든게 멈추고 실행 구문안에 있는 작업이 다 끝난 후 반환 vs 실행 구문 메서드를 즉각 반환

위에까지만 쓰려고 했으나 쓰고 있던 오픈소스가 궁금해서 CocoaAsyncSocket를 살펴보겠습니다.
CocoaAsyncSocket에서는 dispatch source를 많이 사용하는데요, 그래서 dispatch source 문서를 보겠습니다.
문서에 사용방법도 있어서 따로 사용해보지는 않겠습니다.
여기서부터는 objc를 봐야겠네요. 어느 정도 보실 수 있을 거라 생각하고 이해한 대로 설명하겠습니다.

Dispatch Sources

dispatch source로 low-level 이벤트에 대한 처리를 할 수 있다.

아래와 같은 기능을 제공한다.

Timer dispatch sources: 주기적으로 notification 발생

Signal dispatch sources: unix가 보내는 signal을 받을 수 있다.

Descriptor sources: file, socket 에 관련된 다양한 변경 사항을 받을수 있다.
    예를 들어 아래와 같은 상황을 알 수 있다.
    읽고 쓰기가 가능할 때,
    지워 지거나 이동되거나 이름이 변경되었을 때,
    메타 정보가 변경되었을 때

process dispatch sources: 프로세스와 관련된 이벤트를 받을 수 있다.
    예를 들어 아래와 같은 상황을 알 수 있다.
    종료될때,
    fork, exec 호출됬을 떄,
    process에 대한  signal이 도착했을 때

Mach port dispatch sources: Mach Kernel이 보내는 signal을 받을 수 있다.

Custom dispatch sources: 사용자가 정의한 이벤트가 발생될 때 알림을 받을 수 있다.

위에 상황에 맞는 dispatch source를 만들고 해당 이벤트가 발생되면 등록해 놓은 queue에 등록해 놓은 block이나 function을 실행시켜 준다.

중요한 점
block 을 dispatch queue에 수동으로 하나씩 등록했던 것과는 달리 dispatch source를 등록해 놓으면 cancel method를 할 때까지 등록된 block이나 function이 불려 그 안에서 다른 객체를 참조했다면 그 객체가 해제될 수 있으므로 조심해야 한다.

queue에 등록된 block이 백 로그(실행되기를 기다리는 상태) 되는 것을 방지하기 위해 새로운 이벤트와 이전 이벤트를 관리하는 기능이 있다.
예를 들어 이전 이벤트 + 새로운 이벤트로 하나의 이벤트를 만들어 줄 수도 있고 Signal dispatch sources의 경우는 최신 이벤트만 전달해준다.(그렇지만 총 signal의 수를 알려준다)

Creating Dispatch Sources

Dispatch Source를 만들기 위해서는 2가지가 필요하다.

dispatch_source 생성 (dispatch_source_create), descriptor-based dispatch source 만들때 descriptor 정보를 넣어줘야한다.
event 등록 (dispatch_source_set_event_handler, dispatch_source_set_timer…) dispatch_source_create해서 만들어진 dispatch_source는 resume을 해야 시작된다. 그 이유는 dispatch_source_create를 만들고 event를 등록하는데 그전에 이벤트가 일어나면 처리를 해야 하는데 그렇지 못하므로 suspend 상태의 dispatch_source가 반환되는 것 때문이다.

Writing and Installing an Event Handler

dispatch_source_set_event_handler(block), dispatch_source_set_event_handler_f(function pointer)
을 사용해서 이벤트가 발생 될경우 queue에 들어갈 handler를 지정해 줄 수 있다.

위에 설명했듯이 처리되지 않은 이벤트가 있고 그리고 또 이벤트가 들어온다면 병합 또는 최신것만 전달 될것이며
이미 queue에서 해당 이벤트에 대한 handler를 실행중이라면 실행중인 handler가 종료 된후에 queue에 등록한다.
dispatch_set_context를 통해 context받을 포인터 변수를 설정하면 function pointer로 설정된 function으로 data를 전달 받을 수 있지만
block은 handler block 내에서 dispatch_source_get_data 메서드를 사용해 data를 받을 수 있다.

해당 data를 직접적으로 변경하는것은 async로 일어나는 handler 때문에 하지 않는것을 추천한다.

    ispatch_source_t source = dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,
                                     myDescriptor, 0, myQueue);
    dispatch_source_set_event_handler(source, ^{
       // Get some data from the source variable, which is captured
       // from the parent context.
       size_t estimated = dispatch_source_get_data(source);
     
       // Continue reading the descriptor...
    });
    dispatch_resume(source);

아래는 데이터를 받을수 있는 메서드 항목이다.

dispatch_source_get_handle

시스템에서 기본적으로 제공해주는 handler
아래에 있는 dispatch_source일 경우에 해당하는 값을 반환한다.

DISPATCH_SOURCE_TYPE_MACH_SEND: mach port (mach_port_t)
DISPATCH_SOURCE_TYPE_MACH_RECV: mach port (mach_port_t)
DISPATCH_SOURCE_TYPE_PROC: process identifier (pid_t)
DISPATCH_SOURCE_TYPE_READ: file descriptor (int)
DISPATCH_SOURCE_TYPE_SIGNAL: signal number (int)
DISPATCH_SOURCE_TYPE_VNODE: file descriptor (int)
Dispatch Source Memory Pressure Event Flags: file descriptor (int)

dispatch_source_get_data

아래에 있는 dispatch_source일 경우에 해당하는 값을 반환한다.(event에 대한 data)

DISPATCH_SOURCE_TYPE_DATA_ADD: application-defined data
DISPATCH_SOURCE_TYPE_DATA_OR: application-defined data
DISPATCH_SOURCE_TYPE_MACH_SEND: Dispatch Source Mach Send Event Flags
DISPATCH_SOURCE_TYPE_MACH_RECV: not applicable
DISPATCH_SOURCE_TYPE_PROC: Dispatch Source Process Event Flags
DISPATCH_SOURCE_TYPE_READ: 읽을 수 있는 bytes
DISPATCH_SOURCE_TYPE_SIGNAL: number of signals delivered since the last handler invocation
DISPATCH_SOURCE_TYPE_TIMER: 지난 호출로 부터 현재 까지 호출된 횟수
DISPATCH_SOURCE_TYPE_VNODE: Dispatch Source Vnode Event Flags
Dispatch Source Memory Pressure Event Flags: estimated buffer space available

dispatch_source_get_mask

아래에 있는 dispatch_source일 경우에 해당하는 비트 마스크 값을 반환한다.

DISPATCH_SOURCE_TYPE_MACH_SEND: Dispatch Source Mach Send Event Flags
DISPATCH_SOURCE_TYPE_PROC: Dispatch Source Process Event Flags
DISPATCH_SOURCE_TYPE_VNODE: Dispatch Source Vnode Event Flags

Installing a Cancellation Handler

dispatch_source_set_cancel_handler, dispatch_source_set_cancel_handler_f를 사용해 이벤트에 따른 handler 실행을 취소할 수 있다.
descriptor나 mach port의 이벤트는 다시 사용될 때 의도치 않은 버그가 생길 수도 있으니 꼭 취소시켜줘야 한다.

Changing the Target Queue

dispatch_set_target_queue를 사용해 queue를 변경할 수 있다.
즉시 적용은 되지 않고 바꾸기 전에 queue에 이벤트들이 남았다면 다 처리 후 바뀐다.

Associating Custom Data with a Dispatch Source

dispatch_set_context 메서드를 사용하여 dispatch source 사용자가 지정한 데이터와 연결할 수 있다.
dispatch source가 더 이상 필요하지 않다면 cancel handler를 사용해 사용자가 지정한 포인터를 해제해줘야 한다.
block을 사용해 handler를 구현한 경우에 포인터 변수를 안에서 참조할 경우 dispatch source 특성상 오랫동안 메모리에 있으므로 참조한 변수가 사라질 수도 있으니 copy나 retain을 해서 사용하는 것이 좋다.
그리고 cancel handler를 구현해 해당 데이터를 해제해야 한다.

Memory Management for Dispatch Sources

dispatch source는 dispatch queue와 마찬가지로 dispatch_retain 및 dispatch_release 메서드를 사용해서 reference count가 0이 된다면 자동으로 해제된다.

이 아래부터는 예제라서 굳이 적지 않겠습니다.

QOS는 Concurrency Programming Guide를 볼 떄 정리하겠습니다.
아 적다보니 DispatchGroup이 빠졌네요 가능한 빨리 공부해서 채워놓겠습니다.

느낀점

간단하게 작성할 수 있다.
유연하게 작성이 가능하다.(조합할 수 있는게 많다.)
시스템 관련 이벤트를 받을 수 있다.(엄청난것 같다 최고!!!)
C 기반이라서 빠르다고 한다.(직접 느껴보지는 못했습니다)

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

Thread Management(1-2)

2018-05-02T00:00:00+00:00

왜 나는 GCD를 썼을까?(Operation)

iOS에서 Thread 관리하기 1-2 (NSOperation)

이번 블로그는 NSOperation(Operation)과 NSOperationQueue(OperationQueue)의 문서를 보도록 하겠습니다.

예전에 원본을 번역해야지 하는 생각으로 글을 쓰다가 저도 무슨 말인지 모르는데 그냥 해석해놓은 느낌으로 쓴 적이 있습니다. 그런 글 쓰는방식이 좋지 않은 것 같아 이번에는 번역한 것이 아니라 이해한 대로 설명드릴 거라 아마 틀릴 수도 있습니다.

혹시나 틀린 점 있으면 꼭 알려주시면 감사하겠습니다.

Operation

작업 하나를 나타내는 추상 클래스(추상 클래스라 하면 ‘공통된 기능을 가진 놈이다.’ 라고 생각하면 편하다)

개요

추상 클래스이기 때문에 직접 사용하지 말고 상속받아서 사용해라. 또는 기본으로 제공되는 BlockOperation을 사용해도 좋다.
추상 클래스에는 기본적인 구현이 다 되어있기 때문에 사용자들은 본인이 필요한 로직만 작성하면 된다.
operation 한번만 실행 가능하며, 일반적으로는 OperationQueue에 추가하면 OperationQueue는 직접 thread에서 operation을 실행시키거나 dispatch GCD라고 알려진 libdispatch library를 사용해서 operation을 실행시킨다.
start() 메서드를 사용해서 operation을 직접 사용할 수 있지만 작업이 준비되지 않은 상태에서 실행 시키면 exception을 발생시키므로 추가적인 코드를 사용해야한다.(isReady 프로퍼티 사용)

Operation Dependencies (Dependencies란 말그대로 의존적, B작업을 하려면 A가 있어야해)

addDependency(:) 메서드를 사용해서 B의 작업이 끝날때 A작업을 실행해줘 라고 할 수 있다.
removeDependency(:)를 사용하면 지울수 있다.
A의 작업이 A-1, A-2, A-3 있다면 A-3이 끝나면 B는 준비상태가 된다.
A의 작업이 완료가 되면은 B가 시작될 텐데 A의 작업이 끝났다는 게 성공적으로 끝난 건지 실패로 끝났는지 모르므로 추가적인 작업을 해줘야 한다.

KVO-Compliant Properties

아래는 operation 클래스에서 KVC와 KVO를 준수하는 프로퍼티 목록이다. 상속해서 프로퍼티를 추가하는 경우에는 KVC와 KVO를 준수하면 좋다.

isCancelled - read-only: 취소 요청이 들어왔냐?
isAsynchronous - read-only: operation이 concurrently하냐?
isExecuting - read-only: operation 실행 중이냐?
isFinished - read-only: operation 성공이거나 취소되거나 끝난 상태
isReady - read-only: operation 할 꺼니?
dependencies - read-only
queuePriority - readable and writable: QOS
completionBlock - readable and writable

KVO의 알림이 어느 thread에서 실행될지 몰라 cocoa binding(view와 관련된 행위라 main thread에서만 실행되어야 하므로)은 피해야 한다. 그렇지만 cocoa binding은 UIKit에서는 지원하지 않는 것으로 알고 있다.(아니라면 알려주세요) 따라서 신경쓸 필요가 없다.
_{Important: Cocoa bindings is available to Cocoa Objective-C applications running OS X version 10.3 and later}

Multicore Considerations

thread는 stack만이 독립된 자원이기 때문에 다른 메모리에 있는 자원들을 공유할 때 안전해야 한다. operation 클래스에서는 멀티 코어까지 고려해서 안전하게 메서드를 호출할 수 있다. 그렇지만 operation 클래스를 상속받고 메서드를 재정의 하면 내가 알아서 thread-safe 하게 동기적으로 처리해야 한다.

Asynchronous VS Synchronous Operations

queue에 넣지 않고 수동으로 시작하는 경우는 기본으로는 별도의 thread를 만들지 않고 현재 thread에서 동기적으로 실행된다. 반면 비동기 작업을 하려면 별도의 thread에서 비동기 메서드로 작업을 해야 한다.

queue에 넣고 동기로 일을 처리하면 operation 하나당 하나의 thread에서 작업을 한다 따라서 상태를 추적하는 것이 쉽지만 수동으로 비동기 작업을 한다고 한다면 (하나의 operation을 multi thread로 작업을 처리할 경우) 내가 알아서 KVO를 사용해서 모니터링하고 상태의 변경사항을 보는 코드가 생겨야 한다. 상황에 맞게 해야 하지만 queue에 넣고 쓰는 걸 추천한다. 쓰게 된다면 각 operation마다 각각 thread를 만들어 순차적으로 실행되고 각각 operaion(각기 다른 thread) 들은 operation queue의 maxConcurrentOperationCount 프로퍼티에 따라 concurrent 하게 작동이 된다.

operation queue에 operation을 추가한다면 operation의 isAsynchronous의 프로퍼티값이 무엇이든지 single thread에서 작업이 된다. 즉 multi thread로 할 생각 이여도 무시된다.

Subclassing Notes

concurrently or non-concurrently 둘 중 뭘로 할건가에 따라서 달라진다.

Methods to Override

non-concurrently

일반적으로 main() 메서드만 재정의 하면된다. main() 이 메서드 안에서 작업을 실행하면 된다. 그리고 만약에 data의 setter랑 getter를 custom 하게 만든다면 thread-safe하게 만들어야한다.

concurrently

많은 메서드를 재정의 해야 한다. 아래 최소한 이건 재정의 해야 한다고 쓰여있는 목록이다.

start()
isAsynchronous
isExecuting
isFinished

start()에서 비동기 방식으로 작업을 하고 isExecuting 프로퍼티도 thread-safe 하게 설정하고 적절하게 KVO 알림을 보내야 한다.

작업 완료 또는 취소 시에 isExecuting 및 isFinished 프로퍼티의 값을 thread-safe 하게 설정하고 적절하게 KVO 알림을 보내야 한다. 취소된 경우도 isFinished를 true로 해야 한다는 것을 잊지 말자.

중요한 점
start()에서 super를 호출해야 한다. operation을 시작하기 전에 operation이 isCancelled 상태이면 중단해야 한다.

위에 내용만 override 하면 거의 되지만 dependency를 custom 하게 하려면 isReady의 KVO 알림을 적절하게 제공해야 한다. 그 뒤에는 Operation 클래스에 이미 정의된 되로 작업이 될 것이다.

Maintaining Operation Object States

내부적으로 현재 작업 상태를 외부에게 알려주는데 올바르게 알려줘야한다.

isReady

작업을 실행할 상태이면 true, 아니면 false를 반환한다.

isExecuting

operation이 진행중이라면 true 아니면 false를 반환하고 concurrently한 operation을 구현한다면 다른 프로퍼티로 교체하고 KVO 설정도 해줘야한다.

isFinished

operation이 취소되거나 완료된다면 true 그렇지 않다면 false를 반환한다. true를 반환할때 까지 operation queue는 대기하고 있고, dependency로 등록 되있는 operation도 기다리므로 start()메서드를 사용해서 concurrently 하게 작업을 하는경우 isFinished상태에 대한 적절한 KVO 알림을 해줘야 한다.

isCancelled

작업 취소 요청이 들어왔으면 ture 아니면 false를 반환한다. 언제 어디서 취소 요청이 들어올지 모르므로 긴 시간이 걸리는 작업 앞뒤에 isCancelled 프로퍼티를 자주 사용해서 취소됐다면 return 시켜 줘야 한다.

Responding to the Cancel Command

operation queue에 넣은 operation 을 취소 요청을 하려면 cancel() 메서드를 사용하면 되고cancelAllOperations()를 하면 전체 취소 요청을 할 수 있다. 말 그대로 취소 요청이지 즉시 중단된다는 것은 아니다. operation에서 이 상태 값을 보고 return을 시켜줬다면 취소가 잘 됐을 것이다. operation이 operation queue에 등록되기 전에 cancel이 된다면 기본적으로 operation은 return 시킨다. (queue에 추가되거나 start 하기 전에 isCancelled를 확인한다는 뜻이다.)

Operation Queue

operation 관리자

개요

우선순위와 준비 상태에 따라 실행되며 isFinished 상태가 true 이면 operation은 queue에 제거되고 직접 제거할 수는 없다.

중요한 점
Suspending 상태 이면 finished 상태가 아니므로 memory leak이 날 수 있다.

Determining Execution Order

operation의 의존성과, 우선순위 상태에 따라 실행되며, 우선순위가 같고 상태가 isReady == true 이면 queue에 등록된 순서대로 실행된다.

Canceling Operations

cancel() 메서드는 취소 요청을 하는 거지 바로 취소를 한 것은 아니다.
operation에서 작업을 할 때 isCancelled 메서드를 자주 확인하며 그에 따른 처리를 해야 한다.
operation queue에 등록되었지만 실행되지 않은 operation은 내부에서 start() 메서드를 호출할 때 기본 구현으로 이를 체크할 것이므로 괜찮다.

중요한 점
dependency때문에 기다리고 있는 operation을 취소하면 dependency를 무시하고 가능한 빨리 start() 메서드를 실행시켜 완료 상태로 변경해 준다.

KVO-Compliant Properties

OperationQueue 클래스는 KVC, KVO를 준수한다.

operations - read-only
operationCount - read-only
maxConcurrentOperationCount - readable and writable
isSuspended - readable and writable
name - readable and writable

Thread Safety

multi thread(operation 하나당 thread 하나)에서 사용하는 것이 객체에 대한 접근을 동기화할 수 있어서 안전하다. Dispatch framework를 사용하여 queue에 들어있는 작업들을 시작한다.

제 마음대로 사용해 보겠습니다.

class OperationViewController: UIViewController {
    
    let imageOperationQueue = ImageOperationQueue()
    
    let taskNumber = ["1", "2", "3", "4", "5", "6", "7", "8"]
    let taskString = ["a", "b", "c", "d", "e", "f", "g", "h"]
    
    let imageDataArray: [ImageData] = {
        var _imageDataArray = [ImageData]()
        for _ in 0..<10 {
            _imageDataArray.append(ImageData(state: .new, url: URL(string: "http://leehonghwa.github.io/")!))
        }
        return _imageDataArray
    }()
    
    @IBAction func didTapOperationTriggerButton(_ sender: UIButton) {
        /*
            add operation 할 때마다 thread를 만들어 준다.
            operation이 끝나면 thread를 없애준다.
         */
        
        //************************
        //***** 내 마음대로 예제 ******
        //************************
        
        /*
         closure
        operationQueue.addOperation {
            for numberString in self.taskNumber {
                print("\(Thread.current): \(numberString)")
            }
        }
        operationQueue.addOperation {
            for string in self.taskString {
                print("\(Thread.current): \(string)")
            }
        }
         */
        
        /*
        Operation subClass
        operationQueue.addOperation(CustomOperation(taskElement: taskNumber))
        operationQueue.addOperation(CustomOperation(taskElement: taskString))
         */
        
        /*
         Start
         현재 메서드를 호출하는 thread에서 실행됨
         CustomOperation(taskElement: taskNumber).start()
         */
        
        //**********************
        //***** 실용적인 예제 ******
        //***********************
        
        //다운로드
        imageDataArray.enumerated().forEach { (offset, imageData) in
            let operation = ImageOperation(imageData: imageData)
            //dependency 추가
            ResizeImageOperation().addDependency(operation)
            imageOperationQueue.downloadImage(id: offset, operation: operation)
        }
        //취소
        imageOperationQueue.cancelDownloadImage(id: 1)

        //일시정지도 가능하다
        imageOperationQueue.suspend()
        
        //시작
        imageOperationQueue.resume()
    }
}

class CustomOperation: Operation {
    let taskElement: [String]
    init(taskElement: [String]) {
        self.taskElement = taskElement
    }
    
    override func main() {
        guard !isCancelled else { return }
        task()
    }
    
    func task() {
        for element in self.taskElement {
            print("\(Thread.current): \(element)")
        }
        //cancel을 한다고 현재 진행중인 메서드가 끝나는것은 아니므로 이렇게 상태값을 확인한뒤 return 시켜줘야한다.
        guard !isCancelled else { return }
    }
}

// MARK: - Image
class ImageData {
    enum State {
        case new
        case downloading
        case downloaded
    }
    
    var state: State
    let url: URL
    var image: UIImage?
    
    init(state: State, url: URL, image: UIImage? = nil) {
        self.state = state
        self.url = url
        self.image = image
    }
}

//이런식으로도 사용할 수 있을것 같아요
class ImageOperation: Operation {
    let imageData: ImageData
    
    init(imageData: ImageData) {
        self.imageData = imageData
    }
    
    override func main() {
        if imageData.state == .new {
            //시작하기전 검사
            guard !isCancelled else { return }
            imageData.state = .downloading
            imageData.image = ImageService.downloadImage(url: imageData.url)
            //오래걸리는 작업 후 검사
            guard !isCancelled else { return }
            imageData.state = .downloaded
        }
    }
}

class ImageOperationQueue {
    private var currentOperation = [Int: ImageOperation]()
    
    let operationQueue: OperationQueue = {
        var queue = OperationQueue()
        queue.name = "operation-queue"
        //한번에 몇개 실행할건가?
        queue.maxConcurrentOperationCount = 1
        return queue
    }()
    
    func cancelDownloadImage(id: Int) {
        guard let operation = currentOperation[id], operation.imageData.state != .downloaded else { return }
        currentOperation.removeValue(forKey: id)
        operation.cancel()
    }
    
    func downloadImage(id: Int, operation: ImageOperation) {
        if currentOperation[id] == nil {
            currentOperation[id] = operation
        }
        operation.completionBlock = { [weak self] in
            self?.currentOperation.removeValue(forKey: id)
        }
        operationQueue.addOperation(operation)
    }

    func suspend() {
        operationQueue.isSuspended = true
    }
    
    func resume() {
        operationQueue.isSuspended = false
    }
}

느낀점

취소가 쉽다.
의존성이 있는 작업을 할 때 좋을것 같다.
KVO를 제공해 상태를 알기 쉽다.
suspend하기 좋다.
operation을 상속하고 그안에서 작업을 하기 때문에 캡슐화 하기좋다.
thread-safe 하다.

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

Thread Management(1-1)

2018-04-29T23:50:00+00:00

왜 나는 GCD를 썼을까?(Thread)

iOS에서 Thread 관리하기 1-1 (NSThread)

비동기 작업을 해야지 하면 습관적으로

DispatchQueue.global().async {
    //내용
}

이런식으로 사용을 했었는데 다른 방식으로도 비동기 작업을 할 수 있는데 왜 이걸 사용했을까? 라고 물어보면 대답할 수 없었습니다. 이유도 모르고 쓴다는게 부끄러워서 이렇게 정리를 해보기로 했습니다.

우선 공부를 Apple 공식 문서 API(NSThread(Thread), NSOperation(Operation), Dispatch)를 읽고
Concurrency Programming Guide 를 읽고
Thread 관리의 장단점을 비교한 블로그를 보고 이해 하는 순으로 글을 작성하겠습니다.

이번 블로그는 NSThread(Thread)의 문서를 보도록 하겠습니다.

Thread

thread 실행

개요

Objective-C 메서드를 다른 thread에서 실행하려는 경우 이 클래스를 사용해라. thread는 파일 읽어오기, 통신 등 비교적 느린 작업과 빠르게 처리해야 하는 작업을 동시에 처리하게 만들어 준다. 예를 들어 오래 걸리는 작업을 UI를 처리하는 main thread에서 실행시키지 않고 다른 thread에서 처리하게 만들어 UI가 굳지 않게 만들 수 있다. 그리고 큰 작업을 작은 작업 단위로 나눠서 멀티 코어의 이점을 잘 이용할 수 있다.

thread 클래스는 thread의 런타임 조건을 감시하는 기능을 가진 operation class와 비슷한 기능을 지원한다. operation과 비슷한 기능을 사용하여 thread의 실행을 취소하거나 thread가 아직 실행 중이거나 해당 작업을 완료했는지 확인할 수 있다. thread를 취소하려면 cancel 메서드를 사용해라.

_{상속받을 때 주의할 점

thread를 상속받을 때 main 메서드를 재정의 하면 진입점(entry point)을 지정할 수 있으며 재정의하는 main 메서드에서 부모의 메서드를 호출하지 않아도 된다.(super.main())}

Start

thread를 시작합니다.

개요

비동기 적으로 thread를 생성하고 thread의 main() 메서드를 호출한다. isExecuting 프로퍼티는 thread가 실행을 시작하면 true를 반환한다.

만약에 target과 selector를 가지고 thread의 instance를 초기화한 경우에 기본 main() 메서드는 selector를 자동으로 호출한다.

thread가 처음으로 application에 분리된 thread라면 이 메서드는 NSWillBecomeMultiThreaded 이름으로 notification center에 post 한다.

Exit

현재의 thread를 종료한다.

개요

current라는 클래스 메서드를 사용해 현재 thread에 접근한다. thread를 종료하기 전에NSThreadWillExit 이름으로 notification center에 post 한다. notification은 동기적으로 전달되므로 NSThreadWillExit의 모든 관찰자는 thread가 종료되기 전에 notification을 수신할 수 있다.

이 메서드를 호출하면 실행 중에 할당된 모든 리소스를 thread가 정리할 기회가 없으므로 이 메서드를 호출하면 안 된다.

Cancel

thread의 상태를 변경해서 종료되야 한다고 나타낸다.

Operation에 사용된 것과 동일한 의미를 가진다. thread의 상태를 변경하고 isCancelled 프로퍼티에 반영한다. 취소를 지원하는 thread는 주기적으로 isCancelled 메서드를 호출하여 thread가 실제로 취소되었는지 판별하고 종료된 경우 종료해야 한다.

이어서 사용법을 보겠습니다.(제가 궁금해서….)

class ViewController: UIViewController {

    var nsLimitCount: Int = 0
    var detachLimitCount: Int = 0
    
    lazy var nsThread: Thread = {
        let thread = Thread(target: self, selector: #selector(task), object: nil)
        thread.name = "com.apple.ns-thread"//queue 이름이 아니라 thread의 이름이다.
        return thread
    }()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        NotificationCenter.default.addObserver(self, selector: #selector(exit), name: .NSThreadWillExit, object: nil)
    }
    
    @objc func task() {
        if Thread.current == nsThread {
            print("Init NSThread Task")
            
            nsLimitCount += 1
            if nsLimitCount == 3 {
                Thread.exit()
                /*
                 현재 실행중인 스레드 즉각 취소
                 아 궁금해서 현재 스레드가 main thread 일 때 취소하면 취소될까 하고 해봤는데 취소가 됩니다. 재미있네요
                 참고로 문서에는 이 메서드를 사용하지 말라고하네요. 그 문서 번역본도 올려놨습니다.
                 */

                nsThread.cancel()
                /*
                 취소 상태로 변경해 준다.
                 nsThread.isCancelled로 상태를 보고 종료되기전에 처리해야하는 것들을 정리하고 현재 메서드를 종료 시켜줘서 exit를 시켜줘야한다. 아니면 계속 해서 task()를 호출하게 될것이다.
                 */
            }
            
            task()// -> guard !nsThread.isCancelled else { return }
            
        } else {
            print("Detach New Thread Task")
            detachLimitCount += 1
            if detachLimitCount < 3 {
                task()
            }
        }
    }
    
    @objc func exit() {
        //thread가 사라지기전에 사라질 thread에서 호출
        if Thread.current == nsThread {
            print("Init NSThread Exit")
        } else {
            print("Detach New Thread Exit")
        }
    }
    
    @IBAction func didTapNSThreadTriggerButton(_ sender: UIButton) {
        sender.isSelected = !sender.isSelected
        Thread.detachNewThreadSelector(#selector(task), toTarget: self, with: nil)
        if sender.isSelected {
            if !nsThread.isCancelled {
                nsThread.start()
            }
        } else {
            nsThread.cancel()
        }
    }
}

느낀점

해당 selector의 메서드가 끝나면 thread가 종료가 된다는게(다시 만들어야 한다는게) 오버헤드가 클 것 같다.
취소가 쉽다.
serial, concurrent queue 같이 해당 thread가 어떻게 처리할지 설정할 수 있는지 모르겠다.
task를 sync인지 async인지 설정할 수 있는지 모르겠다.
그냥 비동기를 해보고싶다 하면 할 수 있을것 같지만 안하는게 좋을것 같다. 맨 마지막에 비교하는 블로그를 쓸 때 찾아보고 자세히 쓰겠습니다.

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

Responder Chain

2018-04-27T17:00:00+00:00

항상 사용하는 터치 어떻게 처리될까?

어느 날 "Touch는 어떻게 일어나는지 아시나요?” 라는 질문을 받았을 때 머리가 띵한 느낌이 났다. 가장 많이 쓰면서 알지도 못하고 썼구나 하는 자기반성을 하게 되며 이 공부를 하게 되었다. 질문해주신 분 정말 감사합니다!

애플 문서에 나와있겠지 하고 검색해보니 아니나 다를까 https://developer.apple.com/documentation/uikit/touches_presses_and_gestures/understanding_event_handling_responders_and_the_responder_chain 이렇게 잘 나와있었다.

위의 링크 내용을 참고하여 이해한 대로 설명하겠다.

Understanding Event Handling, Responders, and the Responder Chain

이벤트는 UIResponder 클래스의 객체가 받고. 이를 상속받는 클래스는 UIView, UIViewController, UIApplication이다.
responder 객체의 역할은 raw 한 이벤트를 전달받으면 이 이벤트를 처리하거나 다른 responder 객체에게 보낸다.
앱에 이벤트가 들어왔을 경우에 UIKit은 first reponder 객체에게 이벤트를 전달하고 이 객체가 이벤트를 처리하지 않는다면 위에서 말했듯이 다른 responder 객체에게 이 이벤트를 전달한다.
UIKit은 기본적으로 어떻게 이벤트를 responder에게 전달하는지에 대한 규칙이 있지만 이 규칙은 사용자에 따라서 바뀔 수 있다.

아래 사진을 보면 기본적인 responder chain을 볼 수 있다.
구조는 UILabel, UITextField, UIButton 밑에 UIView가 2개 있는 앱이다.
이 구조에서 이벤트가 들어왔을 때 아무도 이벤트를 처리하지 않는다면 이벤트가 어떻게 이동하는지 설명하겠다.

사용자가 textField에 이벤트를 일으키면
textField에서 부모 View에게 이벤트를 전달하고 
이어서 또 부모 view에게 보낸다. 
자신의 부모 view가 없다면즉 해당 view가 root view라면 바로 window에 전달하는 것이 아니라 자신의 view controller에게 이벤트를 전달한다 
그리고 view controller는 window에게 보내고 
UIApplication 객체에게 보내고 
UIApplicationDelegate에게 전달한다.

위에서 언급한 first reponder를 판단할때 아래 기준으로 판단한다.

First Responder

Touch events
touch가 일어난 주체가 first responder이다.

Press events (게임기와 연동)
focus되어 있는 주체가 first responder이다.

Shake-motion events (말 그대로 흔들기)
사용자 또는 UIKit에서 기본으로 설정한 객체가 first responder이다.

Remote-control events (미디어 볼륨, 다음곡 재생 등등)
사용자 또는 UIKit에서 기본으로 설정한 객체가 first responder이다.

Editing menu messages (텍스트 복사, 붙여쓰기 등등)
사용자 또는 UIKit에서 기본으로 설정한 객체가 first responder이다.

_{주의

accelerometers, gyroscopes, magnetometer같은 motion 이벤트는 위의 responder chain을 따르지 않는다. 대신 Core Motion은 사용자가 지정한 객체에게 전달된다. 자세한것은 Core Motion Framework을 보면 된다.}

Control 처리

UIControl을 상속받은 객체에 이벤트가 발생하면 
그 객체의 addTarget:action:controlEvents메서드에 설정된 target에게 action message를 보낸다. 
action message는 event는 아니지만 responder chain을 활용할 수 있다. 만약 target이 nil이라면 위에서 설명한 responder chain순서대로 해당 이벤트에 대한 메서드를 구현한 객체를 찾는다. Editing menu messages를 예로 들자면 cut(_:), copy(_:), paste(_:) 를 구현한 responder 객체를 찾는다.
gesture recognizer를 추가한 view가 있다면 gesture recognizer가 우선으로 event를 받는다 하지만 제대로 event를 처리하지 않는다면 
다음 view에게 넘어가고 또 적절한 처리가 없다면 responder chain 대로 흘러간다.

_{주의

터치 위치가 뷰의 범위 밖에있는 경우 hitTest (_ : with :) 메소드는 해당 뷰와 모든 하위 뷰를 검색하지 않는다. 예를들면 clipsToBounds 속성이 false 인 경우이고 view의 크기보다 큰 하위 view가 있어도 하위 view는 터치를 받지 못한다.

UiKit은 Touch가 처음 일어날때 해당 객체에 UITouch 객체를 만들며 touch가 끝나면 해제된다. touch 영역이 변경되거나 속성이 변경된다면 UIKit은 UITouch 객체를 업데이트 시켜준다.}

Responder Chain 변경

Responder Chain의 next 속성을 재정의 함으로서 기본 responder chain을 변경할 수 있다. next 속성에 다음 responder가 됬으면 하는 객체를 반환해주면 된다.

많은 UIKit 클래스가 이미 이 속성을 재정의 하고 특정 객체를 반환하고 있다.
5가지의 예를 들자면
기본은 다음 responder는 super view이지만 responder view가 view controller의 root view이면 next 속성의 반환값은 view controller 이다.
responder chain이 window의 root view controller까지 왔다면 next 속성은 window 이다.
presented 된 view controller라면 next 속성은 presenting view controller 이다.
UIWindow 객체의 next 속성은 UIApplication 객체 이다.
UIApplication 객체의 next 속성은 app delegate이다.(단 UIResponder의 클래스를 상속받은 객체이면서 view. view controller, app객체가 아니어야 한다.)

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

Overview - Themes

2017-10-03T05:30:00+00:00

Themes

제 생각이 많이 들어간 번역이니 정확한 원문을 읽으시려면 https://developer.apple.com/ios/human-interface-guidelines/를 참고해주세요.

iOS Design Themes

앱 디자이너는 앱을 잘 디자인하면(앱의 품질과 기능이 우수) 앱 스토어 차트 상단에 앱이 올라가 있을 것이다.(~~당연한 말씀~~)

iOS에서 중시하는 3가지(아래에 다른? 플랫폼과 iOS의 차이 점이 3가지 있다. ~~Google Material Design에도 중시하던데…~~)

직관적(Clarity:)
글씨: 모든 디바이스와 상태(가로, 세로, 확대 등)에 따라 글씨는 잘 읽혀야 한다.
아이콘: 딱 봐도 뭔지 알아야 한다.
장식요소(선, 애니메이션 등등): 해당 기능 및 내용을 설명하는 요소로 적절하게 사용해야 한다. 예를 들어 버튼을 누르면 눌린 상태를 사용자에게 알려준다(UIControlStateHighlighted) 여백, 색상, 글꼴, 그래픽 및 인터페이스 요소는 일관되어야 한다. (책도 보면 제목 부제목 소제목, 본문 구분하는 것처럼 이렇게 하면 사용자는 그 글씨 크기만 봐도 이게 제목이구나를 학습한다.)
콘텐츠 중시(Deference):
좋은 모션과 인터페이스는 콘텐츠를 이해하기 쉽게 도와준다. 일반적으로 콘텐츠(내용)는 전체 화면을 채워서 전달하지만 반투명과 흐린 배경을 가진 콘텐츠(내용)는 콘텐츠(내용)가 전체 화면을 채우지 않아도 배경 자체가 더 많은 것을 사용자에게 전달한다.(예를 들어 불투명한 배경은 사용자가 어떠한 화면 위에 뷰가 떠있는지 알게 된다.) 베젤, 그래디언트 및 그림자의 사용을 최소화하여 인터페이스를 밝게 유지하면서 콘텐츠를 잘 보이게 하는 것이 중요하다.
뷰들간의 계층(Depth):
각각의 레이어와 사실적인 모션은 계층과 내용에 대한 이해를 돕는다. 화면 전환(push, present)은 추가적인 콘텐츠를 보여주기에 적합하고 전환된 화면 되돌리기(pop, dismiss)는 이전 콘텐츠로 되돌리기에 적합하다. 또한 전환 액션은 현재 자신이 보고 있는 문맥이 어느 위치인지 가늠할 수 있게 도와준다.

Design Principles

앱의 정체성을 생각할 때 아래의 정체성 6가지를 살펴봐야 한다.

미적:
앱의 모양과 동작이 기능과 잘 결합되어야 한다. 예를 들어, 중요한 작업을 하는 앱은 중요한 작업에 집중할수 있도록 디자인과, 동작, 기능을 디자인(차분하게 디자인) 해야하고 게임은 게임에 어울리는 디자인, 동작, 기능을 디자인(화려하게 디자인) 해야한다.
일관성:
시스템에서 제공되는 익숙한 인터페이스 및 요소, 잘 알려진 아이콘, 포준 텍스트 스타일 및 통일된 용어 사용은 사용자가 따로 학습하지 않아도 된다.(~~개인적으로 drawer menu || hamburger menu는 사용하지 않았으면 좋겠다.~~)
직접 조작(사용자의 행동에 따른 결과):
화면상의 콘텐츠를 직접 조작하는 행위로 콘텐츠에 대한 이해를 도울 수 있고 보다 많은 사용자를 확보할 수 있다. 직접 조작은 장치를 회전하거나 제스처(탭, 스와이프, 핀치 등등)를 사용하여 화면 콘텐츠에 영향을 줄 수 있는 행위를 말한다. 사용자는 직접 조작을 통해 즉각적으로 눈에 보이는 결과를 볼 수 있다.
피드백:
사용자의 행동에 따른 결과를 보여주는 것이 피드백이다. iOS는 모든 사용자의 행동에 대한 응답으로 피드백을 줄 수 있게 만들어져 있다. 피드백의 예로는 버튼을 누르고 있을 때 누르고 있다는 피드백(버튼의 하이라이트 티드 색상), progress indicators(진행 상태를 알려주는 요소) 같은 진행 상태에 대한 피드백, 애니메이션 및 사운드 피드백 등등 있다.
은유(실생활에 쓰이는 환경을 앱에 도입):
앱의 가상 환경이 실생활의 환경 또는 iOS의 기본 앱과 익숙한 환경을 따르면 사용자는 보다 빨리 학습할 수 있게 된다. 실생활 환경 예) 물리적인 화면(핸드폰 화면)을 벗어나는 가상화면(스크롤 콘텐츠)는 스크롤 또는 스와이프(책을 보는 행동과 유사)를 통해 벗어나는 영역을 볼 수 있다. 기본 앱과 비슷한 환경 예) 스위치 토글, 슬라이더 이동, 피커 값을 통한 값 설정(날짜 선택할 때 밑에 드럼통 모양으로 뜨는 것)
사용자 컨트롤:
iOS에서 앱이 아닌 사람이 앱을 제어할 수 있다. 앱은 행동 경로를 제안하거나 위험한 결과에 대해 경고할 수 있지만 일반적으로 앱이 의사 결정을 맡는 것은 잘못된 선택이다. 가장 좋은 앱은 사용자가 의사 결정을 하는 앱이다(광고를 꼭 봐야만 하는 앱은 앱이 내 의사결정과 관계없이 행동을 결정하기 때문에 나쁜 앱이다). 앱을 친숙하고 예측 가능한 행동을 하게 만들고, 삭제 같은 부정적인 작업에는 별도의 확인을 하며 작업이 이미 진행 중이더라도 취소하기 쉽게 만들어 사람들이 앱을 통제하고 있다는 느낌을 들게 해줘야 한다.

참고: https://developer.apple.com/ios/human-interface-guidelines/overview/themes/

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

tableView(_:commit:forRowAt:)

2017-08-15T03:55:00+00:00

데이터 소스에게 수신자의 지정된 행을 삽입하거나 삭제하도록 요청한다.

파라미터

tableview: 삽입, 삭제를 요청하는 테이블 뷰 객체.
editingStyle: indexPath에 명시된 특정 행에 요청된 삽입 또는 삭제에 관한 셀 편집 스타일. 사용 가능한 삽입 또는 삭제에 관한 편집 스타일.
indexPath: 테이블 뷰의 행을 나타내는 index path.

개요

사용자가 테이블 뷰에서 UITableViewCell 객체와 연결된 삽입(초록색 더하기) 컨트롤 또는 삭제 버튼을 누르면 테이블 뷰는 이 메시지를 data source에게 보내 변경 내용을 반영하도록 요청한다. 사용자가 삭제(빨간색 빼기) 컨트롤을 탭 하면 테이블 뷰에 삭제 버튼이 표시되어 사용자에게 삭제에 대한 정보를 보여준다. data source는 UITableView의 insertRows(at:with:) 또는 deleteRows(at:with:) 메서드를 호출하여 삽입 또는 삭제를 반영한다.

테이블 뷰의 스와이프 삭제 기능(사용자가 삭제 버튼을 보기 위해 가로로 스와이프 하는 기능)을 사용하기 위해서 이 메서드를 구현해야 한다.

이 메서드의 구현 내에서 setEditing(:animated:)을 호출하면 안 된다. 만약에 반드시 setEditing(:animated:)을 사용해야 한다면 perform(_:with:afterDelay:) 메서드를 사용하여 이 메서드를 지연된 후에 호출해라.

참고: https://developer.apple.com/documentation/uikit/uitableviewdatasource/1614871-tableview

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

resignFirstResponder

2017-08-11T14:55:00+00:00

윈도우의 first responder status를 해제하도록 수신자 객체에게 알린다.

개요

기본 구현은 first responder status를 해제하고 YES를 반환한다. custom responders에서 이 메서드를 override 하여 객체 상태를 업데이트하거나 선택 영역에서 highlight 표시를 제거하는 등의 다른 작업을 수행할 수 있다. first responder status를 해제하지 않으려면 NO를 반환할 수도 있다. 이 메서드를 override 하는 경우 코드의 특정 지점에서 super(슈퍼 클래스 구현)를 호출해야 한다.

참고: https://developer.apple.com/documentation/uikit/uiresponder/1621097-resignfirstresponder?language=objc

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}

endEditing:

2017-08-10T14:30:00+00:00

뷰(또는 뷰에 텍스트 필드가 포함된 뷰)의 first responder status를 해제한다.

파라미터

force: 강제로 first responder status를 해제하려면 YES 설정해라.

반환 값

뷰의 first responder status가 해제됐다면 YES 그렇지 않다면 NO.

개요

이 메서드는 현재 뷰와 하위 뷰의 계층에서 first responder인 텍스트 필드를 찾는다. 만약에 메서드가 그 텍스트 필드를 찾았다면 텍스트 필드의 first responder를 해제할 것을 요청하고 만약에 이 메서드의 파라미터를 YES로 설정한다면 텍스트 필드에게 first responder를 해제할 것을 요청하지 않고 강제로 해제한다.

참고: https://developer.apple.com/documentation/uikit/uiview/1619630-endediting?language=objc

_{잘못된 부분이 있다면 알려주시면 바로 수정하겠습니다.}