Проблема производительности WPF с CommandManager - PullRequest
Новая
       13

Проблема производительности WPF с CommandManager

8 голосов
/ 28 февраля 2011

Мы создали новое, довольно сложное WPF-приложение с нуля и столкнулись с проблемой производительности по мере увеличения числа команд, зарегистрированных в CommandManager.Мы используем простые легкие команды в нашей реализации MVVM, однако сторонние элементы управления, которые мы используем (Infragistics), не делают, и вызываем CommandManager.RegisterClassCommandBinding, чтобы добавить RoutedCommands.Проблема производительности проявляется в восприятии медлительности пользовательского интерфейса при ответе на пользовательский ввод, например, медленное переключение между элементами управления, ввод текста «прерывистый», а всплывающая анимация «неуклюжий».Когда приложение запускается впервые, пользовательский интерфейс становится быстрым.По мере открытия большего количества экранов, содержащих сетки Infragistics, производительность ухудшается.

Внутри CommandManager есть закрытое поле с именем _requerySuggestedHandlers, которое представляет собой List .Я использовал рефлексию, чтобы получить ссылку на эту коллекцию, и заметил, что когда я вызываю .Clear (), отзывчивость пользовательского интерфейса улучшается до его исходного состояния.Очевидно, что я не хочу обходить очистку коллекций, о которых я мало знаю, особенно с помощью рефлексии (!), Но я сделал это, чтобы увидеть, излечит ли это проблемы с производительностью, и вуаля.

Обычно,эта ситуация прояснится через некоторое время.Однако коллекция WeakReferences (_requerySuggestedHandlers) будет урезана только после запуска сборки мусора, которая является недетерминированной.Из-за этого, когда мы закрываем окна, содержащие сетки (Infragistics XamDataGrid), свойство CanExecute для «мертвых» команд сетки продолжает оцениваться без необходимости, даже после закрытия окна.Это также означает, что если мы закроем несколько окон, производительность все равно будет падать, пока не начнется сборка мусора.Я понимаю, что это может произойти при распределении, и я сам видел это, потому что, если я открою дополнительное окно, это приведет к тому, что начальная память (из расположенной Windows) будет собрана, и производительность вернется к норме.

ИтакУчитывая вышеизложенное, вот мои вопросы:

  1. Как и откуда вызывается CommandManager.InvalidateRequerySuggested ()?Я не нашел никакой документации на MSDN, которая объясняет это в мельчайших подробностях.Я подключился к событию CommandManager.RequerySuggested и похоже, что оно вызывается всякий раз, когда элементы управления теряют фокус.
  2. Возможно ли подавить вызов CommandManager.InvalidateRequerySuggested () в ответ на ввод пользователя?
  3. Кто-нибудь еще сталкивался с этой проблемой, и если так, как вы избежали ее?

Спасибо!

1 Ответ

4 голосов
/ 28 февраля 2011

Это звучит как один из редких случаев, когда детерминированный вызов GC.Collect() является правильным решением.Обычный аргумент против этого заключается в том, что сборщик мусора умнее вас.Но когда вы имеете дело с WeakReference объектами, вы попадаете на территорию, где вы можете знать то, чего не знает сборщик мусора.Запуск сборки мусора определенно лучше, чем очистка _requerySuggestedHandlers - помимо прочего, он ничего не сделает с WeakReference объектами, которые указывают на элементы управления, которые все еще живы.Я бы выбрал это вместо попытки выяснить, как подавить RequerySuggested, так как это испортило бы поведение тех команд, о которых вы все еще заботитесь.

...