优化基于ExtJS 4.1的应用

虽然Sencha在Ext JS 4.1提升了性能，但基于Ext JS的应用性能优化仍然是奋斗目标。要优化应用性能，一般须要根据Ext JS的加强优点对修改代码。本文将介绍如何实现优化

E文好的朋友，能够到http://www.sencha.com/blog/optimizing-ext-js-4-1-based-applications查看原文。

虽然Sencha在Ext JS 4.1提升了性能，但基于Ext JS的应用性能优化仍然是奋斗目标。要优化应用性能，一般须要根据Ext JS的加强优点对修改代码。

本文将介绍如何实现优化，还将介绍一个用于Ext JS 4.1的新的性能测量工具——页面分析器。其主要功能是改善应用的性能。经过它，就能够定出测量指标兵测量它，从而找出代码中的瓶颈，兵采起正确的步骤消除瓶颈。页面分析能够作到这一点。最后，还将介绍Grid的优化，并介绍另外一个新的用于评估Grid性能的Ext JS工具——Infinite Grid Tuner。

正如咱们为Ext JS开发人员工做同样，咱们注意到几个共同的趋势，在编写应用程序时要×××能调整的办法。虽然咱们不能一一列举拖垮应用程序的每一个编码技术，但经过如下介绍的方法，高开发人员就可在使用框架时提升应用程序的性能。

检查事件监听

在应用程序中如何使用事件监听是一个×××能的一个关键。例如，想在Store第一次加载数据时触发load事件，若是不注意，就会形成Store每次加载数据时都会触发load事件。这时候，在Store第一次加载数据触发load事件后关闭它，将会提高应用程序的总体性能。方法就是在监听中添加“single:true”：

listeners: {
 load: onFirstLoadData,
 single: true
}

另一个常常忽略的是afterrender事件，它会在全部DOM元素都渲染后触发。渲染后修改元素会引发回流（reflows），从而下降应用性能。相反，使用beforerender事件，在渲染前调整元素的样式，可以让元素在渲染时就是正确的样式。有时候，一些代码必须在渲染后，元素的大小被肯定后才能运行。这时候，在Ext JS 4.1，能够考虑使用其提供的一个新事件——boxready，它会在组件大小肯定后触发。

移除doLayout和doComponentLayout的调用

简而言之，就是尽可能移除这些昂贵的调用。在旧版本Ext JS（4.0以前），doLayout会让框架在组件或容器继续前进时，从新计算其布局。即便在Ext JS 4.0，有时候，也须要在直接更新DOM后或解决某些缺陷时调用它。

在Ext JS 4.1，布局的触发有点不一样，于是，代码基本不须要调用doLayout或doComponentLayout。若是你的应用事实上须要这些调用来解决错误，那么请提交一个bug报告，一把咱们能修复它。

惟一非错误时，须要调用doLayout或doComponentLayout，是在应用代码直接修改DOM的时候。缘由是框架不知道这样的变化，于是须要调用它们更新受影响的布局。

减小容器嵌套

咱们常常看到过多嵌套容器的应用，例如，一个容器内只有一个容器，而这个容器内有多个组件。这时候，能够取消外层容器，只使用一个容器完成一样的工做。很重要的一点，必须记住，每一个容器的初始化、渲染和布局都须要花费时间，于是，必须排除这些没必要要的嵌套容器，这样，应用将运行得更快。相似的代码以下（id属性在实际上不多见到，添加在这里是为了标记这里有两个容器）：

{
 id: 'container1',
 items: [{
 id: 'container2',
 items: [{
 id: 'component3'
 }]
 }]
}

若是可能，上面代码可减小为一个容器：

{
 id: 'container1',
 items: [{
 id: 'component3'
 }]
}

使用容器替换面板

请记住，Ext JS面板比容器功能强大，但也是很昂贵的。于是，最好指定“xtype: 'container'”，以免应用使用默认的面板，以下所示：

（译者注：面板包含标题、工具栏等不少部件，于是其实例化时要建立不少部件的实例，并作不少布局运算，而容器就是一个简单的div，于是在非必要状况下使用容器，确实会大幅改善应用的性能，这个必定要切记）

{
 xtype: 'container', // defaultType is 'panel'
 items: [ ... ]
}

减小边框布局（borderLayout）嵌套

在Ext JS4.1，不少状况下，再也不须要使用边框布局嵌套。移除嵌套能够减小初始化、渲染和布局组件的时间。在ExtJS以前的版本不少状况下都须要嵌套，例如，在同一区域内有两个或两个以上相同的区域。在Center区域上有2个North区域的时候，你必须嵌套边框布局。如今，使用一个边框布局就能够实现两个North区域。

在Ext JS4.1，区域能够根据须要动态添加，任何添加的区域可在前端显示并在不须要的时候隐藏它们。还能够经过weight属性定义区域的优先权，例如，能够定义West区域的优先权在North区域以前。这些变化意味着再也不须要嵌套边框buutons，从而提升使用该布局的组件的渲染速度。

（译者注：该功能的改变很是方便，如今设计布局比以前版本的轻松多了）

减小DOM的读取和写入

在Ext JS4.1，咱们已经尽量的减小了布局对DOM的读取和写入。一样，在你的代码也须要这样作。DOM在读取自身时会下降应用速度，尤为是在混合了DOM写入操做时的开销至关高，并且这样结合会引发回流。尝试使用beforerender来维护样式，这样能够在渲染时修改组件，而不是在渲染后。避免使用setStyle、addCls、removeCls以及其它直接修改DOM元素的语句，这些语句都会引发写入操做。做为通常规则，为了得到更好的性能，维护DOM时须要写入时，多尝试使用批量读取和写入。

使用Ext.suspendLayouts和Ext.resumeLayouts消除额外的布局操做

Ext JS 4.1提供了Ext.suspendLayouts和Ext.resumeLayouts两个新方法来协调多个组件和容器的更新。例如，要迅速增长两个组件到两个连续容器，会致使多个布局和渲染操做被执行。若是在添加这些组件以前调用Ext.suspendLayouts方法，将再也不单独执行个别组件的布局操做。添加完成后，调用Ext.resumeLayouts方法，框架将只执行一次渲染和布局操做。

谨记，不单添加组件会触发容器的布局操做，组件的其它操做或改变也会触发容器的布局操做。重要的是针对在应用中的性能问题进行具体状况具体分析，以确保没有多余的布局操做被执行。

{
 Ext.suspendLayouts();
// batch of updates
 Ext.resumeLayouts(true);
}

Ext JS页面分析器介绍

Ext JS 4.1带有一个新工具，可用来查找和衡量应用程序的性能问题。经过它，可快速检测代码的修改对性能的影响。页面分析器会在加载Ext JS 4.1页面时与诊断工具挂钩。页面分析器包含了许多实验×××，本文将介绍其最有用的，用于优化应用性能的布局选项卡。

你能够在Ext JS 4.1 SDK包的示例文件夹（Examples）下找到该工具：

./examples/page-analyzer/page-analyzer.html

复制整个“page-analyzer”文件夹到要分析的应用主机上，由于浏览器安全问题，页面分析器必须与分析页面在同一服务器上进行通信，并且要确保页面分析器的版本与Ext JS的版本号匹配。若是使用不一样的版本，它会罢工。

注意，该工具是首次发布，还处于发展中，于是，请经过Ext JS论坛将工具的使用状况反馈给咱们。

如下是使用页面分析器的步骤：

一、打开浏览器兵输入页面分析器的地址。

二、打开后，在分析器中输入测试页面的地址。

三、页面将在iframe中加载，这就是为何分析器必须与应用在同一服务器的缘由。打开页面后的分析器以下图所示：

单击布局选项卡，将看到以下图所示的布局运行状况。

你能够在同一个组件中找到多个布局操做，而后查看你的代码，看看是否能够经过减小布局操做来提升性能。

Grid优化

Ext JS Grid是形成Web应用性能问题的一个主要缘由，尤为是在显示大量数据的时候。当Grid在渲染小量数据的时候，速度不是问题。然而，在显示大量数据的时候，若是不注意，虚拟的无限滚动就会成为性能瓶颈。无限滚动依赖于页面缓存分页，也就是在用户对Grid中进行滚动操做显示数据以前，须要在分页滚动对象内保存分页数据。

当用户滚动时，缓存数据就变成可见的，而消失在页面顶部的则再也不存放在DOM中。调整的主要途径是让让DOM的大小尽量的小，并在客户端缓存数据从而减小与服务器的交互。

滚动原理

当Store的配置项buffered为true时，会实例化一个PagingScroller对象用于监控视图（Grid自带的数据视图）的滚动，同时要为视图即将进行的遍历操做提供实时数据而缓存分页数据。

下图说明了用户滚动时视图获取数据的方式。PageingScroller会在往前方向维持一个前导缓冲地带，而在日后方向则维持一个小的后向缓存地带。

PagingScroller要求Store确保后向缓冲地带和前导缓冲地带都在缓冲中，这就须要计算那些页面是须要的，以确保它们被缓存，而Store只须要经过Ajax请求不在缓存中的页面。

当视图往下滚动时，渲染表格的边界将会进入视图，当距离边距numFromEdge行的时候，Store就要加载继续往下的数据，同时保证垂直坐标同步以保证可视行在相同位置。当所需数据在页面缓存的时候，这个操做是在瞬间和无形中实现的。若是拖动滚动条超过了缓存页面，将会发送yieldAjax请求，并显示遮蔽直到数据返回。

若是滚动增量在一个合理的速度范围内，请求区域的前导边界进入另外一不在缓存的页面时，会调用Ajax请求该页。在大多数状况下，若是前导缓冲区域足够大，它会在在到达缓存行以前渲染表格。

默认状况下，页面缓存只会缓存最近使用的5页，这个根据浏览状况进行添加，让更多的数据缓存在客户端，从而减小Ajax请求。Store的purgePageCount配置项可控制该行为。

若是数据不是太多，例如50000行，那能够将它们整个缓存到客户端。设置Store的配置项purgePageCount为0，页面缓存后将不会被丢弃。

如何设计大表取决于如何渲染和浏览速度。表越大，在视图到边界及从预取缓冲到更新数据之间的滚动范围就越多。然而，从预取缓冲中获取的数据越多，从新渲染的时间就越长。这须要在可视数据与从新渲染之间要保持一个平衡。若是应用的目标是快速浏览器，能够选择显示更多的行和数据。若是是较慢的浏览器，则可以使用显示较小的行的较小的表，从而让其更快到达可视边界，适应常常的和更频繁的刷新。

为了协助你调试Grid，Ext JS 4.1包内Examples目录下有一个名称为“Infinite Grid Tuner”的示例，它带有1个5万数据的数据集，可让你设置不一样的方式经过预处理缓冲为Store加载数据。例如，能够模拟Ajax的延时、修改预取数据的行数以及调整表的大小。你能够经过修改下图左侧上显示的不一样的参数，研究一下怎样设置才能让你的应用在浏览器上表现得更好。

经过Infinite Grid Tuner，你能够调整Store的purgePageCount设置。该设置会在渲染后从页缓存中删除大量数据。若是设置为0，它会在缓存中保存全部数据，这意味着，若是用户滚动Grid，将不须要从服务器中加载数据。

使用Infinite Grid Tuner，要清楚两个概念：Grid内的可视数据能够被看做是一个滑动窗口。一样，页面缓存也能够被看做与Grid相关的滑动窗口的全部数据。你可使用tuner改变二者的大小，还能够为它们分别补充规则，以肯定从可视边界到从Grid可视部分和页面缓存获取数据之间，用户的滚动行数所在位置。

原文地址： http://www.mhzg.net/a/20123/2012368450567.html