優化基於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