有如下优点：

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 重构整个项目的时间，将来的事情谁知道呢？