Советы по производительности MVVM для приложений WinUI

В этом разделе рассматриваются некоторые рекомендации по повышению производительности приложений WinUI, связанных с MVVM, привязками и представлением композиции.

Шаблон Model-View-ViewModel (MVVM)

Шаблон модель-представление-модель представления (MVVM) распространён во многих приложениях WinUI. (MVVM очень похож на описание шаблона Model-View-Presenter, но это адаптировано к XAML.) Проблема с шаблоном MVVM заключается в том, что он может непреднамеренно привести к приложениям, которые имеют слишком много слоев и слишком много выделений. Мотивы для использования MVVM следующие.

  • Разделение проблем. Всегда полезно разделить проблему на небольшие части, а шаблон, такой как MVVM или MVC, — это способ разделить приложение (или даже один элемент управления) на небольшие части: фактическое представление, логическая модель представления (модель представления) и логика приложения независимо от представления (модель). В частности, это популярный рабочий процесс, при котором дизайнеры управляют видом с помощью одного инструмента, разработчики владеют моделью с помощью другого инструмента, а интеграторы дизайна управляют моделью представления, используя оба инструмента.
  • Модульное тестирование. Модульное тестирование можно проводить независимо от представления, тестируя модель представления (и, следовательно, модель) без необходимости создавать окна или управлять вводом данных и т. д. Сохраняя небольшое представление, вы можете протестировать большую часть приложения, не создавая окно.
  • Гибкость изменения взаимодействия с пользователем. Представление, как правило, отображает наиболее частые изменения и самые поздние изменения, так как взаимодействие с пользователем настраивается на основе отзывов конечных пользователей. Сохраняя представление отдельно, эти изменения можно внедрить быстрее и с меньшим количеством изменений в приложении.

Существует несколько конкретных определений шаблона MVVM и сторонних платформ, которые помогают реализовать его. Но строгое соблюдение любого варианта шаблона может привести к приложениям с гораздо большими затратами, чем может быть оправдано.

  • Привязка данных XAML (расширение разметки {Binding}) была разработана частично для включения шаблонов модели или представления. Но {Binding} влечет за собой нетривиальный рабочий набор и нагрузку на ЦП. Создание {Binding} приводит к серии выделений памяти, а обновление целевого объекта привязки может привести к рефлексии и упаковке. В WinUI эти проблемы устраняются с расширением разметки {x:Bind}, которое компилирует привязки во время сборки и широко используется в примерах WinUI и рабочих приложениях. Рекомендация. Используйте {x:Bind}.
  • В MVVM популярно связывать Button.Click с моделью представления с помощью ICommand, таких как общие вспомогательные элементы DelegateCommand или RelayCommand. Эти команды представляют собой дополнительные затраты ресурсов, включая слушатель события CanExecuteChanged, увеличивая рабочий набор и увеличивая время старта или навигации страницы. Рекомендации: В качестве альтернативы использованию удобного интерфейса ICommand рекомендуется размещать обработчики событий в коде, присоединять их к событиям представления и вызывать команду в модели просмотра при возникновении этих событий. Кроме того, необходимо добавить дополнительный код, чтобы отключить кнопку, если команда недоступна.
  • Это популярно в MVVM для создания страницы со всеми возможными конфигурациями пользовательского интерфейса, а затем свернуть части дерева, привязав свойство Видимости к свойствам в виртуальной машине. Это увеличивает время запуска без необходимости, а также, возможно, нагрузку на рабочий набор, поскольку некоторые части дерева могут никогда не отображаться. Рекомендации: Используйте функцию атрибута x:Load , чтобы отложить ненужные части дерева вне запуска. Кроме того, создайте отдельные пользовательские элементы управления для разных режимов страницы и используйте код для хранения только необходимых элементов управления.

Связанные материалы

  • Last updated on