mobile - 为什么HTML/Web UI响应比 native UI慢？

Question

我不明白，为什么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 micro template）。

我认为慢速事件响应的最大因素可能是：


并行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，Android浏览器=应用程序线程+ ui线程

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

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

Answer 1

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

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


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


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

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

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

更新：当我们比较一个使用相同Web服务的Web应用程序和Windows / WPF（或本机）应用程序以部分更新其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浏览器引擎。


UI操作可能会使选择器执行不必要的步骤来更新UI。
网页没有控制权通知浏览器进行部分渲染。


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