티스토리 뷰

반응형

 

init() vs viewDidLoad() in UIViewController

 

왜 갑자기 이런 의문이 들었을까?

UI 라이브러리인 Texture를 학습하며 init과 didLoad에 차이점을 학습한 경험이 있어요.

 

출처: https://texture-kr.gitbook.io/wiki/newbie-guide/node

UIKit에서 UIViewController를 구성할 경우 init은 Main 스레드에서 동작하지만, Texture에서는 init과 didLoad의 차이가 있었어요.

 

어떤 코드의 경우 init에서 초기화를 하는지, didLoad에서 초기화를 하는지에 따라 큰 차이를 낼 수 있었어요. 

예를 들면, UI 같은 경우 갱신을 Main 스레드에서 진행하기 때문에 굳이 init에서 선언하기보다 didLoad에서 선언하는 것이 좋았죠.

 

그래서 작업할 때 초기화 위치에 대한 고민을 많이 했던 것 같아요.

 

그런데 UIKit으로 작업하는 중 viewDidLoad와 init에서도 위와 같은 차이가 존재할지 궁금했어요. 

 

UIViewController의 Life Cycle(생명 주기)

일반적으로 구현하는 ViewController는 UIViewController를 채택하고, 그래서 class로 선언을 해줘요.

class이기 때문에 init을 선언해줄 수 있겠죠?

 

이제 ViewController의 LifeCycle에 대해 알아볼게요.

 

출처: https://zeddios.tistory.com/43

 

UIViewController를 사용하기 위해서는 instantiate 되어야하므로 당연히 init이 시작일 거예요. 그리고 View를 부르는 loadView가 진행되고, 그 이후 View가 load 되었다는 뜻의 ViewDidLoad가 불려지겠죠.

 

이렇게 보면 당연히 다른 위치이므로 기능적으로 차이가 있을 것 같은데요, 그림에서 보는 것처럼 init 시점에는 아직 View가 load되지 않았기 때문에 View의 요소들에 접근하게 되면 에러가 발생해요.

 

예시로 볼게요! 

Label의 text를 viewDidLoad에서 초기화할 경우, 화면이 실행되며 정상적으로 메세지가 출력되는 것을 확인할 수 있어요.

 

 

반면에 init에서 초기화할 경우

 

 

위와 같은 에러가 발생해요.

testLabel이 없는 상태인데 값을 할당하려다보니 문제가 생기는 것이죠!

 

하지만 위의 차이 말고는 ViewController 생성 시 한 번 불린다는 것은 같아요.

 

결론

ViewController를 초기화 하고 싶을 때, 초기화 대상이 View와 연관된 값이라면 반드시 viewDidLoad에서 처리해야 해요.

 

객체를 ByteStream으로 변환하는 작업처럼 특정한 작업이 아니라면 일반적인 경우는 viewDidLoad에서 초기화 작업을 하면 될 것 같아요 :]

 

반응형
댓글