這篇文章主要介紹了AngularJS框架使用過程當中的一些性能優化要點,Angular通常被用來制作大型單頁應用,因而性能問題也是必須考慮的因素,需要的朋友可以參考下

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() 已經在很多場景被討論過的?；旧蟬cope.$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適應性也很好。但我們必須打破一些規則來實現我們的想法，稍后討論。

201635161723160.jpg (590×558)

一個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次測試的平均值)：

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

“從服務器獲取數據”里的數據包括了我們使用AJAX從后端獲取log數據的時間。這個跟點擊下一頁按鈕不同，因為我們預取下一頁的log數據，但是或許適用于其他的UI響應。即使這樣，優化后的程序也可以做到實時更新。