Angular 1 深度解析：脏数据检查与 angular 性能优化

时间 2019-11-15

原文原文链接

TL;DR

脏检查是一种模型到视图的数据映射机制，由 $apply 或 $digest 触发。
脏检查的范围是整个页面，不受区域或组件划分影响
使用尽可能简单的绑定表达式提高脏检查执行速度
尽可能减小页面上绑定表达式的个数（单次绑定和ng-if）
给 ng-repeat 添加 track by 让 angular 复用已有元素

什么是脏数据检查（Dirty checking）

Angular 是一个 MVVM 前端框架，提供了双向数据绑定。所谓双向数据绑定（Two-way data binding）就是页面元素变化会触发 View-model 中对应数据改变，反过来 View-model 中数据变化也会引起所绑定的 UI 元素数据更新。操做数据就等同于操做 UI。html

看似简单，其实水很深。UI 元素变化引起 Model 中数据变化这个经过绑定对应 DOM 事件（例如 input 或 change）能够简单的实现；然而反过来就不是那么容易。前端

好比有以下代码：程序员

<p ng-bind="content1"></p>
<p ng-bind="content2"></p>
<button ng-click="onClick()">Click Me</button>

用户点击了 button，angular 执行了一个叫 onClick 的方法。这个 onClick 的方法体对于 angular 来讲是黑盒，它到底作了什么不知道。可能改了 $scope.content1 的值，可能改了 $scope.content2 的值，也可能两个值都改了，也可能都没改。angularjs

那么 angular 到底应该怎样得知 onClick() 这段代码后是否应该刷新 UI，应该更新哪一个 DOM 元素？算法

angular 必须去挨个检查这些元素对应绑定表达式的值是否有被改变。这就是脏数据检查的由来（脏数据检查如下简称脏检查）。数据库

脏检查如何被触发

angular 会在可能触发 UI 变动的时候进行脏检查：这句话并不许确。实际上，脏检查是 $digest 执行的，另外一个更经常使用的用于触发脏检查的函数 $apply 其实就是 $digest 的一个简单封装（还作了一些抓异常的工做）。express

一般写代码时咱们无需主动调用 $apply 或 $digest 是由于 angular 在外部对咱们的回调函数作了包装。例如经常使用的 ng-click，这是一个指令（Directive），内部实现则相似于json

DOM.addEventListener('click', function ($scope) {
  $scope.$apply(() => userCode());
});

能够看到：ng-click 帮咱们作了 $apply 这个操做。相似的不仅是这些事件回调函数，还有 $http、$timeout 等。我听不少人抱怨说 angular 这个库太大了什么都管，其实你能够不用它自带的这些服务（Service），只要你记得手工调用 $scope.$apply。后端

脏检查的范围

前面说到：angular 会对全部绑定到 UI 上的表达式作脏检查。其实，在 angular 实现内部，全部绑定表达式都被转换为 $scope.$watch()。每一个 $watch 记录了上一次表达式的值。有 ng-bind="a" 即有 $scope.$watch('a', callback)，而 $scope.$watch 可不会管被 watch 的表达式是否跟触发脏检查的事件有关。api

例如：

<div ng-show="false">
  <span id="span1" ng-bind="content"></span>
</div>
<span id="span2" ng-bind="content"></span>
<button ng-click="">TEST</button>

问：点击 TEST 这个按钮时会触发脏检查吗？触发几回？

首先：ng-click="" 什么都没有作。angular 会由于这个事件回调函数什么都没作就不进行脏检查吗？不会。

而后：#span1 被隐藏掉了，会检查绑定在它上面的表达式吗？尽管用户看不到，可是 $scope.$watch('content', callback) 还在。就算你直接把这个 span 元素干掉，只要 watch 表达式还在，要检查的还会检查。

再次：重复的表达式会重复检查吗？会。

最后：别忘了 ng-show="false"。多是由于 angular 的开发人员认为这种绑定常量的状况并很少见，因此 $watch 并无识别所监视的表达式是不是常量。常量依旧会重复检查。

因此：

答：触发三次。一次 false，一次 content，一次 content

因此说一个绑定表达式只要放在当前 DOM 树里就会被监视，无论它是否可见，无论它是否被放在另外一个 Tab 里，更无论它是否与用户操做相关。

另外，就算在不一样 Controller 里构造的 $scope 也会互相影响，别忘了 angular 还有全局的 $rootScope，你还能够 $scope.$emit。angular 没法保证你绝对不会在一个 controller 里更改另外一个 controller 生成的 scope，包括自定义指令（Directive）生成的 scope 和 Angular 1.5 里新引入的组件（Component）。

因此说不要怀疑用户在输入表单时 angular 会不会监听页面左边导航栏的变化。

脏检查与运行效率

脏检查慢吗？

说实话脏检查效率是不高，可是也谈不上有多慢。简单的数字或字符串比较能有多慢呢？十几个表达式的脏检查能够直接忽略不计；上百个也能够接受；成百上千个就有很大问题了。绑定大量表达式时请注意所绑定的表达式效率。建议注意一下几点：

表达式（以及表达式所调用的函数）中少写太过复杂的逻辑
不要链接太长的 filter（每每 filter 里都会遍历而且生成新数组）
不要访问 DOM 元素。

使用单次绑定减小绑定表达式数量

单次绑定（One-time binding 是 Angular 1.3 就引入的一种特殊的表达式，它以 :: 开头，当脏检查发现这种表达式的值不为 undefined 时就认为此表达式已经稳定，并取消对此表达式的监视。这是一种行之有效的减小绑定表达式数量的方法，与 ng-repeat 连用效果更佳（下文会提到），但过分使用也容易引起 bug。

善用 `ng-if` 减小绑定表达式的数量

若是你认为 ng-if 就是另外一种用于隐藏、显示 DOM 元素的方法你就大错特错了。

ng-if 不只能够减小 DOM 树中元素的数量（而非像 ng-hide 那样仅仅只是加个 display: none），每个 ng-if 拥有本身的 scope，ng-if 下面的 $watch 表达式都是注册在 ng-if 本身 scope 中。当 ng-if 变为 false，ng-if 下的 scope 被销毁，注册在这个 scope 里的绑定表达式也就随之销毁了。

考虑这种 Tab 选项卡实现：

<ul>
  <li ng-class="{ selected: selectedTab === 1 }">Tab 1 title</li>
  <li ng-class="{ selected: selectedTab === 1 }">Tab 2 title</li>
  <li ng-class="{ selected: selectedTab === 1 }">Tab 3 title</li>
  <li ng-class="{ selected: selectedTab === 1 }">Tab 4 title</li>
</ul>
<div ng-show="selectedTab === 1">[[Tab 1 body...]]</div>
<div ng-show="selectedTab === 2">[[Tab 2 body...]]</div>
<div ng-show="selectedTab === 3">[[Tab 3 body...]]</div>
<div ng-show="selectedTab === 4">[[Tab 4 body...]]</div>

对于这种会反复隐藏、显示的元素，一般人们第一反应都是使用 ng-show 或 ng-hide 简单的用 display: none 把元素设置为不可见。

然而入上文所说，肉眼不可见不表明不会跑脏检查。若是将 ng-show 替换为 ng-if 或 ng-switch-when

<div ng-if="selectedTab === 1">[[Tab 1 body...]]</div>
<div ng-if="selectedTab === 2">[[Tab 2 body...]]</div>
<div ng-if="selectedTab === 3">[[Tab 3 body...]]</div>
<div ng-if="selectedTab === 4">[[Tab 4 body...]]</div>

有以下优势：

首先 DOM 树中的元素个数显著减小至四分之一，下降内存占用
其次 $watch 表达式也减小至四分之一，提高脏检查循环的速度
若是这个 tab 下面有 controller（例如每一个 tab 都被封装为一个组件），那么仅当这个 tab 被选中时该 controller 才会执行，能够减小各页面的互相干扰
若是 controller 中调用接口获取数据，那么仅当对应 tab 被选中时才会加载，避免网络拥挤

固然也有缺点：

DOM 重建自己费时间
若是 tab 下有 controller，那么每次该 tab 被选中时 controller 都会被执行
若是在 controller 里面调接口获取数据，那么每次该 tab 被选中时都会从新加载

各位读者本身取舍。

当脏检查赶上数组

ng-repeat！这就更有（e）趣（xin）了。一般的绑定只是去监听一个值的变化（绑定对象也是绑定到对象里的某个成员），而 ng-repeat 却要监视一整个数组对象的变化。例若有：

<ul ng-init="array = [
  { value: 1 },
  { value: 2 },
  { value: 3 },
  { value: 4 },
]">
  <li ng-repeat="item in array" ng-bind="item.value"></li>
</ul>

会生成 4 个 li 元素

没有问题。若是我添加一个按钮以下：

<button ng-click="array.shift()">删除第一个元素</button>

请考虑：当用户点击这个按钮会发生什么？

咱们一步一步分析。开始的时候，angular 记录了 array 的初始状态为：

[
  { "value": 1 },
  { "value": 2 },
  { "value": 3 },
  { "value": 4 }
]

当用户点击按钮后，数组的第一个元素被删除了，array 变为：

[
  { "value": 2 },
  { "value": 3 },
  { "value": 4 }
]

二者比较：

array.length = 4 => array.length = 3
array[0].value = 1 => array[0].value = 2
array[1].value = 2 => array[1].value = 3
array[2].value = 3 => array[2].value = 4
array[3].value = 4 => array[3].value = undefined （array[4] 为 undefined，则 undefined.value 为 undefined，见 Angular 表达式的说明）

如同你所见：angular 通过比较，看到的是：

数组长度减小了 1
数组第 1 个元素的 value 被改成 2
数组第 2 个元素的 value 被改成 3
数组第 3 个元素的 value 被改成 4

反应到 DOM 元素上就是：

第 1 个 li 内容改成 2
第 2 个 li 内容改成 3
第 3 个 li 内容改成 4
第 4 个 li 删掉

能够看到，删除一个元素致使了整个 ul 序列的刷新。要知道 DOM 操做要比 JS 变量操做要慢得多，相似这样的无用操做最好能想办法避免。

那么问题出在哪里呢？用户删除了数组的第一个元素，致使了整个数组元素前移；然而 angular 无法得知用户作了这样一个删除操做，只能傻傻的按下标一个一个比。

那么只要引入一种机制来标记数组的每一项就行了吧。因而 angular 引入了 track by

详解 track by

用来标记数组元素的必定是数组里相似 ID 的某个值。这个值必定要符合如下这两个特色。

不能重复。ID 重复了什么鬼
值必定要简单。ID 是用于比较相等的，有时候因为算法不一样可能还要比较大小，处于速度考虑不能太复杂。

基于这两个特色。若是用户没有给 ng-repeat 指定 track by 的表达式，则默认为内置函数 $id。$id 会检查 item 中有没有一个名为 $$hashKey 的成员。若有，返回其值；如没有，则生成一个新的惟一值写入。这就是数组中那个奇怪的 $$hashKey 成员来历，默认值是 "object:X"（你问我为何是个字符串而不是数字？我怎么知道。。。）

仍是前面的问题，引入 track by 后再来看。由于没有指定 track by，则默认为 $id(item)，实际为 $$hashKey。

<ul ng-init="array = [
  { value: 1 },
  { value: 2 },
  { value: 3 },
  { value: 4 },
]">
  <li ng-repeat="item in array track by $id(item)" ng-bind="item.value"></li>
</ul>

开始的时候，$id(item) 给数组中全部项建立了 $$hashKey

这时 angular 记录了 array 的初始状态为：

[
  { "value": 1, "$$hashKey": "object:1" },
  { "value": 2, "$$hashKey": "object:2" },
  { "value": 3, "$$hashKey": "object:3" },
  { "value": 4, "$$hashKey": "object:4" }
]

当用户点击按钮后，数组的第一个元素被删除了，array 变为：

[
  { "value": 2, "$$hashKey": "object:2" },
  { "value": 3, "$$hashKey": "object:3" },
  { "value": 4, "$$hashKey": "object:4" }
]

先比较 track by 的元素，这里为 $id(item)，即 $$hashKey

"object:1" => "object:2"
"object:2" => "object:3"
"object:3" => "object:4"
"object:4" => undefined

二者对不上，说明数组被作了增删元素或者移动元素的操做。将其规整

"object:1" => undefined
"object:2" => "object:2"
"object:3" => "object:3"
"object:4" => "object:4"

那么显然，第一个元素被删除了。再比较剩余的元素

array[0].value = 2 => array[0].value = 2
array[1].value = 3 => array[1].value = 3
array[2].value = 4 => array[2].value = 4

结论是：

原数组第一个元素被删除
其余没变

angular 经过将新旧数组的 track by 元素作 diff 猜想用户的行为，最大可能的减小 DOM 树的操做，这就是 track by 的用处。

默认 track by 的坑

So far so good! 然而需求某天有变，程序员小哥决定用 filter 给数组作 map 后再渲染。

<ul ng-init="array = [
  { value: 1 },
  { value: 2 },
  { value: 3 },
  { value: 4 },
]">
  <li ng-repeat="item in array | myMap" ng-bind="item.value"></li>
</ul>

map 定义以下：

xxModule.filter('map', function () {
  return arr => arr.map(item => ({ value: item.value + 1 }));
});

ng-repeat 执行时先计算表达式 array | myMap 的值：

arrayForNgRepeat = [
  { value: 2 },
  { value: 3 },
  { value: 4 },
  { value: 5 },
]

注意数组 arrayForNgRepeat 和原来的数组 array 不是同一个引用，由于 filter 里的 map 操做生成了一个新数组，每一项都是新对象，跟原数组无关。

ng-repeat 时，angular 发现用户没有指定 track by，按照默认逻辑，使用 $id(item) 做为 track by，添加 $$hashKey

arrayForNgRepeat = [
  { value: 2, "$$hashKey": "object:1" },
  { value: 3, "$$hashKey": "object:2" },
  { value: 4, "$$hashKey": "object:3" },
  { value: 5, "$$hashKey": "object:4" },
]

生成 DOM：

这里请再次注意：数组 arrayForNgRepeat 与原始数组 array 没有任何关系，数组自己是不一样的引用，数组里的每一项也是不一样引用。修改新数组的成员不会影响到原来的数组。

这时 array 的值：

array = [
  { value: 1 },
  { value: 2 },
  { value: 3 },
  { value: 4 },
]

这时用户的某个无关操做触发了脏检查。针对 ng-repeat 表达式，首先计算 array | myMap 的值：

newArrayForNgRepeat = [
  { value: 2 },
  { value: 3 },
  { value: 4 },
  { value: 5 },
]

先比较 track by 的元素。用户没有指定，默认为 $id(item)。

$id 发现数组中有一些元素没有 $$hashKey，则给它们填充新 $$hashKey，结果为

newArrayForNgRepeat = [
  { value: 2, "$$hashKey": "object:5" },
  { value: 3, "$$hashKey": "object:6" },
  { value: 4, "$$hashKey": "object:7" },
  { value: 5, "$$hashKey": "object:8" },
]

这时两边的 track by 的实际结果为

"object:1" => "object:5"
"object:2" => "object:6"
"object:3" => "object:7"
"object:4" => "object:8"

二者对不上，说明数组被作了增删元素或者移动元素的操做。将其规整

"object:1" => undefined
"object:2" => undefined
"object:3" => undefined
"object:4" => undefined
undefined => "object:5"
undefined => "object:6"
undefined => "object:7"
undefined => "object:8"

结论是：

原数组所有 4 个元素被删除
新添加了 4 个元素

因而 angular 把原来全部 li 删除，再建立 4 个新的 li 元素，填充它们的 textContent，放到 ul 里

若是怀疑我说的话，请本身在浏览器里测试。你能够清楚的看到调试工具里 DOM 树的闪烁

`track by` 与性能

不恰当的 ng-repeat 会形成 DOM 树反复从新构造，拖慢浏览器响应速度，形成页面闪烁。除了上面这种比较极端的状况，若是一个列表频繁拉取 Server 端数据自刷新的话也必定要手工添加 track by，由于接口给前端的数据是不可能包含 $$hashKey 这种东西的，因而结果就形成列表频繁的重建。

其实没必要考虑那么多，总之加上没坏处，至少能够避免 angular 生成 $$hashKey 这种奇奇怪怪的东西。因此

请给 ng-repeat 手工添加 track by！

重要的事情再说一遍

请给 ng-repeat 手工添加 track by！

一般列表都是请求接口从数据库中读取返回的。一般数据库中的记录都有一个 id 字段作主键，那么这时使用 id 做为 track by 的字段是最佳选择。若是没有，能够选择一些业务字段可是确保不会重复的。例如一个连表头都是动态生成的表格，表头就可使用其字段名做为 track by 的字段（对象的 key 是不会重复的）。

若是真的找不到用于 track by 的字段，让 angular 自动生成 $$hashKey 也不是不能够，可是切记检查有没有出现 DOM 元素不断重刷的现象，除了仔细看调试工具的 DOM 树是否闪烁以外，给列表中的元素添加一个特别的标记（好比 style="background: red"），也是一个行之有效的方法（若是这个标记被意外清除，说明原来的 DOM 元素被删除了）。

除非真的没办法，不推荐使用 $index 做为 track by 的字段。

`track by` 与单次绑定连用

track by 只是让 angular 复用已有 DOM 元素。数组每一个子元素内部绑定表达式的脏检查仍是免不了的。然而对于实际应用场景，每每是数组总体改变（例如分页），数组每一项一般却不会单独变化。这时就能够经过使用单次绑定大量减小 $watch 表达式的数量。例如

<li ng-repeat="item in array track by item.id">
  <div>a: <span ng-bind="::item.a"></span></div>
  <div>b: <span ng-bind="::item.b"></span></div>
  <div>c: <span ng-bind="::item.c"></span></div>
  <div>d: <span ng-bind="::item.d"></span></div>
  <div>e: <span ng-bind="::item.e"></span></div>
</li>

除非 track by 字段改变形成的 DOM 树重建，item.a 等一旦显示在页面上后就不会再被监视。

若是每行有 5 个绑定表达式，每页显示 20 条记录，经过这种方法每页就能够减小 5 * 20 = 100 个绑定表达式的监视。

注意：若是在 ng-repeat 内部使用的单次绑定，就必定不要用 track by $index。不然用户切换下一页页面也不会更新。

使用分页减小绑定个数

这个就很少说了。能后端分页的就后端分页；接口不支持分页的也要前端分页；前端分页时能够简单的写个 filter 用 Array.prototype.slice 实现。

能直接减小数组中项的个数就不要在 ng-repeat 中每项上写 ng-show 或 ng-if

写在最后的话

脏检查这个东西，其实在三大主流前端框架中或多或少都有涉及。React 每次生成新的 Virtual DOM，与旧 Virtual DOM 的 diff 操做原本就能够看作一次脏检查。Vue 从相对完全的抛弃了脏检查机制，使用 Property 主动触发 UI 更新，可是 Vue 仍然不能抛弃 track by 这个东西。

既然脏检查在三大主流框架里或多或少都有所保留，为何惟独 Angular 的性能被广为诟病呢？其实仍是说在 Angular 1 的机制下，脏检查的执行范围过大以及频率太过频繁了。Angular 1.5 从 Angular 2+ 引入了组件（Component）的概念，然而形似而神非，其实只是一个特殊的 Directive 马甲而已，并不能将脏检查的执行范围限制在各个组件以内，因此并不能本质的改变 Angular 1 脏检查机制效率低下的现状。

也许 Angular 1 终将被淘汰。但 Angular 做为前端第一个 MVVM 框架，着实引起了前端框架更新换代的热潮。百足之虫死而不僵，无论怎么样我还得继续维护停留在电脑里的 Angular 1 项目。不过也许老板哪天大发慈悲给咱们用 Vue 重构整个项目的时间，未来的事情谁知道呢？

注：本文同时发布在个人 sf 专栏