WinUI 앱에 대한 MVVM 성능 팁

이 항목에서는 MVVM, 바인딩 및 뷰 컴퍼지션과 관련된 WinUI 앱에 대한 몇 가지 성능 고려 사항에 대해 설명합니다.

모델-뷰-뷰모델(MVVM) 패턴

MVVM(Model-View-ViewModel) 패턴은 많은 WinUI 앱에서 일반적입니다. (MVVM은 Model-View-Presenter 패턴에 대한 Fowler의 설명과 매우 유사하지만 XAML에 맞게 조정됩니다.) MVVM 패턴의 문제는 실수로 레이어가 너무 많고 할당이 너무 많은 앱으로 이어질 수 있다는 것입니다. MVVM의 동기는 다음과 같습니다.

• 우려의 분리. 문제를 더 작은 조각으로 나누는 것이 항상 유용하며, MVVM 또는 MVC와 같은 패턴은 앱(또는 단일 컨트롤)을 실제 보기, 뷰의 논리 모델(뷰-모델) 및 뷰 독립적 앱 논리(모델)와 같은 작은 조각으로 나누는 방법입니다. 특히 디자이너가 하나의 도구를 사용하여 보기를 소유하고, 개발자가 다른 도구를 사용하여 모델을 소유하고, 디자인 통합자가 두 도구를 모두 사용하여 뷰 모델을 소유하도록 하는 것이 인기 있는 워크플로입니다.
• 단위 테스트 뷰와 독립적으로 뷰 모델(및 결과적으로 모델)을 단위 테스트할 수 있으므로 창 만들기, 입력 구동 등에 의존하지 않습니다. 보기를 작게 유지하면 창을 만들지 않고도 앱의 상당 부분을 테스트할 수 있습니다.
• 사용자 환경 변경에 대한 민첩성. 최종 사용자 피드백에 따라 사용자 환경이 조정되므로 보기에서 가장 자주 변경되고 가장 늦은 변경 내용이 표시되는 경향이 있습니다. 보기를 별도로 유지하면 앱에 대한 변동이 줄어들면서 이러한 변경 내용을 더 빠르게 수용할 수 있습니다.

MVVM 패턴에 대한 여러 가지 구체적인 정의와 이를 구현하는 데 도움이 되는 타사 프레임워크가 있습니다. 그러나 패턴의 모든 변형을 엄격하게 준수하면 정당화할 수 있는 것보다 훨씬 더 많은 오버헤드가 있는 앱으로 이어질 수 있습니다.

• XAML 데이터 바인딩({Binding} 태그 확장)은 부분적으로 모델/뷰 패턴을 사용하도록 설계되었습니다. 그러나 {Binding}은(는) 상당한 작업 집합 및 CPU 오버헤드를 발생시킵니다. {Binding}을(를) 만들면 일련의 할당이 발생하고 바인딩 대상을 업데이트하면 리플렉션 및 boxing이 발생할 수 있습니다. WinUI에서 이러한 문제는 빌드 시 바인딩을 컴파일하고 WinUI 샘플 및 프로덕션 앱에서 널리 사용되는 {x:Bind} 태그 확장으로 해결됩니다. 권장 사항: {x:Bind}를 사용합니다.
• MVVM에서는 Button.Click을 공통 DelegateCommand 또는 RelayCommand 도우미와 같은 ICommand를 사용하여 뷰 모델에 연결하는 것이 인기가 있습니다. 하지만 이러한 명령은 CanExecuteChanged 이벤트 수신기, 작업 집합에 추가, 페이지의 시작/탐색 시간에 추가 등 추가 할당입니다. 추천: 편리한 ICommand 인터페이스를 사용하는 대신, 이벤트 처리기를 코드 숨김에 배치하고, 뷰 이벤트에 연결하고, 해당 이벤트가 발생할 때 뷰 모델에서 명령을 호출하는 것이 좋습니다. 또한 명령을 사용할 수 없는 경우 단추를 사용하지 않도록 설정하는 추가 코드를 추가해야 합니다.
• MVVM에서는 가능한 모든 UI 구성을 사용하여 페이지를 만든 다음 Visibility 속성을 VM의 속성에 바인딩하여 트리의 일부를 축소하는 것이 좋습니다. 이렇게 하면 시작 시간과 작업 집합에 불필요하게 추가됩니다(트리의 일부 부분이 표시되지 않을 수 있기 때문). 권장 사항:x:Load 특성 기능을 사용하여 트리에서 필요하지 않은 부분을 시작 시점에서 지연시킵니다. 또한 페이지의 다양한 모드에 대해 별도의 사용자 컨트롤을 만들고 코드 숨김을 사용하여 필요한 컨트롤만 로드된 상태로 유지합니다.