18

I can't understand, Why HTML/Web UI response slower than WinForms/WPF/Android View/Native UI?

The Native UI also have styles, elements nesting, events than the CSS, DOM, javascript events of the Web UI.

Event response time includes: focus changing, dropdown, scrolling, animation moving, animation resizing, etc.

The DOM tree insertion/replacing is also slow, inserting 10000 chars html will cost 100 ms in google chrome in android 4.0 while parsing its template only cost 20 ms(jQuery micro template).

I releazied maybe the biggest factor that slowdown event response is:

  1. The UI locking between parallel javascript processes;
  2. The rendering engine is too slow to process the new UI changing messages from javascript workers, especially when the browser rendering engine is busy with the last UI updating(because of the point 3);
  3. The html layout method (for example: css cascading, inline flow layout, responsive layout etc) may slow down partial UI updating.
  4. Parsing html/xml cost long time, a hint: Android view inflation relies heavily on pre-processing of XML files that is done at build time(http://developer.android.com/reference/android/view/LayoutInflater.html)

A subset of HTML and CSS standards maybe the future solution for webview app development:

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/

A pile of native UI markup languages: http://en.wikipedia.org/wiki/User_interface_markup_language

why there is not a simplified HTML standard and a simplified Webcore layout engine to replace these native UIML?

Maybe we could realize a subset html in kivy.org project.

PC, android browser = application thread + ui thread

iOS browser = application thread + ui data thread + ui hardware thread(CoreAnimation/OpenGL ES)

In ios browser, application thread could directly call ui hardware thread.

4

5 回答 5

16

如果 Web UI 在客户端完全由 JavaScript 实现，那么与 WinForms/Native UI 的区别将是微不足道的。

但是，在大多数情况下，Web UI 会触发一些 Web 请求到 Web 服务器，然后它必须经过以下步骤才能达到与 WinForms/Native 应用程序相同的效果：

  1. 向 Web 服务器发送 HTTP 请求 (GET/POST/...)
  2. Web 服务器是一个可执行文件（采用外部应用程序或服务的格式），侦听一个或多个端口。当它接收到请求时，对其进行解析并找到 Web 应用程序。
  3. Web 服务器在应用程序中执行后端（服务器端）逻辑。
    诸如 ASP.NET 之类的 Web 应用程序是预编译的。此步骤的时间复杂度可能非常接近 Windows 应用程序。
  4. Web 服务器将结果呈现为标记并将其发送回客户端
  5. 客户端（浏览器）解析结果并在必要时更新 UI。网页中的控件/图像/其他资源在浏览器中呈现的时间通常比 Windows 应用程序呈现其显示的时间要长一些。

即使 Web 服务器是本地的，也不能简单地忽略数据解析/格式化/传输所产生的成本。

另一方面，具有 WinForms/Native UI 的应用程序通常会维护一个消息循环，该循环是活动的并托管在机器代码中。UI请求通常只是触发在消息表中查找然后执行后端逻辑（上面的步骤2）
当它返回结果并更新UI时，它可以是简单的二进制数据结构（不需要在标记中） ，并且不回复另一个应用程序（浏览器）以呈现到屏幕上。

最后，WinForms/Native 应用程序通常可以完全控制维护多个线程以逐步更新 UI，而 Web 应用程序无法直接控制这种类型的服务器端资源。

更新：
当我们比较一个 Web 应用程序和一个 Windows/WPF（或本机）应用程序使用相同的 Web 服务来部分更新它们的 UI 时

在此处输入图像描述

两个 UI 应该以可忽略的速度差异响应和刷新。响应和刷新 UI 的二进制和脚本执行之间的实现差异几乎没有。
两个 UI 都不需要重建控件树并刷新整个外观。在相同的条件下，它们可能具有相同的 CPU 优先级、内存/虚拟内存缓存以及进程/线程级别的相同/接近数量的内核对象和 GDI 句柄。
在这种情况下，正如您所描述的，应该几乎没有视觉差异。

更新 2：
实际上 Web 和 Windows 应用程序中的事件处理机制是相似的。DOM 有事件冒泡。同样，MFC 有命令路由；Winforms 有它的事件流；WPF 有事件冒泡和隧道等。这个想法是一个 UI 事件可能不严格属于一个控件，并且一个控件有某种方式声称一个事件已被“处理​​”。对于标准控件，焦点更改、文本更改、下拉菜单、滚动事件应该对 Web 和 Windows 应用程序具有相似的客户端响应时间。

在性能方面，渲染是最大的区别。Web 应用程序对“设备上下文”的控制有限，因为 Web 页面由外部应用程序（Web 浏览器）托管。Windows 应用程序可以使用 WPF 等 GPU 资源实现动画效果，并通过部分刷新“设备上下文”来加快渲染速度。这就是为什么 HTML5 画布让 Web 开发人员兴奋，而 Windows 游戏开发人员已经使用 OpenGL/DirectX 超过 10 年。

更新 3：
每个 Web 浏览器引擎（http://en.wikipedia.org/wiki/Layout_engine）都有自己的渲染 DOM、CSS 实现；和（CSS）选择器的实现。在网页中移动和调整元素大小正在改变 DOM、CSS（树）设置。选择器和渲染性能高度依赖于 Web 浏览器引擎。

  1. UI 操作可能会使选择器通过不必要的步骤来更新 UI。
  2. 网页无法控制通知浏览器进行部分呈现。

这使得花哨的 JavaScript 控件（一些 jQuery UI、dojo、Ext JS）不能实时快速，通常比 Flash 控件慢。

于 2012-05-27T06:44:44.493 回答
2

与数据在网络上传输的时间相比，在客户端上花费的时间可以忽略不计。Windows 窗体或浏览器中网页的实际呈现时间以（数十或数百）微秒为单位。向服务器发送请求并返回结果以毫秒为单位。

您可以很容易地确认这一点：

  1. 创建一个简单的 Winforms 应用程序，计时。
  2. 创建一个类似的基于 Web 的应用程序。在您自己的 PC 上的网络服务器上运行它，IE //localhost/myapp.asp 并计时。
  3. 在远程网络服务器上运行它并计时。

您会看到 1 最快，紧随其后的是 2（稍微慢一点，解释 HTML、CSS 等），而 3 由于网络时间的原因要慢得多。

要回答您的问题，差异几乎完全是由于网络延迟，这比本地处理时间大一个数量级。

编辑：添加评论解释原因会有点不受欢迎。

于 2012-05-29T15:11:58.890 回答
0

要记住的一件事是浏览器本身是一个原生应用程序，因此为浏览器运行而构建的任何东西本质上都是用（至少）一个额外的抽象层编写的，而不是直接为原生执行而编写的东西。

同样值得注意的是这样的动态：

300 毫秒点击延迟，消失了 http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

这种人为延迟的最初动力是支持捏缩放与其他触摸交互——也就是说，在这种情况下，较慢的响应速度是一种刻意区分不同用户操作的方式。

当然，虽然这是一个相当具体的用例，但一般概念确实可以作为基于浏览器与本机实现的不同考虑因素的示例。也就是说，基于浏览器的体验包括解决各种交互和内容的一些常见框架成本，而原生体验自然会更具体地定制为仅侦听/响应所需的交互模型。

在整个实现过程中，许多微小的部分（比如这个）在原始原生版本中变得更纤细和更集中，这有助于提高响应能力的总体效果。

于 2013-12-20T03:05:47.870 回答
0

3大不同

  1. WebUI 应用程序在浏览器中运行，这取决于浏览器的优化程度。

  2. 浏览器也有自己的 javascript jvm。另一个必须在运行之前运行并解释代码的进程。

所有这些都是在本机操作系统之上的额外层。如果您要打开计算机的活动监视器并在浏览器中打开一个网页，您会注意到什么是资源占用网络浏览器。

  1. 原生 UI 元素具有图形加速支持。根据操作系统的不同，本机 ui 模板被编译为本机格式，无需解析即可进行渲染。
于 2013-12-19T13:42:29.540 回答
-1

仅在不符合标准的浏览器中（包括所有 Android 浏览器、所有 Mac OS 浏览器、所有 Linux 浏览器，以及最糟糕的所有 Google Chrome 版本）。这些是写得不好、未经优化的浏览器，不关心触摸屏延迟、UI 响应和平滑滚动。在任何类型的 CPU 活动、磁盘或网络 I/O 和用户输入期间，它们都会锁定和卡顿。

Internet Explorer 11 或 iOS Safari 等高级浏览器有时甚至比未经优化的本机应用程序响应速度更快。

基本上只有 Windows 8.1 和 iOS 有响应式浏览器。就 UI 响应性而言，所有其他浏览器都较差。差别真的很大。IE11 和 iOS Safari在 UI 延迟和流畅度上抹杀了其他浏览器。

于 2013-12-18T10:51:49.187 回答