Porady dotyczące wydajności maszyny MVVM dla aplikacji WinUI

W tym temacie omówiono niektóre zagadnienia dotyczące wydajności aplikacji WinUI związane z maszyną MVVM, powiązaniami i kompozycją widoku.

Wzorzec Model-View-ViewModel (MVVM)

Wzorzec Model-View-ViewModel (MVVM) jest często spotykany w wielu aplikacjach WinUI. (MVVM jest bardzo podobny do opisu wzorca Model-View-Presenter według Fowlera, ale jest dostosowany do XAML). Problem ze wzorcem MVVM polega na tym, że może przypadkowo prowadzić do aplikacji, które mają zbyt wiele warstw i zbyt wiele alokacji. Motywacje stojące za wzorcem MVVM są następujące.

• Podział odpowiedzialności. Zawsze warto podzielić problem na mniejsze elementy, a wzorzec, taki jak MVVM lub MVC, to sposób dzielenia aplikacji (a nawet pojedynczej kontrolki) na mniejsze elementy: rzeczywisty widok, model logiczny widoku (view-model) i logikę aplikacji niezależnej od widoku (model widoku). W szczególności, popularnym rozwiązaniem jest przydzielenie projektantom odpowiedzialności za widok z użyciem jednego narzędzia, deweloperom za model z użyciem innego narzędzia, a integratorom projektu za widok-model przy użyciu obu narzędzi.
• Testowanie jednostkowe. Można testować jednostkowo model widoku (i w związku z tym model) niezależnie od widoku, a tym samym nie polegać na tworzeniu okien, prowadzeniu danych wejściowych itd. Zachowując mały widok, możesz przetestować dużą część aplikacji bez konieczności tworzenia okna.
• Zwinność do zmian środowiska użytkownika. Widok ma tendencję do zauważania najczęściej występujących zmian i najpóźniejszych zmian, ponieważ doświadczenie użytkownika jest dostosowywane na podstawie opinii użytkowników końcowych. Dzięki oddzieleniu widoku te zmiany mogą być uwzględniane szybciej i z mniejszym współczynnikiem zmian w aplikacji.

Istnieje wiele konkretnych definicji wzorca MVVM i struktur innych firm, które pomagają je zaimplementować. Jednak ścisłe przestrzeganie wszelkich odmian wzorca może prowadzić do aplikacji o wiele większych kosztów, niż można uzasadnić.

• Powiązanie danych XAML (rozszerzenie znaczników {Binding}) zostało zaprojektowane częściowo w celu włączenia wzorców modelu/widoku. Jednak element {Binding} wiąże się z nietrywialnym zużyciem pamięci roboczej i obciążeniem procesora. Utworzenie elementu {Binding} powoduje szereg alokacji, a aktualizowanie elementu docelowego powiązania może spowodować refleksję i boksowanie. W systemie WinUI te problemy są rozwiązywane za pomocą rozszerzenia znaczników {x:Bind}, które kompiluje powiązania w czasie kompilacji i jest szeroko używane w przykładach winUI i aplikacjach produkcyjnych. Zalecenie: użyj polecenia {x:Bind}.
• Jest popularne w MVVM, aby połączyć Button.Click z modelem widoku przy użyciu ICommand, na przykład z typowymi pomocnikami, takimi jak DelegateCommand lub RelayCommand. Te polecenia jednak stanowią dodatkowe alokacje, w tym odbiornik zdarzeń CanExecuteChanged, zwiększenie zestawu roboczego oraz wydłużenie czasu uruchamiania/nawigacji strony. Zalecenie: Alternatywą dla korzystania z wygodnego interfejsu ICommand jest umieszczenie programów obsługi zdarzeń w kodzie, dołączanie ich do zdarzeń wyświetlania i wywoływanie polecenia w modelu wyświetlania po wywołaniu tych zdarzeń. Należy również dodać dodatkowy kod, aby wyłączyć przycisk, gdy polecenie jest niedostępne.
• Jest popularne w podejściu MVVM tworzenie strony ze wszystkimi możliwymi konfiguracjami interfejsu użytkownika, a następnie ukrywanie części drzewa przez powiązanie właściwości Visibility z właściwościami w modelu widoku. Spowoduje to niepotrzebne wydłużenie czasu uruchamiania, a także potencjalnie zwiększyć zestaw roboczy, ponieważ niektóre części drzewa mogą nigdy nie być widoczne. Zalecenia: Użyj funkcji atrybutu x:Load , aby odroczyć niepotrzebne części drzewa przed uruchomieniem. Ponadto utwórz oddzielne kontrolki użytkownika dla różnych trybów strony i użyj kodu-behind, aby załadować tylko niezbędne kontrolki.