[iphone] -viewWillAppear :와 -viewDidAppear :의 차이점은 무엇입니까?

차이점은 무엇이며 -[UIViewController viewWillAppear:]그리고 -[UIViewController viewDidAppear:]?



답변

일반적으로 이것은 내가하는 일입니다.

1) ViewDidLoad- 뷰와 함께 표시되어야하는 뷰에 컨트롤을 추가 할 때마다 ViewDidLoad 메서드에 넣습니다. 기본적으로이 메소드는 뷰가 메모리에로드 될 때마다 호출됩니다. 예를 들어 뷰가 3 개의 레이블이있는 양식 인 경우 여기에 레이블을 추가합니다. 그러한 형태가 없다면보기는 절대 존재하지 않을 것입니다.

2) ViewWillAppear : ViewWillAppear을 사용하여 양식의 데이터를 업데이트합니다. 따라서 위의 예에서는이 정보를 사용하여 실제로 내 도메인의 데이터를 양식에로드합니다. UIViews 작성은 상당히 비싸므로 ViewWillAppear 메소드에서 가능한 한 많이 피해야합니다.이를 호출하면 iPhone이 이미 UIView를 사용자에게 보여줄 준비가되어 있으며 여기에서 무거운 것을 수행한다는 의미입니다 애니메이션이 지연되는 등 매우 눈에 띄는 방식으로 성능에 영향을줍니다.

3) ViewDidAppear : 마지막으로 ViewDidAppear를 사용하여 위의 양식에 대한 추가 데이터를 얻기 위해 웹 서비스 호출을 수행하는 것과 같이 실행하는 데 오랜 시간이 걸리는 작업에 대한 새 스레드를 시작합니다. 이미 존재하고 사용자에게 표시되는 경우 데이터를받는 동안 사용자에게 멋진 “대기”메시지를 표시 할 수 있습니다.


답변

viewDidLoad === >>> 여기에 초기화 코드를 넣으십시오. 뷰 수명주기 동안 변경 될 수있는 동적 데이터를 넣지 마십시오. 따라서 핵심 데이터에서 데이터를 가져 오는 경우 뷰 수명 동안 변경 될 수있는 경우 여기에서 수행하고 싶지 않습니다. 예를 들어 탭 컨트롤러가 있다고 가정하십시오. tab1에서 tab2로 전환하고 tab2의 모델에서 무언가를 변경합니다. tab1로 돌아와 모델 코드가 viewDidLoad에서 수행 된 경우 KVO 또는 NSFetchedResultsController 등을 사용하지 않는 경우 업데이트되지 않습니다.

viewWillAppear === >>> 뷰가 이미 메모리에 있는지 여부에 관계없이 뷰가 나타나려고 할 때마다 호출됩니다. 모델 논리와 같은 동적 코드를 여기에 넣으십시오.

viewDidAppear === >>> 네트워크 호출과 같이 화면이 화면에 표시되어있는 경우에만 수행 할 값 비싼 작업을 여기에 배치하십시오.

참고 : 앱이 백그라운드에 있고 포 그라운드로 돌아 오는 경우 NSNotificationCenter를 사용하여이를 처리해야합니다. 아래 주석에서 코드를 작성했습니다. viewWillAppear / viewDidAppear가 실행된다고 생각할 수 있습니다. 거기에 중단 점을두고 테스트하십시오. 발사하지 않습니다. 따라서 백그라운드에서 앱에 변경된 사항이있는 경우 알림을 사용하여 업데이트해야합니다.


답변

viewWillAppear방법은 실제보기를로드하기 전에 호출된다.

viewDidAppear메소드는 뷰가 이미로드되어 있고 무언가를 표시하려고 할 때 호출됩니다.


답변

viewWillAppear :
■보기가 창보기 계층 구조에 추가
되기 전에 호출 ■ [vc.view layoutSubviews] 전에 호출 (필요한 경우)
viewDidAppear :
■보기가보기 계층 구조에 추가 된
후 호출 ■ [vc.view layoutSubviews] 이후에 호출 (필요하다면)


답변

몇 가지 관찰 :

  • viewDidLoad뷰가 처음 인스턴스화 될 때 메서드가 호출됩니다. IBOutlet참조는 이것이 호출 된 시점에 연결되지만 이전에는 호출되지 않습니다. 그러나 frame이것이 호출 된 시점에는보기가 설정되지 않을 수 있습니다. 여기에는 하위보기 및 관련 제약 조건을 추가 / 구성 할 수있는 좋은 장소입니다. 그러나 frame메인 뷰의 치수를 기준으로 값을 수동으로 구성하는 경우 해당 프레임의 구성은 viewWillAppear또는 까지 지연되어야합니다 viewDidLayoutSubviews.

  • viewWillAppear뷰 계층의보기의 프리젠 테이션을 시작하려고 할 때 메서드가 호출됩니다. 특히 이것은 뷰의 프리젠 테이션의 애니메이션 시작시 호출됩니다. 그 viewWillDisappear견해는이 견해에서 벗어난 전환이 시작될 때 분명히 호출됩니다.

  • viewDidAppear방법은 뷰의 표현이 완료 될 때, 특히 모든 관련 애니메이션이 완료되었을 때 호출됩니다. viewDidDisappear이 견해에서 벗어난 전환이 완료되면 동반자 가 분명하게 호출됩니다.

두 가지 중요한 경고 사항 :

  • viewDidLoad뷰가 처음 인스턴스화 될 때 한 번만 호출됩니다. 반면에, viewWillAppear그리고 viewDidAppear뷰가 처음 제시하지 않을 경우에만 호출하지만, 이후의 모든 시간은 문제의 동일한 뷰는 다시 발표입니다됩니다. 예를 들어, 처음으로보기를 제시하면이 세 가지 메소드가 모두 호출됩니다. 문제의보기는 이후 연속적으로 기각되면, 다른보기 나타낸다면 viewWillAppearviewDidAppear문제의보기를 추가하고 다시 뷰 계층에 애니메이션 때 일반적으로 다시 호출 될 것이다,하지만 viewDidLoad하지 않습니다를. viewDidLoad이 특정 인스턴스가 처음 생성 될 때만 호출됩니다.

    따라서보기가 다시 나타날 때마다 작업을 수행하려면 (예 : 닫거나 다시 표시) viewWillAppear또는 에서 수행하십시오 viewDidAppear. 보기가 처음 인스턴스화 될 때만 발생하도록하려면에서 수행하십시오 viewDidLoad.

  • 을 호출 viewWillAppear한다고해서 해당 뷰로의 전환이 완료되는 것은 아닙니다. 특히, 실시간 사용자 입력으로 구동되는 대화식 전이를 사용하고 있지만 대화식 전이는 취소 될 수 있습니다. 즉, viewWillAppear부름을 받았다고 해서 그것이 viewDidAppear부름을 의미하는 것은 아닙니다 . 일반적으로 대화 형 제스처가 취소되면 전환이 완료되지 않았기 때문에 취소되지 않습니다.

    WWDC 2013에서 대화식 전환과 관련하여 발표자는 이름 viewWillAppear을 ” viewMightAppear, 또는 viewWillProbablyAppear, 또는 iReallyWishThisViewWouldAppear“로 바꾸어야한다고 농담했습니다 .

    내장 대화식 ​​제스처의 예는 a를 사용하고 UINavigationController“왼쪽 가장자리에서 스 와이프”하여보기 팝업을 시작하는 경우입니다. 는 viewWillAppear당신이 진열되는 뷰를 위해 호출됩니다,하지만 당신은이 팝업 제스처를 시작한에서보기로 다시 돌아가 그 “왼쪽 가장자리에서 슬쩍”취소하면 팝업이 취소되고이 viewDidAppear보기에 대해 당신은에 시작 다시 전화하지 않을 것입니다.

    이것의 결과는 호출 할 때마다 호출 할 viewWillAppear것이라고 가정하는 코드를 작성하지 않도록주의해야한다는 것 viewDidAppear입니다. 전환이 취소 된 경우에는 해당되지 않습니다.


답변

뷰를로드하기 전에 viewwillappear가 호출되어 뷰를로드하기 전에 특정 작업을 수행 할 수 있으며 뷰를로드 한 후 viewdidappear가 호출되므로 포스트 태스크가 해당 메소드에서 수행됩니다.


답변

“will”과 “did”의 차이점 … 이름에서 알 수 있듯이 view가 나타나기 전에 viewWillAppear가 호출되고 view가 나타날 때 viewDidAppear가 호출됩니다.