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

【问题标题】：Why HTML/Web UI response slower than Native UI?为什么 HTML/Web UI 响应比 Native UI 慢？
【发布时间】：2012-05-24 05:58:53
【问题描述】：

我不明白，为什么 HTML/Web UI 响应比 WinForms/WPF/Android View/Native UI 慢？

与 Web UI 的 CSS、DOM、javascript 事件相比，Native UI 还具有样式、元素嵌套、事件。

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

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

我发现减速事件响应的最大因素可能是：

并行 javascript 进程之间的 UI 锁定；
渲染引擎太慢，无法处理来自 javascript worker 的新 UI 更改消息，尤其是当浏览器渲染引擎忙于最后一次 UI 更新时（因为第 3 点）；
html 布局方式（例如：css 层叠、内联流布局、响应式布局等）可能会减慢部分 UI 更新速度。
解析 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、安卓浏览器=应用线程+ui线程

iOS浏览器=应用线程+ui数据线程+ui硬件线程(CoreAnimation/OpenGL ES)

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

【问题讨论】：

您的思考基于哪些事实？你有数字吗？例子？您真的将网页与原生应用进行比较吗？
也许是因为 CSS？在我看来，风格应该像编程中的功能一样，一个风格类可以包含另一个类，但它们不应该级联ui元素之间的影响。
我试图投票关闭（但不能因为有赏金开放）这个问题太宽泛，将导致讨论，因为起始前提是错误的：“HTML/Web UI 响应比 WinForms/Native UI 慢”，所以问为什么并得到答案是没有用的。我知道一些非常快的网络应用程序和一些非常慢的表单应用程序。

标签： mobile user-interface web response native

【解决方案1】：

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

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

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

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

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

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

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

两个 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 浏览器引擎。

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

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

【讨论】：

现在的web应用和native应用从服务器返回的数据通常是相同的（例如，JSON格式）。两者都将更新相同数量的 UI 元素。事实上，我觉得没有什么区别，在这一点上，网络应用程序和原生应用程序一样快。我认为主要区别在于初始渲染时间和事件响应时间。谁有测试方法和详细的对比图？
@diyism 没有意识到您在谈论基于返回数据的部分 UI 刷新。请查看我的更新。
1.我想也许我们还没有涵盖问题中最重要的部分：事件响应时间：焦点变化、下拉、滚动、动画移动、动画调整大小等 2.我可以感觉 Native app 更新部分控制树和 Web app 更新 DOM 树之间的显着差异，但我认为它们实际上有区别（例如：动画调整大小可能会影响 Web 应用程序中的整个树，但不会影响 Native 应用程序）。跨度>
为什么在原生应用中调整动画大小比网页应用快得多？因为 html 布局比 WinForms 布局更破旧？甚至它们都有嵌套元素。
这里有一些关于 Native、Hybrid、Web 的资料：buildmobile.com/native-hybrid-or-web-apps

【解决方案2】：

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

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

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

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

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

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

【讨论】：

【解决方案3】：

三大区别

WebUI 应用程序在浏览器中运行，这取决于浏览器的优化程度。
浏览器也有自己的javascript jvm。另一个必须在运行之前运行并解释代码的进程。

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

原生 UI 元素支持图形加速。根据操作系统的不同，本机 ui 模板被编译为无需解析即可呈现的本机格式。

【讨论】：

【解决方案4】：

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

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

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

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

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

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

【讨论】：

【解决方案5】：

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

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

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

【讨论】：