라이브 스트리밍 성능 분석 및 개선 과정

소개

안녕하세요. 노머스 모바일팀에서 iOS앱 개발을 맡고 있는 이도연입니다.

fromm의 라이브 스트리밍 서비스가 전면 오픈되었습니다!

이를 위해 많은 아티스트, 팬분들께 더 좋은 경험을 제공하고자 라이브 스트리밍 성능을 최적화하는 작업을 하게 되었습니다.

Xcode Instruments를 활용한 성능 분석 과정과, 어떻게 성능을 개선했는지에 대해 공유드리겠습니다.

라이브 성능 분석 조건

성능을 분석하기 위해 사용자의 다양한 환경을 고려할 필요가 있었습니다. 이를 위해 여러 조건을 가정하였습니다.

1. 일반기기 (iPhone 15 Plus)
2. 저성능 기기(iPhone 13 mini)
3. 저전력 모드
4. 타 앱이 구동되고 있는 환경

조건별 Instruments 분석

Xcode Instruments의 Time Profiler를 이용하여 행을 분석했습니다.

행은 메인 스레드의 응답 속도를 기준으로 다음과 같이 분류됩니다.

응답 시간	설명	행 분류 기준
100ms 미만	일반적으로 즉각적인 속도로 느껴지는 상태입니다.	-
100ms ~ 250ms	상황에 따라 살짝 지연이 느껴질 수 있는 상태입니다.	-
250ms 이상 ~ 500ms 미만	대부분의 툴에서 “Microhang”으로 간주하며, 성능 문제를 판단하는 기준이 됩니다.	Microhang
500ms 이상	사용자가 끊김을 느낄 수 있는 상태로, 정식 행(Full Hang)으로 간주됩니다.	정식 행(Full Hang)

[테스트 1] 일반기기 (iPhone 15 Plus)

• 마이크로행: 1개
• 행: 0개

특별히 문제가 될 만한 행은 잡히지 않았습니다.

[테스트 2] 저성능 기기 + 게임(3D)

• 마이크로행 6개
• 행: 1개

약간 영향이 있는 것으로 보이나 심각한 수준은 아닙니다.

[테스트 3] 저성능 기기 + 저전력 모드

• 마이크로행: 36개
• 행: 2개

행이 급격히 증가했습니다.

[테스트 4] 저성능 기기 + 저전력 모드 + 게임 + 녹화

• 마이크로행: 46개
• 행: 2개

테스트 3과 비슷한 양상을 보였습니다.

분석 결과, 게임/녹화 등 타 앱 동작의 영향보단 저성능 기기 + 저전력 모드 영향이 크다고 판단할 수 있습니다.

결과

테스트 조건	[테스트 1] 일반기기 (iPhone 15 Plus)	[테스트 2] 저성능 기기 + 게임(3D)	[테스트 3] 저성능 기기 + 저전력 모드	[테스트 4] 저성능 기기 + 저전력 모드 + 게임 + 녹화
마이크로 행	1개	6개	36개	46개
행	0개	1개	2개	2개

일반 기기 환경에서는 문제가 될만한 행은 나타나지 않았습니다.

그러나 저성능 기기, 특히 저전력 모드에서는 사용성에 영향을 줄 만큼의 행이 나타났습니다.

특히 두가지 경우가 문제가 될 만 했는데요.

두 개의 500ms 이상의 행과 주기적으로 나타나는 500ms 이하의 다수의 마이크로 행 입니다.

행 분석

500ms 이상의 행 분석

문제가 된 행의 Instruments 타임라인을 확인해보면, 해당 행이 나타나는 시점에 메인 스레드가 활발히 동작하고 있음을 알 수 있습니다.

이 경우에 메인 스레드가 과도하게 바빠져 사용자의 액션에 반응하지 못하는 상황이 발생합니다.

타임 라인의 세 번째 줄은 SwiftUI의 body실행을 추적하는 타임라인입니다.

이를 확인해보면 LiveStreamingHostView의 body 실행 시간이 다른 뷰에 비해 현저히 길다는 점을 확인할 수 있습니다.

이를 근거로 LiveStreamingHostView의 렌더링 시간이 오래 길어지며 메인 스레드의 과부하로 이어졌다고 판단했습니다.

500ms 이하의 마이크로 행 분석

하나의 마이크로 행을 확대하여 분석한 결과입니다.

3번째 타임라인에서는 LiveStreamingHostView가 재평가되는 모습을 확인할 수 있으며, 타임라인 마지막 줄에서는 메인 스레드가 활발하게 동작하고 있음을 볼 수 있습니다.

이를 통해, 주기적으로 발생하는 마이크로 행의 원인은 실행 시간이 오래 걸리는 LiveStreamingHostView가 반복적으로 재평가되기 때문이라는 점을 확인할 수 있었습니다.

해결 방향 결정

Instruments의 타임라인 분석을 통해 LiveStreamingHostView에 문제가 있다는 것을 알아냈습니다.

이를 해결하기 위한 방안은 두 가지로 나눌 수 있습니다.

1. LiveStreamingHostView의 실행 시간을 줄인다.
2. LiveStreamingHostView의 재평가 횟수를 줄인다.

그러나 1번 해결책은 카메라 화면 송출과 같은 라이브 스트리밍의 특성상 기능을 축소하거나 최적화할 수 있는 방법에 한계가 있었습니다.

따라서 2번 해결책을 채택하여 불필요한 재평가 횟수를 줄이는 방향으로 접근했습니다.

문제 발생 원인

뷰의 불필요한 재평가를 줄이려면 뷰를 재평가하는 요인을 찾아 제거해야 합니다.

이에 따라 LiveStreamingHostView가 자주 재평가되는 원인을 파악하기 위해 SwiftUI의 ._printChanges() 메서드를 활용했습니다.

public var body: some View {
    let _ = Self._printChanges()
    ZStack {
    // ...

[결과]

LiveStreamingHostView: @self, @identity, _viewStore, _keyboardResponder changed.
LiveStreamingHostView: \State.recorder changed. // 하위 뷰 State
LiveStreamingHostView: @self, _viewStore changed.
LiveStreamingHostView: \State.recorder changed. // 하위 뷰 State
LiveStreamingHostView: \ValueReference<LiveRecordState, InMemoryKey<LiveRecordState>>.<computed 0x00000001050f9174 (LiveRecordState)>, @self, _viewStore changed.

이를 통해 하위 뷰에서만 영향을 받아야 할 상태 변경에도 상위 뷰가 영향을 받고 있다는 것을 확인했습니다.

원인은 TCA의 Scope

fromm의 라이브 스트리밍 페이지는 SwiftUI + TCA(The Composable Architecture)를 기반으로 구성되어 있습니다.

TCA는 Point-Free에서 개발한 Swift 라이브러리로, 상태 관리와 비즈니스 로직을 모듈화하여 테스트 가능하고 확장 가능한 애플리케이션 아키텍처를 제공합니다.

전체 화면은 LiveStreamingHostView라는 SwiftUI 뷰로 구성되어 있습니다.

그리고 LiveStreamingHostView 내부에 하위 뷰들이 있고 LiveStreamingHostFeature에서 각 하위뷰의 Reducer들을 Scope기능으로 연결하고 있습니다.

하위 뷰의 상태 변화가 상위 뷰에 영향을 미치는 원인은 TCA의 Scope 사용 방식에 있었습니다.

Scope 기능은 TCA에서 매우 강력한 기능으로 상위 뷰와 하위 뷰 간의 자유로운 소통을 가능하게 해주는 등 여러 장점을 제공합니다.

Scope 기능을 사용하려면 하위 뷰의 State를 상위 뷰에서 생성해야 하는데 이 과정에서 문제가 발생했습니다.

fromm에서는 아래와 같이 scope 기능을 이용하고 있습니다.

public struct LiveStreamingHostViewReducer: Reducer {

    // MARK: - State

    @ObservableState
    public struct State: Equatable {

        // MARK: - Sub Reducer

        public var chat: LiveChatViewReducer.State?
        public var control: LiveStreamingControxlViewReducer.State
        public var headerView: LiveStreamingHeaderViewReducer.State
        public var liveRoomState: LiveRoomStatReducer.State?
        public var recorder: LiveStreamingRecorderReducer.State
        public var waitingRoom: LiveStreamingWaitingRoomReducer.State?

이때 하위 뷰의 State가 상위 뷰의 State의 일부로 포함되면서, 하위 뷰의 상태 변경 사항이 상위 뷰로 전파되는 현상이 나타난 것입니다.

이러한 동작은 특정 상황에서는 유용할 수 있지만, 현재 fromm의 라이브 기능에서는 불필요한 상태 변경 전파를 유발하며 의도치 않은 동작을 초래하고 있었습니다.

1. scope 기능을 사용하지 않기

첫 번째 해결책은 Scope기능을 사용하지 않고 각 하위 뷰 컴포넌트에서 Reducer를 생성하는 방법입니다.

하지만 이 방법은 하위 Reducer에서 상위 리듀서로 action을 전달할 경로도 없어지기 때문에 각 컴포넌트들이 밀접하게 action을 주고받아야하는 현재 상황에는 적합하지 않았습니다.

2. scope 기능을 사용하며 상태를 옵저빙하지 않는 방법 찾기

Scope 기능을 사용하면서 상태 변경을 상위뷰로 전파하지 않을 방법을 찾던 중 TCA에서 제공하는 매크로에서 방법을 찾을 수 있었습니다.

TCA의 @ObservableState는 각 State 프로퍼티에 @ObservationStateTracked, @ObservationStateIgnored라는 추가적인 매크로를 생성해주고 있습니다.

이 매크로들은 어떤 역할을 하는지 swift-composable-architecture의 ComposableArchitectureMacros 소스코드에서 해당 매크로의 구현부를 확인해보겠습니다.

@ObservationStateTracked의 구현부를 보면 다음과 같은 코드들을 생성하도록 되어있고,

public struct ObservationStateTrackedMacro: AccessorMacro {
  public static func expansion<
    Context: MacroExpansionContext,
    Declaration: DeclSyntaxProtocol
  >(
    of node: AttributeSyntax,
    providingAccessorsOf declaration: Declaration,
    in context: Context
  ) throws -> [AccessorDeclSyntax] {
        // ...
    let initAccessor: AccessorDeclSyntax =
      """
      @storageRestrictions(initializes: _\(identifier))
      init(initialValue) {
      _\(identifier) = initialValue
      }
      """

    let getAccessor: AccessorDeclSyntax =
      """
      get {
      \(raw: ObservableStateMacro.registrarVariableName).access(self, keyPath: \\.\(identifier))
      return _\(identifier)
      }
      """

    let setAccessor: AccessorDeclSyntax =
      """
      set {
      \(raw: ObservableStateMacro.registrarVariableName).mutate(self, keyPath: \\.\(identifier), &_\(identifier), newValue, _$isIdentityEqual)
      }
      """
    let modifyAccessor: AccessorDeclSyntax = """
      _modify {
        let oldValue = _$observationRegistrar.willModify(self, keyPath: \\.\(identifier), &_\(identifier))
        defer {
          _$observationRegistrar.didModify(self, keyPath: \\.\(identifier), &_\(identifier), oldValue, _$isIdentityEqual)
        }
        yield &_\(identifier)
      }
      """

    return [initAccessor, getAccessor, setAccessor, modifyAccessor]
  }
}

@ObservationStateIgnored는 추가 코드를 생성하지 않도록 구현되어 있습니다.

public struct ObservationStateIgnoredMacro: AccessorMacro {
  public static func expansion<
    Context: MacroExpansionContext,
    Declaration: DeclSyntaxProtocol
  >(
    of node: AttributeSyntax,
    providingAccessorsOf declaration: Declaration,
    in context: Context
  ) throws -> [AccessorDeclSyntax] {
    return []
  }
}

이름에서 알 수 있듯, 이 매크로들은 SwiftUI 업데이트를 위해 상태를 옵저빙하는 역할을 합니다.

그리고 @ObservationStateIgnored는 TCA 옵저빙 시스템에 상태를 등록하지 않음으로써 상태 변화에도 SwiftUI의 body가 재평가되지 않도록 합니다.

@ObservableState는 이미 매크로가 적용된 프로퍼티에 대해 추가적인 매크로를 생성하지 않습니다.

따라서 @ObservationStateIgnored를 명시적으로 추가하면 @ObservationStateTracked가 생성되지 않아 해당 프로퍼티가 옵저빙되지 않도록 설정할 수 있습니다.

개선

현재 상황에서는 상위 Reducer가 하위 Reducer의 State를 옵저빙할 필요가 없기 때문에 @ObservationStateIgnored 매크로를 사용하여 상위뷰가 하위뷰의 State에 영향을 받지 않도록 했습니다.

public struct LiveStreamingHostReducer: Reducer {
    @ObservableState
    public struct State: Equatable {
        // MARK: - Sub Reducers
        @ObservationStateIgnored
        public var chat: LiveChatReducer.State?
        @ObservationStateIgnored
        public var control: LiveStreamingControlReducer.State
        @ObservationStateIgnored
        public var headerView: LiveStreamingHeaderReducer.State
        @ObservationStateIgnored
        public var recorder: LiveStreamingRecorderFeature.State
        
        // ...

결과

개선을 통해 LiveStreamingHostView가 하위 뷰 상태로 인해 재평가되는 횟수를 줄일 수 있었습니다.

또한 상위 뷰의 재평가가 하위 뷰의 재평가로 이어지지 않게 되어, LiveStreamingHostView의 평균 body 실행 시간이 167ms에서 11ms로 93.41% 감소하였습니다.

개선 전

개선 후

이에 따라 행, 마이크로 행 또한 눈에 띄게 줄어든 모습입니다.

개선 전

개선 후

마무리

@ObservationStateIgnored 매크로는 이 외에도 다양한 활용 가능성이 있을 것으로 보입니다.

예를 들면 struct로 구성된 Reducer 특성상 State 외의 데이터를 저장할 방법이 제한적인데요,

이럴 때 @ObservationStateIgnored 매크로를 활용하면, 뷰 성능에 영향을 주지 않으면서 추가 데이터를 저장할 수 있습니다!

이 글이 TCA를 적용 중이신 개발자분들께 조금이나마 도움이 되기를 바랍니다.

읽어주셔서 감사합니다 🙇