Советы по повышению производительности с помощью MVVM и языка программирования

В этом разделе рассматриваются некоторые рекомендации по повышению производительности, связанные с выбором шаблонов проектирования программного обеспечения и языка программирования.

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

Шаблон Model-View-ViewModel (MVVM) распространен во многих приложениях XAML. (MVVM очень похож на описание Fowler шаблона модели-представления-докладчика, но оно адаптировано к XAML). Проблема с шаблоном MVVM заключается в том, что он может непреднамеренно привести к приложениям, которые имеют слишком много слоев и слишком много выделений. Эти мотивы для MVVM.

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

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

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

Рекомендации по C++/CX

• Используйте последнюю версию. Существуют постоянные улучшения производительности компилятора C++/CX. Убедитесь, что ваше приложение строится с помощью последнего набора инструментов.
• Отключите RTTI (/GR-). RTTI включен по умолчанию в компиляторе, поэтому, если среда сборки не переключает ее, вы, вероятно, используете его. RTTI имеет значительные издержки, и если ваш код не имеет глубокой зависимости от него, вы должны отключить его. Платформа XAML не требует, чтобы код использовал RTTI.
• Избегайте интенсивного использования ppltasks. Ppltasks очень удобно при вызове асинхронных API WinRT, но они имеют значительные затраты на размер кода. Команда C++/CX работает над функцией языка — ожиданием, что обеспечит гораздо более высокую производительность. В то же время сбалансируйте использование ppltasks в горячих путях кода.
• Избегайте использования C++/CX в бизнес-логике приложения. C++/CX предназначен для удобного доступа к API WinRT из приложений C++. Он использует оболочки, имеющие накладные расходы. Следует избегать C++/CX внутри бизнес-логики или модели класса и резервировать его для использования в границах кода и WinRT.