Angular 1 深度剖析：脏数据搜检与 angular 机能优化

2019年8月25日 207次阅读 来源: CarterLi

TL;DR

  1. 脏搜检是一种模子到视图的数据映照机制，由 $apply 或 $digest 触发。
  2. 脏搜检的局限是悉数页面，不受地区或组件分别影响
  3. 运用只管简朴的绑定表达式提拔脏搜检实行速率
  4. 只管削减页面上绑定表达式的个数（单次绑定和ng-if）
  5. 给 ng-repeat 增加 track by 让 angular 复用已有元素

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

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

看似简朴，实在水很深。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 的值，也能够两个值都改了，也能够都没改。

那末 angular 究竟应当怎样得知 onClick() 这段代码后是不是应当革新 UI，应当更新哪一个 DOM 元素？

angular 必需去挨个搜检这些元素对应绑定表达式的值是不是有被转变。这就是脏数据搜检的由来（脏数据搜检以下简称脏搜检）。

脏搜检怎样被触发

angular 会在能够触发 UI 变动的时刻举行脏搜检：这句话并不正确。现实上，脏搜检是 $digest](https://docs.angularjs.org/api/ng/type/$rootScope.Scope#$digest) 实行的，另一个更经常使用的用于触发脏搜检的函数 [$apply 实在就是 $digest 的一个简朴封装（还做了一些抓非常的事变）。

一般写代码时我们无需主动挪用 $apply 或 $digest 是因为 angular 在外部对我们的回调函数做了包装。比方经常使用的 ng-click，这是一个指令（Directive），内部完成则 相似 于

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 的表达式是不是跟触发脏搜检的事宜有关。

比方：

<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 会不会监听页面左侧导航栏的变化。

脏搜检与运转效力

脏搜检慢吗？

说实话脏搜检效力是不高，然则也谈不上有多慢。简朴的数字或字符串比较能有多慢呢？十几个表达式的脏搜检能够直接忽略不计；上百个也能够接收；成百上千个就有很大题目了。绑定大批表达式时请注重所绑定的表达式效力。发起注重一下几点：

  1. 表达式（以及表达式所挪用的函数）中少写太甚庞杂的逻辑
  2. 不要衔接太长的 filter（每每 filter 里都邑遍历而且天生新数组）
  3. 不要接见 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>

有以下长处：

  1. 起首 DOM 树中的元素个数明显削减至四分之一，下降内存占用
  2. 其次 $watch 表达式也削减至四分之一，提拔脏搜检轮回的速率
  3. 假如这个 tab 下面有 controller（比方每一个 tab 都被封装为一个组件），那末仅当这个 tab 被选中时该 controller 才会实行，能够削减各页面的相互滋扰
  4. 假如 controller 中挪用接口猎取数据，那末仅当对应 tab 被选中时才会加载，防止收集拥堵

固然也有瑕玷：

  1. DOM 重修自身费时候
  2. 假如 tab 下有 controller，那末每次该 tab 被选中时 controller 都邑被实行
  3. 假如在 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 元素

  • 1
  • 2
  • 3
  • 4

没有题目。假如我增加一个按钮以下：

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

请斟酌：当用户点击这个按钮会发作什么？

我们一步一步剖析。最先的时刻，angular 纪录了 array 的初始状况为：

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

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

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

二者比较：

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

犹如你所见：angular 经由比较，看到的是：

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

回响反映到 DOM 元素上就是：

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

能够看到，删除一个元素致使了悉数 ul 序列的革新。要晓得 DOM 操纵要比 JS 变量操纵要慢很多，相似如许的无用操纵最好能想办法防止。

那末题目出在那里呢？用户删除了数组的第一个元素，致使了悉数数组元素前移；然则 angular 没法得知用户做了如许一个删除操纵，只能傻傻的按下标一个一个比。

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

详解 track by

用来标记数组元素的肯定是数组里相似 ID 的某个值。这个值肯定要相符以下这两个特性。

  1. 不能重复。ID 重复了什么鬼
  2. 值肯定要简朴。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

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

二者对不上，申明数组被做了增删元素或许挪动元素的操纵。将其规整

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

那末明显，第一个元素被删除了。再比较盈余的元素

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

结论是：

  1. 原数组第一个元素被删除
  2. 其他没变

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：

  • 2
  • 3
  • 4
  • 5

这里请再次注重：数组 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 的现实效果为

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

二者对不上，申明数组被做了增删元素或许挪动元素的操纵。将其规整

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

结论是：

  1. 原数组悉数 4 个元素被删除
  2. 新增加了 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 重构悉数项目的时候，未来的事变谁晓得呢？

    原文作者：CarterLi
    原文地址: https://segmentfault.com/a/1190000010433675
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞