iOS에서 viewDidAppear — 것이 뭔지, 호출 시점 및 예제

viewDidAppear이란

viewDidAppear는 View가 창 계층구조에 추가되고 전확 애니메이션이 완전히 완료된 후에 UIKit이 호출하는 UIViewController의 메소드입니다. 이 시점에서 화면은 최종 상태입니다: 보이고, 상호작용이 가능하고, 모든 UIKit 애니메이션이 중지되었습니다. 개발자는 화면이 사용자의 눈 앞에 있음이 보장되어야 하는 작업을 수행하기 위해 이 메소드를 재정의합니다.

화면이 표시를 준비하는 viewWillAppear와 달리, viewDidAppear는 사용자가 이미 인터페이스를 보고 있다는 것을 나타냅니다. 이것이 중요한 차이점입니다: viewWillAppear에서 애니메이션을 시작하면 UIKit이 아직 전확을 처리하고 있기 때문에 프레임 드롭이 발생할 수 있습니다. viewDidAppear에서는 전확이 완료되어 콘트롤러의 자원을 새 컨텐츠 렌더링에 사용할 수 있습니다.

이 메소드는 viewWillAppear와 유사하게 Bool 타입의 animated 파라미터를 받습니다. true인 경우 화면의 나타남이 애니메이션과 함께 수행되었음을 의미합니다. 이 파라미터를 UI 동작을 적응시키는 데 사용할 수 있습니다: 예를 들어, 비애니메이션 되돌아오기 시 입장 애니메이션을 스킵하는 경우등이 있습니다.

viewDidAppear가 호출되는 시점

viewDidAppear는 화면이 나타나는 과정을 완료한 모든 시나리오에서 호출됩니다. iOS 개발자의 관점에서 주요 사례를 살펴보겠습니다.

네비게이션 전확이 완료되면

UINavigationController가 push 또는 pop 애니메이션을 끝낸 후, 대상 컨트롤러에서 viewDidAppear가 호출됩니다. 스택의 첫 번째 화면의 경우 초기 열기 애니메이션 후에 실행됩니다. 이것이 주요 시나리오로, 개발자가 viewDidAppear에 로직을 위치할 때 주로 표적으로 하는 것입니다.

모달을 닫은 후

사용자가 모달로 표시된 컨트롤러를 닫고 이전 컨트롤러로 돌아올 때, UIKit은 돌아오는 컨트롤러에서 viewDidAppear를 호출합니다. animated 파라미터는 dismiss가 애니메이션과 함께 수행되었는지에 따라 달라집니다. 이 순간은 자식 화면으로부터 데이터를 받은 후 UI를 업데이트하는 데 중요합니다.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    logScreenView()
    startOnboardingAnimation()
}

TabBar 탭 전환 시

UITabBarController는 전환 애니메이션이 완료된 후 선택된 탭의 컨트롤러에서 viewDidAppear를 호출합니다. 이것은 전환이 시작될 때 실행되는 viewWillAppear와 다릅니다. 탭에 환영 애니메이션이 있거나 활성 시간을 추적해야 하는 경우, viewDidAppear가 올바른 위치입니다.

백그라운드에서 돌아올 때

앱이 백그라운드에서 포그라운드로 돌아올 때, View의 생명 주기가 일시적으로 중단된 경우 보인는 컨트롤러에서 viewWillAppear와 viewDidAppear가 호출될 수 있습니다. 그러나 백그라운드로부터의 복귀를 신뢰하게 추적하려면 UIApplication.willEnterForegroundNotification을 별도로 사용하세요.

viewDidAppear에서의 실용적 작업

viewDidAppear는 정확한 실행을 위해 보이는 화면이 필요한 작업을 처리합니다. 실제 프로젝트에서 주요 사용 시나리오를 살펴보겠습니다.

분석 이벤트 보내기

viewDidAppear의 가장 일반적인 작업은 화면 뷰 추적입니다. Firebase Analytics, Amplitude 또는 Mixpanel과 같은 분석 시스템은 화면이 사용자에게 실제로 표시된 후에만 이벤트를 수신해야 합니다. viewWillAppear에서 이벤트를 보내면 시청 시간이 저케찌되고 잘못된 트리거가 발생할 수 있습니다.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    Analytics.logEvent(
        name: "screen_view",
        parameters: [
            "screen_name": "ProfileScreen",
            "screen_class": String(describing: self)
        ]
    )
}

입장 애니메이션 시작

화면이 나타난 후에 시작되어야 하는 애니메이션—요소의 단계적 나타남, 패러랙스, 튜토리얼—은 viewDidAppear에서 시작됩니다. 이 시점에서 그래픽 컨텍스트가 완전히 준비되어 애니메이션이 시작부터 프레임 드롭 없이 부드럽게 진행됩니다. 이것은 UIViewPropertyAnimator를 사용하는 애니메이션에 특히 중요합니다.

비동기 로딩 시작

무거운 비동기 작업—고해상도 이미지 로딩, 큰 JSON 파싱, 비디오 초기화—는 viewDidLoad 또는 viewWillAppear보다 viewDidAppear에서 시작하는 것이 더 좋습니다. 메소드가 호출될 때쓰, 사용자는 이미 인터페이스를 보고 있기 때문에 화면 나타남을 지연하지 않고 스켈론 또는 로더를 표시할 수 있습니다.

타이머 및 간격 시작

화면에 주기적 업데이트가 필요한 요소—카운트다운 타이머, 진행 표시기, 진행 애니메이션—가 있는 경우, 이들은 viewDidAppear에서 시작되고 viewDidDisappear에서 중지됩니다. 이를 통해 화면이 보이지 않을 때 타이머가 작동하는 것을 막아 배터리와 CPU 자원을 절약합니다.

컨텐츠 재생 시작

미디어 컨텐츠—비디오, 오디오, Lottie 애니메이션—은 viewDidAppear에서 시작되며, 그 이전에 시작되지 않습니다. viewWillAppear에서 재생을 시작하면 화면이 아직 나타나는 동안 사용자가 첫 덧 초를 농칠 수 있습니다. viewDidAppear에서는 사용자가 첫 프레임부터 컨텐츠를 보고 있다는 확신으로 AVPlayer 또는 Lottie 애니메이션을 시작할 수 있습니다. 이것은 정확한 타이밍이 중요한 온보딩 화면과 스플래시 화면에 특히 중요합니다.

애니메이션과 성능

애니메이션을 시작하는 올바른 시기는 인터페이스의 부드럽기 인식에 직접 영향을 미칩니다. 단순한 애니메이션의 경우 viewWillAppear와 viewDidAppear에서 시작하는 차이가 느껔지지 않을 수 있지만, 복잡한 시나리오에서는 중요해집니다.

UIKit이 화면 간 push 전확을 수행할 때, 스크린샷을 찍고 애니메이트하며 동시에 새 컨트롤러에서 viewWillAppear를 호출합니다. 이 순간에 무거운 애니메이션—패러랙스, 블러, 변환—을 시작하면 UIKit이 전확 애니메이션의 프레임을 드롭하여 떨리는 효과가 발생할 수 있습니다. viewDidAppear는 전확 애니메이션이 완료되었음을 보장하여 렌더링을 완전히 제어할 수 있게 합니다.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)

    UIView.animate(
        withDuration: 0.6,
        delay: 0.3,
        usingSpringWithDamping: 0.8,
        initialSpringVelocity: 0.5
    ) {
        self.cardView.alpha = 1.0
        self.cardView.transform = .identity
    }
}

요소의 자연스러운 캐스케이드 나타남을 만들기 위해 지연과 감쇠를 사용하세요. 이 접근 방식은 인터페이스 인식을 개선하고 체류 시간(dwell time)을 능립니다. 사용자가 컨텐츠 탐색에 더 많은 시간을 보내면 행동 메트릭에 조우적인 영향을 미칩니다.

viewDidAppear에서의 일반적 실수

잘못된 사용 viewDidAppear는 성능 문제, 예기치 않은 애니메이션 동작 그리고 과다한 추적을 초래할 수 있습니다. 일반적인 실수를 살펴보겠습니다.

첫 번째 실수는 여러 번 호출입니다. viewDidAppear는 탭 전환, 백그라운드서 복귀, 모달 전확 등 특정 시나리오에서 여러 번 호출될 수 있습니다. 메소드가 플래그 확인 없이 무거운 작업을 수행하면 중복됩니다. 일회성 작업에는 hasAppeared 플래그 또는 dispatchOnce를 사용하세요.

두 번째 실수는 숨기기 시 취소 없이 네트워크 요청을 시작하는 것입니다. 사용자가 요청 완료 전에 화면을 떠나면 결과가 이미 숨겨진 View에 적용될 수 있습니다. 취소 가능한 URLSessionTask를 사용하고 viewDidDisappear에서 취소하세요.

세 번째 실수는 viewDidAppear 대신 viewWillAppear에서 추적하는 것입니다. 일부 개발자는 viewWillAppear에서 분석 이벤트를 보내지만, 화면이 나타나지 않은 경우(예: 취소된 pop 제스처)에 공수의 트리거가 발생합니다. viewDidAppear는 사용자가 실제로 화면을 보았다는 유일한 신뢰할 수 있는 지표입니다.

넣 번째 실수는 super를 잊는 것입니다. UINavigationController, UITabBarController 그리고 UISplitViewController의 정상 작동에는 super.viewDidAppear 호출가 필요합니다. 이것이 없으면 표준 네비게이션과 UI 업데이트 메카니즘이 고장날 수 있습니다.

다섯 번째 실수는 viewDidLayoutSubviews를 고려하지 않고 화면 방향 또는 크기를 변경하는 것입니다. viewDidAppear에서 애니메이션이 View의 최종 그리기에 의존하는 경우, viewDidLayoutSubviews가 viewDidAppear 전에 여러 번 호출될 수 있다는 것을 기억하세요. 첫 번째 화면 나타남시, viewDidAppear가 호출되기 전에 레이아웃이 완료되지만, 그 후 크기 변경시(예: 장치 회전) viewDidAppear가 호출되지 않아 애니메이션이 시작되지 않을 수 있습니다. 이러한 경우 firstLayout 플래그 확인과 함께 viewDidLayoutSubviews를 사용하세요.

올바른 구현은 애니메이션 객체에 대한 참조를 유지하고 화면을 떠나는 경우 명시적으로 취소하는 것입니다. 여섯 번째 실수는 정지 플래그 없이 무한 애니메이션을 시작하는 것입니다. viewDidAppear에서 반복 애니메이션(예: 검빙이는 표시기 또는 회전 로더)을 시작하지만 viewDidDisappear에서 정지하지 않으면, 화면이 숨겨져도 애니메이션이 GPU 자원을 소모합니다. 항상 활성 애니메이션에 대한 참조를 유지하고 해당 생명 주기 메소드에서 removeAllAnimations 또는 setCompletion을 호출하세요.

일곱 번째 실수는 활동을 중단하기 위해 viewDidDisappear를 무시하는 것입니다. viewDidAppear에서 GPS, 가속도 계 또는 자이로스코프 청청을 시작한 경우, viewDidDisappear에서 반드시 중단하세요. 그렇지 않으면, 사용자가 오래전에 다른 화면으로 이동했더라도 섹서가 백그라운드에섟 계속 작동하며 배터리를 소비합니다. 해당 생명 주기 메소드에서 챥을 이루는 시작 및 정지 호출을 사용하세요. 이를 통해 장치의 자원을 정확하게 관리할 수 있습니다.