整理AngularJS架構使用過程當中的一些效能最佳化要點_AngularJS

1. 簡介

無論你正在編寫一箇舊的應用程式還是在一個大型應用中採用AngularJS，效能是一個重要的方面。瞭解是什麼原因導致AngularJS應用程式慢下來非常重要，要知道，在開發過程中做出權衡是很重要的。本文將介紹一些AngularJS比較常見的效能問題，以及最佳化的建議。

2. 效能測試工具

本文採用jsPerf http://jsperf.com/ 效能測試的基準。

3. 軟體效能

評價軟體效能有兩個基本的因素：

首先是演算法的時間複雜度。一個簡單的例子就是線性搜尋和二分檢索有著非常顯著的效能差距。

第二個軟體緩慢的原因被稱為空白間複雜度。這是一台電腦需要多少“空間”或記憶體運行你的應用程式。記憶體需求越多，運行速度就越慢。

4 Javascript的效能

有些效能問題不僅僅是Angular帶來的，而是JavaScript本來就有的。

4.1 迴圈

避免在迴圈內部調用函數，可以移到外部調用。

var sum = 0;for(var x = 0; x < 100; x++){ var keys = Object.keys(obj); sum = sum + keys[x];}

上面的方面明顯沒有下面的快：

var sum = 0;var keys = Object.keys(obj);for(var x = 0; x < 100; x++){ sum = sum + keys[x];}

4.2 DOM訪問

在擷取DOM元素時要注意

angular.element('div.elementClass')

這種方式是非常昂貴的。其實這在AngularJS中並不會引起太大的問題。但是留意一下是有好處的。DOM樹要小，DOM的訪問要儘可能的少。

4.3 變數作用範圍記憶體回收

把你的變數作用範圍限制地越緊密越好，這樣記憶體回收行程就可以更快地回收空間。注意下面的問題：

function demo(){ var b = {childFunction: function(){  console.log('hi this is the child function') }; b.childFunction(); return b;}

當這個函數終上了，這裡就沒有到b的引用。b就會被回收了。但是如果有這樣一行：

var cFunc = demo();

這個引用就會阻止記憶體回收。要盡量避免這類引用。

4.4 數組和對象

這裡有很多點：

比如：

for (var x=0; x<arr.length; x++) { i = arr[x].index;}

比這一種快一點(注* arr為數組， obj為json對象)

for (var x=0; x<100; x++) { i = obj[x].index;}

比這一種更快一點

var keys = Object.keys(obj);for (var x = 0; x < keys.length; x++){ i = obj[keys[x]].index;}

5 重要的概念

我們已經討論過有關JavaScript的效能，現在有必要看一看AngualrJS中的核心概念，看看它究竟是怎麼運作的。

5.1 域（Scopes）和更新周期（Digest Cycle）

Angular的域本質上是一些JavaScript對象，它們從一些預定義的對象繼承而來。基本上，小的域比大的域運行要快。

換句話說，每建立一個新的域，都會給記憶體回收行程添加更多待回收的內容。

在寫AngularJS應用中尤其要注意的一個核心概念和效能影響方面是更新周期（Digest Cycle）。實際上每一個域都會存放一個由方法組成的數組 $$watchers。

每當域中的一個值（屬性）或綁定的DOM，如 ng-repeat，ng-switch 和 ng-if 等等，調用 $watch 時，一個函數(function)就會添加到相對應域中的$$watchers數組隊列中。

當域中的值發生改變時，在$$watchers中所有的watchers函數都會被觸發調用。並且當它們的任何一個修改了域中的某個值時，它們會被再次觸發執行。

這個過程會一直迴圈下去直到$$watcher數組隊列中不再做任何更改或拋出異常為止。

更外如果任何代碼執行$scope.$apply()，都會觸發更新周期。

最後一點是 $scope.evalAsync() 會在一個非同步呼叫中執行，並且在當前和下個執行循環中，不會調用其的更新周期。

6. 在設計Angular時應該遵守的一般準則

6.1 大型物件和伺服器調用

所以這些都告訴了我們什嗎？首先我們要儘可能地簡化我們的對象。當對象是從伺服器返回時，這一點尤為重要。

直接將資料庫中的一行轉換成對象只是臨時性方案，因此不要使用.toJson().

只需要把Angular需要的屬性值返回回來。

6.2 監視函數（Watching Functions）

另一個常見的問題是為觀察者綁定的函數。不要將任何東西（ng-show, ng-repeat等等）直接綁定到一個函數。不要直接監視任何函數的傳回值。該函數會在每個更新周期都執行，可能會降低你應用的速度。

6.3 監視對象(Watching Objects)

同樣，Angular提供了第三個選擇性參數來監視整個對象的改動。將調用$watch的第三個參數設為true。這是一個非常可怕的想法。一個更好的解決辦法是依靠服務和對象的引用，監視域之間的變化。

7 列表問題

7.1 長列表（Lists）

盡一些可能避免長列表。ng-repeat會進行了一些很重的DOM操作（更不用說對$$watchers的汙染），所以無論是在分頁或是在無限滾動中，盡量使用小型資料進行渲染。

7.2 過濾器(Filters)

要盡量避免使用過濾器。他們會在每個更新周期運行兩次，每當發生任何改變時運行一次，另一次是收集更深層次的改變時觸發。所以不要直接從內部列表中移除對象，使用CSS控制即可。（注* 用添加CSS類名去隱掉他們）

渲染時的 $index 值並不是真正的數組索引值，它豪無價值。但是排好序的數組索引，無法讓你遍曆到所有列表中的域。

7.3 更新 ng-repeat

當使用ng-repeat時要盡量避免對全域列表的重新整理。ng-repeat會產生一個$$hashkey屬性和一系統唯一的項。這意味著當你調用 scope.listBoundToNgRepeat = serverFetch() 時會引起對整個列表的重新重新整理。會通知執行所有的watchers並觸發每一個元素，這是非常消耗效能的。

這裡有兩種解決方案。一種是維護兩個集合，和帶有過慮器(filter)的ng-repeat(基本上需要自訂同步邏輯，因此演算法更複雜，可維護性更差)，另一種方案是使用track by去指定你自己的key(Angular 1.2 開始支援，只需要很少的同步邏輯)。

總之：

scope.arr = mockServerFetch();

會比下面的這種慢

var a = mockServerFetch();for(var i = scope.arr.length - 1; i >=0; i--){ var result = _.find(a, function(r){ return (r && r.trackingKey == scope.arr[i].trackingKey); }); if (!result){ scope.arr.splice(i, 1); } else { a.splice(a.indexOf(scope.arr[i]), 1); } }_.map(a, function(newItem){ scope.arr.push(newItem);});

這種

<div ng-repeat="a in arr track by a.trackingKey">

比上面的慢些

<div ng-repeat="a in arr">

8 渲染問題

另一個引起Angular應用慢的原因是不正確地使用 ng-hide/ ng-show 或 ng-switch。

ng-hide 和 ng-show 簡單地對CSS display屬性進行切換。這意味著表面上看不見的東西其實還存在於域中， 所有的$$watchers還是會被觸發。

ng-if 和 ng-switch實際上從DOM中完全移除了，相應的域也會被移除。效能差異顯而易見。

9. 更新周期問題

9.1 綁定

盡量減少你的綁定。在Angular 1.3中這裡有一個新的一次綁定文法，{{::scopeValue}}。它只會被域執行一次，並不添加到監視器要監視列表中（watcher array）.

9.2 $digest() 和 $apply()

scope.$apply 是一個強大的工具，可以讓你向Angular引入外部的值。本質上它會觸發Angular的所有事件（例如ng-click）。問題是scope.$apply會從根域$rootScope開始，遍曆所有的域鏈，觸發每一個域。

scope.$digest只會執行指定域及其相關的域。兩種效能差異不言自明。折中的方案是，不觸發任何域等到下一個更新周期再更新。

9.3 $watch()

scope.$watch() 已經在很多情境被討論過的。基本上scope.$watch是不好的設計的一個標誌。如果你非要建立一個觀察者。記住對它儘可能地解除綁定。你可以用$watch的返回函數解除綁定。

var unbinder = scope.$watch('scopeValueToBeWatcher', function(newVal, oldVal) { });unbinder(); //這一行將watcher從 $$watchers 中移除。

如果你不能早一點解除綁定，記住在 $on('$destroy') 中進行解除綁定。

9.4 $on, $broadcast 和 $emit

像$watch一樣，他們都是一些很慢的事件，（有可能）遍曆整個範圍。他們可能像GOTO一樣，讓你的程式無法調試。不過幸運地是像$watch一樣，他們都可以在完全不需要的時侯解除綁定。比如在 $on('$destroy')中。

9.5 $destroy

像前面提到的那樣，你應該在$on('$destroy')中解除綁定你所有的事件接聽程式，取消任何$timeout的執行個體，或者任何其它非同步執行的互動。這不僅僅是確保安全。還可以讓你的域更快地被記憶體回收。不這樣做，他們會一直在後台運行。直接你清空CPU和RAM。

另外，解除綁定DOM上的事件接聽程式也非常重要，不這樣做很可能在老式瀏覽器中引起記憶體泄露。

9.6 $evalAsync

scope.$evalAsync是一個強大的工具。它可以在當前域中執行，並不觸發域的更新。evalAsync可以極大地提高你網頁的效能。

10 指令問題

10.1 隔離的域（Isolate Scope）和Transclusion

域隔離和Transclusion是Angular最另人激動的特性，它們是Angular的核心組件。

但是這裡也有一些權衡，指令不能直接建立一個替換他們父組元素的域。通過隔離的域或Transclusion我們可以建立一個新的對象去跟蹤，添加新的監視器，但是這也會降低應用的效能。在添加之前應該仔細想一想有沒有這個必要。

10.2 編繹周期

指令(Directive)的compile函數是在域被附加前操作DOM的完美功能（比如說綁定事件）。一個很重要的效能方面是，傳入compile函數的元素和屬性以原始html模板呈現。只會被運行一次，接下來會直接使用。另外一個重要的點是prelink和postlink的區別。prelink從外向內執行。postlinks從內向外執行。prelink效能稍好一些，因為它不會產生第二次更新周期。但是這時子項目的DOM還未被建立。

11 DOM事件問題

Angular提供了很多預定義的DOM事件指令。ng-click，ng-mouseenter，ng-mouseleave等等。當調用scole.$apply()時這些事件都會被執行。另外一種更有效率的方式是直接在DOM上面綁定addEventListener，並且盡量使用scope.$digest

最佳化執行個體

測試一個應用程式框架確實是個嚴峻的挑戰，當使用者點擊日誌中任何一個單詞，我們就要搜尋出相關資訊，而頁面上可以點擊的元素又不計其數；我們想讓日誌的分頁功能也瞬間得到反饋。我們其實已經預先擷取到了下一頁面的日誌資料，所以使用者介面的更新就成為了瓶頸，如果拿 AngularJS直接實現日誌視圖的換頁功能需要1.2秒，但是如果仔細最佳化一下的話就可以降到35毫秒。這些最佳化被證明在應用的其他部分也是適用的，並且對AngularJS適應性也很好。但我們必須打破一些規則來實現我們的想法，稍後討論。

一個Github更新的日誌demo

An AngularJS log viewer

本質上，日誌視圖就是一個日誌訊息的列表，每個字都可以點擊。所以把Angular的指令加到DOM元素中，簡單實現如下：

<span class='logLine' ng-repeat='line in logLinesToShow'> <span class='logToken' ng-repeat='token in line'>{{token | formatToken}} </span> </span>

在單頁面應用中有個數千個tokens是很正常的，在早期的測試中，我們發現進入日誌的下一頁會花費好幾秒來執行JavaScript。更糟的是，不相關的操作(比如點擊導航下拉框)延遲也不輕，AngularJS的大神說最好把資料元素綁定的數量控制在200以下。對於一個單詞就是一個元素的我們來說，早已遠超這個數。

分析：

用Chrome的JavaScript profiler工具，我們可以快速定位兩個拖延點。首先，每次更新要花大量時間在DOM元素的建立和銷毀上，如果新的view有不同的行數，或者任何一行有不同數量單詞，Angular的ng-repeat指令就會建立或者銷毀DOM元素，這個代價太大了。

其次，每一個單詞都有自己的change watcher，AngularJS會watch這些單詞，一旦滑鼠點擊就會觸發，這個是影響不相關操作(下拉式功能表導航)延遲的罪魁禍首。

最佳化#1：緩衝DOM elements

我們建立了一個ng-repeat指令的變體，在我們的版本中，如果綁定資料的數量減少了，超出的DOM元素會隱藏而不是銷毀，如果元素的數量過會兒有增加了，我們會重用這些緩衝的元素。

最佳化#2：Aggregate watchers

用來調用change watchers的所有時間大部分都浪費了，在我們的應用中，特定單詞上的資料繫結都是永遠不會改變的除非整個日誌訊息變化，為了達成這一點，我們建立了一個指令”hides“隱藏掉了子項目的change watchers，只有等特定父元素運算式修改的時候才會調用他們。就這樣，我們避免了在每一次滑鼠點擊或者其他微小的修改而導致的全盤change watchers(為了實現這個想法，我們稍微修改了AngularJS的抽象層，我們稍後再細說)。

最佳化#3：延遲元素建立

前面說了，我們為日誌裡的每一個單詞單獨建立了DOM，我們可以利用每一行的單個DOM元素得到相同的視覺呈現；其他元素都是為響應滑鼠點操作而建立的，因此，我們決定延遲這部分建立，只有當滑鼠移動到某行的時候我們再建立他。

為了實現這個，我們為每一行建立了兩個版本，一個就是簡單的文本元素來顯示完整的日誌資訊，另外一行就是個預留位置，用來顯示最終為每一個單詞填充後的效果。這個預留位置開始是隱藏的，當滑鼠移動到那一行的時候才會顯示，而簡單文本那一行這個時候就隱藏掉。下面會講到，顯示預留位置是如何填充單詞元素的。

最佳化#4：避開對隱藏元素的監視

我們建立了另外一個指令，用來阻止對隱藏元素的監視，這個指令支援最佳化#1，相較於原資料，我們多了更多的隱藏DOM節點，所以必須消除對多出來的DOM節點的監視。這也支援最佳化#3，讓延遲單詞節點的建立更加容易。因為直到這行資料的tokenized版本出現我們才會建立他 。

下面的代碼就是所有的最佳化後的樣子，我們自訂的指令是粗體顯示。

<span class='logLine' sly-repeat='line in logLinesToShow' sly-evaluate-only-when='logLines'> <div ng-mouseenter=”mouseHasEntered = true”>  <span ng-show='!mouseHasEntered'>{{logLine | formatLine }} </span>  <div ng-show='mouseHasEntered' sly-prevent-evaluation-when-hidden>   <span class='logToken' sly-repeat='tokens in line'>{{token | formatToken }}</span>  </div> </div> </span>

Sly-repeat 是ng-repeat的變體，用來隱藏多出來的DOM元素而不是銷毀他們，sly-evaluate-only-when阻止內部change watchers除非“logLines”變數修改，sly-prevent-evaluation-when-hidden主要負責當滑鼠移動到指定行的上面的時候，隱藏的div才顯示。

這裡展示出了AngularJS對於封裝和分離的控制力，我們做了複雜的最佳化但是並沒有影響模板的結構(這裡展示的代碼並不是真正產品裡的代碼，但是他展示了所有的要點)。

結果：

我們來看一下效果，我們添加了一些代碼來衡量，從滑鼠點擊開始，一直到Angular's $digest迴圈結束(意味著更新DOM結束)。

我們衡量點擊”下一頁“按鈕的效能是通過Tomcat日誌，環境用的是MacBook Pro上的Chrome，結果見下表(每個資料都是10次測試的平均值)：

	資料已經緩衝	從伺服器擷取資料
簡單實現	1190 ms	1300 ms
最佳化後	35 ms	201 ms

這些資料不包括瀏覽器用在DOM布局和重繪(JavaScript執行完成後)的時間，每次大概30毫秒。儘管如此，效果也顯而易見；下一頁的回應時間從1200毫秒驟降至35毫秒(如果算上渲染是65毫秒)。

“從伺服器擷取資料”裡的資料包括了我們使用AJAX從後端擷取log資料的時間。這個跟點擊下一頁按鈕不同，因為我們預取下一頁的log資料，但是或許適用於其他的UI響應。即使這樣，最佳化後的程式也可以做到即時更新。