Есть ли разница в производительности между WPF и Winforms?

Ответ 1

Нет никакого значимого ответа "да" или "нет". Это зависит от многих факторов, включая, но не ограничиваясь:

• Какой пользовательский интерфейс вы создаете.

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

• Насколько эффективно вы оптимизируете производительность на каждой платформе.

  Конечно, легко реализовать малоэффективные интерфейсы с обеих платформ. Внедрение сложного пользовательского интерфейса, чтобы он выполнялся очень хорошо, требует знания того, как эффективно использовать сильные и слабые стороны платформы.

• Используете ли вы готовые элементы управления или сторонние элементы управления и качество этих элементов управления.

  Элементы 1 и 2 переносятся на любые сторонние компоненты.

Если вы опытный и компетентный разработчик WinForms, то вы, вероятно, уже знаете, как создавать представления в WinForms. Кривая обучения для WPF крутая; любой опытный разработчик WPF может вам это рассказать. Они также расскажут вам, что вы можете использовать его для создания богатых пользовательских интерфейсов, которые хорошо работают. Это также верно. То же самое верно для WinForms.

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

Все, что сказал, если вы еще не вложили значительные средства в любую платформу, я бы пошел по маршруту WPF. Это богатая (хотя и тяжеловесная) структура, которая может быть выполнена для того, чтобы хорошо работать. Объем усилий, необходимых для его наилучшего выполнения, во многом зависит от типов просмотров, которые вы создаете, но я создал много высокопроизводительных высокочастотных представлений данных с помощью WPF. Я также создал визуально богатую стратегическую игру с WPF. Но не чувствуйте себя вынужденным пойти с ним; если ваши разработчики уже знакомы с WinForms, он остается вполне жизнеспособным вариантом.

Обновление: Я думаю, маловероятно, что поддержка WinForms будет удалена из .NET в ближайшие несколько лет, но если это вызывает беспокойство, я бы пошел на WPF. Типы видов, которые вы описываете, могут быть созданы в WPF достаточно легко. Для сравнения, у меня есть несколько представлений, способных отображать от 50 000 до 500 000 строк с 60 + столбцами; тысячи обновлений строк в секунду; пользовательская, многоуровневая сортировка и группировка; выборочная фильтрация; индивидуальные резюме; все время обновлялись в псевдореальном времени ( "человеческое" в реальном времени). Получение такого уровня производительности было непростым, но это можно сделать. Объем и частоту данных, которые вы описываете, должны быть значительно упрощены с любой платформой и с использованием только встроенного набора управления.

Ответ 2

Если вы выполняете сложные пользовательские интерфейсы, WPF - это путь. winforms ничего не поддерживает.

Если вы делаете простые пользовательские интерфейсы, WPF - это путь, потому что:

• он позволяет гораздо более чистый шаблон (MVVM) в отличие от ужасного слишком большого кода для всех процедурных winforms.
• Он обладает гораздо большими возможностями DataBinding.
• Если вам когда-либо понадобится настроить что-либо, вы можете.
• Он имеет встроенную виртуализацию пользовательского интерфейса.
• По умолчанию это разрешение не зависит.

Если вы беспокоитесь о долгосрочной перспективе:

WPF - это путь. Текущей/будущей инфраструктурой пользовательского интерфейса Windows является WinRT XAML. Будет намного проще переносить ваше приложение WPF на WinRT XAML, чем приложение winforms. И поскольку MVVM действительно технологично-агностик, вы можете в конечном итоге повторно использовать свои ViewModels в ЛЮБОЙ другой технологии пользовательского интерфейса.

Изменить: Поскольку я получаю много downvotes, и там много обсуждений вокруг этого ответа, я собираюсь конкретно сосредоточиться на вопросе OP и попытаться дать довольно объективный ответ:

Производительность:. Когда вы сравниваете использование памяти WPF с winforms для действительно простых пользовательских интерфейсов (Window или Form, содержащих только TextBox), WPF, похоже, потребляет гораздо больше памяти чем winforms. Это связано с тем, что структура WPF намного больше, чем winforms, и поэтому для работы она имеет гораздо больше "вещей для загрузки". Это также верно, когда вы сравниваете времена холодного запуска (опять же, в ситуации с 1 контролом).

В отличие от этого, когда вы создаете более тяжелые пользовательские интерфейсы, состоящие из нескольких элементов управления/кнопок/DataGrids/ComboBoxes/TextBoxes/и т.д. (вещи, которые действительно распространены в бизнес-приложениях), разница начинает уменьшаться, пока она даже не благоприятствует WPF. Это связано с тем, что WPF DependencyProperty система, которая сохраняет значения свойств по умолчанию в одном пространстве памяти, а не в каждом экземпляре.

WPF предназначался для использования в сложных/богатых пользовательских интерфейсах с самого начала и оптимизирован для работы в ситуациях, когда есть тысячи элементов управления, а не 1-управляющий случай.

Еще один важный аспект, который следует учитывать при сравнении производительности между WPF и winforms с точки зрения данных, - это, как упоминалось выше, Виртуализация пользовательского интерфейса, Просто взглянув на это видео, становится очевидным, что WPF работает намного лучше в ситуации, когда вам нужно отображать строки 20k в ListBox. Я сказал гуру winforms, что winforms, похоже, также поддерживает это, но вам нужно прибегнуть к вызову P/Invoke из-за того, что winforms не поддерживают его должным образом, и из того, что он сказал, это не очевидно для меня, если другие элементы управления, кроме ListBox, также поддерживают это в winforms (например, DataGridView и TreeView). ВСЕ WPF ItemsControls уже или могут быть сделаны виртуальными по умолчанию с помощью простых стилей Application-wide.

Аппаратное ускорение: вы можете подумать: "Мне это не нужно", но если вы посмотрите вокруг, есть тысячи ситуаций, когда winforms начнут мерцать ужасно при обновлении пользовательского интерфейса, не обязательно в сложной ситуации рисования, но также при изменении размера окна, содержащего множество элементов управления. Есть способы обойти это, но опять же, вам придется начинать терять время на устранение проблемы, с которой вам никогда не придется начинать, вместо того, чтобы концентрироваться на вашей бизнес-логике. У вас НИКОГДА не возникнет эта проблема с WPF не только потому, что она аппаратно ускорена, но и потому, что она основана на основе Vector, а не на основе Bitmap.

Заключение: хотя winforms могут работать лучше в 1-контрольном случае, WPF является явным победителем на всех уровнях для реальных Datacentric UI.

Помимо всего этого, и, как упоминалось в @Blam, выбор технологии требует анализа не только характеристик производительности, но и масштабируемости, настраиваемой, поддерживаемость, легкость развития, долгосрочная перспектива, среди многих других вещей.

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

С настраиваемостью, в частности, я скажу, что даже если вы not планируете когда-либо создавать Полностью настраиваемый, богатый пользовательский интерфейс, выбор WPF по-прежнему является гораздо более мудрым решением, потому что с winforms вы можете в конце концов ударить по стене, если захотите Показывать свои данные в формате, который не поддерживается по умолчанию. Тогда вам придется начинать страдать и терять свое время с помощью ужасных техник, таких как "Draw Draw", тогда как в WPF все, что вам нужно, это просто DataTemplate

Конечно, WPF - сложная структура, но на самом деле это не сложность этого, что делает крутую кривую обучения, а требуемую Смена менталитета действительно то, с чем борются большинство разработчиков из других фреймворков.

И, как уже упоминалось выше, важно, чтобы вы кодировали против абстракций, а не против определенного набора классов, чтобы ваш код в конечном итоге мог быть перенесен в другие среды, если это было необходимо. WPF допускает это, winforms - нет.

Если вы кодируете winforms, вы будете навсегда застревать в недееспособности winforms и код за хаками. Это правда, что если вы используете MVP для winforms, это несколько смягчено, но все же у Ведущих есть гораздо более тесная связь с инфраструктурой пользовательского интерфейса, чем ViewModels в MVVM, которые полностью совместимы с пользовательским интерфейсом.

Если вы код в WPF с XAML и MVVM, вы можете в конечном итоге заменить взгляды WPF XAML на что-то еще, и не оставляйте ваши ViewModels нетронутыми, а это значит, что вам на самом деле НЕ нужно переписывать все ваше приложение с нуля, потому что ViewModels приложение, а не представления.

Ответ 3

Я попробовал рисовать большое количество строк на панели в winforms и на том же dt на холсте при использовании WPF и обнаружил, что winforms creted drwing менее чем за секунду, если WPF занимает много секунд, хотя я использую Pathgeometry в WPF, а не в шпилях

Ответ 4

Я закодировал несколько приложений в шаблоне MVVM как для Windows Forms, так и для WPF, и когда вы сравниваете одно и то же приложение, реализованное на обоих, выигрыши окон формируются для приложений, привязанных к данным. Вы заметили, что влияние влияет больше, если у вас есть несколько дочерних datagrid, связанных с одним родительским datagrid или структурой, никогда не понимающим, почему. Поэтому для бизнес-приложений я всегда кодирую WPF только в том случае, если это необходимо. Я также считаю, что сортировка и фильтрация также проще в формах окон.