移动 – 为什么HTML / Web UI响应比Native UI慢?

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

Native UI还具有样式,元素嵌套,事件不同于Web UI的CSS,DOM,JavaScript事件.

事件响应时间包括:重点改变,下拉菜单,滚动,动画移动,动画调整大小等.

DOM树插入/替换也很慢,插入10000个字符html将在Android 4.0中的谷歌chrome中花费100毫秒,而解析其模板只花费20毫秒(jQuery微模板).

我认为可能是减缓事件响应最大的因素是:

>平行JavaScript进程之间的UI锁定;
>渲染引擎太慢,无法处理来自JavaScript工作人员的新UI改变消息,特别是当浏览器渲染引擎忙于最后一次UI更新(因为第3点)时;
> html布局方法(例如:css cascading,inline流布局,响应布局等)可能会减慢部分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硬件线程.

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

然而,在大多数情况下,Web UI会触发Web服务器的一些Web请求,然后必须执行以下步骤才能实现与WinForms / Native应用程序相同的效果:

>发送HTTP请求(GET / POST / …)到Web服务器
> Web服务器是一种可执行文件(以外部应用程序或服务的形式)侦听一个或多个端口.当它收到请求,解析它,并找到Web应用程序.
> Web服务器在应用程序中执行后端(服务器端)逻辑.
Web应用程序(如ASP.NET)是预编译的.这个步骤的时间复杂度可能非常接近Windows应用程序.
> Web服务器将结果呈现为标记,并将其发送回客户端
>客户端(浏览器)解析结果,并在需要时更新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)选择器的实现.在Web页面中移动和调整元素大小正在改变DOM,CSS(树)设置.选择器和渲染性能高度依赖于Web浏览器引擎.

> UI操作可以使选择器执行不必要的步骤来更新UI.
>网页无法通知浏览器进行部分渲染.

这使得花哨的JavaScript控件(一些jQuery UI,dojo,Ext JS)不能实时快速,通常比Flash控件慢.

相关文章
相关标签/搜索