UIViewController LifeCycle

❓ init을 하면 loadView가 불릴까?

 

라는 질문을 최근에 받은 적이 있습니다.

 

처음에 질문을 들었을때는 당연히 불리겠지...? 아닌가 ..??? 하면서 약간 어안이 벙벙이 됐었는데..

생각하다보니 실제로 개발하면서 자주 쓰는 viewDidLoad나 viewWillAppear 같은 메서드 말고는 크게 관심 갖지 않았던 것 같고 

당연히 안다고 생각했던 life cycle에 대해 내가 잘 모르고 있다는 생각이 들엇습니다.

 

기왕 이렇게 된 김에 Life Cycle에 대해 자세히 알아보면서 저 질문에 대한 정답을 찾아보려구 합니다.

 

---

UIViewController / UIView의 관계

Life Cycle! 이라고 하면 평상시 View Life Cycle 이라고 많이 불렀던 것 같은데 

먼저 내가 알아보려고 하는 Life Cycle이 누구의 생애주기인지 딱 정리하고 넘어가겠습니다.

 

요렇게 버튼 두개가 존재하는 화면이 있다고 했을때, Hierarchy를 찍어보면 오른쪽 처럼 나오게 됩니다.

 

흰색 화면 부분을 잡아서 Debug Navigator로 가보면 UIView 라고 당당하게 가리키는 것을 볼 수 있습니다.

또 Constraints도 UIView의 하위에 존재하는 것을 확인 할 수 있습니다.

 

 

정리해보면,

• UIViewController : 화면 전체의 흐름, 전환, 사용자와의 상호작용 관리 (navigation, modal, gesture 등)
• UIView : 화면 안에 보여지는 UI 요소, 레이아웃(Constraints)과 그리기(draw) 담당

요렇게 정리할 수 있고 - 우리가 평상시에 말하던 Life Cycle은 UIViewController의 Life Cycle이라고 정리할 수 있습니다.

 

UIViewContoller의 Life Cycle

UIViewController Life Cycle

일단 Life Cycle을 한 눈에 보면 요렇게 생겼습니다.

그리고 옆에 있는 init / layoutSubviews / draw 는 View에서 호출되는 메서드를 의미합니다.

 

let vc = DetailViewController()
navigationController?.pushViewControllers(vc, animated: true)

 

 

 

위와 같이 뷰컨트롤러를 하나 생성해서 push 하는 코드를 실행시켰을때 호출되는 메서드를 순서대로 따라가보겠습니다.

 

init

객체를 생성하기 위해 호출하는 메서드로,

이때 UIViewController의 객체가 생성되어 메모리에 한자리 차지하게 됩니다.

init 전 / 후

 

loadView

class DetailViewController: UIViewController {
	override func loadView() {
    	// super.loadView()
        view = MyCustomView()
    }
}

• UIViewController가 내부에서 갖는 view를 생성하고 메모리에 올림
• UIViewController의 view가 nil인 경우 loadView() 내부적으로 view에 기본으로 UIView() 생성해서 할당
• 직접 root view를 커스텀한 view로 변경하고 싶은 경우 super.loadView()를 실행시키지 않고 직접 생성 후 할당
• https://developer.apple.com/documentation/uikit/uiviewcontroller/loadview()

요건 아래서 쫌 더 자세히 보겠슴니당

기본 UIView 사용 / MyCustomView로 변경

옹졸한 커스텀 뷰 주입

못생기긴 했지만 Custom View에 사이즈 고정해버리면 아예 뷰컨 자체도 요렇게 작아집니다 !

 

viewDidLoad

• ViewController 안에 View가 생성되어 메모리에 완전히 올라온 뒤 한 번 호출
• 뷰가 메모리에서 해제된 후 다시 메모리에 올라오면 또 다시 호출됨
• 화면 최초 진입시 API 호출이나 addSubview, UI 초기화 작업 담당
  • view가 메모리에 로드된 직후 딱 한 번만 호출됨
  • 아직 화면 상에 보여지진 않지만 root view는 존재하기 때문에 - 보여지기 전에 subview 추가 + 레이아웃 처리 가능
• https://developer.apple.com/documentation/uikit/uiviewcontroller/viewdidload()

 

viewWillAppear

• view가 View Hierarchy* 상에 올라오기 직전에 호출되는 메서드
  • *View Hierarchy에 올라온다는 것은 뷰들이 서로 부모-자식 관계로 연결되어 계층 구조가 잡힌다는 것을 의미합니다.
  • 계층 구조가 잡히면 화면 상에서 확인 가능해짐
• 메모리와 상관없이 화면 상에 보여질 때마다 호출
  • 메모리에는 이미 올라와있는 상태이고, 해당 뷰컨 위로 다른 뷰컨이 push되거나 present되더라도 해당 뷰컨이 메모리 해제되진 않음 -> viewDidLoad는 불리지 않고 viewWillAppear만 반복 호출
• 화면 전환 후에 바로 UI나 데이터 갱신이 필요한 경우 해당 메서드 내부에서 처리
• https://developer.apple.com/documentation/uikit/uiviewcontroller/viewwillappear(_:)

흰 화면의 viewWillAppear, viewDidAppear

 

viewWillLayoutSubViews

• ViewController의 root view가 내부적으로 layoutSubviews를 하기 전에 호출되는 메서드
• view 내부의 subview들이 View Hierarchy에 올라오기 직전 호출되며, 아직 subview들의 frame과 bounds가 확정되지 않은 상태

 

[UIView] layoutSubviews

• view 내부의 subview들의 frame과 bounds를 배치하는 메서드
• UIKit이 Auto Layout 제약 조건에 따라 subview 위치와 크기를 계산할 때 호출됨
• 호출 시점
  • view가 로드될 때 (자동 호출)
  • view 내에서 bounds나 constraints가 변경될 때 (자동 호출)
  • setNeedsLayout() 또는 layoutIfNeeded() 호출할 때 (강제 호출)
    
    • setNeedsLayout : 뷰의 레이아웃 갱신이 필요해! 라고 알리는 역할, 즉시 레이아웃을 변경하지 않고 다음 갱신시에 자동으로 layoutSubviews를 호출하도록 예약
    • layoutIfNeeded : 지금 바로 레이아웃 갱신해! 라고 하는 역할, 즉시 layoutSubviews가 호출됨

 

viewDidLayoutSubviews

• ViewController의 root view가 내부적으로 layoutSubviews를 완료 후 호출되는 메서드

• view 내부의 subviews들이 View Hierarchy에 올라왔기 때문에, subviews들의 frame과 bounds가 확정됨
  • 그치만 아직 눈에 보여지진 않음
  • view 내부 subviews들이 서로서로 계층이 잡힌거고, root view는 아직 View Hierarchy에 올라오지 않음
• 레이아웃 후 후처리나, frame 기반의 UI 업데이트, animation 준비 처리
  • ex) width가 동적인 뷰에 radius를 비율에 따라 적용해야 하는 경우, 계산된 frame 값을 기준으로 적용
• https://developer.apple.com/documentation/uikit/uiviewcontroller/viewdidlayoutsubviews()

 

viewDidAppear

• UIViewController 내의 root view인 view까지 View Hierarchy에 올라온 후 호출되는 메서드
• 메모리에는 당연히 이미 올라가있고, 화면 상에도 보여지는 상태

 

• 화면 진입 후 바로 애니메이션을 실행시키거나 UI 업데이트 액션 등이 보여야 할 때 사용
• https://developer.apple.com/documentation/uikit/uiviewcontroller/viewdidappear(_:)/

 

[UIView] draw(_:)

• UIKit에서 제공하는 Core Graphics 기반의 그리기 함수로, 화면에 UIBezierPath, CGGradient 같은 커스텀 그래픽을 그림
• 호출 시점
  • view가 로드될 때 커스텀 그래픽을 그려야 하는 경우 viewDidAppear에서 (항상 호출 X, 필요에 따라)
  • setNeedsDisplay() 호출될 때
• https://developer.apple.com/documentation/uikit/uiview/draw(_:)

 

 

여기까지 하면 화면이 보여지기 위해 실행되는 메서드 끝 - 이제 화면에서 사라질 차례

// DetailViewController에서
navigationController?.popViewController(animated: true)

 

viewWillDisappear

• ViewController가 화면에서 사라지기 직전에 호출되는 메서드로, 화면 전환 애니메이션 시작 전에 호출
• View Hierarchy에 존재하고, 메모리도 아직 해제되지 않은 상태

• 타이머, 애니메이션 중단, 네트워크 요청 취소, 제스처 정리 등의 작업을 수행
• swipe back 제스처를 시작하면 호출됨
  • 제스처를 중간에 멈춰버리면 다시 viewWillAppear - viewDidAppear 순으로 호출됨
  • -> viewWillDisappear가 호출된다고 해서 해당 뷰컨이 해제됨은 보장할 수 없음

• https://developer.apple.com/documentation/uikit/uiviewcontroller/viewwilldisappear(_:)

 

viewDidDisappear

• 화면 상에서 사라진 후에 호출
• View Hierarchy에서 사라졌지만, 메모리는 해제되기 전의 상태

• NotificationCenter, Observer 등 해제 작업 실행
• https://developer.apple.com/documentation/uikit/uiviewcontroller/viewdiddisappear(_:)/

 

deinit

• ViewController 객체가 ARC에 의해 메모리에서 해제될 때 호출
• ARC (Automatic Reference Counting)
  • Swift, Objective-C에서 메모리를 자동으로 관리하는 시스템
  • 참조 타입인 Class에 대해서 자동으로 참조가 몇개 존재하는지 카운팅하고, 카운트가 0이 되는 순간 ARC에서 deinit 호출

---

loadView 집중해서 보기

init을 하면 loadView가 불린다?

맨 처음 시작이었던 질문으로 돌아가보겠습니다.

❓ init을 하면 loadView가 불릴까?

 

결론부터 말하면 ❌ 입니다.

 

UIViewController의 init과 loadView의 정의를 다시 보면

init은 UIViewController 객체를 생성하는 것이고 loadView는 UIViewController 안의 root view를 생성하는 것입니다.

 

loadView는 root view가 직접적으로 필요해질때 호출되는 lazy 메서드이기 때문에 

단순히 상위 객체인 UIViewController를 생성만 했을때에는 loadView가 호출되지 않습니다.

 

그럼 root view가 필요한 때는 언제일까여 ?

vc.view 와 같이 직접적으로 view를 호출하거나, 화면 전환을 통해 view가 그려져야 하는 경우 UIViewController에서는 view를 필요로 합니다.

// init 호출
let vc = ViewController()

// loadView 호출
view.addSubview(vc.view)

// init + loadview + viewDidLoad + ... 호출
let otherVC = OtherViewController()
navigationController?.pushViewController(otherVC, animated: true)

 

정리해보면 아래와 같은 상황일때 init은 됐지만, loadView는 호출되지 않는다고 할 수 있습니다 🥲

 

• view에 한 번도 접근하지 않은 경우
• push / present / addSubview 되지 않은 경우
• addChild만 하고 view를 계층에 넣지 않은 경우
• init에서 아무 view 접근 코드를 쓰지 않은 경우

ex) 객체만 생성하고 push를 하지 않은 경우 -> init 후에 바로 deinit됨

let vc = DetailViewController()
// navigationController?.pushViewController(vc, animated: true)

class DetailViewController: UIViewController {
    override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: Bundle?) {
        super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
        print("✅ init")
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    override func loadView() {
        view = MyCustomView()
        print("loadView") // ❌
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
		print("viewDidLoad") // ❌
    }
    
    ...
    
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        print("viewDidDisappear") // ❌
    }
    
    deinit {
        print("✅ deinit")
    }
}

/*
✅ init
✅ deinit
*/

위와 같은 코드에서는 root view를 생성하는 loadView()를 아예 타지 않기 때문에 MyCustomView도 당연히 생성되지 않습니다.

 

 

그럼 loadView는 왜 lazy 일까요 ?

1. 불필요한 view loading을 막아서 메모리 절약

 

UI 객체는 init만 하고 즉시 보여지지 않는 경우도 존재하기 때문에 

메모리를 아껴야 하는 모바일 환경에서는 굳이 보이지도 않는데 먼저 메모리에 만들 필요가 없습니다.

그러다보니 진짜로 필요해질 때까지 view 생성을 최대한 늦춰 불필요한 view의 loading을 막는 것이죵

 

2. 스토리보드 / 코드베이스 에서의 뷰 로딩 로직 통합

 

super.loadView()는 내부적으로 view가 없을때 UIView()를 생성해서 할당해주는 메서드입니다.

그렇기 때문에 loadView를 override 했을때 스토리보드 방식과 코드베이스 방식에서의 내부 동작이 약간 다릅니다.

• 스토리보드 방식 : 구성되어있는 nib 객체를 로드
• 코드베이스 방식 : override해서 UIView 주입 또는 커스텀 view 주입

// 코드베이스
override func loadView {
	super.loadView() // view가 없으니까 UIView() 생성해서 할당
}

// 코드베이스 (커스텀 뷰, 메모리 낭비 버전)
override func loadView {
	super.loadView() // view가 없으니까 UIView() 생성해서 할당
	view = CustomView() // 커스텀 뷰로 바꿔치기
}

// 코드베이스 (커스텀 뷰, 메모리 절약 버전)
override func loadView {
	view = CustomView() // 비어있는 view에 커스텀 뷰 생성해서 할당
}

// 스토리보드
override func loadView {
	super.loadView() // 스토리보드에서 생성한 view(nib)를 로드해오기 때문에 view가 있음 -> UIView() 생성해서 할당하지 않음
}

// 스토리보드 (덮어쓰기)
override func loadView {
	view = CustomView() // 스토리보드에서 생성한 view를 덮어쓰기함
}

 

*스토리보드에서는 override를 권장하지 않음.

loadView에서 override 해서 새로운 커스텀 view를 할당해버리면, 스토리보드에서 만들어둔 UI를 덮어버림

요렇게 다 만들어뒀더니 덮어버림..

 

아무튼 그래서 

스토리보드 방식일때랑 코드베이스 방식일때의 view 초기화 흐름을 통일하기 위해

loadView()는 lazy하게 호출되도록 설계되어있습니다.

 

loadView 사용시 주의사항

 

1. 직접 커스텀 view를 넣어주는 경우 super.loadView() 호출을 권장하지 않습니다.

 

안되는건 아님. 그치만 비효율적인 느낌

override func loadView() {
	super.loadView() // view = UIView() 생성된 상태
    // ➡️ OS에서 자체 생성한 UIView 메모리 주소: ObjectIdentifier(0x0000000102709990)
		
    view = MyCustomView()
    // ➡️ 코드로 직접 넣어준 MyCustomView 메모리 주소 : ObjectIdentifier(0x0000000102604b10)
}

 

 

코드베이스를 기준으로 super.loadView() 하는 시점에 내부적으로 UIView()를 생성해서 self.view에 할당을 해주는데

이후에 바로 새로운 커스텀 뷰를 생성해서 넣어주면, 기존에 생성했던 뷰는 메모리에 남아있다가 바로 버려지게 됩니다.

 

즉, 안되는건 아니지만 불필요한 메모리 할당이 생기기 때문에 권장하지 않는다~ 이런 느낌입니다.

 

2. loadView를 override만 하면 안됩니다.

 

왜냐하면 크래시 나버림 !

class ViewController: UIViewController {
    override func loadView() {
//        super.loadView()
//        view = MyCustomView()
        os_signpost(.event, log: log, name: "#0 loadView")
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        os_signpost(.event, log: log, name: "#1 viewDidLoad")
        setUI()
        getCurrentWeather()
    }
}

 

왜 크래시가 나냐며는 

loadView는 view가 nil일때 호출되어서 view에 객체를 할당해주는 역할의 메서드인데

 

위 코드처럼 내부에서 super.loadView()도 안하고 직접 view를 넣어주지도 않아버리면

viewDidLoad에 넘어갔다가 view가 비어있으니 다시 loadView가 호출되고 또 다음에 viewDidLoad가 호출됐는데 또 view가 비어있으니까 또 다시 loadView가 호출되고 .. 

난리난리 나다가 결국 터져버리게 됩니다.

 

당연히 메모리 상에 view도 없음

 

사실 loadView를 override해서 쓸 일이 그다지 많지 않은 것 같아서 몰라도 큰 문제는 없겠지만

호옥시나 직접 커스텀한 뷰를 넣어줘야 할 일이 생긴다면 꼬옥 주의하시길 바랍니당

 

---

결론은 init 한다고 해서 loadView가 불리진 않는다

입니당

 

이제서야 loadView가 뭐하는 녀석인지 정확하게 알게 된 것 같슴다 🥹

 

마지막으로 UIViewController 메모리랑 뷰 계층 관점에서 보는 Life Cycle 보면서 마무리

 

[✅  메모리 관점 / 🟠  뷰 계층 관점]에서 완료 시점