현재 진행 중인 프로젝트에서는 Clean-Swift 를 이용해 화면 단위를 개발하고 있는데요,
Clean-Swift(VIP Pattern) 컴포넌트에 대한 단위 테스트를 작성하기 위해 어떤 부분을 고민했는지 공유해보려고 합니다.

Clean-Swift 에서는 Scene에 대한 단위 테스트를 작성할 때 크게 3가지의 단위 테스트를 통해 구현을 검증하도록 가이드합니다.

1. ViewController => Interactor 호출 테스트
2. Interactor => Presenter 호출 테스트
3. Presenter => ViewController 호출 테스트

다시 말해 Clean-Swift에서는 Spy객체(모의 객체)의 특정 메서드가 호출되었는지 여부를 검사하는 것을 통해 구현을 검증하도록 가이드합니다.

1) 화면 단위를 Scene으로 표현하였습니다.

제가 생각하는 기존 단위 테스트의 문제점은, 테스트 내부에서 인터페이스를 호출했는지, 어떻게 사용하는지 하나하나를 다 검증하기 때문에 구현 내용 혹은 인터페이스가 바뀌게 될 경우 테스트가 쉽게 깨질 수 있다는 점입니다.

또한 Scene에 대한 단위 테스트를 작성하기 위해 최소 3개의 Spy객체(모의 객체)를 생성하고 관리해야 한다는 점 또한 테스트를 작성하는데 부담이 되는 지점이라 생각하였습니다.

이러한 문제점을 해결하기 위해 무엇을 테스트해야 효율적이고, 견고한 테스트를 작성할 수 있을지에 대한 고민이 들기 시작했는데요,

모의 객체의 특정 메소드를 호출했는지를 검증하는 것보다, 실제 실행 후 최종 상태에 대해 검증해야겠다는 생각을 하기 시작했습니다.

Black box test

마치 블랙박스 테스트처럼 내부 구현보다는 외부에서 보이는 결과를 중심으로 테스트하는 방향으로 말이죠.

이렇게 하면 인터페이스 변경에 따른 테스트 유지보수 비용을 줄이고, 테스트가 쉽게 깨지지 않고 더 견고하게 유지될 수 있을 것이라 기대했습니다.

그렇다면, VIP Cycle에 대한 Output은 무엇일까요?

제가 생각한 VIP Cycle에 대한 output은 'view'라고 판단하였습니다.
view에서 시작된 데이터가 요청, 가공을 거쳐 view에 '결과'로써 다시 표시되기 때문입니다.

따라서 VIP Cycle이 의도한 대로 올바르게 흘러가는지 검증하기 위해서는 display logic을 검증하면 되겠다고 판단하였습니다.

그렇다면, display logic을 검증할 수 있는 환경은 어떻게 만들 수 있을까요?

제가 생각한 방법은 VIP 사이클은 그대로 진행되도록 두면서,

Presenter의 display logic을 스텁으로 대체하여 그 스텁된 객체의 흐름을 검증하는 것입니다.

마치 아래의 그림처럼 말이죠

사실, 이 그림이 오늘 얘기하고 싶은 것의 전부입니다.

그럼 사례를 통해 흐름을 보도록 하겠습니다.

extension ShareGardenSceneInteractor: ShareGardenSceneBusinessLogic {
  func requestMyGarden() {
    self.tasks[TaskKey.requestMyGarden] = Task {
    defer { self.tasks[TaskKey.requestMyGarden] = nil }
    
      do {
        try Task.checkCancellation()
        let myGarden = try await self.shareGardenSceneWorker.requestMyGarden()
        try Task.checkCancellation()
        let response = ShareGardenScene.RequestMyGarden.Response(myGarden: myGarden)
        self.presenter?.presentMyGarden(response: response)
      } catch {
        // present error
      }
    }
  }

interactor에 이러한 메서드가 있다고 가정했을 때

presenter는 interactor의 호출에 따라

  extension ShareGardenScenePresenter: ShareGardenScenePresentationLogic {
    func presentMyGarden(response: ShareGardenScene.RequestMyGarden.Response) {
     /* make view model */
      
      self.viewController?.displayMyGarden(viewModel)
    }
    
    func presentMyGardenRequestError() {
      self.viewController?.displayMyGardenRequestError()
    }
     /* present another error */
  }

view에 결과를 전달하게 될 것입니다.

이러한 구조를 이용하기 위해 앞서 살펴봤던 것처럼 display logic을 스텁하였습니다.

@MainActor
final class ShareGardenSceneViewControllerStub {
  
  weak var viewController: ShareGardenSceneDisplayLogic?
  
  let (myGardenStream, myGardenStreamContinuation) = AsyncStream.makeStream(
    of: ShareGardenScene.RequestMyGarden.ViewModel.self,
    bufferingPolicy: AsyncStream.Continuation.BufferingPolicy.bufferingNewest(1)
  )
  
  let (myGardenRequestErrorStream, myGardenRequestErrorStreamContinuation) = AsyncStream.makeStream(
    of: Void.self,
    bufferingPolicy: AsyncStream.Continuation.BufferingPolicy.bufferingNewest(1)
  )
}

extension ShareGardenSceneViewControllerStub: ShareGardenSceneDisplayLogic {
  func displayMyGarden(_ viewModel: ShareGardenScene.RequestMyGarden.ViewModel) {
    self.myGardenStreamContinuation.yield(viewModel)
    self.viewController?.displayMyGarden(viewModel)
  }
  /* display another error */
}

AsyncStream을 이용한 이유는 Swift Concurrency를 이용해 output이 준비되기까지 테스트의 흐름을 suspension point에서 중단시켜 놓기 위함입니다.

AsyncStream.Continuation의 yield(_:) 를 통해 suspend 된 작업을 재개하여suspend point에 값을 반환하도록 하고, 해당 값을 검증하도록 하였습니다.

import Testing
import AsyncAlgorithms

extension ShareGardenSceneTests {
  @Test(arguments: [true, false])
  private func myGardenRequest(isSuccessful: Bool) async {
    // Given
    / ... /
    
    // When
    self.loadView()
    
    // Then
    enum RequestMyGardenResult {
      case success(ShareGardenScene.RequestMyGarden.ViewModel)
      case error
    }
    
    let mergedStream = merge(
      self.sut.myGardenStream.map { RequestMyGardenResult.success($0) },
      self.sut.myGardenRequestErrorStream.map {
        _ in RequestMyGardenResult.error
      }
    )
    
    for await result in mergedStream {
      switch result {
      case .success(let viewModel):
        #expect(viewModel.nickname == expectedMyGarden.nickname)
        #expect(viewModel.description == expectedMyGarden.description)
        #expect(viewModel.pomodoroRecords == expectedMyGarden.pomodoroRecords)
      case .error:
        #expect(true)
      }
      
      self.sut.myGardenRequestErrorStreamContinuation.finish()
      self.sut.myGardenStreamContinuation.finish()
      return
    }
  }

parameterized test를 사용하기 위해 Swift Testing을 사용하였습니다.
이를 통해 성공, 실패 시나리오에 대한 테스트를 쉽게 진행할 수 있었습니다.

위와 비슷한 흐름으로 다른 테스트 케이스를 작성해 시나리오에 따른 VIP Cycle을 검증하였습니다.

AsyncStream Continuation의 결과가 선후 관계를 갖는 경우에는 structured concurrency를 이용해 테스트를 진행해 주었습니다.

이를 통해 VIP Cycle의 내부 구현 검증을 피하고, 실제 실행 후 최종 상태에 대해 검증함으로써 테스트가 쉽게 깨지지 않도록 하였습니다.

🧪 테스트 결과

사용자가 입력하고 보게 되는 최종 상태에 대해 검증을 하게 됨으로써 기획 단계에서 백로그에 작성한 시나리오에 대한 행위 기반 테스트를 한 눈에 확인할 수 있게 되었습니다🎉

이와 더불어 VIP Cycle 테스트의 결과로 VIP 컴포넌트의 핵심 객체인 View, Interactor, Presenter의 테스트 커버리지는 평균 94.8%를 가질 수 있게 되었습니다.

VIP Cycle을 테스트 함으로써 VIP Cycle과 별개로 별도의 로직 테스트가 필요한 부분은 개별적으로 테스트를 작성해 로직의 정확성을 확보해 나가는 방향으로 테스트를 진행하였습니다.

모든 기능을 개발한 뒤에 VIP Cycle을 통해 시나리오에 맞게 테스트가 진행되는 걸 보니 조금 더 자신 있게 새로운 기능을 개발할 수 있게 된 것 같습니다 :)

Clean-Swift를 사용하며, 어느 부분을 테스트해야 하는지 고민한 경험을 작성해 보았는데요,

아직은 현재의 테스트 구조에서 크게 부족함을 느끼지 못했지만,

더 복잡한 케이스가 등장하거나, 테스트 구조에서 개선의 여지를 느끼게 된다면, 글을 업데이트하러 오도록 하겠습니다:)

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

안녕하세요 Noah입니다.

SOPT라는 동아리에서 대학생들이 모여 만들게 된 앱이 공개된지 얼마되지 않았음에도 불구하고 감사하게도 많은 회원 수를 유치하게 되었습니다.

서비스 소개 페이지 : https://havit.app/

또 그만큼 돈으로 살 수 없는 소중한 피드백과, 사용자의 사용경험을 들어볼 수 있었는데요,

오늘은 사용자의 사용 경험을 높이기 위해 했던 경험 한 가지를 공유하고자 합니다.

내가 만든 앱을 누군가가 사용해 본다는 건 정말 특별한 경험이었습니다 ☺️

HAVIT 앱은 인터넷에서 찾은 유용한 웹페이지, 블로그, 기사, 이미지, 동영상 등을 저장하고, 필요할 때 언제든지 쉽게 찾아볼 수 있는 콘텐츠 아카이빙 서비스를 제공합니다.

어느날 받게 된 피드백

사용자는 원하는 콘텐츠를 저장하면서 해당 콘텐츠와 관련된 카테고리를 설정하여 자신만의 개인적인 콘텐츠 라이브러리를 구축할 수 있습니다.

먼저 앱을 처음 보시는 분들을 위해 "공유하기 프로세스"의 사이클을 보도록 하겠습니다.

공유하기 -> Share Extension 진입 -> 카테고리 선택 -> 콘텐츠 저장 (콘텐츠 미리보기 제공) -> 완료 버튼 터치 -> 저장

사용자는 위의 프로세스를 거쳐 콘텐츠를 저장하게 됩니다.

앱을 출시한 지 얼마되지 않아 사용자로부터 피드백을 받게 됩니다.

"콘텐츠가 가끔 중복으로 저장돼요!"

문제 원인 찾기

문제를 해결하기 위해 먼저 문제가 어디서 발생하는지 찾기 위한 방법을 고민하기 시작했습니다.

콘텐츠가 중복되는 현상은 네트워크 요청 과정 중 동시성 문제와 관련이 있다고 판단하여, instruments에서 Swift Concurrency profiling template을 이용해 콘텐츠를 생성하는 동작을 다양하게 시도해보았습니다.

콘텐츠를 생성하는 동작을 여러 조건으로 시도해보던 중 콘텐츠 저장 버튼을 여러 번 터치 시 아래의 레코드를 얻을 수 있었습니다.

생성된 Task들의 상태를 보니, 중복된 비동기 작업 호출로 인한 Continuation 상태의 task들이 작업이 완료되기 이전에 연속해서 생겨나는 것을 확인할 수 있었습니다.

사실,

"중복 요청 방지? Combine 혹은 RxSwift 의 throttle, debounce과 같은 operator로 입력 event를 제어하면 되는 것 아닌가?" 라는 생각을 가지고,

앱을 출시하기 이전에 throttle operator를 이용해 짧은 시간 내에 여러 번 발생하는 중복 요청에 대해 방지를 해놓았다고 생각했기 때문에 이러한 문제가 생기리라고 예상하지 못하였습니다.

Combine 혹은 RxSwift의 throttle, debounce를 사용하게 될 경우 아래의 문서의 내용에서 알 수 있듯 time interval에 의존하게 됩니다.

"Publishes either the most-recent or first element published by the upstream publisher in the specified time interval."
- Apple Documentation -

"Returns an Observable that emits the first and the latest item emitted by the source Observable during sequential time windows of a specified duration."
- ReactiveX / RxSwift -

하지만 네트워크 요청과 같은 비동기 작업은 시간(time interval)에 의존하는 작업이 아닙니다.

따라서 throttle과 같이 특정 time interval, duration에 의존하여 입력 event를 제어하는 방법은 제외해야겠다고 판단하였습니다.

따라서 시간에 의존하지 않고, 비동기 작업에 대한 중복 요청을 방지할 수 있는 방법을 생각해 보기 시작했습니다.

비동기 작업에 관하여

그렇다면 먼저 비동기 작업은 뭘까요?

“비동기 작업”은 나중에 알 수 없는 시간에 완료될 수 있는 작업입니다.

그렇기 때문에

1. 해당 비동기 코드는 실행과 동시에 바로 완료되는 것도 아니고,
2. 호출 스레드의 코드 실행을 막지도 않습니다 (non-block)

네트워크 작업은 비동기로 처리하는 대표적인 작업입니다.

그렇다면 왜 대부분 네트워크 작업을 비동기로 처리해야 할까요?

먼저 메모리 계층구조를 살펴봅시다.

메모리의 계층구조의 위에 있으면 있을수록 명령을 처리하는 CPU와 가까우며, 그만큼 데이터에 접근하는 속도 역시 빠릅니다. 반대로 계층구조의 밑으로 가면 갈수록 명령을 처리하는 CPU와 멀어지며, 그만큼 데이터에 접근하는 속도 역시 느려집니다.

네트워크를 통해 어떠한 데이터를 가져오거나 보내는 것은 현재 컴퓨터(로컬 디바이스)에 있는 데이터가 아닌, 네트워크 통신을 통해 다른 컴퓨터에 있는 데이터를 가져오는 것이므로 그만큼 데이터에 접근하는 속도 역시 디바이스 내에 있는 데이터에 접근하는 것보다는 느릴 것입니다.

만약 네트워크 통신을 통해 가져온 데이터를 이용해서 작업을 하는 코드를 메인 스레드에서 동기적으로 구성한다면 Remote Storage에 있는 데이터를 가져올 때까지 사용자의 인터렉션에 프로그램이 반응하지 못하게 될 것입니다. 그리고 이는 좋지 못한 사용자 경험으로 이어질 것입니다.

"100 ms is the threshold for delays in direct user interaction. If a delay in user interaction becomes longer than 100 ms, it starts to become noticeable and causes a hang. A shorter delay is rarely noticeable."
- Apple Developer Documentation

Apple의 문서에 따르면 100ms보다 지연시간이 길어지면 눈에 띄기 시작하며 버벅임이 발생한다고 합니다.

좋은 사용자 경험을 제공하기 위해선 메인 스레드에서 동기적으로 작성하는 함수의 경우 최대 100ms 이내에 실행되어야 한다는 중요한 힌트를 위 문서를 통해 얻을 수 있습니다.

따라서 네트워크 요청 작업은 100ms 이내에 실행될 것이라는 보장이 없기 때문에 (사용자 네트워크 환경, 원격 서버 환경과 같은 여러 불확실한 환경적 요인 포함) 비동기적으로 처리하여 요청에 대한 응답이 올 때까지 동기적으로 기다리는 것이 아닌, 다른 작업을 수행할 수 있도록 해주어야 합니다.

앞서 말했듯 네트워크 요청과 같은 비동기 작업은 시간(time interval)에 의존하는 작업이 아닙니다.

알 수 없는 시간에 완료될 수 있는 작업이기 때문에 이를 비동기적으로 처리하여

메인 스레드를 block 하지 않고, 계속해서 사용자와 인터렉션 할 수 있게 해주어야 합니다.

따라서 위의 공유하기 프로세스 사이클에서 보았던 "콘텐츠 저장 "네트워크 요청 작업 역시 비동기 작업으로 구성하게 되었습니다.

문제 해결 아이디어

다시 돌아와서 현재 우리는 "콘텐츠가 가끔 중복으로 저장돼요!"라는 문제를 해결하려고 하고 있습니다.

이 문제는 시간에 의존하지 않는 작업인 비동기 작업을 throttle과 같이 특정 time interval, duration에 의존하여 입력 event를 제어하는 operator를 사용했기 때문에 발생했습니다.

그렇다면 어떻게 해결할 수 있을까요?

처음에 생각했던 방식은 flag 변수를 두고 비동기 작업이 완료될 때까지 새로운 비동기 작업 요청을 막는 것이었습니다.

하지만 조금 더 생각해 보면 변수는 스레드 세이프하지 않습니다.

만약 A 스레드에서 비동기 작업을 요청한 뒤에 B 스레드에서 비동기 작업을 요청한다면 flag 변수라는 공유 데이터에 접근하는 상황에서 race condition이 발생해 중복된 비동기 작업이 요청될 수 있습니다.

물론 flag 변수에 접근하는 코드 역시 mutual exclusion을 보장하기 위해 NSLock, Serial Queue등 여러 동기화 방법을 사용하여 보완할 수 있지만 flag 변수라는 관리 포인트가 늘어나 복잡도가 올라갈 것 같습니다.

이러한 복잡도를 해결하기 위해 캐시를 고려하기 시작했습니다.

캐시는 동일한 요청에 대해 이전에 요청한 결과를 재사용함으로써 중복 요청을 방지하는 문제를 해결하기 위해 필요한 특성을 가지고 있습니다.

또한 부가적으로 대부분의 캐싱 시스템은 내부적으로 동기화 문제를 처리하는 메커니즘이 구현되어 있어 개발자가 직접 동기화 로직을 신경 쓸 필요가 없게 되어 앞서 전술한 flag 변수를 사용했을 때 스레드 동기화로 인한 복잡도가 올라가는 것을 피할 수 있습니다.

swift-corelibs-foundation/Sources/Foundation/NSCache.swift at main · apple/swift-corelibs-foundation

The Foundation Project, providing core utilities, internationalization, and OS independence - apple/swift-corelibs-foundation

GitHubapple

혹시 몰라 Swift Foundation framework의 NSCache 구현 부를 살펴본 결과 NSLock을 이용한 동기화 메커니즘이 구현되어 있음을 확인할 수 있었습니다.

따라서 비동기 작업을 중복으로 요청하지 않도록 하게 하기 위해 캐시의 특성을 이용하여 비동기 작업의 단위인 Swift Concurrency의 Task 를 캐시 하여 문제를 해결하는 것으로 결정하게 되었습니다.

이제 콘텐츠를 저장하는 요청에 대한 작업을 캐시 하여 문제를 해결해 봅시다.

비동기 작업 캐시 하기

요구사항은 다음과 같습니다.

• 콘텐츠를 저장하는 작업이 진행 중일 경우 캐시 된 작업을 반환한다.
• 콘텐츠를 저장하는 작업이 완료되었을 경우 완료된 결과를 반환한다.

위의 요구사항으로부터 두 가지의 상태를 가진다고 가정할 수 있습니다.

1. 작업이 진행 중인 상태
2. 작업이 완료된 상태

Swift의 enum은 위의 상태를 표현하기에 자연스러운 것 같습니다.

그렇다면 작업은 어떻게 표현할 수 있을까요?

Swift Concurrency의 Task는 비동기적으로 실행할 수 있는 작업의 단위를 의미합니다.

Task와 enum을 이용해 위 내용을 코드로 바꿔봅시다.

작업이 요청(request)되었지만, 아직 완료되지 않은 Task의 경우 중복 네트워크 요청 방지를 위해 inProgress 케이스를 사용하며, 작업이 완료된 경우 ready 케이스를 사용할 예정입니다.

이제 위 enum을 캐시 해보겠습니다.

캐시 항목이 영속성을 갖지 않기 원하므로 디스크 캐시가 아닌 메모리 캐시로 구현하기 위해 NSCache 를 이용해 구현해 보도록 하겠습니다.

위 선언 부를 보면 알 수 있듯 NSCache는 reference type만을 저장할 수 있기 때문에 enum을 캐시 할 수 없습니다.

따라서 enum을 보유하는 클래스를 만들어 이 클래스의 인스턴스를 캐시에 삽입하도록 하겠습니다.

final 키워드와 모든 프로퍼티를 let으로 선언하여, 스레드 간에 상태의 변경 없이 해당 인스턴스를 안전하게 전달할 수 있습니다.

Task를 캐시하는데 필요한 타입을 만들어 보겠습니다.

Swift의 서브스크립트를 이용해 복잡도를 숨기고, 캐시에 접근하는 코드를 간결하게 만들어 보도록 하겠습니다.

세터(setter)에서 만약 값이 nil이 들어온다면, 해당 key에 대한 캐시를 제거해 딕셔너리와 비슷한 동작을 하도록 합니다.

NSCache는 스레드 세이프 합니다.

이말인즉슨, 여러 스레드에서 데이터에 액세스해도 race condition이 발생하지 않습니다.

그러나 여러 스레드에서 접근할 때 비동기 작업 요청을 한 번만 실행하도록 해야 합니다.

하지만 NSCache의 스레드 세이프는 이를 보장하기에 충분하지 않습니다.

멀티 스레드 코드의 일반적인 문제는 예측할 수 없는 코드의 실행순서입니다.

첫 번째 요청에 대해 비동기 작업을 대기하면 이전 작업이 완료되기 전에 새 요청이 실행됩니다.

우리가 하려고 하는 바는 다른 네트워크 요청을 시작하지 않고, 이미 진행 중인 요청 작업을 기다리는 것입니다.

actor type을 사용해 이 문제를 해결해 보도록 하겠습니다.

actor type을 사용하면 동시 접근하는 것으로부터 캐시를 보호할 수 있습니다.

하지만 단순히 actor type을 사용하는 것 역시 문제를 해결할 수 없습니다.

actor는 가변상태에 대한 독점적인 액세스를 보장하는데 왜 문제를 해결할 수 없을까요?

바로 actor reenterancy와 관련된 특성 때문인데요, actor는 actor의 Mailbox에서 한번에 하나의 메시지를 처리합니다. 하지만, actor는 해당 메시지를 전부 완료 하는 것을 보장하지는 않습니다.

await 함수를 호출하면 실행이 잠재적으로 suspend되고, actor는 비동기 작업이 완료되기 전에 새로운 함수를 호출 할 수 있게 됩니다.

이러한 actor reentrerancy라는 특성이 현재 작업에서는 어떤 문제를 불러일으킬 수 있을까요?

actor내부에서 특정 URL에 대한 비동기 작업 요청을 한 후 await로 인한 잠재적인 suspend상태에서(작업이 완료되지 않은 상태) 동일한 URL에 대해 비동기작업을 actor에 하게되면 캐시에는 아직 해당 값이 기록되어 있지 않으므로 중복으로 비동기 작업을 요청하는 결과를 낳게 될 것 입니다.

따라서 캐시에 값이 있는지 확인하고, 요청 작업 실행을 시작할 때 캐시된 값을 찾아 추가 비동기 작업 요청을 하지 않도록하여 문제를 해결해보겠습니다.

테스트 코드 작성 및 결과 검증

이제 요구사항대로 제대로 작동하는지 테스트 코드를 통해 검증해 보도록 하겠습니다.

우리의 요구사항은 비동기 작업을 동시에 두 개를 요청했을 때 작업이 한 번만 이루어져야 합니다.

이 요구사항을 토대로 테스트 코드를 작성해 보도록 하겠습니다.

테스트에 통과했습니다!

다음은 instruments를 이용해 앞서 살펴본 바와 같이 다시 한번 문제 상황을 재연해 문제를 해결했는지 확인해보도록 하겠습니다.

instruments를 이용해 검증한 결과 역시 비동기 작업을 중복해서 요청을 하고있지 않다는 것을 확인할 수 있었습니다.

이로써 검증까지 마쳤습니다.

문제를 해결하며 고민했던 내용들이 여러분들에게 도움이 되는 글이 되었으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다.

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

참고

swift-evolution/proposals/0306-actors.md at main · apple/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

GitHubapple

“그림자가 겹치면 더 어두워질까요?” 시한부 판정을 받은 한 사내가 주인공 히로야마에게 던진 질문이다. 히로야마는 대답한다. 아무것도 변하지 않는다면 말이 안 된다고. 매일 집 앞에서 한 할머니의 비 쓰는 소리에 잠에서 깨고, 양치를 하고, 화분에 물을 주고, 파란색 작업복을 입고, 똑같은 자판기 캔 커피를 먹으며 출근하는 주인공 히로야마. 매일 챙겨가야 할 소지품들을 순서대로 놓아둘 만큼 질서와 안정을 추구하는 주인공마저 변화는 당연한 거라 말한다.

빔 벤더스의 영화 <퍼펙트 데이즈>(2024)는 시종일관 그런 겹침을 찬란하다고 말한다. 빛의 각도, 나뭇잎 모양, 그리고 바람의 세기. 세 변수가 만든 그림자는 그 순간에만 존재하는 것처럼. 주인공 히로야마의 반복되는 삶 속에서도 우연한 ‘겹침'이 변주를 만든다. 화장실 청소부인 히로야마는 매일 다른 이들을 마주하며 오늘이 또 어제와 다른 하루임을 느낀다. 엄마를 잃어버린 아이. 피부색이 다른 외국인. 밤샘 회식으로 아직 술이 덜 깬 직장인. 그는 그때 말없이 옅은 미소를 띤다. 누군가 화장실에 남기고 간 빙고 게임 종이에 X를 그리며 게임을 이어 나가는 그의 표정엔 하루에 대한 기대감과 설렘 마저 묻어난다. 그런 변주가 단지 기쁨만을 의미하는 건 아니다. 청소부 후배 다카시가 갑자기 일을 관두자 늘어난 일에 그는 짜증을 내기도 하고, 연락을 끊고 살던 동생과의 만남에 오열하기도 한다. 마지막에 차를 몰며 웃는지 우는지도 모르는 그의 표정에서 기쁨 그리고 슬픔 만감이 교차한다. 경계를 넘나드는 겹침이 찬란한 이유는 그냥 그 순간에만 존재하기 때문일 것이다.

관계도 마찬가지다. 우리는 각자 세계에 살아간다. 그러면서 우연히 포개어지기도 한다. 나의 세계를 알아봐 준 누군가에 강한 친밀감을 느끼기도 한다. 50대 남성인 히로야마와 20대 여성인 다카시 여자 친구. 전혀 겹칠 게 없던 두 인물이 ‘카세트 테이프'의 감성과 취향에 공감할 때, 히로야마와 10대 조카 니코가 각각 필름 카메라와 아이폰으로 일렁이는 그림자를 함께 포착할 때. 시대와 성별을 뛰어넘어 포개지는 그 순간을 기적이라 말하는 건 과한 얘길까. 엔딩 크레딧이 올라가면 마지막으로 한 문구가 나타난다. '코모레비: 흔들리는 나뭇잎 사이로 일렁이는 햇살을 뜻하는 일본어로 코모레비는 그 순간에만 존재합니다'

취향의 파편화. 초개인화 시대 겹침의 영역은 점점 줄어드는 것만 같다. 단적으로 O,A,B,AB 4분의 1로 연결되던 우리는 이제는 MBTI, 16분의 1 더 적은 확률로 겹치게 됐다. 각자 고유한 다양성을 존중하면서도 우리가 연결되는 순간은 그래서 더 소중하다. 포기와 배려라는 위계적 층위가 아닌 수평적으로 겹치는 우리의 순간. 시선의 각도, 우리의 모양, 공감의 세기가 만들어내는 순간의 찬란함.

URL의 미리보기 이미지(대표 이미지)를 Apple의 Link Presentation 프레임워크를 이용해 불러오도록 개발하며 특정 링크의 경우 아래와 같이 continuation misuse로 인한 leak이 발생하는 것을 확인하여 주의할 점에 대해 기록 삼아 남겨본다.

무엇이 문제였는지, 작성한 코드를 확인해 보자

Before

func requestPreviewImage() async throws -> UIImage {
  let primaryImageProvider = self.linkMetadata?.imageProvider ?? self.linkMetadata?.iconProvider
  return try await withCheckedThrowingContinuation { continuation in
    primaryImageProvider?.loadObject(ofClass: UIImage.self) { (previewImage, error) in
      guard let previewImage = previewImage as? UIImage,
      error == nil
      else {
        continuation.resume(throwing: LinkMetadataServiceError.contentsCouldNotBeLoaded)
        return
      }
		
      continuation.resume(returning: previewImage)
    }
  }
}

기존 completion Handler 기반의 코드를 Swift Concurrency로 bridge 해주기 위해 CheckedContinuation을 사용해 주었다.

CheckedContinuation을 사용해 주었기에 디버깅 콘솔에서 아래와 같은 메시지를 확인할 수 있었다.

SWIFT TASK CONTINUATION MISUSE: requestPreviewImage() leaked its continuation!

어디가 문제였을까?

imageProvider, iconProvider에 모두 nil이 할당되어 primaryImageProvider 에 nil이 들어가게 된다면?

func requestPreviewImage() async throws -> UIImage {
  let primaryImageProvider = self.linkMetadata?.imageProvider ?? self.linkMetadata?.iconProvider
  return try await withCheckedThrowingContinuation { continuation in
    primaryImageProvider?.loadObject(ofClass: UIImage.self) { (previewImage, error) in
      guard let previewImage = previewImage as? UIImage,
      error == nil
      else {
        continuation.resume(throwing: LinkMetadataServiceError.contentsCouldNotBeLoaded)
        return
      }
		
      continuation.resume(returning: previewImage)
    }

    // nil일 경우 오게되는 컨텍스트
  }
}

Optional Chaining을 이용해 메소드를 호출했기 때문에 nil로 평가되어 loadObject메소드를 호출하지 못하고 다음 컨텍스트로 넘어가게 된다.

따라서 continuation의 인터페이스를 호출하지 못하게 되어 continuation misuse로 인한 leak이 발생하게 된다.

문제를 알게 되었으니, 코드를 수정해 보자

After

func requestPreviewImage() async throws -> UIImage {
  guard let linkMetadata = self.linkMetadata,
        let primaryImageProvider = linkMetadata.imageProvider ?? linkMetadata.iconProvider,
        primaryImageProvider.canLoadObject(ofClass: UIImage.self)
  else { throw LinkMetadataServiceError.contentsCouldNotBeLoaded }
		
  return try await withCheckedThrowingContinuation { continuation in
    primaryImageProvider.loadObject(ofClass: UIImage.self) { (previewImage, error) in
      guard let previewImage = previewImage as? UIImage,
      error == nil
      else {
        continuation.resume(throwing: LinkMetadataServiceError.contentsCouldNotBeLoaded)
        return
      }
  
      continuation.resume(returning: previewImage)
    }
  }
}

guard 구문에서 Optional Binding을 해주고, NSItemProvider의 canLoadObject(ofClass:)
를 이용해 객체를 로드할 수 있는지 확인한 뒤에 조건문을 통과하지 못한다면 에러를 throw하며 early exit하도록 해주어 문제를 해결할 수 있었다.

Conclusion

continuation을 사용할 때는 코드 실행 경로에서 resume은 코드 실행 경로에서 딱 한 번 호출되어야 한다는 것에 유의해서 코드를 작성하다 보니 두 번 이상 호출하지 않도록 하는 부분은 신경을 썼었는데,

이번 경우처럼 한 번도 호출하지 못하는 경우에 대해서는 신경을 쓰지 못했던 것 같다.

그래도 다행인 부분은 withCheckedThrowingContinuation(function:_:)을 사용했기에 빠르게 문제를 확인할 수 있었다.

checkedContinuation은 런타임에 misuse에 대한 검사를 하기 때문에 unsafeContinuation보다 오버헤드가 있긴 하지만, 이처럼 개발을 하는 과정 중에 빠르게 문제를 확인할 수 있게 도와주어 misuse에 대한 확신이 없는 경우에 좋은 것 같다.

안녕하세요! 오늘은 Swift Concurrency가 등장하기 이전에는 동시성 프로그래밍을 구현하기 위해 어떠한 도구들을 사용했는지, 어떠한 맥락으로 동시성 프로그래밍을 도와주는 도구들이 등장하게 되었는지 더 나아가 Swift Concurrency는 어떠한 문제를 해결하기 위해 등장하게 되었는지 살펴보도록 하겠습니다.

Thread

동시성 프로그래밍을 할 때 '스레드'라는 단어가 많이 언급되는데요, 스레드를 많이 쓰면 쓸수록 더 많은 작업을 동시적으로 실행할 수 있으니, 스레드는 많을수록 좋은 걸까요?

"동시"라는 단어에 대한 맥락은 이전 포스트와 같이합니다!

아래의 표를 볼까요?

스레드의 수가 많아짐에 따라 퍼포먼스(시간 당 작업효율)가 올라가지만, 어느 순간부터는 더 이상 퍼포먼스가 향상되지 않는 구간이 나타나는데요,

이는 CPU의 스레드가 많아질수록 스레드 스위칭 등의 오버헤드가 발생하게 되어 코어당 일정 수의 스레드가 넘어가게 될 경우 성능에 좋지 않은 영향을 미치게 되기 때문입니다.

이를 thread-explosion이라고 합니다.

따라서 대부분의 CPU 제조사는 스레드가 아닌, 코어 수를 증가시켜 병렬처리로 인한 성능 향상을 꾀하는 식으로 CPU를 발전시켜 나가고 있습니다.

늘어난 코어만큼 사용자가 컴퓨터가 빨라졌다는걸 느끼게 하려면 스레드는 CPU 코어 수에 맞추어 적당하게 만들고, 만들어놓은 스레드를 활용하기 위해 스레드에서 돌아가는 코드들을 빠르게 다른 코드로 교체해 줘야 효율적으로 돌아가는 것으로 느끼게 될 것입니다.

프로세스 내의 user-level 스레드 역시 동일한 논리를 따릅니다.

방금 언급한 스레드는 CPU 코어에서 동작하는 CPU 스레드를 말합니다.
밑에서 살펴보겠지만 우리가 이번 글에서 다루게 될 스레드는 user-level 스레드, 프로세스 내에서 실행되는 세부 작업의 단위입니다.
따라서 아래의 글에서 등장하는 스레드는 특별한 언급이 없는 이상 user-level 스레드를 말합니다 :)

따라서 프로그래밍 방식도 역시 과도하게 스레드를 많이 만들어 스레드 스위치와 같은 오버헤드를 비용을 발생시키는 것보다 시스템이 만들어 놓은 스레드에 실행할 코드를 보내는 식으로 발전하게 됩니다.

애플 개발 생태계에서도 역시 스레드를 생성해 사용하는 API가 있지만, 프로그래밍 방식이 변화함에 따라 이제는 잘 사용하지 않고 있습니다.

스레드, 한번 만들어볼까요?

NSThread

URL로부터 데이터를 가져온 후, 콘솔에 출력하는 함수를 동기적으로 구성한 다음, 스레드를생성한 후에 해당 함수를 생성한 user-level 스레드에서 실행하는 간단한 예제를 만들어봅시다.

먼저 URL로부터 데이터를 가져온 후, 콘솔에 출력하는 함수를 아래와 같이 동기적으로 구성해 봅시다.

func fetchAndPrintHTML(from url: URL) {
  let responseData = try! Data(contentsOf: url)
  print(String(data: responseData, encoding: .utf8)!)
}

위 함수의 첫 번째 줄을 살펴보면 파라미터로 받은 url을 이용해 Data 생성자를 이용해 동기적으로 데이터를 가져오기 때문에 네트워크 요청이 완료될 때까지 해당 함수를 실행하는 스레드가 차단될 것입니다.

그다음으로 해당 함수를 실행할 스레드를 생성해 보도록 하겠습니다.

final class NetworkRequestManager {
  private var networkRequestThread: Thread? = nil

  func startRequest() {
    self.networkRequestThread = Thread(
      target: self,
      selector: #selector(self.fetchAndPrintHTML(from:)),
      object: URL(string: "https://www.naver.com")!
    )
    self.networkRequestThread?.start()
  }
}

startRequest 함수에서는 NSThread(일명 Cocoa thread)를 이용해 스레드를 생성해 주고 있는데요, NSThread는 이미 실행 중인 스레드에서 새 스레드를 생성하고, 코드를 실행하는 데 사용할 수 있는 메서드를 제공합니다.

NSThread를 이용해 스레드를 생성하는 방법은 크게 두 가지가 있습니다.

1. 새 NSThread 객체를 만들고 start 메서드를 명시적으로 호출하는 방법과
2. detachNewThreadSelector:toTarget:withObject: 클래스 메서드를 사용하여 새 스레드를 생성하는 방법이 있습니다.

공식 문서 참조: https://developer.apple.com/documentation/foundation/thread

이 방법 중 첫 번째 방법을 사용해 NSThread 객체를 생성해 주었는데요,

self.networkRequestThread = Thread(
  target: self,
  selector: #selector(self.fetchAndPrintHTML(from:)),
  object: URL(string: "https://www.naver.com")!
)

스레드가 실행할 메서드가 속한 객체와, 실행할 메서드, 메서드를 호출할 때 필요한 객체를 지정해 주었습니다.

그다음

self.networkRequestThread?.start()

스레드의 start 메서드를 이용해 스레드를 시작해 주었습니다.

네트워크 요청을 하는 함수를 동기적으로 구성한 후, 해당 함수를 NSThread 생성자를 이용해 생성한 스레드에서 실행할 수 있게 되었는데요, 이제 작성한 코드를 다시 구성해 보도록 하겠습니다.

final class NetworkRequestManager {
  private var networkRequestThread: Thread? = nil
	
  func startRequest() {
    self.networkRequestThread = Thread(
      target: self,
      selector: #selector(self.fetchAndPrintHTML(from:)),
      object: URL(string: "https://www.naver.com")!
    )
    self.networkRequestThread?.start()
  }

  @objc private func fetchAndPrintHTML(from url: URL) {
    let responseData = try! Data(contentsOf: url)
    print(String(data: responseData, encoding: .utf8)!)
  }
	
  deinit {
    self.networkRequestThread?.cancel()
    self.networkRequestThread = nil
  }
}

#selector 에 사용되는 함수는 Objective-C에서 호출될 수 있도록 @objc 키워드가 붙어있어야 하므로 위에서 작성한 함수에 @objc 키워드를 붙여주었습니다.

작성한 코드를 실행해 볼까요?

let networkRequestManager = NetworkRequestManager()
networkRequestManager.startRequest()
print("안녕하세요")

RunLoop.main.run()

만약 startRequest함수가 스레드를 생성하지 않고 네트워크 요청을 동기적으로 처리했다면, startRequest함수 내부의 네트워크 요청이 완료된 후에 "안녕하세요"라는 문자열이 출력되었을 것입니다.

그러나, 우리는 스레드를 생성한 후에 동기적으로 구성한 네트워크 요청을 해당 스레드에서 실행하도록 코드를 작성했으며, 네트워크 요청보다 콘솔에 출력하는 작업은 상대적으로 빠르게 실행되기 때문에 콘솔에서 아래와 같은 결과를 확인할 수 있습니다.

안녕하세요
   <!doctype html> <html lang="ko" class="fzoom"> <head> <meta charset="utf-8"> <meta name="Referrer" content="origin"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=1190"> <title>NAVER</title> <meta name="apple-mobile-web-app-title" content="NAVER"/> <meta name="robots" content="index,nofollow"/> <meta name="description" content="네이버 메인에서 다양한 정보와 유용한 컨텐츠를 만나 보세요"/> <meta property="og:title" content="네이버"> <meta property="og:url" content="https://www.naver.com/"> <meta property="og:image" content="https://s.pstatic.net/static/www/mobile/edit/2016/0705/mobile_212852414260.png"> <meta property="og:description" content="네이버 메인에서 다양한 정보와 유용한 컨텐츠를 만나 보세요"/> <meta name="twitter:card" content="summary"> 
/ ... /

Swift에서 스레드를 만들어 사용하기 위해서는 위와 같은 방법을 사용하거나 조금 더 복잡하고, 세부적인 작업이 필요하다면 NSThread를 상속한 후에 코드를 작성할 수 있습니다.

방금 우리가 살펴본 방식은 개발자가 스레드를 생성하고, 어떤 스레드가 있는지 확인한 후에 특정 스레드가 해당 메서드를 실행할 수 있도록 개발자가 결정하는 방식입니다.

앞서

"프로그래밍 방식도 과도하게 스레드를 많이 만들어 스레드 스위치와 같은 오버헤드를 비용을 발생시키는 것보다 시스템이 만들어 놓은 스레드에 실행할 코드를 보내는 식으로 발전하게 됩니다."

라는 말을 했었는데요, 우리가 방금 살펴본 방식은 개발자가 스레드를 생성하고, 스레드를 실행하는 메커니즘이기 때문에 과도하게 스레드가 많이 생성될 수 있는 문제와 여러 휴먼 에러의 발생위험이 있습니다.

또한 이를 올바르게 작성했는지 검증하기 위한 디버깅, 테스팅 비용을 지불해야할 것입니다.

따라서 뒤에 등장하게 될 동시성 프로그래밍을 도와주는 도구들은 CPU 코어 개수에 맞게 스레드를 시스템이 생성하고, 시스템이 만들어놓은 스레드에 개발자가 작성한 코드를 전달하는 방식을 도입하게 됩니다.

결국 개발자가 작성한 코드의 단위는 클로져가 되고, 해당 클로져를 시스템이 관리하는 큐에 제출하고, 큐에 있는 클로저를가용한 스레드에 시스템이 분배하는 방식이 Grand Central Dispatch(GCD)입니다.

Grand Central Dispatch

GCD를 이용해, 앞서 보았던 예제인 네트워크 요청을 동기적으로 구성한 다음, 해당 코드를 다른 스레드에서 실행할 수 있도록 하는 예제를 최대한 비슷하게 다시 만들어봅시다.

먼저 시스템이 관리할 큐를 생성해 보도록 합시다.

final class NetworkRequestManager {
  private let networkRequestQueue = DispatchQueue(
    label: "com.example.networkRequestQueue"
  )
}

DispatchQueue(label:) 생성자를 이용해 private concurrent queue를 생성해 주었습니다.

다음으로 클로저 단위의 작업을 캡슐화하는 DispatchWorkItem을 선언해 주도록 하겠습니다.

final class NetworkRequestManager {
  private let networkRequestQueue = DispatchQueue(
    label: "com.example.networkRequestQueue"
  )
  private var fetchHTMLWorkItem: DispatchWorkItem? = nil
}

앞에서 살펴본 예제와 같이 네트워크 요청을 동기적으로 한 후에 응답을 콘솔에 출력하는 함수를 추가하도록 하겠습니다.

final class NetworkRequestManager {
  private let networkRequestQueue = DispatchQueue(
    label: "com.example.networkRequestQueue"
  )
  private var fetchHTMLWorkItem: DispatchWorkItem?

  private func fetchAndPrintHTML(from url: URL) {
    let responseData = try! Data(contentsOf: url)
    print(String(data: responseData, encoding: .utf8)!)
  }
}

이제 해당 함수를 실행하기 위해 큐에 작업을 제출하는 코드를 추가해 보겠습니다.

final class NetworkRequestManager {
  private let networkRequestQueue = DispatchQueue(
    label: "com.example.networkRequestQueue"
  )
  private var fetchHTMLWorkItem: DispatchWorkItem?

  private func fetchAndPrintHTML(from url: URL) {
    let responseData = try! Data(contentsOf: url)
    print(String(data: responseData, encoding: .utf8)!)
  }
	
  func startRequest() {
    self.fetchHTMLWorkItem = DispatchWorkItem {
      self.fetchAndPrintHTML(from: URL(string: "https://www.naver.com")!)
    }
    
    if let workItem = self.fetchHTMLWorkItem {
      self.networkRequestQueue.async(execute: workItem)
    }
  }

  deinit {
    self.fetchHTMLWorkItem?.cancel()
  }
}

작성한 코드 예제를 실행해 보도록 하겠습니다.

let networkRequestManager = NetworkRequestManager()
networkRequestManager.startRequest()

print("안녕하세요")

RunLoop.main.run()

결과를 확인해 봅시다.

안녕하세요
   <!doctype html> <html lang="ko" class="fzoom"> <head> <meta charset="utf-8"> <meta name="Referrer" content="origin"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=1190"> <title>NAVER</title> <meta name="apple-mobile-web-app-title" content="NAVER"/> <meta name="robots" content="index,nofollow"/> <meta name="description" content="네이버 메인에서 다양한 정보와 유용한 컨텐츠를 만나 보세요"/> <meta property="og:title" content="네이버"> <meta property="og:url" content="https://www.naver.com/"> <meta property="og:image" content="https://s.pstatic.net/static/www/mobile/edit/2016/0705/mobile_212852414260.png"> <meta property="og:description" content="네이버 메인에서 다양한 정보와 유용한 컨텐츠를 만나 보세요"/> <meta name="twitter:card" content="summary"> 
/ ... /

결과는 앞서 살펴본 예제와 동일합니다.

스레드를 생성하는 방식과 비교해, GCD는 시스템이 스레드를 관리함으로써 스레드 관리에 대한 신경을 쓰지 않을 수 있었습니다.

지금은 간단한 예제를 실행해 보았지만, 예제가 더 많이 복잡해지면 차이는 더 분명해질 것으로 생각합니다.

방금 살펴본 GCD 역시 한계를 가지고 있는데요, GCD도 concurrent dispatch queue에 의해 예약된 작업이 스레드를 차단할 경우, 시스템은 대기 중인 다른 병렬작업을 실행할 추가 스레드를 생성하게 됩니다.

위에서 작성한 코드 예제에서는 아래와 같이 custom concurrent queue를 생성해 주었는데요,

private let networkRequestQueue = DispatchQueue(
  label: "com.example.networkRequestQueue"
)

custom concurrent queue를 과도하게 생성하게 될 경우, 각각의 dispatch queue는 스레드 리소스를 사용하기 때문에 스레드를 생성하게 되어 앞서 살펴본 그래프와 같이

많은 스레드간 문맥 전환으로 인한 성능저하로 이어질 수 있습니다.

더 많은 스레드가 실행되면 문맥 전환이 더 자주 발생하고, 이로 인해 시스템의 부담이 더 커지게 됩니다. 이것이 바로 “thread-explosion”입니다.

thread-explosion: 시스템 내의 스레드가 많아져 스레드 스위칭 등의 오버헤드가 발생하게 되는 현상

따라서 Apple의 문서에서는 custom queue를 생성하는 대신 global concurrent dispatch queue에 작업을 제출해 스레드 수를 최소화하는 것을 가이드하고 있습니다.

또한 DispatchQueue는 First In First Out 특성을 가진 Queue이기 때문에 우선순위 역전 현상이 발생할 수 있으며, 클로저를 이용해 명시적으로 작업을 제출하는 방식이기에 작업을 기다리는 순서가 복잡해지게 되면 클로저들이 중첩되는 상황이 생기게 되어 개발자로 하여금 코드의 흐름을 따라가기 어렵게 만드는 문제가 있습니다.

이러한 문제들을 해결하기 위해 Swift Concurrency가 등장하게 되는데요,

앞서 살펴본 예제, Swift Concurrency를 이용해 다시 작성해 볼까요?

Swift Concurrency

먼저 실행되기 원하는 작업의 단위를 Task를 이용해 지정해주도록 하겠습니다.

final class NetworkRequestManager {
  private var networkRequestTask: Task<Void, Never>? = nil
}

네트워크 요청을 동기적으로 한 후에 응답을 콘솔에 출력하는 함수를 추가하도록 하겠습니다.

final class NetworkRequestManager {
  private var networkRequestTask: Task<Void, Never>? = nil
	
  private func fetchAndPrintHTML(from url: URL) {
    let responseData = try! Data(contentsOf: url)
    print(String(data: responseData, encoding: .utf8)!)
  }
}

이제 해당 함수를 실행하기 위해 task를 생성하는 함수를 추가해 보겠습니다.

final class NetworkRequestManager {
  var networkRequestTask: Task<Void, Never>? = nil
	
  func startRequest() {
    self.networkRequestTask = Task {
      self.fetchAndPrintHTML(from: URL(string: "https://www.naver.com")!)
    }
  }
	
  private func fetchAndPrintHTML(from url: URL) {
    let responseData = try! Data(contentsOf: url)
    guard Task.isCancelled == false
    else { return }

    print(String(data: responseData, encoding: .utf8)!)
  }
	
  deinit {
    self.networkRequestTask?.cancel()
    self.networkRequestTask = nil
  }
}

네트워크 요청을 한 이후에 Task가 취소되었는지 여부를 확인하고 취소가 되지 않았다면 콘솔에 응답을 출력합니다.

Swift Concurrency를 이용해 작성한 코드 예제를 실행해 보도록 하겠습니다.

let networkRequestManager = NetworkRequestManager()
networkRequestManager.startRequest()

print("안녕하세요")

RunLoop.main.run()

결과를 확인해봅시다.

안녕하세요
   <!doctype html> <html lang="ko" class="fzoom"> <head> <meta charset="utf-8"> <meta name="Referrer" content="origin"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=1190"> <title>NAVER</title> <meta name="apple-mobile-web-app-title" content="NAVER"/> <meta name="robots" content="index,nofollow"/> <meta name="description" content="네이버 메인에서 다양한 정보와 유용한 컨텐츠를 만나 보세요"/> <meta property="og:title" content="네이버"> <meta property="og:url" content="https://www.naver.com/"> <meta property="og:image" content="https://s.pstatic.net/static/www/mobile/edit/2016/0705/mobile_212852414260.png"> <meta property="og:description" content="네이버 메인에서 다양한 정보와 유용한 컨텐츠를 만나 보세요"/> <meta name="twitter:card" content="summary"> 
/ ... /

역시 결과는 앞서 살펴본 예제와 동일합니다.

GCD와 비교해 어떤가요?

코드 외적으로는 동기적인 코드를 작성하는 것과 비슷하게 코드를 작성할 수 있게 되었습니다.

또한, 컴파일 단계에서 데이터 레이스와 관련된 에러를 발생시켜 코드 작성 실수로 발생할 수 있는 문제를 해결할 수 있습니다.

이와 함께, 이전 GCD가 가지고 있던 문제인 스레드가 과도하게 생성되어 발생하는 thread-explosion 문제를 suspend point(await)에서 스레드 간 문맥 전환이 아닌, 작업의 재개 여부를 추적하는 가벼운 객체인 continuation 간 전환을 하도록 하여, 스레드를 차단하지 않고 함수 호출 정도의 비용만 지불하도록 하였습니다.

더불어, 프로세스의 스레드 수를 CPU 코어 수만큼 생성하도록 제한하여 thread-explosion 문제를 해결하였습니다.

WWDC-21 Swift concurrency: Behinde the scenes 참조

또한 GCD와 달리 작업이 실행되는 순서가 FIFO가 아니기 때문에 먼저 추가된 작업이 실행되고 있을 때 실행되고 있는 작업보다 우선순위가 더 높은 작업이 추가되면 해당 작업을 먼저 실행함으로써 우선순위 역전 문제를 해결하였습니다.

마치며

이번 글에서는 Swift Concurrency 이전에는 동시성 프로그래밍을 구현하기 위해 어떠한 도구들을 사용했는지, 어떠한 맥락으로 동시성 프로그래밍을 도와주는 도구들이 등장하게 되었는지 살펴보았습니다.

이를 통해 Swift Concurrency가 등장한 배경을 이해하는 데 여러분께 도움이 되었으면 좋겠습니다.

Swift Concurrency 역시 Swift와 함께 발전하는 기술이기에 앞으로 추가될 기능들이 더 기대가 됩니다.

긴 글 읽어주셔서 감사합니다.

이번 주제에서는 Swift Concurrency에 대해 자세히 알아보기에 앞서 동시성과 병렬성에 대한 개념을 잡아보려고 해요

코드를 다른 코드와 동시에 실행한다는 것은 무엇을 의미하는 걸까요?
Computer Science에서 ‘동시’라는 단어의 의미는 2개 이상의 사건이 정확히 같은 시간에 진행되는 것을 의미하는 “same-time”을 의미하는걸까요?

그럼 시작해보시죠!

우리가 작성하는 대부분의 코드는 동시성이 없는, 단일 스레드에서 실행되는 코드
아래와 같이 동기적인 방식으로 한번에 한줄, 한줄 씩, 한 함수씩 실행돼요

func getFullName() {
 let givenName = getGivenName()
 let familyName = getFamilyName()
 print(“\\(givenName) \\(familyName)”)
}

func getGivenName() -> String {
 print("What's your given name?")
 return readLine() ?? " - "
}

func getFamilyName() -> String {
 print("What's your family name?")
 return readLine() ?? " - "
}

getFullName()

• 위 코드는 readLine() 함수에서 사용자의 입력을 받을 때까지 대기하고 있을 거예요
• 물론 사용자의 입력을 받을 때까지 대기할 동안 아무런 작업도 하지 못합니다.

위 처럼 오래걸리는 작업 혹은 프로그램이 CPU 혹은 스레드를 계속해서 점유하지 않고 원활하게 실행되도록 하려면 동시성을 활용해야해요

CPU는 여러 작업을 동시에 수행할 수 있습니다.

여러작업을 동시에 수행한다는 것은 무엇을 말하는걸까요?

여러작업을 동시에 수행한다는 것은 하나의 작업을 동시(same-time)에 수행하는 것이 아닌, 여러 작업을 번갈아 실행하며 동시(same-time)에 수행되는 것 처럼 보이는 것을 의미해요

한 개의 Core를 가진 CPU에서도 한 개 이상의 스레드를 동시에(번갈아 가며) 실행하며 멀티 스레딩 환경을 구현할 수 있어요

그렇다면 여러 코어를 가진 CPU에서는 어떨까요?

여러 CPU Core를 가진 환경에서는 병렬로 여러 스레드를 실행할 수 있는데요,

동시성과 병렬성의 차이

이쯤에서 동시성과 병렬성의 차이에 대해 정리하면 좋을 것 같아요

동시성은 위에서 말했던 것처럼 여러 작업을 번갈아가며 수행하는 것을 의미해요

병렬성은 여러 작업을 same-time에 수행한다는 것을 의미해요

Thread Safety

여러파일에서 한줄 한줄 씩 파일을 읽어서 특정 키워드를 찾아 일치한 키워드를 결과 파일에 기록하는 상황을 가정해보겠습니다.

색이 다른 각각의 박스는 다른 스레드에서 실행되고 있다고 가정합니다.

위 작업은 어떠한 잠재적인 문제를 가지고 있을까요?

여러 스레드가 정확하게 same-time에 일치한 특정 키워드를 기록하려고 할 때 데이터 레이스가 발생하게 됩니다.

기록하는 작업이 원자적으로 이루어진다는 전제하에서는 동시적으로 일치한 항목을 기록하려고 하면 괜찮지만, 병렬로 일치한 항목을 기록할 경우 데이터의 일관성이 깨지게 되는 문제가 발생할 수 있어요

위와 같은 상황 이외에도 멀티스레드 환경에서는 적어도 하나가 쓰기 연산을 수행할 때 데이터 레이스의 위험이 따르는데요,

예측 불가능한 결과를 방지하기 위해 멀티스레드 환경에서 작업할 때는 데이터 레이스를 피하기 위한 적절한 동기화 메커니즘을 사용해야 해요.

예를 들어 뮤텍스(Mutex)나 세마포어(Semaphore) 같은 도구를 사용하여 공유 자원에 대한 접근을 조절하고, 원자성을 보장할 수 있는 연산을 사용해야합니다.

마치며

이번 시간에는 동시성과 병렬성의 차이에 대해 알아보았는데요, Swift Concurrency에서는 앞서 살펴본 문제들을 어떻게 해결했는지 다음 글들을 통해서 알아보도록 하겠습니다 :)

안녕하세요 Noah입니다.
Bundle Class는 Bundle directory를 추상화해 내부 구조를 몰라도 편하게 접근할 수 있도록 해주는데요,
오늘은 이 번들 디렉터리의 구조와 개념, Bundle class의 사용법에 대해 예제와 문서를 보며 함께 알아보도록 하겠습니다.

Bundle

Apple Developer Documentation에서는 Bundle Class를 아래와 같이 소개하고 있어요

A representation of the code and resources stored in a bundle directory on disk.

• Apple Developer Documentation

Bundle Class는 디스크의 번들 디렉터리에 저장된 코드 및 리소스를 나타낸다고 하는데요,
먼저 Bundle Class의 설명에 나오는 번들 디렉터리가 어떤 의미인지 조금 더 자세히 알아봅시다 🏊‍♂️

Bundle Directory

Bundle은 한국말로 '묶음'인데요, 슈퍼마켓에서 파는 맥주 번들, 과자 번들을 떠올리며 아래의 설명을 읽어보시면 좋을 것 같습니다!

Apple에서 정의하는 Bundle은 실행 코드와 해당 코드에서 사용하는 리소스(이미지, 음악, 스토리보드 등등) 를 포함하는 계층 구조를 가진 표준화된 디렉터리를 말하는데요,

Bundle을 사용해 application, app extension, framework, plug-in을 나타내며, Bundle이 다른 Bundle을 포함할 수도 있습니다.

예를들면 애플리케이션 번들 이 app extension 번들을 포함하는 것처럼 말이죠

애플리케이션 번들 디렉터리의 구조에 대해 알아볼까요?

Application

macOS Application Bundle

앞서 말한 것 처럼 Bundle은 표준화된 디렉터리 이기 때문에 Bundle에는 콘텐츠를 보관할 수 있는 위치가 정해져 있습니다.

가령 app extension은 plug-in용으로 예약된 위치에, 스토리보드는 리소스용으로 예약된 위치에 배치해야해요

번들의 구조는 번들의 타입과 플랫폼에 따라 다릅니다.

한번 확인해볼까요?

음악 애플리케이션을 우클릭한 후에 Show Package Contents를 클릭해 봅시다.

Bundle을 확인해 보려고 하는데 왜 Package를 열어봐야할까요?
Package의 정의를 먼저 읽어봅시다.

A package is any directory that the Finder presents to the user as if it were a single file.
- Apple Developer Bundle Programming Guide

패키지는 Finder가 사용자에게 단일 파일로 보여주는 디렉터리를 말합니다.
패키지는 macOS에서 디렉터리를 추상화하는 기본적인 방법 중 하나인데요, Package는 디렉터리이지만 Finder에서는 이를 단일 파일로 인식합니다. 따라서 일반적인 디렉터리를 파인더에서 더블클릭하면 해당 디렉터리 내부로 이동하지만, 패키지를 더블클릭하면 해당 파일이 실행됩니다.

따라서 우리가 mac에서 사용하고 있는 application도 모두 패키지입니다.

위에서 우클릭으로 확인하려고 했던 application도 여러 패키지 종류 중 하나인데요, Finder가 패키지로 인식하는 것은 .app, .bundle, .framework, .plugin 등이 있습니다.

그렇다면 우리가 알아보려고 하는 번들과 패키지는 어떤 관계일까요?

많은 타입의 번들이 패키지이기도 한데요,

패키지가 사용자에게 디렉터리를 단일 파일로 보여줌으로써 사용자 경험을 개선하기 위해 존재하는 반면
번들은 개발자가 코드를 패키징하고 운영체제에서 해당 코드에 액세스할 수 있도록 돕는데 더 중점을 둡니다.

번들은 표준화된 구조를 가지고 있는 반면, 패키지는 내부에 어떤 폴더 구조도 가질 수 있기 때문에 모든 패키지가 번들인 것은 아닙니다.

따라서 우리가 보려고 하는 application은 finder에서 단일 파일로 보여지는 패키지이면서, 실행 코드와 해당 코드에서 사용하는 리소스(이미지, 음악, 스토리보드 등등)을 포함하는 번들입니다.

다시 돌아와서 show package contents를 클릭해 패키지이면서, 실행 코드와 해당 코드에서 사용하는 리소스를 포함하는 번들인, application 번들을 확인해 봅시다.

macOS 애플리케이션 번들에 접근해 보니 가장 먼저 Contents라는 디렉터리가 있네요, 내부로 한 번 더들어가 볼까요?

Contents 디렉터리 내부를 보니,여러 디렉터리와 파일을 확인할 수 있는데요,
그 중 Resources 디렉터리 내부를 들여다보도록 해보겠습니다.

Resources 디렉터리에 들어가 보니 앱에서 사용하는 아이콘, 로컬라이제이션과 관련된 파일, WelcomeWindowController.nib 이라는 스토리보드 파일(리소스 관련 파일)을 확인할 수 있네요!

앞서 번들은 계층 구조를 가진 표준화된 디렉터리를 가리킨다고 했는데요,
카카오톡의 애플리케이션 번들도 Music 앱처럼 Resources 디렉터리를 포함하고 있을까요?
한번 살펴봅시다!

마찬가지로 Contents/Resources 에 들어가보면 스토리보드 파일과, 앱 아이콘과 앱 내에서 사용되는 여러 이미지 파일과 음악파일을 확인할 수 있어요

번들의 구조는 앞서 말한 바와 같이 번들의 타입과 플랫폼에 따라 다르기 때문에 iOS나 watchOS, tvOS에서는 다른 구조일 수 있어요

iOS에서의 애플리케이션 번들은 밑에서 확인해보도록 하겠습니다.

macOS에서의 애플리케이션 번들은 어떤 표준화된 계층 구조를 가지고 있을까요?
macOS에서의 애플리케이션 번들은 아래와 같은 파일들을 포함하고 있어요

Info.plist를 통해 애플리케이션 및 관련 파일에 대한 관련 정보를 식별하기 때문에 애플리케이션 번들은 Info.plist를 꼭 포함하고 있어야 합니다.

모든 애플리케이션 번들은 실행파일(executable file)을 포함하고 있는데요, 이 파일에는 애플리케이션의 main entry point와 애플리케이션 타겟에 정적으로 링크된 코드가 포함되어 있어요

Resources는 애플리케이션의 실행파일 외부에 있는 데이터 파일 입니다.
위에서 본 것처럼 이미지, 아이콘, 음악파일, 스토리보드 파일, 로컬라이제이션과 관련된 파일로 구성되어 있어요

대부분의 Resources 파일은 특정 언어, 지역에 맞게 로컬라이제이션 할 수 있습니다.

이제 iOS에서의 애플리케이션 번들의 구조를 살펴볼까요?

iOS Application Bundle

iOS 애플리케이션 번들의 구조는 모바일 디바이스 요구사항에 맞게 디스크 공간을 절약하고 파일에 대한 액세스를 단순화하기 위해 최상위 번들 디렉터리에 애플리케이션 실행파일과 애플리케이션에서 사용하는 모든 리소스를 포함하고 있어 macOS 애플리케이션 번들과 비교했을 때 비교적 평평한 구조로 되어있어요

대부분의 Xcode 프로젝트 템플릿으로 만든 프로젝트는 실행 파일을 빌드할 때 빌드하려고 하는 target에 대한 번들을 생성하는데요,
iOS 애플리케이션을 빌드할 때 만들어지는 애플리케이션 번들을 확인해 보며 iOS 애플리케이션 번들의 구조를 살펴봅시다.

iOS App 프로젝트에서 Product를 클릭한 후에

Show Build Folder in Finder를 클릭합니다.

Build/Products/Dev-iphonesimulator 에 접근하게 되면
아래와 같이 애플리케이션 번들을 확인할 수 있는데요,

애플리케이션 번들 내부로 가볼까요?

앞서 말한 것처럼 macOS 애플리케이션 번들과 달리 iOS 애플리케이션 번들은 최상위 번들 디렉터리에 애플리케이션 실행파일과 애플리케이션에서 사용하는 모든 리소스가 포함되어 있네요

iOS 애플리케이션 번들도 역시 Info.plist를 포함하고 있어야 하는데요, Info.plist에는 번들의 ID, 버전 번호, display name등 애플리케이션에 대한 정보가 들어있어요

앞서 대부분의 Xcode 프로젝트 템플릿으로 만든 프로젝트는 실행 파일을 빌드할 때 번들을 생성한다고 했는데요, 우리가 Xcode에서 iOS App 템플릿을 이용해 프로젝트를 시작할 때 아래와 같은 창이 뜨는 것을 확인할 수 있습니다.

이곳에서 개발자가 입력하는 정보에 따라 Bundle Identifier가 정해지는 것을 확인할 수 있어요

Plug-ins

Settings.bundle은 설정 애플리케이션에 추가하려는 정보가 담긴 특수한 타입의 플러그인 번들이에요
제가 참여했던 프로젝트인 Havit에서는 애플리케이션에서 사용한 오픈소스 라이브러리 정보를 Settings.bundle을 이용해 설정 애플리케이션에서 확인할 수 있도록 해주었어요

여기까지 자주 쓰는 iOS, macOS의 애플리케이션 번들 디렉터리의 구조를 잠시 살펴보았습니다.

앞서 번들은 개발자가 코드를 패키징하고 운영체제에서 해당 코드에 액세스할 수 있도록 돕는데 더 중점을 둔다고 했는데요,

어떻게 그리고 어떤 도움을 줄까요?

Bundle class

번들 디렉터리를 추상화한 클래스인 Bundle class를 살펴봅시다.
추상화를 통해 얻을 수 있는 이점은 무엇일까요?

추상화를 통해 얻을 수 있는 이점 중 하나는 사용하는 쪽에서 구현 디테일을 몰라도 인터페이스를 통해 필요한 결과를 얻을 수 있는 것이라고 생각해요

그럼, 위에서 살펴본 번들 디렉터리를 추상화하면 어떨까요?
번들 디렉터리를 사용해야 하는 개발자 입장에서는 파일구조에 대한 세부 디테일을 몰라도 Bundle의 리소스에 쉽게 접근할 수 있게 됩니다.

위에서 살펴본 번들 디렉터리를 추상화한 class가 바로 Bundle class입니다.

Bundle class의 인터페이스를 살펴보며 어떻게 사용해야 할지 알아봅시다.

번들 객체를 사용하는 일반적인 패턴은 다음과 같습니다.

먼저 의도한 번들 디렉터리에 대한 번들 객체를 만든 후, 해당 번들 객체의 메서드를 사용해 필요한 리소스를 찾거나 로드합니다.

자주 사용하는 일부 리소스 타입은 번들 없이도 로드할 수 있는데요,
예를 들어 아래 처럼 이미지를 로드할 때 이미지를 에셋 카탈로그에 저장하고, UIImage의 init(named:) 을 이용해 이미지 리소스에 접근하는 것이 그 예시입니다.

먼저 리소스를 찾기 위해서는 먼저 찾으려고 하는 리소스가 포함되어있는 번들을 지정해야 하는데요,
가장 자주 쓰게 되는 번들은 현재 실행 중인 애플리케이션의 코드와 리소스가 포함되어있는 메인 번들입니다.
이 메인 번들 객체를 통해 앱과 함께 제공된 리소스에 액세스할 수 있습니다. 아래의 코드처럼 말이죠

let mainBundle = Bundle.main

이 메인 번들 객체를 통해 아래와 같이 현재 실행 중인 코드와 리소스가 포함되어있는 애플리케이션 번들 디렉터리를 확인해 볼 수 있습니다.

let mainBundleDirectoryFilePath = Bundle.main.bundleURL

메인 번들 이외에 다른 번들에 접근하기 위해서는 어떻게 해야할까요?

Apple의 Bundle Class문서의 설명에 따르면 앱이 플러그인, 프레임워크 또는 기타 번들 콘텐츠와 상호작용하는 경우 번들 객체를 통해 앱이 사용하고 있는 번들에 접근할 수 있다고 되어있는데요,

셸 스크립트, 정적 라이브러리, 및 별도의 동적 라이브러리는 번들 구조를 사용하지 않습니다.

예시를 만들어 보며, 프로젝트에서 사용 중인 프레임워크 번들에 접근하는 방법을 살펴보도록 하겠습니다.

먼저 사용할 프레임워크를 하나 생성한 후에

프레임워크의 Product Name은 Example로 하도록 하겠습니다.

Bundle Identifier에 noah.Example이라고 쓰여 있는 게 보이시나요?

이곳에서 사용할 클래스를 하나 생성해 보도록 하겠습니다.

모듈 외부에서 사용할 것이므로 public 접근제어자를 달아주도록 하겠습니다.

Something이라는 클래스를 생성하고 빌드를 한 후에

iOS App 프로젝트에서 방금 만든 프레임워크를 사용해 보도록 하겠습니다.

이곳에서 바로 앞에 만든 프레임워크를 추가해 보도록 하겠습니다.
사용할 모듈을 import 한 후에

mainBundleIdentifier를 확인해 보도록 하겠습니다.

mainBundleIdentifier는 noah.iOSExample이네요
iOS App 프로젝트를 생성할 때 만들어진 Bundle Identifier와 동일한 것으로 미루어 보아 mainBundleIdentifier가 올바르게 불러와진 것을 확인할 수 있어요

다음 브레이크 포인트로 넘어가 봅시다.

frameworkBundleIdentifier의 값은 noah.Example입니다.
역시 위에서 프레임워크를 만들 때 생성한 프레임워크의 Bundle Identifier와 동일한 것으로 미루어보아
우리가 생성한 프레임워크의 번들의 identifier를 올바르게 불러와진 것을 확인할 수 있어요

이처럼 메인 번들에서 로드하는 리소스 대신 프레임워크의 번들 객체에 대한 참조를 통해 프레임워크에 있는 번들 리소스에 접근해 해당 파일을 불러올 수 있는데요,
이를테면 프레임워크에 있는 이미지 혹은 Color Asset을 사용할 수 있습니다.

이를 위해 UIImage에는 UIImage(named:in:with:)와 같은 생성자를 제공하고 있으며 번들 객체를 넣는 파라미터 자리에 이미지를 가져오려고 하는 번들 객체를 전달하면 됩니다.

또한 UIColor에도 역시 UIColor(named:in:compatibleWith:)생성자를 통해 Color Asset을 가져오려고 하는 번들 객체를 전달하면 해당 번들 디렉터리에서 Color Asset을 가져올 수 있어요

이를 잘 활용하면 프레임워크가 독립적인 리소스를 갖도록 할 수 있겠네요 :)

image와 colorAsset과 같이 번들에 접근하기 위해서는 framework의 linking option에서 mach-o type을 dynamic library로 설정해 주어야 하는데요, 이 이유에 대해서는 다음 포스트에서 알아보도록 하겠습니다.

또한 번들 객체에 대한 참조를 얻기 위해서는 앞서 언급한 Bundle과 연관된 클래스 이름을 적는 것 말고도 아래의 생성자를 이용해
Bundle의 identifier를 통해, file URL을 통해, directory의 path를 언급하는 것을 통해 번들 객체에 대한 참조를 얻을 수 있어요

init?(identifier: String)

Returns the NSBundle instance that has the specified bundle identifier.

init?(url: URL)

Returns an NSBundle object initialized to correspond to the specified file URL.

init?(path: String)

Returns an NSBundle object initialized to correspond to the specified directory.

번들에 리소스가 들어가는 시점에 관하여

그렇다면 위에서 본 애플리케이션 번들에 리소스는 어느 시점에 들어가게 될까요?
Xcode에서 iOS App 프로젝트 템플릿을 이용하면 컴파일할 소스 파일, 번들에 리소스를 복사하는 과정 등 애플리케이션 번들이 만들어지기 위해 필요한 규칙이 미리 정의되어있는 것을 확인할 수 있는데요,

프로젝트의 App Target의 Build Phase를 보면

Copy Bundle Resources 라는 Phase를 확인할 수 있어요
바로 이 시점에 리소스가 애플리케이션 번들에 들어가게 됩니다.

빌드 결과로 나오게 된 애플리케이션 번들을 확인해 볼까요?

Assets.xcassets은 Assets.car로 Something.storyboard 파일은 Somthing.storyboardc로 컴파일 되어 애플리케이션 번들에 들어가 있음을 확인할 수 있어요

xib파일은 nib파일로 컴파일됩니다.

마치며

Bundle Class가 아무리 추상화가 잘 되어있어도 번들 디렉터리의 구조와 그 안에 있는 코드 및 리소스에 액세스하는 방법을 이해하는 것이 중요하다고 생각해요

따라서 오늘은 번들 디렉터리와, 번들 클래스에 대한 개념과 자주 쓰이는, 혹은 쓰게될 macOS 애플리케이션 번들, iOS 애플리케이션 번들의 구조에 대해 자세히 알아보고 Bundle class의 사용법에 대해 알아보았습니다.

이번 글이 번들에 대한 이해를 높이는 계기가 되었으면 좋겠습니다.
긴 글 읽어주셔서 감사합니다.

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

참고

• Apple Developer Bundle Programming Guide
• https://hcn1519.github.io/articles/2018-12/bundle

WWDC 2016 UnderStanding Swift Performance을 보고 동료들과 스터디를 한 뒤에 잘못 이해하고 있던 부분(부끄럽지만 Value Type은 무조건 Stack에만 할당되는 것으로 알고 있었습니다.)을 바로 잡기 위해 메모리 맵을 확인해보며 Value Type이 무조건 Stack에만 할당되는 것이 아님을 저번 포스트를 통해 조사해보았습니다.

지난번 포스트 : Value Type은 무조건 Stack에만 할당될까?

조사하며 알게 된 내용을 평소 존경하는 개발자이자 전 스포티파이의 개발자이신 Jonathan Rasmusson님의 교육용 레포지토리에 같이 공부하는 더 많은 학생들에게 이 내용을 공유하고 싶어 아래와 같이 공유하였습니다.

정말 감사하게도 이슈를 남긴 지 얼마 되지 않아 답변을 남겨주셨고,

답변을 보며 앞으로 개발자로서 지녀야 할 자세에 대해 많은 생각을 했습니다.

좋은 기업에서, 또 현업에서 오래도록 경험을 쌓아오신 분이, 학생인 제 의견도 받아들여 주시는 것을 보며,

발전을 위해 서로 놓친 것을 얘기해주고 공유해주는 개발자들의 문화가 너무 멋있었고 너무 자랑스러웠습니다.

저 역시 항상 열린 마음으로 더 좋은 방향으로 나아가기 위해 동료들과 함께 끊임없이 고민하는 멋진 개발자가 되고 싶네요!

공유와 성장을 통해 하루하루 발전해 나가는 내일을 만들어 나가는 모든 분들 화이팅입니다 :)

감사합니다.

아래는 해당 이슈링크입니다:)

https://github.com/jrasmusson/ios-professional-course/issues/2

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

여러분 안녕하세요! Noah입니다.

혹시 Git을 사용하면서 commit id를 보신 적이 있나요?

우리는 commit id로 특정 버전을 가리켜 commit을 되돌리기도 하고,

특정 commit의 변경사항을 되돌리기도 합니다.

그렇다면 이 commit id는 어떻게 해서 만들어지는 걸까요?

Q. 서버에서 고유한 id를 부여해주나요..?🧐

A. Git은 로컬에서 관리되는 버전 관리시스템이기 때문에 별도의 인터넷이 연결되지 않은 환경에서도 commit이 되고,

commit id가 부여되는 것을 확인할 수 있습니다!

이를 통해 commit id를 부여하는 방식이 서버가 부여해주는 것이 아닌,

별도의 규칙을 통해 부여되는 것임을 유추해볼 수 있습니다.

Q. 그런데요…id는 고유한 게 생명 아닌가요?

서버에서 id를 부여해주는 게 아니면 어떻게 고유한 걸 보장하죠??🧐

A. 이를 알아보기 전에 먼저 hash function에 대해 이해하고 있어야 합니다.

hash function을 첨 들어보셨다면?!
hash function에 대한 자세한 설명은 아래의 링크를 참고해주세요!
위키피디아 해시함수
hash algorithm

Git은 hash를 이용해 commit의 id를 생성합니다.

그러면 commit id를 생성하는데 필요한 해시 알고리즘은 어떠한 것을 채택하고 있을까요?

Git은 commit id를 생성하는데 필요한 해시 알고리즘으로 SHA-1을 채택하고 있습니다.

commit id가 40자리로 구성되어있는 것을 보고 SHA-1을 사용하고 있다고 유추해볼 수도 있겠습니다.

commit id가 만들어지는 과정을 살펴보면 아래 그림과 같습니다.

SHA-1의 입력으로 들어가는 많은 정보들 중에 한 글자만 바뀌더라도 commit id는 바뀌게 됩니다.

Q. 그럼 hash function을 사용하면 고유한 id라는 게 보장이 되나요?

hash function은 collision이 발생하지 않나요??🧐

맞습니다. 발생할 수 있습니다.

hash function가 무한한 가짓수의 입력값을 받아 유한한 가짓수의 출력 값을 생성하는 경우,

비둘기집 원리(pigeonhole principle)에 의해 해시 충돌은 항상 존재합니다.

비둘기집 원리 :
https://ko.wikipedia.org/wiki/비둘기집_원리

SHA-1의 출력 값은 40자리 수의 16진수 문자열입니다.

SHA-1로 생성 가능한 commit id의 개수는

한 자리 수당 4비트씩 곱하면 4*40 = 160비트 10비트는 대략 1000(정확히는 1024)

그렇다면 SHA-1로 생성 가능한 commit id의 개수는

1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 0000

10의 48승개입니다.

10의 48승이라는 숫자를 조금 더 다가오도록 예시를 들어보면, 달(Moon)은 10의 47승개의 원자로 구성되어있습니다.

같은 commit id를 발견할 확률은 우주에 여러 개의 달(Moon)이 있다고 가정했을 때 이 달 중에서 원자 하나를 무작위로 고른 다음, 다른 달에서 원자하나를 무작위로 골랐을 때 같은 원자를 선택할 가능성과 같습니다.

Q. 그래도 누군가가 악의적으로 commit id를 중복시키기 위해 계속해서 시도한다면요?🧐

A. “이렇게 까지 해야 하나…”

git의 commit id를 중복되게 하기 위해 컴퓨팅 연산에 드는 비용, 시간과

git commit id를 중복되게 만들어서 얻을 수 있는 이익을 비교했을 때 가성비가 0에 수렴하기 때문에

충분한 재원을 가진 누군가가 시도를 하지 않는 이상 시도하기 어렵다고 합니다.

구글에서는 SHA1의 충돌 쌍을 만들어내기 위해 9경 번의 연산을 시도했다고 합니다.

하지만 SHA-1의 충돌 공격에 대해서는 많은 문제가 드러났고,

이미 보안 분야에서는 SHA-1은 거의 퇴출된 상태입니다.

때문에 GitHub에서는 Git contents의 충돌을 감지하고 이에 대한 대응책을 내놓았습니다.

SHA-1 collision detection on GitHub.com

그렇다면

이렇게 중앙 집중형 서버 없이 고유한 ID를 부여받을 수 있는 hash는 또 어디에 사용할 수 있을까요?

바로 블록체인입니다.

비트코인과 같이 블록체인 기술을 사용하는 암호화폐의 거래 과정은 중앙집중형 방식이 아닌, 탈중앙화 된 전자장부에 쓰입니다.

그렇다면 각 블록에 포함된 거래내역(트랜잭션)의 id는 어떻게 부여받을까요?

블록에 포함된 트랜잭션의 id는 중복 없이 고유해야 합니다.

id를 관리하는 서버에서 고유한 트랜잭션의 id를 부여할까요?

만약 id를 서버에서 부여한다면 블록체인의 철학인 탈중앙화와 어긋나는 행위일 것입니다.

따라서 블록체인의 트랜잭션의 id를 부여하는 방식 역시 hash를 이용합니다.

비트코인에서는 transaction의 id를 부여하는 hash algorithm으로 SHA-256을 사용하는 것으로 알려져 있습니다.

자, 여기까지 Git의 commit id가 어떻게 생성되는지 알아보며, 이와 함께 hash function이 또 어느 곳에 사용되었는지 알아보았습니다.

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

참고

• GitHub Blog
• Stack Overflow

OSI7 Layer Model

안녕하세요 :) Noah입니다.

오늘은 TCP와 UDP의 통신방식에 관한 얘기를 나눠볼까 합니다. 인간사회에 여러 가지 규칙이나 규약이 있듯, 컴퓨터 네트워크 분야에도 여러 가지 규약이 있습니다.
이러한 규약을 정하는 기관 중 국제표준화기구(ISO)에서 통신이 일어나는 과정을 단계별로 쉽게 파악하고,

다른 시스템 간의 원활한 통신을 위해 제안한 통신규약인 OSI 7 Layer Model은 위의 그림과 같습니다.

TCP, UDP에 대해 알아보기 전에

4계층에 해당하는 전송계층을 더 자세히 알아보겠습니다.

전송계층에서는 source to destination, end-to-end간 연결을 제공하며,
오류 제어, 흐름 제어, 데이터 순서화 등의 기능을 제공합니다.

여기서 말하는 end-to-end란 단순히 컴퓨터에서 컴퓨터로 만의 전달이 아닌,
송신 컴퓨터의 응용프로그램(프로세스)에서 최종 수신 컴퓨터의 응용프로그램(프로세스)으로의
전달을 의미합니다.

전송계층에서의 주소 표현은 포트 번호를 사용하는데,
포트 번호는 통신 프로세스를 구별하는 번호입니다.

또한, 전송계층에서의 프로토콜 데이터 단위(PDU)는 세그먼트라고 하며,
전송계층에서는 신뢰성 관련 제어기능을 지원할 수도 있고, 안할수도 있습니다.

이제 TCP, UDP에 대해 알아봅시다😎

TCP에 관하여

TCP(Transmission Control Protocol)를 한마디로 정의하자면
신뢰성있는 데이터 통신을 가능하게 해주는 프로토콜입니다.

TCP의 가장 중요한 특징 중 하나는 Connection을 수립하는 과정입니다.

(Connection Establish) 이에 관해서는 3-way-handshake라는 과정이 존재하는데,
이에 관해서는 잠시 후에 살펴보도록 하겠습니다.

다른 특징으로 TCP는 데이터의 순차 전송을 보장하며,
흐름 제어, 혼잡 제어, 오류 감지가 가능하다는 특징을 가지고 있습니다.

TCP 헤더

전송계층에서는 포트 번호로 통신을 합니다.

따라서 TCP header에는 Source port와 destination port가 존재하고,
순차 전송의 신뢰성을 보장하기 위해 Sequence number, Acknowledge number가 존재하고,
flag field는 tcp의 연결을 제어하고, 데이터 관리를 하기 위해 존재합니다.

flag field중 크게 3가지만 먼저 알아보면 SYN은 연결을 요청할 때 쓰이는 flag,
FIN은 연결을 종료할 때 쓰는 flag, ACK는 응답을 잘 받았음을 알려주기 위한 flag입니다.

이에 대한 자세한 내용은 3-way-handshake를 살펴보며 더 자세히 알아보겠습니다.

3-way-handshake

3-way handshake

3-way-handshake란 Connection을 수립하는 과정입니다.

Client에서 Server에 연결을 신청을 할 때 SYN을 1로 설정해 송신을 한 뒤에
Server에서 받으면 요청을 잘 받았다는 의미로 ACK를 1로 설정해 송신합니다.

Connection은 양방향이기 때문에 서버 역시 연결을 요청한다는 의미로 ACK와 함께
SYN을 1로 설정해 송신합니다.
Client도 요청을 잘 받았다는 의미로 ACK를 1로 설정해 다시 송신하면 Connection이 수립됩니다.

Connection이 수립된 이후에 데이터 송수신을 크게 3단계로 보면

1. Client가 데이터를 송신한다.
2. Server에서 잘 수신 했다면 ACK를 송신한다.
3. Client가 대기하다가 ACK를 수신하지 못하면 재전송을 한다.

이러한 일련의 과정을 통해 TCP는 TCP의 장점인 신뢰성 있는 통신을 구현합니다.

4-way-handshake

4-way handshake

Connection이 수립(establish) 되었다면 Connection을 닫는 과정도 필요합니다.

1. Client에서 더 이상 보낼 데이터가 없으면 FIN을 1로 설정하여 Server에게 송신한다.
2. Server에서는 잘 수신 받았다는 의미로 ACK를 1로 설정하여 클라이언트에게 송신한다.
3. Connection을 수립할때와는 다르게 Server쪽에서 아직 보낼 데이터가 남아있을 수도 있기 때문에
   잠시 대기후 Server쪽에서 데이터를 모두 전달했다면 FIN을 1로 설정해 Client 쪽으로 송신한다.
4. Client에서 잘 수신을 받았으면 ACK를 1로 설정해 Server에게 송신하면 상태가 Closed 된다.

이러한 단계를 통해 TCP의 Connection을 Close합니다.

TCP의 단점으로는 매번 Connection을 3-way-handshake로 연결하기 때문에 시간 손실이 발생하고,
조금만 세그먼트를 손실해도 재전송을 한다는 점입니다.

e-mail과 같이 손실이 없어야 하는 데이터의 경우 이러한 과정이 장점이 될 수 있지만
실시간 스트리밍과 같이 손실이 어느정도 발생해도 되는 데이터의 경우에는 비효율적인 통신 방법이 될 수 있다는 점을 주의해야합니다.

UDP에 관하여

UDP(User Datagram Protocol)를 한마디로 정의하면 TCP보다 신뢰성이 떨어지지만 전송 속도가
일반적으로 빠른 프로토콜이라 할 수 있습니다.

Connection을 TCP처럼 수립하지 않고,
비연결 방식으로 통신을 하며 TCP의 주요기능인 순차 전송, 흐름 제어, 혼잡 제어 기능을 제공하지 않으며, Checksum을 통해 최소한의 에러검출을 진행합니다.

주로 데이터의 신뢰성이 중요하지 않을 때 사용됩니다.(ex. 실시간 스트리밍)

UDP 헤더

UDP헤더의 경우 TCP헤더 보다 비교적 단순합니다.

포트 번호로 통신을 하기위한 Source port와 destination port가 존재하고,
에러 검출을 위한 Checksum이 존재합니다.

UDP 통신과정

UDP의 데이터 전송 방식은 Connection이 없으니 확인을 하지 않고,
무조건 데이터를 요청 하면 보내는 방식입니다.

Server는 UDP 관련해 소켓을 열어두고 있어 데이터를 요청 하기만 하면 무조건 받습니다.
또한 Checksum을 이용해 최소한의 오류만을 검증하기 때문에 패킷의 손실이 상대적으로 많습니다.

그렇기에 TCP와 비교하여 신뢰성 있는 데이터의 전송을 보장할 수 없습니다.

또한, 앞서 언급된 Client와 Server는 모두 end-system이며 동시에 host입니다.

TCP와 UDP 비교

TCP와 UDP의 특징을 표로 비교하여 한눈에 쉽게 알아보려 합니다.

표를 통해 전송계층 프로토콜을 선택할 때 TCP, UDP의 특성을 파악하고,
상황에 따라 적절한 프로토콜을 사용해야 한다는 사실을 도출할 수 있습니다.

이외에도 차세대 전송계층 프로토콜로는 SCTP, RSVP 구글에서 개발한 QUIC, 등이 있습니다.

혹시 제가 잘못 알고 있는 부분이 있거나, 오타 혹은 궁금한 점 있으시면 댓글로 알려주시면 감사하겠습니다!!😎

도움을 주신 분

• 명지대 컴퓨터공학과 박현민 교수님

참고

• 우아한 Tech 👨‍🏫 르윈의 TCP UDP

이미지 출처

• OSI 7 Layer Model
• TCP 헤더
• 3-way handshake
• 4-way-handshake
• UDP 헤더
• UDP 통신과정

운영체제가 프로세스별로 메모리를 관리하는 방식을 이해하기 위한 학습의 일환으로 Apple의 과거 Macintosh Operating System의 메모리 관리 모델을 현대 프로세스 메모리 관리 모델과 비교해가며, stack, heap, text, 글로벌 변수 GVAR, BSS의 역할에 대해 정리해보자.

Inside Macintosh: Memory

Classic Mac OS memory management

먼저 오늘 살펴보려고 하는 Apple의 Macintosh System 7.0이다.

이미지 출처 : https://github.com/EG-tech/digipres-posters

Apple은 1980년대에 자체 운영체제인 Macintosh System을 만들었기 때문에 UNIX 계열과는 다른 부분이 있다. 이 때문에 밑에서 볼 Process memory model은 현재 우리가 일반적으로 알고 있는 Unix계열의 process memory model과 다르다.

현재 우리가 사용하고 있는 Mac OS는 2000년대 초반 Classic Mac OS와는 다른 UNIX에 뿌리를 두고있는 운영체제이며, Classic Mac OS는 OS X가 출시 된 이후 WWDC 2002에서 MacOS 9의 모의 장례식을 통해 사라지게 되었다..

Apple developer 사이트에 archive된 도서를 통해 Macitonsh system의 Process memory model을 살펴보도록 해보자
링크: Inside Macintosh: Memory

About Memory

Macintosh Operating System이 시작되면 사용 가능한 RAM을 두개의 섹션으로 나눈다. 두개의 섹션 중 하나는 system partition인데, system partition은 항상 주소 지정이 가능한 가장 낮은 메모리 주소(0번지)에서 시작한다. system partition에는 system heap, global variable들의 집합을 포함한다.

linux와 같은 현대 운영체제에서는 일반적으로 virtual memory를 kernel space와 user space로 나누는데 Macintosh System에서는 이를 system partition과 application partition으로 나누는 것 같네요!

나머지 섹션인 system partition 외부의 모든 메모리는 application이나 기타 software components에 할당할 수 있다.

Macintosh System 7(1991년 출시) 이상부터 사용자가 한번에 여러 application을 열 수 있게되었는데, 과거 Apple에서 application 별로 메모리를 어떻게 관리했었는지 살펴보자.

Apple은 Macintosh System 7부터 가상메모리를 제공하기 시작했으며, 이때부터 협력형 멀티태스킹을 지원하기 시작했다.
참조: https://en.wikipedia.org/wiki/System_7

전술한 바와 같이 system partition 메모리에서 가장 낮은 위치를 차지한다.
application partition은 먼저 메모리의 상단 부분부터 로드 된다.

위 그림에서는 세개의 application이 있는데, application마다 고유한 partition을 가지고 있다. Application1로 표시된 application이 active application이다.

현재 활성화된 애플리케이션을 가리키는 것으로 생각되네요

오른쪽에 있는 라벨들은 system global variables에서 사용하는 system global variable이다.

The System Heap

system partition의 main part는 system heap이다. 일반적으로 system heap은 system resource, system code segement 및 system data structure와 같은 다양한 항목을 로드하는 운영체제 및 기타 system software에서 독점적으로 사용하도록 예약되어 있다. 예를들어 system buffer, queue 등이 system heap에 할당된다.

The System Global Variables

Memory의 가장 낮은 부분은 system global variables(or low-memory system global variables)라고 하는 global variable의 collection이 차지한다.

운영체제는 이러한 global variable을 사용해 운영 환경에 대한 여러 종류의 정보를 유지한다. 예를 들어 operating-system queue의 head에 대한 pointer, menu bar의 높이 등이 있다.

low memory에 위치한 대부분의 global variable은 일반적으로 운영체제, 또는 기타 system software에만 유용한 정보가 포함되어있다.

low memory에 위치한 다른 global variable 현재 application에 대한 정보가 포함되어있다. 예를 들어

• ApplZoneglobal variable에는 현재 활성화 된 application partition의 의 첫번째 바이트의 주소가 저장되어있다.
• ApplLimit global variable에는 현재 활성화 된 application의 힙이 확장할 수 있는 마지막 바이트의 주소가 저장되어있다.
• CurrentA5 global variable에는 현재 활성화 된 application의 global variable과 parameter사이의 경계 주소가 저장되어있다.

이러한 global variable에는 활성화된 application에 대한 정보가 포함되어있기 때문에 운영체제는 context switching이 발생할 때마다 이러한 global variable의 값을 변경한다.

제가 공부했었던 다른 현대 Operating System에서는 ApplZone, ApplLimit, CurrentA5와 같은 메모리 주소공간과 같은 정보들은 프로세스 별로 Process Control Block이라는 자료구조에 담아 kernel에 저장하고 있다가 CPU의 레지스터에(메모리 정보와 같은 경우 현재 page table을 가리키는 레지스터 등)해당 정보들을 복사하는 방식인데, 위의 global variable들이 이와 비슷한 역할을 하는 것으로 보입니다.

일반적으로 low memory에 위치한 global variable들은 read/write하지 않는 것이 좋다. 대부분의 global variable들은 문서화되어있지 않고, 변경할 경우 예측하기 어렵기 때문에 사용하지 않는 것이 좋다. 일반적으로 low memory에 위치한 global variable을 application에서 사용할 가능성이 있는 경우 함수를 호출하여 global variable의 현재 값을 가져올 수 있다.

이 역시 다른 현대 Operating System에서는 kernel의 보호문제로 User mode에서는 kernel space에 접근해야하는 경우 system call을 이용해 접근해야 하는데 Macintosh System에서는 application에서 system call을 사용하지 않고도 system partition의 global variable에 접근할 수 있었나 봅니다.

Organization of Memory in an Application Partition

application이 시작되면 운영체제는 application partition이라는 memory partition을 할당합니다. 해당 partition에는 application code의 필수 segment와 application과 관련된 기타 데이터가 포함된다.

아래의 그림은 applcation partition의 일반적인 구성을 보여준다.

application partition은 세가지의 major part로 나뉜다.

• application stack
• applicaiton heap
• application global variable and A5 world

heap은 application의 low memory끝(ApplZone)에 위치하며 항상 높은 메모리 쪽으로 확장된다.
A5 World는 application partition의 high memory끝에 위치하며 크기가 고정되어있다.

stack은 A5 World의 low memory부터 시작하며 heap의 상단을 향해 아래쪽으로 확장한다.

잠깐 A5 world? 그게 뭘까?

Apple은 Macintosh에 classic 68K 런타임 아키텍쳐를 사용했는데요, 모든 classic 68k application에는 A5 world 메모리 영역이 포함되어있습니다. 즉 메모리 영역을 말하는 것이지요.

A5 world에는 다음과 같은 항목들을 저장합니다.

• application의 global variable
• application의 paramter
• application이 code segment간에 호출할 수 있도록 하는 jump table
• Macintosh의 그래픽 모델인 Quickdraw의 drawing environment의 정보를 저장하고 있는 global variable

결국 일반적으로 알고 있는 프로세스의 메모리 모델에서 데이터 영역에 해당하는 것 같네요!

위 그림에서 볼 수 있듯, 왼쪽에 보이는 것이 Maciontosh System의 프로세스 별 메모리 구조, 오른쪽이 일반적으로 우리가 알고 있는 프로세스의 메모리 구조입니다. Data, Code(Text)영역이 Heap의 밑부분에 위치한 반면 과거 Macintosh System에서는 Stack의 윗부분의 A5 world라는 일반으로 우리가 알고있는 data 영역에 통상적으로 알고있는 process model의 data(GVAR, BSS)에 해당하는 데이터를 저장하고 있습니다.

이에 대해서는 뒤에서 조금 더 살펴봅시다!

통상적인 process memory model에서 데이터 섹션은 GVAR, BSS로 나뉘는데 GVAR에는 초기화된 전역변수, BSS영역에는 초기화되지 않은 전역변수가 저장됩니다.

왜 나눠놓았을까? BSS영역에는 초기화되지 않은 전역변수들이 저장되어 프로그램이 실행될 때 영역을 차지해 BSS영역 변수들이 많아져도 프로그램의 실행 코드 사이즈를 늘리지 않는다는 특징이 있습니다.
참고 : https://ko.wikipedia.org/wiki/.bss

자! 다시 돌아와서

일반적으로 stack과 heap 사이에는 사용되지 않는 메모리 영역(unused memory)이 있다. 이 영역은 application heap에 할당된 공간을 침범하지 않고, stack이 커질 수 있는 공간을 제공한다. 그러나 경우에 따라 application heap 용도로 예약된 공간을 stack이 침범할 수 있는데, 이 경우 heap의 데이터가 손상될 가능성이 매우 높다.

The Application stack

stack은 application partition의 memory영역으로 한쪽 끝은 늘어나거나 줄고, 다른 쪽 끝은 고정된 상태로 유지됩니다. 이는 stack 영역이 항상 LIFO(후입선출)순서로 할당 및 해제됨을 의미한다. 마지막으로 할당된 항목이 항상 가장 먼저 해제된다. 또한 stack의 할당된 영역이 항상 연속적이라는 의미이기도 하며, stack의 맨 위에서만 해제되고 중간에서는 해제되지 않기 때문에 이는 stack에 할당되지 않는 “holes(구멍)“는 없음을 의미한다.

일반적으로 stack은 high memory에서 low memory로 쌓인다. 늘어나거나 줄어드는 stack의 끝은 실제로는 스택이 차지하는 메모리의 하단에 있지만 일반적으로 stack의 상단이라고 한다.

LIFO특성으로 인해 stack은 함수 또는 프로시저 실행과 관련된 메모리 할당에 특히 유용하다. application이 특정 루틴을 호출하면 stack frame에 대한 공간이 stack에 자동으로 할당된다. stack frame에는 루틴의 parameter, local variable 및 반환주소가 포함된다.

위 그림은 함수 호출 중에 stack이 어떻게 확장되고 축소되는지 보여준다. 맨 왼쪽 그림은 함수가 호출되기 직전의 stack을 보여준다. 중간 그림과 맨 오른쪽 그림은 확장된 stack frame과 함수의 결과가 어디에 있게 되는지 보여준다. 함수의 실행이 완료되고 나면 local variable들과 함수 parameter들은 stack에서 pop되며,함수의 결과는 이전 stack의 최상단에 있다.

Pascal과 같은 고급 개발 언어를 사용하는 경우 stack의 동적 메모리 할당은 일반적으로 자동으로 처리되며, 컴파일러는 각 함수 또는 프로시저 호출에 대한 stack frame을 만들고 삭제하는 코드를 생성한다.

The Appliaction heap

application heap은 동적으로 할당되고, 요청시 해제되는 application partition의 memory영역이다. heap은 application의 low memory끝에서 시작하여 memory 위쪽으로 확장된다. heap에는 stack에 할당되지 않은 거의 모든 항목이 포함된다.

예를 들어 application heap에는 현재 memory에 로드된 application의 code segment와 resource가 포함되어있다. heap에는 window records, dialog records, document data와 같이 동적으로 할당된 다른 항목도 포함된다.

여기서 말하는 code segment란 application의 실행 코드를 의미합니다.
참조 : Apple Document Segment Manager

일반적으로 알고있는 process memory model에서는 heap, text섹션을 분리해 놓았는데, 과거 Apple의 Macitosh System은 이를 heap에 포함되어있다고 설명하고 있는게 흥미롭네요

Memory Manager를 직접적(예를들면, NewHandle함수 사용) 혹은 간접적(예를 들어, Memory Manager를 호출하는 NewWindow와 같은 루틴을 사용)으로 호출하여 application의 heap내에 공간을 할당한다.

Heap의 공간은 특정 object에 필요한 모든 크기의 블록으로 할당된다.

Memory Manager는 heap의 블록을 추적하는데 필요한 모든 것을 수행한다. 이러한 작업은 임의의 순서로 발생할 수 있기 떄문에 heap은 일반적으로 stack처럼 질서 정연한 방식으로 확장 및 축소되지 않는다. 대신 application이 실행된 후 한동한 아래의 그림처럼 heap이 할당된 블록과 free block(사용 가능한 블록)으로 단편화(fragmentation)되는 경향이 있다. 이를 Heap fragmentation이라고 한다.

Heap fragmentation이 발생하면 사용가능한 여유공간이 충분하더라도 공간이 요청된 크기보다 작은 블록으로 나뉘어있기 때문에 Memory manager가 특정 크기의 block을 할당하라는 application의 요청을 수행하지 못할 수 있다. 이러한 일이 발생하면 Memory manager는 할당된 블록을 이동하여 필요한 공간을 생성하려고 시도한다. 이 작업(operation)을 Heap compaction이라고 한다.

아래의 그림은 Heap compation 작업을 수행한 heap을 나타낸다.

‘할당된 메모리 블록이 Heap compaction중에 자유롭게 이동할 수 있는 한 Heap compaction은 일반적으로 문제가 되지 않지만 자유롭게 이동할 수 없는 두 가지 상황이 있다. 즉, 재배치 불가능한 블록(nonrelocatable)인 경우와 잠긴(locked) 블록인 경우이다. Heap fragmentation을 최소화하기 위해서는 재배치 불가능한 블록을 드물게 사용해야 하며, 절대적으로 필요한 경우에만 블록을 lock해야한다.

이 방법에 대해서는 범위가 넘어가므로 다루지 않도록 하겠습니다. 더 자세한 내용이 궁금하신 분들은 문서를 참고해주세요!

The Application Global Variables and A5 World

application의 global variable은 application partition의 상단에 위치한 A5 World에 저장된다.

A5 World의 구조는 아래와 같다.

global variable과, jump table크기는 application마다 다를 수 있지만 이러한 각 항목의 크기는 고정되어있다.

application의 global variable은 전술했던 quickdraw global variable 위 또는 아래에 나타날 수 있다. 이 두 항목의 상대적 위치는 linker에 의해 결정된다.

system global variable인 CurrentA5는 현재 application global variable과 application parameter와의 경계를 가리킨다.

application의 jump table에는 application의 각 루틴에 대한 entry가 포함되어있다. 다른 segment의 code에 의해 호출되며, Segment Manager는 jump table을 사용하여 code segment에 의해 호출되는 외부 참조 루틴의 주소를 결정한다.

jump table에 대한 설명

application parameter는 32바이트 메모리이며 이는 운영체제에서 사용하도록 예약되어있다.

Temporary Memory

Macintosh 멀티태스킹 환경에서 각 application은 특정 memory partiton으로 제한된다. (크기는 ‘SIZE’라는 application의 resource에 의해 결정된다.) application heap의 크기에 제한을 두기 때문에 application partition크기에 제한이 있어 application에서 사용하는 buffer 및 기타 리소스가 부족할 수 있다.

위 그림처럼 application의 heap에서 현재 사용 가능한 것 보다 더 많은 memory가 필요한 경우 다른 application에 아직 할당되지 않은 사용가능한 memory를 사용하도록 운영체제에 요청할 수 있다. temporary memory로 알려진 이 memory는 사용 가능한 RAM에서 할당된다. 일반적으로 해당 memory는 application영역의 memory와 인접하지 않다.

temporary memory를 가끔씩만 사용하는 좋은 이유 중 하나는 요청한 temporary memory를 항상 받을 것이라고 가정할 수 없기 때문이다.

Virtual Memory

Macintosh system 7.0이상에서 Maciontosh computer는 virtual memory로 알려진 운영체제의 기능을 활용할 수 있다.

이를 통해 시스템은 사용 가능한 물리적 메모리의 한계를 넘어 확장되는 논리 주소 공간을 가질 수 있다. 운영체제는 사용 가능한 보조 저장소의 일부(즉 하드 디스크의 일부)를 사용하여 주소 공간을 확장해 현재 RAM에 필요하지 않은 응용 프로그램 및 데이터의 일부를 보관한다.

Intel이 80286(1982년 출시) CPU를 통해 가상 메모리 기능을 제공했던 것에 비해 Apple은 9년뒤인 1991년 부터 가상 메모리를 지원하기 시작했네요 👀

Addressing Modes

Macintosh에서 운영체제는 32비트 주소지정, 즉 32비트를 사용하여 메모리 주소를 결정하는 기능을 지원한다. 기존 방식인 24비트 주소지정 방식은 24비트 주소 지정 방식에서 논리 주소 공간의 크기는 16MB이지만 8MB가 I/O, ROM 및 슬롯 공간용으로 예약되어 있으므로 가장 큰 연속 프로그램 주소공간(Contiguous)은 8MB이다. 32비트 방식에서 최대 프로그램 주소 공간은 1GB이다.

Summary

여기까지 Apple의 과거 Process memory model과 현대의 일반적인 Process memory model을 비교해보며, 구조는 약간 다르지만(global variable이 stack의 상단의 A5 World라는 곳에 있는 등) 전체적인 큰 부분에서의 기본적인 컨셉은 같이하고 있었다는 사실을 알 수 있었으며, Unix계열의 Process memory model과 비교해보며 각 Section의 (stack, heap, text, 글로벌 변수 GVAR, BSS)의 역할에 대해 학습할 수 있었습니다.

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

안녕하세요 Noah입니다 :)

오늘은 Gang of Four 소프트웨어 디자인 패턴 중 행위 패턴에 속하는

Observer Pattern 에 대해서 알아보도록 하겠습니다.

iOS에서 Observer Pattern은

Foundation framework의 NotificationCenter, KVO(Key Value Observing), Property Observer, Combine framework의 Publisher, Subscriber 등에서 쓰이는데요,

Combine framework의 Publisher(Observable), Subscriber(Observer)과 Notification Center는 Observer Pattern과 비슷하지만 약간의 차이를 가진 Pub/Sub Pattern을 사용합니다.

이러한 여러 기술들의 기본 구현 철학이 되는 소프트웨어 디자인 패턴인 Observer Pattern에 대해 알아봅시다!!

Observer Pattern

Observer를 그대로 직역하면 감시자 라고 할 수 있겠네요!

이름에서부터 느낌이 오지만 지켜보는 것과 관련 있는 디자인 패턴입니다.

Observer Pattern의 컨셉을 간단하게 GIF로 나타내면 다음과 같은데요

하나 이상의 Observer(감시자) 들이 한 곳, 하나의 Subject를 바라보고 있다가 그곳에서 어떠한 event가 발생하면 Subject를 바라보던 Observer 들이 그에 따른 반응을 하는 패턴입니다.

그림과 같이 Observer Pattern은 Observer 들이 한 곳 하나의 Subject를 바라보고 있는데요,

다시 말해 하나의 Observer 혹은 다수의 Observer들은 하나의 Subject의 event, 상태 변화에 귀 기울이고 있습니다.

이를 통해 Observer Pattern은 one to many 즉, 1 대 다의 의존 관계를 갖는 것을 알 수 있습니다.

우리가 만약 Observer Pattern을 사용하지 않고 Subject의 상태 변화, event를 탐지, 알아차리기 위해서는 일정한 간격의 시간 즉, Time interval을 두고 Subject의 상태를 계속해서 체크해야 할 텐데요,

이러한 방식을 컴퓨터 과학에서는 “Polling”이라고 합니다.

물론 모든 상황에 Polling과 Observer Pattern 중 Observer Pattern만 적용할 수는 없지만,

주기적으로 Subject의 상태를 계속 체크해야 하는 Polling 방식보다 Subject의 상태변화 혹은 event가 있을 때만 Observer에게 알리는 Observer Pattern이 훨씬 효율적일 것입니다.

계속해서 Subject의 상태를 체크해야 하는 경우 Polling은 리소스 낭비로 이어질 수 있겠습니다.

자, 이제 Observer Pattern의 구조를 파헤쳐봅시다.

Observer Pattern의 구조

Observer Pattern의 UML은 위와 같이 생겼습니다.

먼저 Observer 부분부터 보겠습니다.

Observer Protocol(Interface)

먼저 event, 알림을 감지할 Observer Protocol(Interface)을 만들어줍니다.

Observer Protocol은

메소드로 Subject의 event, 알림을 감지했을 때

Observer가 해야 할 일을 담을 update 메소드를 가지고 있습니다.

그러면 이제 이 Protocol을 채택 및 준수하여 각 Observer에서 해야 할 일을

정의한 실제 Observer를 정의해줄 수 있습니다.

다음과 같이 말이죠

ConcreteObserverA, ConcreteObserverB 는

각각 자신이 event, 알림을 감지해야 할 일을 정의한 update() 메소드를 가지고 있기 때문에

Subject의 event, 알림을 감지했을 때는 각 Observer에 맞는 update()메소드가 실행될 것입니다.

여기까지 Swift Code로 작성해보면 다음과 같습니다.

편의상 별도의 동등 비교 연산을 추가하지 않고 === 연산자를 이용해 같은 instance를 가리키는지(point)에 대한 여부로 객체를 비교하기 위해 class로 구현하도록 하겠습니다.

Observer

protocol Observer: AnyObject {
	func update()
}

class ConcreteObserverA: Observer {
	func update() {
		print("ConcreteObserverA: Subject의 state가 변경되었습니다.")
	}
}

class ConcreteObserverB: Observer {
	func update() {
		print("ConcreteObserverB: Subject의 state가 변경되었습니다.")
	}
}

자, 이제 Observer의 관찰의 대상이 되는 Subject를 봐야 하는데요,

Subject

Observer와 Subject의 화살표의 모양을 보면

Subject와 Observer의 관계는 has 관계입니다.

다시 말해, Subject가 Observer를 소유하고 있습니다.

이를 쉽게 그림으로 표현하면 다음과 같습니다.

Subject가 observerCollection에 Observer를 소유하고 있습니다.

이를 더 이해하기 쉽게 참조 관계를 보면 다음과 같습니다.

“Subject가 Observer를 소유한다”라는 개념까지 Swift Code로 작성해보면 다음과 같습니다.

class Subject {
    var observerCollection: [Observer] = []
}

이제 UML을 다시 보겠습니다.

Subject는 3개의 동작(메소드)을 가지고 있습니다.

1. registerObserver(observer)
2. unregisterObserver(observer)
3. notifyObservers()

3개의 메소드의 이름이 되게 직관적이기 때문에 각각의 동작을 유추해볼 수 있는데요,
(이래서 함수명, 메소드 명을 잘 지어야 하나 봅니다..)

registerObserver(observer)

Subject의 observerCollection에 여러 Observer 들을 소유할 수 있게 Observer를 등록해주는 메소드입니다.

unregisterObserver(observer)

observerCollection에 있는 여러 Observer들 중 특정 Observer와 Subject간의 관계를 해제해주는 메소드입니다. 어떻게 보면 구독 취소와도 비슷한 것 같습니다.

notifyObservers()

Observer Pattern의 핵심입니다. 바로 Subject의 event를 알리는 메소드인데요,
Subject가 소유하고 있는 Observer 들의 update메소드를 호출해줍니다.

notifyObservers() 의 메소드 구현 부를 보면

상태변화, event 알림을 감지했을 때 각 Observer에서 해야 할 일을 수행할 수 있도록

observerCollection을 순회하면서

각각의 observer 들의 update() 메소드를 호출해주는 것을 알 수 있습니다.

여기까지 살펴본 Subject를 Swift Code로 작성해보면 다음과 같습니다.

Subject

class Subject {
	var observerCollection = [Observer]()
	
	func registerObserver(observer: Observer) {
		print("Subject: Observer가 등록되었습니다.")
		observerCollection.append(observer)
	}
	
	func unregisterObserver(observer: Observer) {
		print("Subject: Observer가 해제되었습니다.")
		observerCollection = observerCollection.filter { $0 !== observer }
	}
	
	func notifyObservers() {
		print("Subject: Notifying observers...")
		for observer in observerCollection {
			observer.update()
		}
	}
}

Implement

이제 작성한 코드를 구현해 실제로 사용해보도록 하겠습니다.

자, 사용하기에 앞서 우리의 client는 몇 가지 기능을 원한다고 가정을 하고 코드를 사용해보도록 하겠습니다.

1. Subject는 state를 가지고 있다.
2. 어떠한 Business Logic이 실행되면 state를 변화시키고, 이 변화에 대한 알림을 Observer 들에게 알린다.
3. 각각의 Observer 들은 Subject의 알림에 반응한다.

위의 기능을 구현한 코드는 아래와 같습니다.

Implement Observer Pattern

protocol Observer: AnyObject {
	func update()
}

class ConcreteObserverA: Observer {
	func update() {
		print("ConcreteObserverA: Subject의 state가 변경되었습니다.")
	}
}

class ConcreteObserverB: Observer {
	func update() {
		print("ConcreteObserverB: Subject의 state가 변경되었습니다.")
	}
}

class Subject {
	var state: Int = { return Int.random(in: 0...10) }()
	
	var observerCollection = [Observer]()
	
	func registerObserver(observer: Observer) {
		print("Subject: Observer가 등록되었습니다.")
		observerCollection.append(observer)
	}
	
	func unregisterObserver(observer: Observer) {
		print("Subject: Observer가 해제되었습니다.")
		observerCollection = observerCollection.filter { $0 !== observer }
	}
	
	func notifyObservers() {
		print("Subject: Notifying observers...")
		for observer in observerCollection {
			observer.update()
		}
	}
	
	func someBusinessLogic() {
		print("Subject: I'm doing something important.")
		state = Int.random(in: 0...10)
		print("Subject: state가 변경되었습니다. : \(state)")
		notifyObservers()
	}
}

이제 작성된 코드를 이용해 class를 생성하고, observer를 등록하고,
해제하고 Business Logic을 실행토록 해보겠습니다.

let subject = Subject()

let observer1 = ConcreteObserverA()
let observer2 = ConcreteObserverB()

/// Observer 등록
subject.registerObserver(observer: observer1)
subject.registerObserver(observer: observer2)
/// Business Logic 실행
subject.someBusinessLogic()
/// Observer 등록 해제
subject.unregisterObserver(observer: observer2)
/// Business Logic 실행
subject.someBusinessLogic()

출력의 결과는 아래와 같습니다.

Subject: Observer가 등록되었습니다.
Subject: Observer가 등록되었습니다.

Subject: I'm doing something important.
Subject: state가 변경되었습니다. : 10
Subject: Notifying observers...

ConcreteObserverA: Subject의 state가 변경되었습니다.
ConcreteObserverB: Subject의 state가 변경되었습니다.

Subject: Observer가 해제되었습니다.

Subject: I'm doing something important.
Subject: state가 변경되었습니다. : 8
Subject: Notifying observers...

ConcreteObserverA: Subject의 state가 변경되었습니다.

등록, 해제에 따라 someBusinessLogic() 메소드가 실행되었을 때

호출되는 Observer의 update() 메소드가 다른 것을 보니, 잘 적용된 것을 확인할 수 있습니다.

iOS Communication Pattern

여기서부터는 iOS 내용입니다!! 🍎

iOS에서 정보전달을 위한 Communication Pattern에는 크게 두 가지 Option이 있는데요,

1. Delegates & Protocol
2. Notification Center & Observers

가 있습니다.

각각의 특성에 맞게 두 가지 옵션을 사용하는데요,

어떠한 상황에서 사용하는지만 간략하게 살펴보면

Delegates & Protocol은 one to one 1 대 1의 의존관계를 갖는 곳에서 사용하며,

Notification Center & Observers는 one to many 1 대 다의 의존관계를 갖는 곳에서 사용합니다.

자 여기까지 살펴보았으니,

잠깐 Foundation framework의 NotificationCenter를 잠시 살펴볼까요?

Notification Center Apple 공식문서

설명을 보니, 등록된 observer들에게 정보를 broadcast 할 수 있는 notification dispatch 메커니즘이라고 합니다.

마치 우리가 여태 봐왔던 Observer Pattern의 설명을 보는 듯하네요!

자 어떠한 메소드들이 있는지 볼까요?

addObserver , removeObserver 메소드의 설명을 보니

아까 우리가 위에서 봤던 Subject의 registerObserver , unregisterObserver 역할을 하고 있는 것으로 보이네요!!

post 메소드의 설명을 보니

Subject의 notifyObservers 와 같은 역할을 하는 것으로 보입니다.

Subject를 다시 보니 한눈에 더 잘 들어오지 않나요?

자 다음은 Apple의 Document Archive에 있는 NSNotificationCenter 문서의 그림입니다.

이 그림은 Notification Center가 Event Channel의 역할을 하고 있기 때문에 Publish/Subscribe 패턴과
유사하지만 설명 편의상 Observer Pattern과 같이 설명하도록 하겠습니다.

이 그림을 우리가 봤던 Observer Pattern과 같이 생각해보면 다음과 같아질 것입니다.

또한, Observer Pattern은 모델-뷰-컨트롤러(Model-View-controller, MVC) 패러다임과 자주 결합되는데요,

Observer Pattern은 MVC에서 모델과 뷰 사이를 느슨히 연결하기 위해 사용됩니다.

대표적으로 위와 같이 모델에서 일어나는 이벤트를 통보받는 Observer가 뷰의 내용을 바꾸도록 하게 말이죠!!

이렇게 Observe Pattern은 이미 정말 다양한 곳에서 쓰이고 있음을 확인할 수 있습니다.

이외에도 다양한 상황에 맞게, 1 대 다 Communication을 해야 할 때 Observer Pattern을 사용하면 좋을 것 같네요!!

Summary

오늘은 Observer Pattern을 정리해보며 이 개념이 어디에서 쓰이는지 보았습니다.

이번 design pattern 공부를 하며 깨닫게 된 것이 있습니다.

소프트웨어 기술의 기본 구현 철학이 되는 소프트웨어 디자인 패턴과 같은 이론의 기본기를 잘 다져놓으면,

새로운 언어, 프레임워크를 학습할 때 있어 학습의 러닝 커브를 줄일 수 있다는 것을 몸소 깨닫게 되었습니다.

흐름에 압도되기보다 급할수록 더 기술의 기본이 되는 기본기에 집중해야겠습니다.

오늘도 포스팅 봐주셔서 감사합니다!!

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다!😊

이미지 출처

• Observer Pattern UML
• Apple Developer Documentation
• Notification Center Image
• 이외 다른 이미지는 직접 제작하였습니다 :)

참고

• Communication Patterns in Swift
• Observer Pattern

위 세션을 아래의 포스트를 통해 정리해보았습니다. 관심있는 분들은 아래의 링크를 참조해주세요!

Swift 성능 이해하기 struct-class

또한 Value Type이 정말 Stack에만 할당되는지, Heap에 할당되는지 확인해보고 싶어 여러도구를 활용해 Swift코해당 인스턴스가 어디에 할당되는지 분석해보며 확인해보려 합니다.

먼저 Value Type의 객체를 만들 때 사용하는 struct를 하나 생성해보도록 하겠습니다.

struct ValueType {
    var member1: Int
    var member2: Int
}

func test() {
    var valueTypeObject = ValueType(member1: 10, member2: 11)

    withUnsafePointer(to: &valueTypeObject) {
        print("valueTypeObject address: \($0)")
    }
}

test()

test() 메소드를 실행하면 valueTypeObject의 주소가 print됩니다.

valueTypeObject의 현재 주소는 위와 같네요

현재 valueTypeObject의 주소 0x00007ff7bfeff2c0 의 메모리영역을 한번 확인해봅시다!

var valueTypeObject = ValueType(member1: 10, member2: 11)

test() 안에서 ValueType 인스턴스를 생성할 때 멤버변수의 값으로 10, 11을 주었으니,

0x00007ff7bfeff2c0영역에 16진수 0A, 0B가 있는걸로 미루어보아

성공적으로 Value Type Object가 생성된 것을 확인할 수 있습니다.

다음으로는 ReferenceType인스턴스를 만들어보도록 하겠습니다.

struct ValueType {
    var member1: Int
    var member2: Int
}

class ReferenceType {
    var member1: Int
    var member2: Int

    init(member1: Int, member2: Int) {
        self.member1 = member1
        self.member2 = member2
    }
}

func test() {
    var referenceTypeObject = ReferenceType(member1: 9, member2: 3)
    var valueTypeObject = ValueType(member1: 10, member2: 11)

    withUnsafePointer(to: &referenceTypeObject) {
        print("referenceTypeObject address: \($0)")
    }

    withUnsafePointer(to: &valueTypeObject) {
        print("valueTypeObject address: \($0)")
    }
}

test()

한번 실행해보도록 하겠습니다.

referenceTypeObject의 주소인 0x00007ff7bfeff2c8를 확인해보도록 하겠습니다.

확인해보기 전에

ReferenceType은 참조타입이기 때문에,

주소(0x00007ff7bfeff2c8)에 접근하게 되면

referenceTypeObject Instance의 주소(0x000000010922e180) 를 가지고 있을 것입니다.

한번 확인해보도록 하겠습니다.

주소를 입력한 뒤에 메모리 영역을 확인해보면

위에서 언급한 0x000000010922e180 주소가 메모리에 저장되어있는 것을 확인해볼 수 있습니다.

낮은 주소(80)부터 저장되어있는 것으로 미루어보아 리틀 엔디안 방식으로 주소를 저장하고 있는 것 또한 확인해볼 수 있네요!!

자 이제 그럼 해당 주소(0x10922e180)에 접근해보도록 하겠습니다.

var referenceTypeObject = ReferenceType(member1: 9, member2: 3)

valueTypeObject와는 달리 앞에 어떠한 값들이 더 저장되어있지만,

우리가 할당한 멤버 변수 9 , 3이 잘 저장되어있는 것을 확인할 수 있습니다.

프로세스의 메모리 구조는 위와 같습니다.

높은 메모리 주소에 Stack이 위치하며 Stack보다 상대적으로 낮은 메모리주소에 Heap이 위치하는 것을 확인할 수 있습니다.

조심스럽긴 하지만

valueTypeObject 인스턴스의 주소 : 0x7ff7bfeff2b0

referenceTypeObejct 인스턴스의 주소 : 0x10922e180

위의 메모리 구조로 미루어보아 현재 valueTypeObject는 Stack에

referenceTypeObject는 Heap에 저장되었다고 예상해볼 수 있겠습니다.

저는 WWDC 2016 UnderStanding Swift Performance을 보고 난 후에 위의 결과처럼 모든 Value Type은 stack에 모든 Reference Type은 heap에 저장되는 것으로 착각하고 있었습니다.

다음 사례를 살펴보도록 하겠습니다.

import Foundation

struct ValueType {
    var member1: Int
    var member2: Int
}

class ReferenceType {
    var member1: Int
    var member2: Int
    var value: ValueType

    init(member1: Int, member2: Int) {
        self.member1 = member1
        self.member2 = member2
        self.value = ValueType(member1: member1 + 1, member2: member2 + 1)
    }
}

func test() {
    var referenceTypeObject = ReferenceType(member1: 9, member2: 3)

    withUnsafePointer(to: &referenceTypeObject) {
        print("referenceTypeObject address: \($0)")
    }

    withUnsafePointer(to: &referenceTypeObject.value) {
        print("ref1.value address: \($0)")
    }
}

test()

위 코드는 ReferenceType이 멤버변수로 ValueType 인스턴스를 소유하고 있는 경우입니다.

마찬가지로 한번 실행을 해보도록하겠습니다.

ReferenceTypeObject 변수는 0x7ff7bfeff2c8에

인스턴스는

에 저장되어있을 것입니다.

인스턴스가 있는 메모리영역 0x10101f740에 접근해보도록 하겠습니다.

var referenceTypeObject = ReferenceType(member1: 9, member2: 3)

우리가 멤버변수로 주입시켜준 9, 3이 들어가있는 것을 확인할 수 있습니다.

이제 referenceObject가 소유하고 있는 Value Type 객체의 주소에 접근해보도록 하겠습니다.

엇

그런데 주소를 보니,

인스턴스가 있는 메모리영역의 시작점 0x10101f740과 불과 32번지(16진수) 밖에 차이나지 않는 곳에

ValueType 인스턴스가 저장되어있네요.

한번 확인해봅시다.

class ReferenceType {
    var member1: Int
    var member2: Int
    var value: ValueType

    init(member1: Int, member2: Int) {
        self.member1 = member1
        self.member2 = member2
        self.value = ValueType(member1: member1 + 1, member2: member2 + 1)
    }
}

var referenceTypeObject = ReferenceType(member1: 9, member2: 3)

ValueType을 생성해줄 때 ReferenceType의 멤버변수보다 1씩 증가하도록 멤버변수를 생성해주었으니,

현재 Value Type인 Object가 heap에 할당되어있는 것을 확인할 수 있습니다.

이를 통해 Value Type이 무조건 Stack에만 할당되는 것이 아님을 확인할 수 있습니다.

상황에 따라 Stack, Heap에 할당되는 것을 알 수 있었습니다.

결국 제가 잘못 알고있었던 것을 다시 한번 확인해볼 수 있었습니다.

사실 WWDC 2016 UnderStanding Swift Performance세션에서도 모든 ValueType이 무조건 Stack에 할당된다고 하지는 않았는데,

struct와 class의 성능의 차이를 보여주는 그래프를 보며 모든 ValueType이 stack에 저장되는 것으로 오해하고 있었습니다.

이번기회를 통해 잘못된 지식을 바로 잡을 수 있었던 것 같습니다.

이외에도 Stack과 Heap메모리에 객체가 할당되는 것을 추정이 아닌, 직접적으로 확인해보고 싶어

현재 SIL과 Memory Instrument를 통해 확인해보고 있습니다만 생각보다 이 과정이 길어지네요..!!

SIL이란 Swift Intermediate Language의 약자로, Swift의 소스 코드를 실행 가능한 바이너리 코드로 바꿀 때,
다른 컴파일러(LLVM)가 취급하기 쉬운 중간표현(Intermediate Representation)으로 변환한 코드를 말합니다. (LLVM IR과는 다릅니다.)
출처 : 우아한형제들 기술블로그

지금 실험해보고 있는 과정을 살짝 보여드리자면 다음과 같습니다ㅎㅎ

SIL 코드를 보며, 할당 동작 한 단계 한 단계 살펴보고 있는데 지식이 없어 시간이 좀 걸리네요 ㅎㅎ ^___^

열심히 연구해보고 결과가 나오는대로 포스트를 업데이트 하도록 하겠습니다!!

감사합니다!!

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

참고

• Value Type은 항상 스택에 저장된다고?
• SIL(Swift Intermediate Language)을 통한 Swift debugging
• apple/swift-sil

들어가며

Advances in UI Data Sources WWDC 세션을 보며 diffable datasource에 대해 알아보도록 하겠습니다 :)

Current State-of-the-Art

기존에는 UITableView 및 UICollectionView 에서 UI data source와 어떻게 상호작용했을까?

UICollectionViewDataSource 구현 예를 보자

위 코드에서는 UICollectionViewDatasource 프로토콜에서 필수(required)로 구현해야하는 두 가지 메서드와 다른 하나의 메서드(optional)가 구현되어있다.

프레임워크는 아래의 두 개의 메서드

optional func numberOfSections(in collectionView: UICollectionView) -> Int

func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int

를 통해 section의 수와 각 section의 item수에 대해 물어본다.

그리고 contents가 렌더링 될 때 cell을 요청한다.

보통 이는 data source는 app 내부의 UICollectionViewDataSource와 같은 프로토콜을 채택한 data controller에 의해 지원된다.

그리고 이 controller는 Core Data와 상호 작용할 수 있고 web service와 상호작용할 수도 있다.

먼저 UI레이어와 data를 가져오기 위한 controller간의 소통방법을 살펴보자

UI레이어가 Controller에 Section에 item이 몇개인지, contents를 렌더링 할 때 cell을 제공하라고 한다.

이 Controller가 응답을 받는 웹 서비스 요청을 가지고 있는 경우에는 조금 더 복잡해진다.

만약 웹 서비스 응답을 통해 data의 변경사항을 알린다면 이 변경사항을 반영하기 위해 UI 레이어를 업데이트하여 변경사항을 반영할 수 있다.

하지만 가끔 업데이트가 잘못되면 이러한 에러를 만날 수 있다.

reloadData() 를 호출하여 문제를 해결할 수도 있다.

collection view의 모든 item을 다시 로드 해야하는 경우 이 메서드를 드물게 호출할 수 있다.
그러면 collection view가 현재 표시된 모든 item(place holder 포함)을 삭제하고, data source 객체의 현재 상태를 기반으로 item을 다시 만든다.
효율성을 위해 collection view에는 visible cell과 supplementary view만 표시된다.
reload한 결과 collection data가 축소되는 경우 collection view는 그에 따라 scroll offset을 조정한다.

item을 insert 및 delete하는 animation block 중간에는 이 메서드를 호출해서는 안된다.
item을 insert 및 delete하면 collection의 data가 자동으로 적절하게 업데이트 된다.

하지만 reloadData()를 호출하면 animation effect가 발생하지 않는다.

이는  사용자 경험을 좋지 않게 만든다.

뭐가 문제일까?

여기서 가장 큰 문제는  data controller(data source 역할을 하는)가 시간이 지남에 따라 변경되는 자신만의 truth(version)를 가지고 있다는 것이다.

그리고 UI역시 자신만의 truth (version)을 가지고 있다.

UI, Data 각각의 truth(version)를 맞추어 주어야하기 때문에 현재의 접근 방식은 오류가 발생하기 쉽다.

UI와 데이터가 각각의 버전을 가지고 있기 때문에 이를 동기화시켜줘야하는 문제가 발생한다.

A New Approach

Diffable Data Source

apply() 메서드는 뭘까?

알아보기에 앞서 Snapshot에 대한 개념을 먼저 알아보자

Snapshots

간단하게 말해 Snapshot은 현재 UI state의 truth(version)이다.

section과 item에 대해 unique identifier가 있으며, IndexPath 대신 identifier를 이용해 update한다.

예제를 통해 이해해보자

FOO, BAR, BIF가 화면에 표시된다고 하자

Controller(data source 역할을 하는)가 변경되면

적용하려는 새로운 Snapshot이 생긴다.

apply 함수를 호출하면 함수의 이름처럼 새로운 Snapshot이 적용된다.

Diffable Data Source는 모든 플랫폼에 걸쳐 4개의 클래스를 제공한다.

iOS, tvOS의 경우 UICollectionViewDiffableDataSource , UITableViewDiffableDataSource 가 있으며

Mac에는 NSCollectionViewDiffableDataSource 가 있다.

그리고 모든 플랫폼에서 공통적으로 사용되는 현재 UI 상태에 대한 책임을 가지고 있는 snapshot 클래스는 NSDiffableDataSourceSnapshot 이다.

예제

이곳 에서 예제 프로젝트를 다운받아 Diffable Data Source가 어떻게 작동 하는지  메커니즘을 학습해보자

다양한 예제를 살펴보며 반복되는 패턴을 찾아보자

총 3개를 살펴볼 예정

변경 혹은 새로운 data set을 전체 data source가 있는 collection view또는 table view에 반영하고 싶을 때마다 snapshot을 생성하기만 하면 된다.

먼저 해당 업데이트 주기에 표시할 item에 대한 configuration으로 해당 snapshot을 채운다.

그 다음 snapshot을 적용해(apply) 변경사항을 UI에 commit한다.

Snapshot 생성, Snapshot 설정, Snapshot apply
이 3단계의 프로세스가 앞으로 계속 반복될 것이니 유의해서 보자

자, 첫번째 예제를 살펴보자

우리가 살펴보려고 하는 예제는 일반적인 검색 UI이다.

searchBar에서 가져온 searchText를 이용해 performQuery  메소드를 호출한다.

func performQuery(with filter: String?) {
        let mountains = mountainsController.filteredMountains(with: filter).sorted { $0.name < $1.name }

        var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>()
        snapshot.appendSections([.main])
        snapshot.appendItems(mountains)
        self.dataSource.apply(snapshot, animatingDifferences: true)
    }

performQuery 메소드 자체는 매우 간단하다.

하는 일은 MountainsController에 와 일치하는 Mountain의 필터링 + 정렬된 목록을 요청하는 것이다.

여기서 MontainsController는 model layer객체입니다.

호출의 결과로 mountain list를 얻게된다.

앞서 말한 것 처럼 Snapshot을 적용하기 위해 3단계의 프로세스를 거친다.

먼저 새로운 NSDiffableDataSourceSnapshot을 만든다.

var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>()

이 snapshot은 처음에는 비어있다. 따라서 원하는 Section과 item으로 채워보자

enum Section: CaseIterable {
	case main
}

var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>()
snapshot.appendSections([.main])

Section을 추가하고, 임의로 이를 main section이라고 해보자

Section에 대한 부분은 뒤에서 좀 더 자세히 다루도록 하겠습니다.

let mountains = mountainsController.filteredMountains(with: filter).sorted { $0.name < $1.name }

var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>()
snapshot.appendSections([.main])
snapshot.appendItems(mountains)

다음으로 update에 표시하려는 item의 identifier(mountiains)를 추가한다.

appendItems의 시그니처를 보면 알 수 있듯 appendItems 메소드에는 identifier 배열을 전달한다.

Hashable과 같은 프로토콜을 채택한 객체를 전달할 수도 있습니다.

snapshot을 구성했으니, 이제 DiffableDataSource를 호출하고 snapshot을 적용하도록 요청해보자

let mountains = mountainsController.filteredMountains(with: filter).sorted { $0.name < $1.name }

var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>()
snapshot.appendSections([.main])
snapshot.appendItems(mountains)
self.dataSource.apply(snapshot, animatingDifferences: true)

apply를 호출하면 사용자가 입력하기전에 이전 업데이트 주기에서 표시한 내용에 대해 파악해야하는 코드를 작성할 필요없이 이전 업데이트와 다음 업데이트 사이의 변경된 사항을 파악한다.

IndexPath와 같이 깨지기 쉽고 일시적인 것을 다루는 것이 아닌, identifier를 다룬다.

NSDiffableDataSourceSnapshot 에 대해 조금 더 살펴봅시다.

NSDiffableDataSourceSnapshot<SectionIdentifierType, ItemIdentifierType> 은 Generic class이기 때문에 SectionIdentifierType 및 ItemIdentifierType 에 의해 parameterized된다.

enum Section: CaseIterable {
	case main
}

먼저 snapshot을 만들 때 사용한 SectionIdentifierType 을 살펴보자

var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>()

Swift의 enum type은 Hashable이기 때문에 SectionIdentifierType 에 enum type을 전달할 수 있다.

이제 ItemIdentifierType 으로 사용한 Mountain type에 대해 살펴보자

class MountainsController {
    struct Mountain: Hashable {
        let name: String
        let height: Int
        let identifier = UUID()
        
        func hash(into hasher: inout Hasher) {
            hasher.combine(identifier)
        }
        
        static func == (lhs: Mountain, rhs: Mountain) -> Bool {
            return lhs.identifier == rhs.identifier
        }
        
        func contains(_ filter: String?) -> Bool {
            guard let filterText = filter else { return true }
            if filterText.isEmpty { return true }
            let lowercasedFilter = filterText.lowercased()
            return name.lowercased().contains(lowercasedFilter)
        }
    }
    
    func filteredMountains(with filter: String?=nil, limit: Int?=nil) -> [Mountain] {
        let filtered = mountains.filter { $0.contains(filter) }
        if let limit = limit {
            return Array(filtered.prefix(through: limit))
        } else {
            return filtered
        }
    }
    
    private lazy var mountains: [Mountain] = {
        return generateMountains()
    }()
}

Mountain struct는 DiffableDataSource와 함께 사용할 수 있도록 Hashable 프로토콜을 채택했다.

그리고 DiffableDataSourceSnapshot의 IdenfitierType으로 사용하기 위한 중요한 요구사항은 각 Mountain이 hash 값으로 고유하게 식별될 수 있어야 한다는 것이다.

그래서 각 Mountain에 고유한 identifier를 부여함으로써 이를 달성했다.

또, identifier의 hash 값은  DiffableDataSource가 다음 업데이트에 무엇을 업데이트 해야하는지 알 수 있도록 고유하게 만들어야한다.

다시 돌아와서 DiffableDataSource에 대한 변경 사항을 발행하는 방법을 살펴보자

예제에서 data source를 구성하는 configureDataSource라는 함수를 살펴보자

collection view로 작업을 하고 있기 때문에 UICollectionViewDiffableDataSource 를 인스턴스화 한다.

다음으로 UICollectionViewDiffablaDataSource 가 Generic class이기 때문에 section 및 item type으로 parameterize한다.

self.dataSource = UICollectionViewDiffableDataSource<Section, MountainsControlelr.Mountain>(collectionView: self.mountainsCollectionView)

위와 같이 data source를 연결하려고 하는 Collection View에 대한 참조를 전달한다.

참조를 전달하면 Diffable DataSource는 해당 포인터를 가져와 해당 CollectionView의 data source로 연결한다.

다음으로 trailing closure 를 전달해야한다.

이 trailing closure는 UICollectionViewDiffableDataSource 의 init에서 확인할 수 있듯 CellProvider에 대해 작성해야한다.

@MainActor public init(collectionView: UICollectionView, cellProvider: @escaping UICollectionViewDiffableDataSource<SectionIdentifierType, ItemIdentifierType>.CellProvider)

public typealias CellProvider = (_ collectionView: UICollectionView, _ indexPath: IndexPath, _ itemIdentifier: ItemIdentifierType) -> UICollectionViewCell?

이곳에 작성할 코드는 data source를 구현하는 경우 일반적으로 cellForItemAtIndexPath 를 구현할 때의 내용과 같다.

Collection View를 호출하고, 원하는 데이터를 표시할 적절한 type의 cell을 요청한다.

그리고 그 cell을  보여주고 싶은 내용으로 채운 다음 다시 반환한다.

따라서 방금 작성한 코드는 cellForItemAtIndexPath 코드를 data source를 인스턴스화 할 때 전달하는 closure로 이식한 것과 같다.

위 방식을 사용하면 해당 IndexPath를 이용해 Model layer에 있는 객체를 찾을 필요가 없다.

Collection View를 설정하고 구성하는 방법에 대한 다른 모든 것은 이전과 동일하다.

다른 예를 살펴보자

이번예제는 iOS 설정 앱의 Wi-Fi 설정 UI예제이다.

이 예제는 섹션이 두개로 나뉘어져있다는 특징을 가지고 있다.

상단에는 Wi-Fi 활성화 / 비활성화 스위치, 현재 연결된 현재 네트워크에 대한 정보가 있는 섹션이 있고,

감지된 네트워크 리스트를 보여주는 (동적으로 업데이트 되는) 또 다른 섹션이 있다.

Wi-Fi비활성화 스위치를 tap하거나 다시 tap하면  아래와 같이 애니메이션이 적용된다.

이러한 동적 UI를 어떻게 구현하는지 살펴보자

먼저 (예제)의  WiFiSettingsViewController의 updateUI 함수를 살펴보자

    /// - Tag: WiFiUpdate
    func updateUI(animated: Bool = true) {
        guard let controller = self.wifiController else { return }

        let configItems = self.configurationItems.filter { ($0.type == .currentNetwork && (controller.wifiEnabled == false)) == false }

        self.currentSnapshot = NSDiffableDataSourceSnapshot<Section, Item>()

        self.currentSnapshot.appendSections([.config])
        self.currentSnapshot.appendItems(configItems, toSection: .config)

        if controller.wifiEnabled {
            let sortedNetworks = controller.availableNetworks.sorted { $0.name < $1.name }
            let networkItems = sortedNetworks.map { Item(network: $0) }
            self.currentSnapshot.appendSections([.networks])
            self.currentSnapshot.appendItems(networkItems, toSection: .networks)
        }

        self.dataSource.apply(self.currentSnapshot, animatingDifferences: animated)
    }

표시해야할 내용이 변경될 때 마다 이 함수가 호출되도록 되어있다.

위에서 살펴본 3단계 프로세스와 동일하다.

self.currentSnapshot = NSDiffableDataSourceSnapshot<Section, Item>()

먼저 snapshot을 생성한다.

snapshot을 보여주려고 하는 내용으로 채워보자

enum Section: CaseIterable {
	case config, networks
}

먼저 Section을 만들고, 맨 위에 표시되는 첫번째 섹션인 config 섹션을 추가하자

func updateUI(animated: Bool = true) {
	guard let controller = self.wifiController else { return }

	let configItems = self.configurationItems.filter { ($0.type == .currentNetwork && (controller.wifiEnabled == false)) == false }

	self.currentSnapshot = NSDiffableDataSourceSnapshot<Section, Item>()

	self.currentSnapshot.appendSections([.config])
    self.currentSnapshot.appendItems(configItems, toSection: .config)
}

그리고 config section에 item을 추가한다.

이제 Wi-Fi가 활성화되면 Model layer와 통신하여 사용가능한 네트워크의 리스트를 받아온다.

func updateUI(animated: Bool = true) {
	guard let controller = self.wifiController else { return }

	let configItems = self.configurationItems.filter { ($0.type == .currentNetwork && (controller.wifiEnabled == false)) == false }

	self.currentSnapshot = NSDiffableDataSourceSnapshot<Section, Item>()

	self.currentSnapshot.appendSections([.config])
    self.currentSnapshot.appendItems(configItems, toSection: .config)
    
    if controller.wifiEnabled {
            let sortedNetworks = controller.availableNetworks.sorted { $0.name < $1.name }
            let networkItems = sortedNetworks.map { Item(network: $0) }
            self.currentSnapshot.appendSections([.networks])
            self.currentSnapshot.appendItems(networkItems, toSection: .networks)
        }
}

그리고 잠시 후에 살펴볼 Item type으로 해당 list를 wrapping한다.

let networkItems = sortedNetworks.map { Item(network: $0) }

해당 network list에 대해 section을 추가하고, section에 item을 추가한다.

두 개의 서로 다른 section이 있기 때문에 각 Item set을 추가하는 section을 위와 같이 명시할 수 있다.

이제 Diffable DataSource에 이러한 변경 사항을 적용하도록 요청하고, 선택적으로 difference에 대해 animation을 적용할 수 있다.

예를 들어 UI를 처음 불러오고 초기 데이터 set을 표시할 때 animation적용을 원할 수도 있고, 원하지 않을 수도 있다.

self.dataSource.apply(self.currentSnapshot, animatingDifferences: animated)

따라서 위와 같이 옵션을 줄 수 있다.

이 세션에서는 enum type이 Hashable이기 때문에 Section을 enum으로 정의해 사용하는 것을 권장하고 있다.

자 이제 위에서 살펴보기로 했던 Item struct를 살펴보자

enum ItemType {
	case wifiEnabled, currentNetwork, availableNetwork
}

struct Item: Hashable {
	let title: String
    let type: ItemType
    let network: WiFiController.Network?

	init(title: String, type: ItemType) {
    	self.title = title
        self.type = type
        self.network = nil
        self.identifier = UUID()
	}
    
    init(network: WiFiController.Network) {
    	self.title = network.name
        self.type = .availableNetwork
        self.network = network
        self.identifier = network.identifier
	}
    var isConfig: Bool {
    let configItems: [ItemType] = [.currentNetwork, .wifiEnabled]
    return configItems.contains(type)
	}
    
    var isNetwork: Bool {
    	return type == .availableNetwork
	}

	private let identifier: UUID
    
    func hash(into hasher: inout Hasher) {
    	hasher.combine(self.identifier)
	}
}

Mountain 구조체와 마찬가지로 Hashable 프로토콜을 채택하고 있다.

이 type을 선언하는 이유는 list를 볼 때 대부분 네트워크 item인 list를 포함하기 때문이다.

하지만 그 외에도 맨 위에 Wi-Fi 활성화/비활성화 스위치를 포함하고 있다.

이는 network item이 아닌, Configuration item이다.

여기서 우리가 해야하는 일은 Item이라는 generic wrapper type에 각 item을 캡슐화 하는 것이다. 그러나 wrapper type은 Diffable Data Source를 전달할 Item type이므로 Hashable을 채택하고, Item이 Hash 값으로 고유하게 식별되는지 확인해야한다.

따라서 network item의 경우 아래와 같이 network list에서 identifier를 가져와 사용할 수 있다.

init(network: WiFiController.Network) {
	self.title = network.name
    self.type = .availableNetwork
    self.network = network
    self.identifier = network.identifier
}

config item의 경우 UUID를 아래와 같이 동적으로 생성한다.

init(title: String, type: ItemType) {
	self.title = title
    self.type = type
    self.network = nil
    self.identifier = UUID()
}

func hash(into hasher: inout Hasher) {
	hasher.combine(self.identifier)
}

Item type의 인스턴스 메소드 hash를 보면 identifier를 기반으로 hash 값을 계산한다.

이것이 Diffable Data Source가 한 업데이트 주기에서 다음 주기까지 동일한 item을 식별할 수 있는데 필요한 전부이다.

DataSource를 configure하는 함수인 configureDataSource 함수를 살펴보자

func configureDataSource() {
        self.wifiController = WiFiController { [weak self] (controller: WiFiController) in
            guard let self = self else { return }
            self.updateUI()
        }

        self.dataSource = UITableViewDiffableDataSource
        <Section, Item>(tableView: self.tableView) { [weak self]
                (tableView: UITableView, indexPath: IndexPath, item: Item) -> UITableViewCell? in
            guard let self = self, let wifiController = self.wifiController else { return nil }

            let cell = tableView.dequeueReusableCell(
                withIdentifier: WiFiSettingsViewController.reuseIdentifier,
                for: indexPath)
            
            var content = cell.defaultContentConfiguration()
            // network cell
            if item.isNetwork {
                content.text = item.title
                cell.accessoryType = .detailDisclosureButton
                cell.accessoryView = nil

            // configuration cells
            } else if item.isConfig {
                content.text = item.title
                if item.type == .wifiEnabled {
                    let enableWifiSwitch = UISwitch()
                    enableWifiSwitch.isOn = wifiController.wifiEnabled
                    enableWifiSwitch.addTarget(self, action: #selector(self.toggleWifi(_:)), for: .touchUpInside)
                    cell.accessoryView = enableWifiSwitch
                } else {
                    cell.accessoryView = nil
                    cell.accessoryType = .detailDisclosureButton
                }
            } else {
                fatalError("Unknown item type!")
            }
            cell.contentConfiguration = content
            return cell
        }
        self.dataSource.defaultRowAnimation = .fade

        self.wifiController.scanForNetworks = true
    }

이전 예제와는 다르게 UITableView로 작업하고 있다.

Snapshot 생성 및 commit의 관점에서 볼 때 API는 매우 유사하기 때문에 CollectionView, TableView의 여부가 이 예제에서는 중요하지는 않은 것 같다.

self.dataSource = UITableViewDiffableDataSource
            <Section, Item>(tableView: self.tableView)

UITableViewDiffableDataSource역시  Generic class 이기 때문에 Section, Item으로 해당 클래스 이름을 parameterized 한다.

그리고 tableView에 대한 참조를 전달하면 방금 생성한 Diffable DataSource가 연결된다.

그 다음 cell provider인 trailing closure를 살펴보자

언뜻 보기에 복잡해 보이지만 다양한 type의 item이 있기 때문에 그렇게 보일 뿐이다.

이 예제에서는 세 가지 type의 item이 있으며 서로 다르게 처리하고 있다.

 self.dataSource = UITableViewDiffableDataSource
        <Section, Item>(tableView: self.tableView) { [weak self]
                (tableView: UITableView, indexPath: IndexPath, item: Item) -> UITableViewCell? in
            guard let self = self, let wifiController = self.wifiController else { return nil }

            let cell = tableView.dequeueReusableCell(
                withIdentifier: WiFiSettingsViewController.reuseIdentifier,
                for: indexPath)
            
            var content = cell.defaultContentConfiguration()
            // network cell
            if item.isNetwork {
                content.text = item.title
                cell.accessoryType = .detailDisclosureButton
                cell.accessoryView = nil

            // configuration cells
            } else if item.isConfig {
                content.text = item.title
                if item.type == .wifiEnabled {
                    let enableWifiSwitch = UISwitch()
                    enableWifiSwitch.isOn = wifiController.wifiEnabled
                    enableWifiSwitch.addTarget(self, action: #selector(self.toggleWifi(_:)), for: .touchUpInside)
                    cell.accessoryView = enableWifiSwitch
                } else {
                    cell.accessoryView = nil
                    cell.accessoryType = .detailDisclosureButton
                }
            } else {
                fatalError("Unknown item type!")
            }
            cell.contentConfiguration = content
            return cell
        }

마지막 예제를 보자

예제를 통해 점점 반복되는 패턴이 보이는 것을 확인할 수 있다.

마지막 예제는 색상(Color) 견본이 표시되는 item을 표시하는 UICollectionView이다.

처음에는 random 순서로 색상이 지정된다.

sort button을 tap하면 스펙트럼 순서로 삽입 정렬이 진행 된다.

위 예제는 update를 config하고 commit하는 방식이 다른 예제와 살짝 다르다.

구체적으로 snapshot을 불러오는 부분이 다르다.

먼저 (예제)의  InsertionSortViewController 를 살펴보자

먼저 performSortStep 함수를 살펴보자

이번에도 위에서 진행했던 3단계의 cycle을 가지고 있다.

이번에도 snapshot을 생성하고, 채운 다음 적용한다.

    /// - Tag: InsertionSortStep
    func performSortStep() {
        if self.isSorting == false {
            return
        }

        var sectionCountNeedingSort = 0

        // Get the current state of the UI from the data source.
        var updatedSnapshot = self.dataSource.snapshot()

        // For each section, if needed, step through and perform the next sorting step.
        updatedSnapshot.sectionIdentifiers.forEach {
            let section = $0
            if section.isSorted == false {

                // Step the sort algorithm.
                section.sortNext()
                let items = section.values

                // Replace the items for this section with the newly sorted items.
                updatedSnapshot.deleteItems(items)
                updatedSnapshot.appendItems(items, toSection: section)

                sectionCountNeedingSort += 1
            }
        }

        var shouldReset = false
        var delay = 125
        if sectionCountNeedingSort > 0 {
            self.dataSource.apply(updatedSnapshot)
        } else {
            delay = 1000
            shouldReset = true
        }
        let bounds = insertionCollectionView.bounds
        DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(delay)) {
            if shouldReset {
                let snapshot = self.randomizedSnapshot(for: bounds)
                self.dataSource.apply(snapshot, animatingDifferences: false)
            }
            self.performSortStep()
        }
    }

그러나 위의 경우 비어있는 새로운 snapshot을 생성하는 대신에

var updatedSnapshot = self.dataSource.snapshot()

Diffable DataSource에 현재 snapshot을 요청하는 기능을 활용한다.

이제 이 snapshot은 UICollectionView 에 표시되는 현재 상태로 snapshot이 미리 채워진다.

따라서 처음부터 다시 시작할 필요가 없고, 해당 상태에서 시작하여 다음 중간 상태를 계산 해낼 수 있다.

다음으로 snapshot을 채우는 부분에서

updatedSnapshot.deleteItems(items)
updatedSnapshot.appendItems(items, toSection: section)

deleteItems , appendItems가 호출되는 것을 볼 수 있다.

Snapshot API를 보면 이러한 종류의 작업을 수행할 때 기존 Snapshot을 수정할 수 있는 다양한 기능이 있음을 알 수 있다.

self.dataSource.apply(updatedSnapshot)

앞서 살펴봤던 방식과 같이 마지막으로 완료되면 해당 snapshot을 Diffable DataSource에 적용하기만 하면된다.

Diffable DataSource를 설정해주는 configureDataSource함수를 보자

self.dataSource = UICollectionViewDiffableDataSource<InsertionSortArray, InsertionSortArray.SortNode>(collectionView: self.insertionCollectionView) {
            (collectionView: UICollectionView, indexPath: IndexPath, sortNode: InsertionSortArray.SortNode) -> UICollectionViewCell? in
            let cell = collectionView.dequeueReusableCell(withReuseIdentifier: InsertionSortViewController.reuseIdentifier, for: indexPath)
            cell.backgroundColor = sortNode.color
            return cell
}

사용중인 type인 Collection View를 지정한 다음 cell provider closure를 작성한다.

이 예제에서는 color만 표시하기 때문에 매우 간단하다.

Considerations

위에서 살펴본 API를 활용하는 방법의 디테일적인 부분에 대해 조금 더 알아보자

앞서 코드예제에서 살펴보았듯 Diffable DataSource는 기본적으로 세 단계를 거친다.

1. Snapshot을 만든다.
2. 필요에 따라 configure한다.
3. apply

따라서 변경사항이 생기면 항상 apply 메서드를 호출해야한다.

Snapshot을 만드는 두가지 방법이 있다.

가장 일반적인 방법은 빈 snapshot을 만들어 Section 및 item에 대한 type으로 snapshot을 구성한다.

두번째 방법은 Color 정렬 예제에서 본 것 처럼 현재 Collection View, Table View의 snapshot을 불러올 수 있다.

이 방법은 아주 작은 것 하나를 수정해야 하는 특정 작업이 발생할 때 유용하다.

let snapshot = self.dataSource.snapshot()

위처럼 코드를 작성하면 snapshot이라는 상수에는 copy(사본)가 저장된다.

따라서 self.dataSource에는 영향을 끼치지 않는다.

또, snapshot의 상태에 대해 알 수 있는 API역시 존재한다.

snapshot을 configure할 때 사용하는 API에서 볼 수 있듯 IndexPath를 사용하지 않는다.

지금까지 item을 추가하고 section을 추가하는 등의 매우 일반적인 패턴의 예제를 보았다.

세번째 함수의 시그니처를 보자

func appendItems(_ identifiers: [ItemIdentifierType], toSection sectionIdentifier: SectionIdentifierType? = nil)

이 함수 시그니처의 경우 sectionIdentifier 에 default parameter가 nil로 지정되어있다. nil로 지정될 경우, 마지막으로 알려진 section에 추가된다.

Identifiers

위에서 살펴보았던 것처럼 Model 데이터를 identifier로 가져올 수 있다는 것을 확인했다.

이를 위해선 Hashable을 채택하고 있어야 하며, 고유해야한다.

DiffableDataSource는 Idenfier를 기반으로 Model을 식별했는데 IndexPath기반의 API에서는 identifier를 어떻게 사용해야할까?

예를 보자

SDK에는 수많은 IndexPath기반의 API가 있다.

+대부분 delegate 메서드에 많이 있다.

따라서 사용자가 콘텐츠와 interaction하고, 항목을 tap하면  delegate메시지 didSelectItemAtIndexPath 가 호출된다.

그렇다면 이 메시지가 불리면 IndexPath를 어떻게 사용해야할까?

이는 새로운 API를 이용해 해결하면 된다.

위 API를 이용하면 Identifier를 IndexPath로 변환하고, IndexPath를 Identifier로 변환할 수 있다.

예제를 보자

이 예제는 indexPath에 해당하는 identifier로 변환하는 예제이다.

위 처럼 IndexPath를 identifier로 변환해 사용할 수 있다.

Performance

Snapshot API에서 diff는 O(N)의 시간복잡도를 가지는 선형 연산이다.

간단히 말해서, item이 많을수록 diff를 찾는 데 더 오래 걸린다.

Main Queue는 사용자 이벤트에 반응해야하기 때문에 가능한 한 항상 자유로워야한다.

많은 수의 item이 있는경우 Background Queue에서 Apply 메서드를 호출하는 것이 안전하다.

Improving app responsiveness | Apple Developer Documentation

Create a more immediate user experience by removing hangs and hitches from your app’s user interface.

Apple Developer Documentation

위 문서를 참고해보자면 Main Queue에서 작업할 때 100ms보다 작업시간이 길어진다면 사용자의 Interaction에 즉각적으로 반응할 수 없기 때문에 Background Queue에서 Apply를 호출하는게 합리적 일 것 같다.

Background Queue에서 Apply를 호출하면, 프레임워크는 diff가 계산되면 메인 큐로 돌아가서 diff의 결과를 적용한다.

Backgrund Queue에서 Apply를 호출하기 위해 이 model을 선택하는 경우 일관성을 유지해야한다.

Background Queue에서 호출했으면 항상 Backround Queue에서 호출해야한다.

Background Queue 또는 Main Queue에서 호출된 결과가 mix and match가 될 수 있기 때문이다.

마무리

이상 Advances in UI Data Source 세션에 대한 정리였습니다.

위에서 살펴본 것처럼 Diffable DataSourec는 Model의 데이터를 CollectionView, TableView로 가져오기 위해 수행해야하는 작업들을 단순화 시킨다는 느낌을 받았습니다.

UI와, data의 sync가 안맞아 발생할 수 있는 문제를 UI를 반영하고 있는 하나의 data source를 둠으로써 해결한다는 점 역시 인상 깊었습니다.

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

WWDC 세션 링크

Advances in UI Data Sources - WWDC19 - Videos - Apple Developer

Use UI Data Sources to simplify updating your table view and collection view items using automatic diffing. High fidelity, quality…

Apple Developer

들어가며

기본에 대해 확실히 짚고 넘어가기 위해 Archive된 문서인 Collection View Basics를 보고, 과거로 돌아가 Collection View의 concept을 이해해보자

Collection View

Collection View는 contents를 화면에 표시하기 위해 다양한 객체와 협력한다.

이 중 일부 객체는 custom 객체이기 때문에 이를 작성해 프레임워크에 알려야한다.

예를 들어 Collection View에 표시할 item 수를 알려주는 data source와 같은 객체를 제공해야한다.

Table View와 마찬가지로 Collection View는 앱의 객체와 협력을 통해 구현되는 data-oriented 객체이다.

코드를 작성하기 위해 Collection View의 작동 방식에 대해 알아보자

A Collection View Is a Collaboration of Objects

Collection view는 data와 data가 화면에 정렬 및 표시되는 방식의 역할을 분리하여 구현할 수 있도록 설계되어있다.

표시할 데이터에 대한 관리는 전적으로 app에 책임이 있지만 시각적인 표현(visual presentation)은 다양한 객체에 의해 관리된다.

아래의 표는1-1에는 UIKit CollectionView 클래스가 나열되어있으며, CollectionView 인터페이스를 구현할 때 수행하는 역할에 따라 클래스를 구성한다.

대부분의 클래스는 서브클래싱 할 필요없이 그대로 사용할 수 있도록 설계되었으므로 일반적으로 매우 적은 코드로 CollectionView를 구현할 수 있다.

제공된 동작(behavior)보다 다양한 동작을 구현하고 싶을 때는 서브클래스를 만들어 해당 동작을 제공할 수 있다.

표의 내용을 하나씩 살펴보자

Top-level containment and management

UICollectionView , UICollectionViewController

UICollectionView 객체는 Collection View의 콘텐츠에 대한 표시 영역(visible area)을 정의한다.

UICollectionView 의 선언부를 보면 알 수 있듯, UICollectionView는 UIScrollView를 상속받아 스크롤 가능한(Scorollable) 영역을 포함할 수 있다.

또한 이 클래스는 layout객체에서 수신한 layout정보를 기반으로 데이터를 표시할 수 있다.

UICollectionViewController 객체는 Collection View에 대한 View Controller level의 관리를 할 수 있다. UICollectionViewController 의 사용이 강제되어있지는 않다.

Content Management

data source 객체는 Collection View와 관련된 가장 중요한 객체이며, 반드시 프레임 워크에 제공해야 하는 객체이다.

data source는 collection view의 contents를 관리하고, 해당 contents를 표시하는 데 필요한 view를 만든다.

data source 객체를 구현하려면 UICollectionViewDataSource protocol 을 준수하는 객체를 만들어야한다.

Collection View delegate 객체를 이용하면 Collection View에서 메시지를 가로채 View의 동작을 custom할 수 있다.

예를 들어 delegate 객체를 사용해서 Collection View에서 item 선택 및 highlighting된 것을 알 수 있다.

delegate 객체를 구현하려면 UICollectionViewDelegate protocol 을 준수하는 객체를 만들어야한다.

data source 객체와 달리 delegate 객체는 선택사항이다.

data source 및 delegate 객체를 구현하는 방법에 대한 자세한 내용은 data source 및 delegate 설계 문서에 있습니다.

iOS 13+

iOS 13 이상 버전부터 사용가능한 이 UICollectionViewDiffableDataSource 역시

UICollectionViewDataSource 의 서브 클래스이다.

이와 관련해서 Adcances in UI Data Sources WWDC 세션을 정리하는 시간을 다음 포스트에서 가져보도록 하겠습니다.

Presentation

Collection View에 표시되는 모든 view는 UICollectionReusableView 클래스의 인스턴스여야한다.

이 클래스는 collection view에서 사용중인 recycling mechanism을 지원한다.

새 view를 만드는 대신 view를 재활용하면 일반적으로 성능(performance)가 향상되며 특히 스크롤과 관련하여 성능이 향상된다.

UICollectionViewCell 객체는 주요 data item에 사용하는 재사용 가능한 view의 특정 타입이다.

UICollectionViewCell class의 선언부를 보면 UICollectionViewCell 이  UICollectionReusableView 의 서브클래스임을 알 수 있다.

Layout

UICollectionViewLayout 의 서브클래스는 layout 객체라고 하며 collection view내에서 cell과 재사용 가능한 view의 위치, 크기, 시각적인 속성을 정의하는 역할을 담당한다.

layout 프로세스 중에 layout 객체는 Collection View에 cell과 reusable view를 표시할 위치와 방법을 알려주는 레이아웃 속성 객체(UICollectionViewLayoutAttributes 클래스의 인스턴스)를 생성한다.

layout 객체는 Collection View내에서 data item이 삽입, 삭제 또는 이동할 때마다 UICollectionViewUpdateItem 클래스의 인스턴스를 수신한다.

이 클래스의 인스턴스를 직접 만들 필요는 없다.

layout  객체에 대한 자세한 내용은 이 문서에 있습니다.

Flow layout

UICollectionViewFlowLayout 클래스는 grid 또는 기타 line-based 레이아웃을 구현하는 데 사용하는 concrete layout객체이다.

이 클래스를 그대로 사용하거나 layout 정보를 동적으로 custom할 수 있는 flow delegate 객체와 함께 사용할 수 있다.

UICollectionView는 iOS6에서 추가된 뷰입니다.
UITableView에서 구현하기 어려웠던 여러 가지 레이아웃 커스터마이징 기능을 제공합니다. 별도로 레이아웃 서브클래스를 만들지 않고 UICollectionViewFlowLayout를 사용하는 것만으로도 기본적인 그리드 레이아웃을 구현할 수 있으며, 좀 더 세밀하게 레이아웃을 제어할 필요가 있을 땐 UICollectionViewLayout의 서브클래스를 만들어 구현하는 것도 가능합니다.

- UICollectionView를 이용한 LINE iOS 대화방 리팩토링 중 -

iOS13+

하지만 시간이 흐름에 따라 점차 복잡한 레이아웃들이 많이 생기게 되었고, Flow layout 으로도 복잡한 레이아웃을 구현하기 어려워짐에 따라 여러 Group을 Composition해서 layout을 구성할 수 있는  Compositional Layout이 등장하게 되었다.

iOS 13 이상 버전 부터 사용가능한 이 UICompositionalLayout 역시 UICollectionViewLayout 의 서브클래스이다.

Collection View의 초기 design이 data와 data가 화면에 정렬 및 표시되는 방식의 역할을 분리하여 design되었기 때문에 layout에 영향을 주는 구현체가 새로 나와도 영향을 주지 않고 확장되는 방식이 흥미로웠습니다.

Figure 1-1  Merging content and layout to create the final presentation

Figure 1-1은 Collection View와 연결된 핵심 객체간의 관계를 보여준다.

Collection View는 data source에서 표시할 cell에 대한 정보를 가져온다.

data source 및 delegate 객체는 앱에서 제공하는 custom 객체이며 cell 선택 및 highlight 표시를 포함해 contents를 관리하는데 사용된다.

layout 객체는 해당 cell이 속한 위치를 결정하고, 해당 정보를 하나 이상의 layout attributes 객체의 형태로 Collection View에 보내는 역할을 한다.

그러면 Collection View가 layout 정보를 실제 cell(및 다른 view)과 병합해 최종 visual presentation을 만든다.

Collection View 인터페이스를 만들 때는 UICollectionView 객체를 만들어야한다.

Collection View를 다른 모든 객체가 나오는 중앙 허브 라고 생각하면 된다.

해당 객체를 추가한 후에는 data source 또는 delegate와 같은 관련 객체를 configuration하기 시작할 수 있다.

모든 configuration은 Collection View 자체를 중심으로 이루어진다.

예를 들어 Collection View 객체를 만들지 않고는, layout 객체를 만들 수 없다.

Reusable Views Improve Performance

Collection View는 view recycling 메커니즘을 사용해 효율성을 높인다.

View가 화면 밖으로 이동하면 View에서 제거되고 삭제되는 대신 reuse queue에 배치된다. 새 contents가 화면에서 스크롤 되면 view가 reuse queue에서 제거되고, 새 contents로 용도가 변경된다.

이러한 recycling 및 reuse를 용이하게 하려면 모든 view가 UICollectionReusableView 의 클래스에서 파생되어야한다.

Collection View는 세 가지 타입의 재사용 가능한 가능한 view를 지원하며, 각 view에는 특정 용도가 있다.

Cell

cell은 Collection View의 주요 contents를 표시한다.

cell의 역할은 data source 객체의 단일 item에 대한 contents를 표시하는 것이다.

각 cell은 필요에 따라 contents를 표시하기 위해 subclass화 할 수 있는 UICollectionViewCell 의 인스턴스여야한다.

cell 객체는 선택 및 highlight 표시 상태 관리를 위한 기능을 제공한다.

cell에 highlight를 적용하려면 code를 작성해야한다.

관련 내용은 이 문서에 있습니다.

Supplementary views

Supplementary view는 Section에 대한 정보를 표시한다.

cell과 마찬가지로 Supplementary view역시 data driven(데이터 기반)이다.

cell과 달리 Supplementary view는 필수가 아니며사용 및 배치는 사용 중인 layout 객체에 의해 제어된다.

예를들어 Flow layout은 Header와 Footer를 Supplementary view로 지원한다.

Decoration view

Decoration view는 layout 객체가 전적으로 소유하며 data source 객체의 데이터에 연결되지 않는 말그대로 시각적인 장식이다.

예를 들어 layout 객체는 Decoration view를 이용해 custom background appearance를 구현할 수 있다.

table view와 달리  collection view는 cell 및 supplementary view에 특정 스타일을 적용하지 않는다. 대신 reusable view class는 사용자가 수정할 수 있는 빈 canvas이기 때문에 예를 들어 작은 view 계층을 작성하거나 이미지를 표시하거나 contents를 동적으로 그리는 데 사용할 수 있다.

data source 객체는 연결된 collection view에서 사용하는 cell 및 supplementary view를 제공할 책임이 있지만 data source 객체는 view를 직접 만들지 않는다.

view를 요청 받으면 data source는 collection view의 메서드를 사용해 원하는 타입의 view를 dequeue한다.

dequeue 프로세스는 reuse queue에서 view를 검색하거나 사용자가 제공한 class, nib 파일 또는 Storyboard를 사용해 새 view를 생성하여 유효한 view를 반환한다.

data source에서 view를 만들고 configuration하는 방법에 대한 자세한 내요은 이 문서에 있습니다.

The Layout Object Controls the Visual Presentation

layout 객체는 Collection View내에서 item 배치 및 시각적 스타일을 결정하는 역할을 한다.

data source 객체가 view와 실제 contents를 제공하지만 layout 객체는 해당 view의 크기, 위치 및 appearance 관련 속성을 결정한다.

이러한 책임의 분리를 통해 app에서 관리하는 data 객체를 변경하지 않고도 layout을 동적으로변경할 수 있다.

Collection View에서 사용하는 layout 프로세스는 app의 나머지 view에서 사용하는 layout 프로세스와 관련이 있지만 별개이다.

이 말은   layout 객체가 수행하는 작업을 부모 view 내에서 자식 view의 위치를 변경하는 데 사용되는 layoutSubViews 메서드와 혼동할 수 있다는 말입니다.
layout 객체는 실제로 해당 view를 소유하지 않기 때문에 관리하는 뷰를 직접 건드리지는 않습니다.

대신 Collection View에서 cell, Supplementary view 및 Decoration view의 위치, 크기 및 시각적 appearance를 설명하는 속성을 생성한다.

그 다음 이러한 속성을 실제 view객체에 적용하는 것은 Collection View의 작업이다.

Figure 1-2  The layout object provides layout metrics

layout 객체는 view의 크기와 위치만 제어하는 것이 아니다.

layout 객체는 transparency, 3D 공간에서의 변형, 다른 view 위 또는 아래의 visibility(있는 경우) 등 기타 view 관련 속성을 지정할 수 있다.

예를 들어 view를 서로 겹쳐서 배치하고 z순서를 변경하여 cell stack을 만들거나 transform을 사용해 원하는 축으로 회전할 수 있다.

layout객체가 Collection View에 대한 책임을 수행하는 방법에 대한 자세한 내용은 이 문서에 있습니다.

Collection Views Initiate Animations Automatically

Collection View는 fundamental level에서 animation을 지원한다.

item 또는 Section을 삽입(또는 삭제)하면 Collection View는 변경사항의 영향을 받는 모든 view에 자동으로 animation을 적용한다.

예를 들어 item을 삽입하면 일반적으로 insert 지점 이후의 item이 새 item을 위한 공간을 확보하기 위해 이동한다.

Collection View는 item의 현재 위치를 감지하고, insert이후 최종 위치를 계산할 수 있기 때문에 이러한 animation을 만들 수 있다.

따라서 각 item의 초기 위치에서 최종 위치까지 animation을 적용할 수 있다.

insert, delete 및 이동 작업에 animation을 적용하는 것 외에도 언제든지 layout을 무효화 하고 layout 속성을 강제로 다시 계산할 수 있다.

layout을 무효화하면 item에 직접 animation이 적용되지는 않으며, layout을 무효화하면 Collection View에서 item에 animation을 적용하지 않고 새로 계산된 위치에 item이 표시된다.

대신 custom layout에서 이 동작을 사용해 cell을 일정한 간격으로 배치하고 animation 효과를 만들 수 있다.

마무리

이상 Collection View Baics에 대한 정리였습니다.

아직 모르는 것이 많고 알아가는 과정입니다. 잘못된 것이 있다면 댓글로 남겨주신다면 감사하겠습니다! 😊

참고

Collection View Basics

Describes the use of collection views in iOS apps.

UICollectionView를 이용한 LINE iOS 대화방 리팩토링 - 1

들어가며 LINE의 대화방 화면은 사용자가 가장 많이&nbsp;사용하는&nbsp;화면 중 하나이며 새로운 기능이 계속 추가되고 있습니다. 그에 따라 코드가 점점 복잡해지면서 최근에 리팩토링을 진행했고, 그 과정에서&nbsp;UICollectionView를 도입했습니다…

LINE ENGINGEERING장병국 / 심재식