Почему ответ HTML/Web UI медленнее, чем собственный пользовательский интерфейс?

Я не могу понять, почему HTML/Web UI реагирует медленнее, чем WinForms/WPF/Android View/Native UI?

Собственный интерфейс также имеет стили, элементы вложения, события, чем CSS, DOM, события javascript веб-интерфейса.

Время отклика событий включает в себя: изменение фокуса, выпадающее меню, прокрутку, перемещение анимации, изменение размера анимации и т.д.

Вставка/замена дерева DOM также медленная, вставка 10000 символов html будет стоить 100 мс в google chrome в android 4.0, а синтаксический анализ его шаблона - только 20 мс (шаблон jQuery micro).

Я высвободил, возможно, самый большой фактор, который замедляет реакцию событий:

Блокировка пользовательского интерфейса между параллельными процессами javascript;
Механизм рендеринга слишком медленный, чтобы обрабатывать новые пользовательские интерфейсы, изменяющие сообщения от рабочих javascript, особенно когда движок рендеринга браузера занят обновлением последнего пользовательского интерфейса (из-за точки 3);
Метод макета html (например: css-каскадный, встроенный макет потока, отзывчивый макет и т.д.) может замедлить частичное обновление пользовательского интерфейса.
Parsing html/xml стоит долгое время, подсказка: инфляция Android-просмотров сильно зависит от предварительной обработки XML файлов, которые выполняются во время сборки (http://developer.android.com/reference/android/view/LayoutInflater.html)

Подмножество стандартов HTML и CSS может быть будущим решением для разработки приложений webview:

http://www.silexlabs.org/haxe/cocktail/

http://www.terrainformatica.com/htmlayout/

http://www.nativecss.com/

http://www.pixate.com/

https://github.com/tombenner/nui

http://steelratstory.com/steelrat-products/wrathwebkit

http://trac.webkit.org/wiki/EFLWebKit

https://github.com/WebKitNix/webkitnix

http://qt-project.org/doc/qt-4.8/richtext-html-subset.html

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Куча родных языков разметки пользовательского интерфейса: http://en.wikipedia.org/wiki/User_interface_markup_language

почему нет упрощенного стандарта HTML и упрощенного механизма компоновки Webcore для замены этого родного UIML?

Возможно, мы могли бы реализовать подмножество html в проекте kivy.org.

PC, android browser = прикладной поток + ui thread

iOS browser = прикладной поток + ui поток данных + ui аппаратная нить (CoreAnimation/OpenGL ES)

В браузере ios поток приложений может напрямую вызвать аппаратный поток ui.

Ответ 1

Если веб-интерфейс полностью реализован JavaScript на стороне клиента, отличие от WinForms/Native UI будет тривиальным.

Однако в большинстве случаев веб-интерфейс запускает веб-запрос на веб-сервер, поэтому для достижения такого же эффекта, как приложение WinForms/Native, необходимо выполнить следующие шаги:

Отправьте HTTP-запрос (GET/POST/...) на веб-сервер
Веб-сервер является исполняемым (в формате внешнего приложения или службы), который прослушивает один или несколько портов. Когда он получает запрос, анализирует его и находит веб-приложение.
Веб-сервер выполняет бэкэнд (серверную) логику в приложении.
Веб-приложение, такое как ASP.NET, предварительно скомпилировано. Временная сложность этого шага может быть очень близка к приложению Windows.
Веб-сервер отображает результат в разметке и отправляет его клиенту
Клиент (браузер) анализирует результат и, при необходимости, обновляет интерфейс. Элементы управления/изображения/другие ресурсы на веб-странице обычно занимают немного больше времени для визуализации в браузере, чем приложение Windows отображает его отображение.

Даже веб-сервер является локальным, стоимость, генерируемая обработкой данных/форматированием/переносом, не может быть просто проигнорирована.

С другой стороны, приложение с WinForms/Native UI обычно поддерживает цикл сообщений, который является активным и размещается в машинных кодах. Запрос пользовательского интерфейса обычно просто запускает поиск в таблице сообщений, а затем выполняет бэкэнд-логику (шаг 2 выше)
Когда он возвращает результат и обновляет пользовательский интерфейс, он может быть просто структурой двоичных данных (необязательно находиться в разметке) и не отвечает другому приложению (браузеру) для рендеринга на экран.

Наконец, приложение WinForms/Native обычно имеет полный контроль, чтобы поддерживать несколько потоков для постепенного обновления интерфейса, в то время как веб-приложение не имеет прямого контроля над ресурсами сервера на стороне сервера.

UPDATE:
Когда мы сравниваем веб-приложение и приложение Windows/WPF (или родное), использующее одну и ту же веб-службу, для частичного обновления своих пользовательских интерфейсов

Два пользовательских интерфейса должны отвечать и обновляться с неослабевающей разницей в скорости. Разница между выполнением двоичных и сценариев для ответа и обновления пользовательского интерфейса почти ничего.
Ни один из пользовательских интерфейсов не должен восстанавливать дерево управления и обновлять весь внешний вид. При одинаковых условиях они могут иметь одинаковый приоритет ЦП, кэширование памяти/виртуальной памяти и одно и то же/закрытие числа объектов ядра и GDI-дескрипторов на уровне процесса/потока.
В этом случае, как вы описали, визуальной разницы практически не должно быть.

ОБНОВЛЕНИЕ 2:
На самом деле механизмы обработки событий в приложениях Web и Windows аналогичны. DOM имеет событие пузыря. Аналогично, MFC имеет команду маршрутизации; У Winforms есть поток событий; WPF имеет событие барботирования и туннелирования, и так далее. Идея - это событие пользовательского интерфейса, которое может не строго принадлежать одному элементу управления, а элемент управления имеет некоторый способ заявить, что событие было обработано. Для стандартных элементов управления изменение фокуса, изменение текста, выпадающее меню, прокрутка событий должны иметь аналогичное время отклика на стороне клиента как для веб-приложений, так и для Windows.

Производительность, рендеринг - самая большая разница. Веб-приложения имеют ограниченный контроль над "контекстом устройства", поскольку веб-страница размещается внешним приложением - веб-браузером. Приложения Windows могут реализовывать анимационные эффекты с использованием ресурсов GPU, таких как WPF, и ускорить рендеринг, частично обновив "контекст устройства". Именно поэтому HTML5-холст заставляет веб-разработчиков возбуждаться, когда разработчики игр Windows используют OpenGL/DirectX более 10 лет.

ОБНОВЛЕНИЕ 3:
Каждый движок веб-браузера (http://en.wikipedia.org/wiki/Layout_engine) имеет собственную реализацию рендеринга DOM, CSS; и реализация селекторов (CSS). Перемещение и изменение размеров элементов внутри веб-страницы изменяет настройку DOM, CSS (tree). Селектор и производительность рендеринга сильно зависят от механизма веб-браузера.

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

которые создают привлекательные элементы управления JavaScript (некоторые jQuery UI, dojo, Ext JS) не могут быть быстрыми в режиме реального времени, обычно медленнее, чем элементы управления Flash.

Ответ 2

Время, затрачиваемое на клиента, незначительно по сравнению с временем, которое данные тратят на сеть. Фактическое время визуализации формы Windows или веб-страницы в браузере измеряется в (десятки или, может быть, сотни) микросекунд. Отправка запроса на сервер и получение результата обратно измеряется в миллисекундах.

Это можно легко подтвердить:

Создайте простое приложение Winforms, запустите его.
Создайте аналогичное веб-приложение. Запустите его на веб-сервере на своем собственном компьютере, I.E.//localhost/myapp.asp и время его.
Запустите его на удаленном веб-сервере и запустите его.

Вы увидите, что 1 быстрее всего внимательно следит за 2 (немного медленнее, интерпретируя HTML, CSS и т.д.), а 3 значительно медленнее из-за сетевого времени.

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

РЕДАКТИРОВАТЬ: Это было бы чем-то вроде downvoters, чтобы добавить комментарий, объясняющий почему.

Ответ 3

Только в нестандартных браузерах (это включает в себя все браузеры Android, все браузеры Mac OS, все браузеры для Linux и худшую из всех версий Google Chrome). Это плохо написанные, неоптимизированные браузеры, не заботящиеся о латентности сенсорного экрана, отзывчивость пользовательского интерфейса и плавная прокрутка. Они блокируются и заикаются во время любого вида активности ЦП, дискового или сетевого ввода/вывода и ввода пользователя.

Улучшенные браузеры, такие как Internet Explorer 11 или iOS Safari, иногда даже более отзывчивы, чем неоптимизированные собственные приложения.

В основном только Windows 8.1 и iOS имеют отзывчивые браузеры. Все другие браузеры хуже, чем в отношении пользовательского интерфейса. Разница действительно огромная. IE11 и iOS Safari стирают другие браузеры в латентности и плавности пользовательского интерфейса.

Ответ 4

3 большие различия

Приложения WebUI запускаются в браузере, что зависит от того, насколько оптимизирован браузер.
В браузере также есть собственный javascript jvm. другой процесс, который должен запускать и интерпретировать код до его запуска.

Все это дополнительный слой, который находится поверх встроенной ОС. Если вы должны открыть монитор активности своего компьютера и открыть веб-страницу в своем браузере, вы заметите, что такое веб-браузер для веб-браузера ресурса.

Собственные элементы пользовательского интерфейса поддерживают поддержку ускорения графики. в зависимости от os, родные шаблоны ui скомпилированы в собственный формат, который не нужно анализировать для рендеринга.

Ответ 5

Следует иметь в виду, что сам браузер является родным приложением, поэтому все, что создано для запуска браузера, по сути написано с (по крайней мере) одним дополнительным слоем абстракции по сравнению с чем-то, написанным непосредственно для собственного исполнения.

Также стоит отметить такую динамику, как это:

Задержка отклика 300 мс, ушла http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

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

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

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