为什么HTML / Web UI响应比Native UI慢？

Question

我无法理解，为什么HTML / Web UI响应比WinForms / WPF / Android View / Native UI慢？

Native UI还包含样式，元素嵌套，事件，而不是Web UI的CSS，DOM，javascript事件。

事件响应时间包括：焦点更改，下拉，滚动，动画移动，动画调整大小等。

DOM树插入/替换也很慢，插入10000个字符html将在Android 4.0中的谷歌浏览器中花费100毫秒，而解析其模板仅花费20毫秒（jQuery微模板）。

我重新启动可能是减速事件响应的最大因素：

1. 并行javascript进程之间的UI锁定;
2. 渲染引擎太慢，无法处理来自javascript worker的新UI更改消息，尤其是当浏览器呈现引擎忙于上次更新UI时（因为第3点）;
3. html布局方法（例如：css级联，内联流布局，响应式布局等）可能会降低部分UI更新速度。
4. 解析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/

一堆本机UI标记语言：http://en.wikipedia.org/wiki/User_interface_markup_language

为什么没有简化的HTML标准和简化的Webcore布局引擎来替换这些原生UIML？

也许我们可以在kivy.org项目中实现一个子集html。

PC，android browser = application thread + ui thread

iOS浏览器=应用程序线程+ ui数据线程+ ui硬件线程（CoreAnimation / OpenGL ES）

在ios浏览器中，应用程序线程可以直接调用ui硬件线程。

Answer 1

如果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应用程序和使用相同Web服务的Windows / WPF（或本机）应用程序来部分更新其UI时



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

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


Performancewise，渲染是最大的区别。 Web应用程序对“设备上下文”的控制有限，因为Web页面由外部应用程序（Web浏览器）托管。 Windows应用程序可以使用WPF等GPU资源实现动画效果，并通过部分刷新“设备上下文”来加速渲染。这就是为什么HTML5 canvas让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控件慢。

Answer 2

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

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

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

你会看到1是最快的，紧接着是2（慢一点，解释HTML，CSS等），3由于网络时间而慢得多。

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

编辑：添加评论解释原因会是一种贬低者。

Answer 3

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

高级浏览器（如Internet Explorer 11或iOS Safari）有时甚至比未经优化的原生应用程序更具响应性。

基本上只有Windows 8.1和iOS才有响应式浏览器。就UI响应而言，所有其他浏览器都是劣质的。差异非常大。 IE11和iOS Safari 删除其他浏览器的UI延迟和平滑度。

Answer 4

3大差异

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

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

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

1. 原生UI元素具有图形加速支持。取决于操作系统，本机ui模板被编译为本机格式，不需要解析以进行渲染。

Answer 5

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

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

  

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

这种人为延迟的最初推动力是支持缩放缩放与其他触摸交互 - 也就是说，在这种情况下，较慢的响应能力是消除不同用户操作歧义的一种有意识的方式。

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

在整个实施过程中，许多微小的部分（例如这个）在原始原生版本中更为纤细和更集中，这可以促进更好响应的一般效果。