为什么HTML/Web UI响应比本机UI慢? [英] Why HTML/Web UI response slower than Native UI?

问题描述

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

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

与Web UI的CSS，DOM，javascript事件相比，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.

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

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. 并行javascript进程之间的UI锁定；
2. 渲染引擎太慢，无法处理来自javascript worker的新UI更改消息，尤其是当浏览器渲染引擎正忙于最后一次UI更新时(由于第3点)；
3. html布局方法(例如:css级联，内联流布局，响应式布局等)可能会减慢部分UI更新的速度.
4. 解析html/xml需要花费很长时间，这是一个提示:Android视图膨胀在很大程度上依赖于在构建时完成的XML文件的预处理(

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)

HTML和CSS标准的子集可能是Webview应用程序开发的未来解决方案:

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/

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

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

为什么没有简化的HTML标准和简化的Webcore布局引擎来代替这些本机UIML?

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

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

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

PC，Android浏览器=应用程序线程+ ui线程

PC, android browser = application thread + ui thread

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

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

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

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

推荐答案

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

If Web UI is completely implemented by JavaScript on the client side, the difference from WinForms/Native UI will be trivial.

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

However, in most cases, the Web UI triggers some Web request to the Web server, then it has to go through the following steps to achieve the same effect as a WinForms/Native app:

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

1. Send a HTTP request (GET/POST/...) to the Web server
2. The Web server is an executable (in the format of an external app or a service) listening to one or multiple ports. When it receives the request, parses it, and finds the Web application.
3. Web server executes backend (server-side) logic within application.
   Web application such as ASP.NET is pre-compiled. Time complexity of this step could be very close to a Windows app.
4. Web server renders the result into markup and sends it back to the client
5. Client (Browser) parses the result and updates the UI if necessary. Controls/images/other resources in a Web page normally take a little longer to render within a browser than a Windows app renders its display.

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

Even the Web server is local, the cost generated the data parsing/formatting/transfer cannot be simply ignored.

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

On the other hand, an application with WinForms/Native UI typically maintains a message loop, which is active and hosted in machine code. A UI request normally just triggers a lookup in the message table and then execute the backend logic (Step 2 in the above)
When it returns result and updates UI, it can be simply binary data structure (doesn't need to be in markup), and doesn't reply another application(browser) to render to the screen.

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

Lastly, a WinForms/Native application normally has full control to maintain multiple threads to update UI gradually, while a Web application has no direct control over that type of server-side resources.

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

UPDATE:
When we compare a Web application and a Windows/WPF (or native) application consuming a same Web service to partially update their UIs

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

The two UIs should respond and refresh with ignorable speed difference. The implementation difference between binary & scripting execution to respond and refresh UI is almost nothing.
Neither of the UIs needs to reconstruct the control tree and refresh entire appearance. Given same conditions, they could have same CPU priority, memory/virtual memory caching, and same/close number of kernel object & GDI handles at process/thread level.
In this case, as you described, there should be almost no visual difference.

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

UPDATE 2:
Actually event handling mechanisms in Web and Windows apps are similar. DOM has event bubbling. Similarly, MFC has command routing; Winforms has its event flow; WPF has event bubbling and tunnelling, and so on. The idea is a UI event might not strictly belong to one control and a control has some way to claim an event has been "handled". For standard controls, focus changing, text changing, dropdown, scrolling events should have similar client-side response time for both Web and Windows apps.

在性能方面，渲染是最大的不同. Web应用程序对设备上下文"的控制有限，这是因为Web页是由外部应用程序(即Web浏览器)托管的. Windows应用程序可以使用WPF等GPU资源来实现动画效果，并通过部分刷新设备上下文"来加快渲染速度.这就是HTML5画布使Web开发人员感到兴奋的原因，而Windows游戏开发人员已经使用OpenGL/DirectX已有10多年了.

Performancewise, rendering is the biggest difference. Web apps have limited control of "device context" because a Web page is hosted by an external application - the Web browser. Windows applications can implement animation effects using GPU resources like WPF and speed up rendering by refreshing the "device context" partially. That's why HTML5 canvas makes Web developers excited while Windows game developers have been using OpenGL/DirectX for over 10 years.

更新3:
每个Web浏览器引擎( http://en.wikipedia.org/wiki/Layout_engine )都有其自己的自己的渲染DOM，CSS实现； (CSS)选择器的实现.在网页中移动元素和调整元素大小正在更改DOM，CSS(树)设置.选择器和呈现性能在很大程度上取决于Web浏览器引擎.

UPDATE 3:
Each Web browser engine (http://en.wikipedia.org/wiki/Layout_engine) has its own implementation of rendering DOM, CSS; and implementation of (CSS) selectors. Moving and resizing elements within a Web page is changing DOM, CSS (tree) setup. The selector and rendering performance highly depends on the Web browser engine.

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

使得精美的JavaScript控件(某些jQuery UI，dojo，Ext JS)无法实时实现，通常比Flash控件慢.

which make fancy JavaScript controls (some jQuery UI, dojo, Ext JS) cannot be real-time fast, usually slower than Flash controls.

这篇关于为什么HTML/Web UI响应比本机UI慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！