`
lyg8266
  • 浏览: 11384 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

operamasks-ui和其它js框架性能对比

阅读更多

一、前言

       前段时间我们团队推出了operamasks-ui ,得到了业界的一些关注,首先谢谢大家的关注,你们的关注就是我们团队的动力。

       在推出一段时间之后也得到了一些反馈,有组件需求的反馈,有组件bug的反馈,还有性能方面的一些反馈,希望我们能给出一个性能对比报告,和各个其它js框架做一个横向的对比,让选择的时候能心中有数。

      针对以上问题我们的测试人员和开发人员先选择了omTree和其它框架对比,做了一系列的测试数据,这里要声明的是我们不是要证明我们的组件有多强,只是想真实的对比一下,是好货拿出来溜溜嘛,同时也发现自己的不足,继续改进组件。

      测试的前提:组件功能一致、数据和数据源一致。

 

二、名词解释

Render Time :用户在页面上看到第一个内容的时间。当开始渲染时用户是可以在浏览器中看见内容的,而有内容的时候 document.body.offsetHeight 应该是大于 0 的,因此根据这一特点使用 timer 来检查。(网上资料显示 FireFox 可以通过在 window 上注册“ MozAfterPaint ”事件来计算浏览器开始渲染的时间,但是实际测试时发现 FireFox7.0 根本监控不到“ MozAfterPaint ”事件,因此也根据 document.body.offsetHeight 大于 0 进行测试)

Dom Ready :文档解析完成的时间,目前对于文档解析具体包括哪些操作没有具体的答案,但文档解析至少应该包括以下操作: HTML 文档分析以及 DOM 树的创建、外链脚本的加载、外链脚本的执行以及内联脚本的执行,但不包括图片、 iframe 等其它资源的加载。

Page Load window.onload 事件触发的时间。与 DOM Ready 时间相比, Page Load 的时间往往要更靠后一些,因为 Page Load 不仅仅是 HTML 文档解析完毕还包括了所有资源加载所需要的时间,例如图片资源的加载、 iframe 的加载等。

Show Time :组件内容展现时间,即 tree 完全展现的时间。

CPU 监控 :通过 ProcessExplorer 监控访问案例时浏览器的 CUP 占用率。

三、概述

本次测试主要是对 operamask-ui easyui extjsui ligerui 几个产品进行前端性能对比测试,被测组件为 tree tree 展示 10 个父节点,每个父节点下又包含 10 层子节点,在展示数据相同的情况下,比较 operamask-ui 与其他几个主流 ui 框架产品的页面加载时间、组件展示时间、 CPU 占用率等。

四、测试环境

被测对象:测试 Operamask-ui (以下检查 om-ui ), easy-ui extjs-ui liger-ui tree 组件,分别在 firefox IE chrome 三种浏览器下的 render domready pageload 、组件内容完全展现的时间以及 CUP 利用率。

硬件配置: Pentium® Dual-Core CPU E5300 @2.60GHz 2.60GHz 3.24GB 内存

 

软件名称

版本

FireFox

7.0.1

IE

IE8

Chrome

17.0

ProcessExplorer

14.12

 

五、测试案例

1、被测组件案例

 

按照各个 ui 框架构造 tree 组件的方式,分别建立 tree 测试组件,测试页面中仅放置一个被测 tree tree 展现格式为 10*10 10 个父节点,每个父节点中迭代 10 层子节点)。

2、监控参数案例

 

(1)       Render Time

var time_to_page_start = new Date()*1,bodyHeights = [];
(function(){
		function handleRender(){
			window.pmc_start_render_time = new Date()*1 - time_to_page_start;
			var h = document.createElement('h3');
			h.innerHTML='Time To Start Render:'+window.pmc_start_render_time + ' ms';
			document.body.appendChild(h);
		}
		if(document.body && document.body.offsetHeight > 0 ){ 
			handleRender();
			return;
		}
		if(document.body){
			bodyHeights.push(document.body.offsetHeight);
		}
		setTimeout(arguments.callee,30);
})();

 

说明:首先记录开始时间 time_to_page_start ,监控 document.body.offsetHeight ,当大于 0 时,表明用户能看到页面上的内容的时间,用次时间减去开始时间,则为渲染时间。

 

(2)       Dom Ready

 

Dom Ready 为页面内所有 dom 节点加载完成的时间。 FireFox 中增加了一个 DOMContentLoaded 方法,该方法是在页面的 DOM 内容加载完成后即触发,而无需等待其他资源的加载。 Webkit 引擎从版本 525 Webkit nightly 1/2008:525+ )开始也引入了该事件, Opera 中也包含该方法。 IE 不支持该方法,但是在 IE 下, dom 的某些方法只有在 dom 解析完成后才能调用, doScroll 就是这样一种方法,因此我们通过监控 doScroll 来监控 IE 中的 Dom   Ready 时间。 Webkit 引擎低版本通过监控 readyState 来判断 dom 是否加载完毕。 JS 脚本如下:

var time_to_page_start = new Date()*1;
(function(){
	function domreadyTime(){
	    window.pmc_start_render_time = new Date()*1 - time_to_page_start;
		var h = document.createElement('h3');
		h.innerHTML = 'Time To Dom Ready: ' + window.pmc_start_render_time + ' ms';
		document.body.appendChild(h);
    }
    this.conf = {enableMozDOMReady:true};   
    var isReady = false;   
    function doReady(){   
        if( isReady ) return;   
        isReady = true;   
        domreadyTime();   
    }   
    if( /MSIE/.test(navigator.userAgent) ){   
      (function(){   
       if ( isReady ) return;   
       try {   
          document.documentElement.doScroll("left");   
       } catch( error ) {   
          setTimeout( arguments.callee, 0 );   
          return;   
       }   
       doReady();   
     })();   
    window.attachEvent('onload',doReady);   
  }   
  else if (/Chrome/.test(navigator.userAgent)){   
    (function(){   
      if( isReady ) return;   
      if (/loaded|complete/.test(document.readyState))   
         doReady();   
      else  
         setTimeout( arguments.callee, 0 );   
     })();   
    window.addEventListener('load',doReady,false);   
  }   
  else{   
     if( /Firefox/.test(navigator.userAgent) || this.conf.enableMozDOMReady)   
       document.addEventListener( "DOMContentLoaded", function(){   
       document.removeEventListener( "DOMContentLoaded", arguments.callee, false );   
       doReady();   
     }, false );   
     window.addEventListener('load',doReady,false);   
   }   
})();

 

 

(3)       Page Load

Page Load 时间指的就是 window.onload 事件触发的时间。与 DOM Ready 时间相比, Page Load 的时间往往要更靠后一些,因为 Page Load 不仅仅是 HTML 文档解析完毕还包括了所有资源加载所需要的时间,例如图片资源的加载、 iframe 的加载等。 JS 脚本如下:

 var time_to_page_start = new Date()*1;
(function(){
	function pageLoad(){
	    window.pmc_start_render_time = new Date()*1 - time_to_page_start;
		var h2 = document.createElement('h3');
		h2.innerHTML = 'Time To Page Load: ' + window.pmc_start_render_time + ' ms';
		document.body.appendChild(h2);
	}
//判断浏览器是否能够识别window.addEventListener,假如可以,则执行以下代码
	if(typeof window.addEventListener!="undefined"){  
		window.addEventListener('load',function(){
			window.removeEventListener('load', arguments.callee, false);
			pageLoad();
		},false);
	}
//某些浏览器无法识别window.addEventListener,只能识别document.addEventListener,因此要增加这一步判断
	else if(typeof document.addEventListener!="undefined"){     
		document.addEventListener("onload",function(){
			document.removeEventListener('onload', arguments.callee, false);
			pageLoad();
		},false);
	}
	//前面两种都无法识别,则判定是否可以识别window.attachEvent  (IE)
	else if(typeof window.attachEvent!="undefined"){
		window.attachEvent("onload",function(){
			pageLoad();
		});
	}
	//前三种都无法识别,则用这最后一种:老式链式事件处理方式
	else{
		var oldfn = window.onload;
		if(typeof window.onload!="function"){
			window.onload = function(){
				pageLoad();
			}
		}
		else{
			window.onload = function(){
				oldfn();
				pageLoad();
			}
		}
})();

 

(4)       Show Time

 

在我们的测试案例中,令 grid 组件读取 500 条数据, tree 组件展示 10 个节点,每个节点中包含 10 层子节点(即子节点中又包含 1 个子节点,如此循环 10 层), Show Time 用于监控组件在页面中所有数据完全展现出来的时间,通过在页面中查找 grid 组件的最后一条数据来判断该组件内容是否完全展现,通过在页面中查找 tree 组件的最后一个节点来判断该组件内容是否完全展现。 JS 脚本如下:

var time_to_page_start = new Date()*1;
/*<![CDATA[*/
(function(){
	function handleRender(){
		window.pmc_start_render_time = new Date()*1 - time_to_page_start;
		var h = document.createElement('h3');
		h.innerHTML = 'Time To Start show: ' + window.pmc_start_render_time + ' ms';
			document.body.appendChild(h);
	}
	//if($('table').find('tr').eq(500).length > 0){  //grid查找方法
	//if($('ul li').length == 110){  //easy-tree,liger-tree,om-tree查找方法
	if($('table tr').length == 111){   //extjs-tree查找方法
		handleRender();
		return;
	}
	setTimeout(arguments.callee,30);
})();

 3、测试执行

 

为了避免各个监控参数互相影响,在被测组件的 html 文件中每次只添加一个监控参数的 js 文件,测试 CPU 时不添加监控参数的 js 文件。测试时只有一种浏览器被打开。

测试各个监控参数的操作步骤为:在浏览器中输入对应组件的 URL ,回车,记录页面中显示的时间,重复此步骤 10 次,取平均值。为了保证不受浏览器缓存的影响,保证监控参数的监听正确,每次执行完之后要清空缓存,重启浏览器。

测试 CPU 占用率的操作:打开 ProcessExplorer ,打开浏览器,输入 URL ,回车,记录回车后测试浏览器在 ProcessExplorer 中的最大值。

 

六、测试数据和图表

 

extjs-tree firefox 下的特别说明:

按照我们的测试案例,设置 tree 组件为 10*10 时( 10 个父节点,每个父节点循环 10 层子节点), extjs tree 组件在 FireFox7.0.1 中无法正常显示,在 IE8 Chrome 下可以正常显示,因此在测试 firefox 时,我们修改了 tree 组件的节点,使其展示 9*11 层。在 tree 组件为 10*10 时,节点个数为 10*10+10=110 个, tree 组件为 9*11 时,节点个数为 9*11+9=108 个,所以 extjs tree 组件在 firefox 下测出的数据不是特别准,比正确的数据偏小,但是与 110 个总个数相比, 2 个节点的时间几乎可以忽略。

6.1 Render Time

单位ms

 

FireFox7.0.1

IE8

Chrome17.0

om- tree

166

344

108

easy- tree

229

997

251

extjs- tree

59

671

222

liger- tree

120

280

109



 

6.2 Dom Ready

单位ms

 

FireFox7.0.1

IE8

Chrome17.0

om- tree

4

31

7

easy- tree

6

31

5

extjs- tree

9

31

9

liger- tree

6

33

29



 

6.3 Page Load

单位ms

 

 

FireFox7.0.1

IE8

Chrome17.0

om- tree

7

32

7

easy- tree

11

31

5

extjs- tree

13

31

9

liger- tree

15

35

29



 

6.4 show time

单位ms

 

FireFox7.0.1

IE8

Chrome17.0

om- tree

84

359

99

easy- tree

179

984

263

extjs- tree

506

1145

365

liger- tree

114

281

82



 

6.5 CPU


 

FireFox7.0.1

IE8

Chrome17.0

om-tree

19.54

28.92

15.63

easy- tree

36.17

38.30

28.92

extjs- tree

50.03

52.37

38.48

liger- tree

22.32

28.92

17.31



 

 

总的来说,各个组件在ie8下面表现最差,chrome和火狐各有千秋

ext性能表现比较好,这也是我们开始没有想到的,其实ext性能不差,只是功能太多了,拖累了,在功能平等的情况下性能还是不错的。

还有就是我们测试都是本地资源,所以资源加载时间可以忽略,其实资源大小摆在那里,哪个js库大哪个小也无需我们列出来,况且功能

不同资源大小肯定不同,如果纠结于资源大小是不公平的。




  • 大小: 18.1 KB
  • 大小: 18 KB
  • 大小: 18.8 KB
  • 大小: 18.3 KB
  • 大小: 18.9 KB
  • 大小: 18.8 KB
  • 大小: 18.9 KB
  • 大小: 19 KB
  • 大小: 17.6 KB
  • 大小: 18.3 KB
分享到:
评论
2 楼 pch272215690 2016-09-27  
可惜夭折了,官网都打不开
1 楼 naily 2012-05-24  
嗯,了解了

相关推荐

    operamasks-ui-2.0-demo.zip

    这个项目可能是一个Web应用程序框架或库,专为开发人员设计,以便在Opera浏览器或其他支持JavaScript的环境中创建交互式和富媒体的用户界面。以下是基于这个压缩包内容可能涉及到的关键知识点: 1. **Opera Masks**...

    operamasks-ui-2.0.zip

    《深入理解OperaMasks UI 2.0:前端框架与应用实践》 OperaMasks UI 2.0是一款由金蝶公司推出的高效、易用的前端界面库,它旨在为开发者提供一套完整的用户界面解决方案,以提升Web应用程序的用户体验和开发效率。...

    operamasks-ui-2.1-demo

    这个WAR文件包含了OperaMasks UI 2.1的所有前端资源,如HTML、CSS、JavaScript代码,以及可能的图片和其他媒体文件。开发者可以通过部署这个WAR文件到支持Servlet容器(如Tomcat或Jetty)来运行OperaMasks UI的示例...

    operamasks-ui-2.1.zip

    这个框架可能特别注重易用性和性能,使得开发者能够快速地开发出响应式和美观的网页应用。"OMUI"是其简称,可能是"Opera Masks User Interface"的缩写,暗示了该框架可能与Opera浏览器或其相关的Web技术有关。 在...

    operamasks-ui-master.zip

    【标题】"operamasks-ui-master.zip" 是一个包含了 OperaMasks UI 2.0 框架的源代码压缩包。这个框架是基于前端开发的,尤其适用于构建企业级的 Web 应用程序,其设计目标是提高开发效率,提供良好的用户体验。...

    扩展OperamasksUI的grid的排序和显示detail属性

    这篇博客“扩展OperamasksUI的grid的排序和显示detail属性”显然聚焦于如何增强Operamasks UI框架的功能,特别是其grid组件。Operamasks UI可能是一个用于构建Web应用的开源库,提供了丰富的组件和功能,便于开发者...

    operamasks_ui

    2. `js` - 存放JavaScript代码,实现UI的交互逻辑和标签功能。 3. `images` - 图片资源,可能包含图标和其他UI元素的图形。 4. `fonts` - 字体文件,用于定制UI的字体样式。 5. `examples` - 示例代码,帮助开发者...

    operamasks2.1整合spring、hebernate实现grid增删改查

    首先,OperaMasks是一个基于JavaScript的富客户端应用框架,它提供了丰富的UI组件和交互效果,用于构建动态、响应式的Web界面。在这个项目中,OperaMasks 2.1版本可能被用到了创建grid(表格)展示数据,以及处理...

    TM框架改进版

    而`OperaMasks`可能是该框架所使用的前端库的源码或者预编译后的JavaScript文件,用于在客户端实现UI效果。 综上所述,"TM框架改进版"是一个综合性的企业级开发解决方案,它利用Spring、Struts2、iBatis和...

    operamasks整合spring、hebernate小例子

    1. **OperaMasks**:OperaMasks是一款基于JavaScript的前端框架,它提供了丰富的UI组件和模板引擎,用于快速开发交互式Web界面。它的主要特点是易于使用、性能优越,并且对浏览器兼容性有良好的支持,使得开发者能够...

    TM框架(实现权限管理和动态开发)

    这个框架的核心是将Spring、Struts2、iBatis和OperaMasks这四个组件有效地结合在一起,以提供高效、灵活且可扩展的解决方案。 首先,Spring框架作为整个系统的基石,它提供了依赖注入(DI)和面向切面编程(AOP)等...

    J2EE程序员需掌握的技术

    - JUnit,JMeter,jWebUnit,Optimizeite,Profiler:单元测试和性能测试工具。 33. **设计模式**: - 单例,命令,工厂,工厂方法,观察者,模板,外观,访问者,状态,装饰器,桥接,DAO,责任链等:理解和应用...

    Event-Handling

    在JavaServer Faces (JSF)框架中,事件处理是一个关键机制,它允许开发者响应用户界面(UI)中的交互事件。本文将深入探讨JSF中的事件处理,主要包括ActionController(行为控制器)与事件监听器如ActionListener和...

Global site tag (gtag.js) - Google Analytics