여러분의 관심사와 흥미를 빅 데이터로 분석하여... 여러분의 관심사와 흥미를 빅 데이터로 분석하여...

이제 동시(concurrent) 프로그래밍(programming)이 익술할 것이다. 하지만 앱이 올바르게 실행되는 것처럼 보인다고 해서, 다양한 동시성(concurrency)과 스레딩(threading) 관련 사례를 처리한 것은 아니다. 이 장(chapter)에서는 Xcode에 내장(built-in)된 Thread Sanitizer를 사용하여, App Store에 배포하기 전에 경합 상태(races)를 발견하는 방법을 자세히 알아본다. Why the sanitizer? 5장(chapter), "Concurrency Problems"에서 논의한 것처럼, 데이터 경합(races)을 피하기 위해 변수(variable)에 대한 모든 접근(accesses)을 동일한 스레드(thread)에서 유지하는 것이 얼마나 ..

개발하게 될 iOS 앱 중 대다수는 데이터 저장(storage)에 Core Data를 사용할 가능성이 높다. 최신 버전의 iOS에서는 동시성(concurrency)과 Core Data를 혼합하는 것이 더 이상 복잡하지 않지만, 여전히 알고 있어야할 몇 가지 주요 개념(concepts)이 있다. 대부분의 UIKit과 마찬가지로 Core Data도 스레드로부터 안전하지 않다(not thread safe). 이 장(chapter)에서는 검색(searching), 엔터티(entities) 생성(creating) 등과 같은 기본(basic) Core Data 개념(concepts)을 이미 알고 있다고 가정한다. Core Data를 처음 접하는 경우 https://bit.ly/2VkUKNb 에서 Core Data ..

operation이 제대로(properly) 작성되었다면, 이를 실행(running) 중에 취소(canceling)할 수도 있다. 이는 시간이 지남에 따라 관련성이 없어질(irrelevant) 수 있는 긴 operations에 매우 유용하다. 예를 들어, 사용자(user)는 화면을 벗어나거나 테이블 뷰(table view)에서 셀(cell)을 스크롤(scroll)할 수 있다. 사용자가 결과를 볼 수 없는데, 데이터를 계속 로드(load)하거나 복잡한(complex) 계산(calculations)을 하는 것은 의미가 없다. The magic of cancel operation queue로 operation을 예약(schedule)하면, 더 이상 제어(control)할 수 없다. 대기열(queue)은 그때부..

이 장(chapter)에서는 operations간의 의존성(dependencies)에 대해 설명한다. 한 operation을 다른 operation에 의존(dependent)시키면, operations간 상호 작용(interactions)에 대한 두 가지 이점을 제공한다: 전제 조건(prerequisite) operation이 완료(completed)되기 전에, 종속(dependent) operation이 시작되지 않도록 한다. 첫 번째 operation에서 두 ​​번째 operation으로 데이터를 자동으로 전달할 수 있는 깔끔한 방법을 제공한다. operations간의 의존성(dependencies)을 활성화(enabling)하는 것이 GCD대신 Operation을 사용하는 주된 이유 중 하나이다. ..

지금까지는 operations은 동기화(synchronous)되어 Operation 클래스(class)의 상태(state) 시스템(machine)과 매우 잘 작동했다. operation이 isReady 상태(state)로 전환되면, 시스템(system)은 사용 가능한 스레드(thread)를 검색할 수 있다. 스케줄러(scheduler)가 operation을 실행(run)할 스레드(thread)를 찾으면, operation은 isExecuting 상태(state)로 전환(transition)된다. 이 시점에서 코드가 실행(executes)되어 완료(completes)되고 상태(state)는 isFinished가 된다. 그러나 비동기(asynchronous) operation에서는 조금 다르게 작동한다. o..

Operations의 진정한 힘은 OperationQueue에서 작업을 처리할 때 나타난다. GCD의 DispatchQueue와 마찬가지로 OperationQueue 클래스(class)는 Operation의 작업 예약(manage the scheduling)과 동시에 실행할 수 있는 최대 operations 수를 관리하기 위해 사용하는 클래스(class)이다. OperationQueue를 사용하면 다음 세 가지 방법으로 작업을 추가 할 수 있다: Pass an Operation. Pass a closure. Pass an array of Operations. 이전 장(chapter)에서 프로젝트(project)를 구현하면서 operation 자체는 동기(synchronous) 작업이라는 것을 알게 되었다..

어떤 면에서 operations은 GCD와 매우 유사하며, 동시성(concurrency)을 처음 사용하면 그 차이점에 대해 혼란스러울(confusing) 수도 있다. GCD와 operations 모두 별도(separate)의 스레드(thread)에서 실행되어야 하는 코드 덩어리(chunk)를 제출(submit)할 수 있다. 그러나 operations은 제출(submitted)된 작업을 보다 효과적으로 제어할 수 있다. 이 책의 시작 부분에서 언급했듯이, operations은 GCD를 기반으로 구축(built on)된다. 다른 operations 에 대한 종속성(dependencies on other operations), 실행중인 작업 취소(cancel the running operation), 보다 복..

dispatch queues는 많은 이점(benefits)이 있지만, 불행하게도 모든 성능(performance) 문제에 대한 만병 통치약(panacea)은 아니다. 앱에서 동시성(concurrency)을 구현할 때, 주의하지 않으면 발생할 수 있는 잘 알려진 세 가지 문제가 있다: 경쟁 상태(Race conditions) 교착 상태(Deadlock) 우선 순위 역전(Priority inversion) Race conditions 앱 자체를 포함하여 동일한 프로세스(process)를 공유하는 스레드(threads)는 동일한 주소(address) 공간(space)을 공유(share)한다. 이것은 각 스레드(thread)가 동일한 공유 리소스를 읽고(read) 쓰려(write)고 한다는 것을 의미한다. 조심..

때로는 작업을 단순히 대기열(queue)에 넣는 대신, 작업의 그룹(group)을 처리해야 하는 경우가 있다. 모두 동시에(same time) 실행할 필요는 없지만, 모든 작업이 완료(completed)된 시점은 알아야 한다. Apple은 이런 경우를 위해 Dispatch Groups을 제공한다. DispatchGroup DispatchGroup는 작업 그룹(group)의 완료(completion)를 추적(track)할 때 사용하는 클래스(class)이다. 먼저 DispatchGroup을 초기화(initializing)한다. 작업을 해당 그룹(group)의 일부로 추적하려는 경우, dispatch queue의 비동기(async) 메서드(method)의 인수로 그룹(group)을 제공할 수 있다: let ..

이 장(chapter)에서는 Dispatch queues와 스레드(threads)가 무엇이며, 개발 작업 흐름(development workflow)에 이를 가장 잘 통합하는 방법에 대해 더 자세히 알아본다. Threads 다중 스레딩(multithreading)이라는 용어(term)를 들어봤을 것이다. 스레드(thread)는 실제로 실행 스레드(thread of execution)의 줄임말며, 실행 중인 프로세스(process)가 시스템의 여러 리소스(resources)에서 작업을 분할하는 방식이다. iOS 앱은 다중 스레드(multiple threads)를 활용하여 여러 작업을 실행하는 프로세스(process)이다. 기기(device)의 CPU에 있는 코어(cores) 수 만큼의 스레드(threads..