TL;DR
- 脏检查是一种模型到视图的数据映射机制,由 @H_301_4@$apply 或 @H_301_4@$digest 触发。
- 脏检查的范围是整个页面,不受区域或组件划分影响
- 使用尽量简单的绑定表达式提升脏检查执行速度
- 尽量减少页面上绑定表达式的个数(单次绑定和@H_301_4@ng-if)
- 给 @H_301_4@ng-repeat 添加 @H_301_4@track by 让 angular 复用已有元素
什么是脏数据检查(Dirty checking)
@H_
301_26@Angular 是一个 MVVM 前端框架,提供了双向数据绑定。所谓双向数据绑定(Two-way data binding)就是
页面元素变化会触发 View-model 中对应数据改变,反过来 View-model 中数据变化也会引发所绑定的 UI 元素数据更新。操作数据就等同于操作 UI。
@H_
301_26@看似简单,其实水很深。UI 元素变化引发 Model 中数据变化这个通过绑定对应 DOM 事件(例如 @H_
301_4@input 或 @H_
301_4@change)可以简单的实现;然而反过来就不是那么容易。
@H_
301_26@比如有如下
代码:
<p ng-bind="content1"></p>
<p ng-bind="content2"></p>
<button ng-click="onClick()">Click Me</button>
@H_
301_26@
用户点击了 button,angular 执行了一个叫 @H_
301_4@onClick 的
方法。这个 @H_
301_4@onClick 的
方法体对于 angular 来说是黑盒,它到底做了什么不知道。可能改了 @H_
301_4@$scope.content1 的值,可能改了 @H_
301_4@$scope.content2 的值,也可能两个值都改了,也可能都没改。
@H_
301_26@那么 angular 到底应该怎样得知 @H_
301_4@onClick() 这段
代码后是否应该刷新 UI,应该更新哪个 DOM 元素?
@H_
301_26@angular 必须去挨个检查这些元素对应绑定表达式的值是否有被改变。这就是脏数据检查的由来(脏数据检查以下简称脏检查)。
脏检查如何被触发
@H_
301_26@angular 会在可能触发 UI 变更的时候进行脏检查:这句话并不准确。实际上,脏检查是
$digest 执行的,另一个更常用的用于触发脏检查的
函数 $apply 其实就是 @H_
301_4@$digest 的一个简单封装(还做了一些抓异常的工作)。
@H_
301_26@通常写
代码时我们无需主动
调用 @H_
301_4@$apply 或 @H_
301_4@$digest 是因为 angular 在外部对我们的回调
函数做了包装。例如常用的 @H_
301_4@ng-click,这是一个指令(@H_
301_4@Directive),内部实现则
类似 于
DOM.addEventListener('click',function ($scope) {
$scope.$apply(() => userCode());
});
@H_
301_26@可以看到:@H_
301_4@ng-click 帮我们做了 @H_
301_4@$apply 这个操作。类似的不只是这些事件回调
函数,还有 @H_
301_4@$http、@H_
301_4@$timeout 等。我听很多人抱怨说 angular 这个库太大了什么都管,其实你可以不用它
自带的这些服务(Service),只要你记得手工
调用 @H_
301_4@$scope.$apply。
脏检查的范围
@H_
301_26@前面说到:angular 会对所有绑定到 UI 上的表达式做脏检查。其实,在 angular 实现内部,所有绑定表达式都被转换为 @H_
301_4@$scope.$watch()。每个 @H_
301_4@$watch 记录了上一次表达式的值。有 @H_
301_4@ng-bind="a" 即有 @H_
301_4@$scope.$watch('a',callback),而 @H_
301_4@$scope.$watch 可不会管被 @H_
301_4@watch 的表达式是否跟触发脏检查的事件有关。
@H_
301_26@例如:
<div ng-show="false">
<span id="span1" ng-bind="content"></span>
</div>
<span id="span2" ng-bind="content"></span>
<button ng-click="">TEST</button>
@H_
301_26@问:点击 @H_
301_4@TEST 这个按钮时会触发脏检查吗?触发几次?
@H_
301_26@首先:@H_
301_4@ng-click="" 什么都没有做。angular 会因为这个事件回调
函数什么都没做就不进行脏检查吗?不会。
@H_
301_26@然后:@H_
301_4@#span1 被隐藏掉了,会检查绑定在它上面的表达式吗?尽管
用户看不到,但是 @H_
301_4@$scope.$watch('content',callback) 还在。就算你直接把这个 @H_
301_4@span 元素干掉,只要 watch 表达式还在,要检查的还会检查。
@H_
301_26@再次:重复的表达式会重复检查吗?会。
@H_
301_26@最后:别忘了 @H_
301_4@ng-show="false"。可能是因为 angular 的开发人员认为这种绑定常量的情况并不多见,所以 @H_
301_4@$watch 并没有识别所监视的表达式是否是常量。常量依旧会重复检查。
@H_
301_26@所以:
@H_
301_26@答:触发三次。一次 @H_
301_4@false,一次 @H_
301_4@content,一次 @H_
301_4@content
@H_
301_26@所以说一个绑定表达式只要放在当前 DOM 树里就会被监视,不管它是否可见,不管它是否被放在另一个 Tab 里,更不管它是否与
用户操作相关。
@H_
301_26@另外,就算在不同 @H_
301_4@Controller 里构造的 @H_
301_4@$scope 也会互相影响,别忘了 angular 还有全局的 @H_
301_4@$rootScope,你还可以 @H_
301_4@$scope.$emit。angular 无法保证你绝对不会在一个 @H_
301_4@controller 里更改另一个 @H_
301_4@controller
生成的 @H_
301_4@scope,
包括 自定义指令(Directive)
生成的 @H_
301_4@scope 和 @H_
301_4@Angular 1.5 里新引入的组件(Component)。
@H_
301_26@所以说不要怀疑
用户在输入表单时 angular 会不会监听
页面左边导航栏的变化。
脏检查与运行效率
@H_
301_26@脏检查慢吗?
@H_
301_26@说实话脏检查效率是不高,但是也谈不上有多慢。简单的数字或字符串比较能有多慢呢?十几个表达式的脏检查可以直接忽略不计;上百个也可以接受;成百上千个就有很大问题了。绑定大量表达式时请注意所绑定的表达式效率。建议注意一下几点:
- 表达式(以及表达式所调用的函数)中少写太过复杂的逻辑
- 不要连接太长的 @H_301_4@filter(往往 filter 里都会遍历并且生成新数组)
- 不要访问 DOM 元素。
使用单次绑定减少绑定表达式数量
@H_
301_26@单次绑定(
One-time binding 是 Angular 1.3 就引入的一种特殊的表达式,它以 @H_
301_4@:: 开头,当脏检查发现这种表达式的值不为 @H_
301_4@undefined 时就认为此表达式已经稳定,并取消对此表达式的监视。这是一种行之有效的减少绑定表达式
数量的
方法,与 @H_
301_4@ng-repeat 连用
效果更佳(下文会提到),但过度使用也容易引发 bug。
善用 @H_301_4@ng-if 减少绑定表达式的数量
@H_
301_26@如果你认为
ng-if 就是另一种用于隐藏、
显示 DOM 元素的
方法你就大错特错了。
@H_
301_26@@H_
301_4@ng-if 不仅可以减少 DOM 树中元素的
数量(而非像 @H_
301_4@ng-hide 那样仅仅只是加个 @H_
301_4@display: none),每一个 @H_
301_4@ng-if 拥有自己的 @H_
301_4@scope,@H_
301_4@ng-if 下面的 @H_
301_4@$watch 表达式都是
注册在 @H_
301_4@ng-if 自己 @H_
301_4@scope 中。当 @H_
301_4@ng-if 变为 @H_
301_4@false,@H_
301_4@ng-if 下的 @H_
301_4@scope 被销毁,
注册在这个 @H_
301_4@scope 里的绑定表达式也就随之销毁了。
@H_
301_26@考虑这种 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>
@H_
301_26@对于这种会反复隐藏、
显示的元素,通常人们第一反应都是使用 @H_
301_4@ng-show 或 @H_
301_4@ng-hide 简单的用 @H_
301_4@display: none 把元素设置为不可见。
@H_
301_26@然而入上文所说,肉眼不可见不代表不会跑脏检查。如果将 @H_
301_4@ng-show 替换为 @H_
301_4@ng-if 或 @H_
301_4@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>
@H_
301_26@有如下优点:
- 首先 DOM 树中的元素个数显著减少至四分之一,降低内存占用
- 其次 @H_301_4@$watch 表达式也减少至四分之一,提升脏检查循环的速度
- 如果这个 tab 下面有 @H_301_4@controller(例如每个 tab 都被封装为一个组件),那么仅当这个 tab 被选中时该 @H_301_4@controller 才会执行,可以减少各页面的互相干扰
- 如果 @H_301_4@controller 中调用接口获取数据,那么仅当对应 @H_301_4@tab 被选中时才会加载,避免网络拥挤
@H_
301_26@当然也有缺点:
- DOM 重建本身费时间
- 如果 tab 下有 @H_301_4@controller,那么每次该 tab 被选中时 @H_301_4@controller 都会被执行
- 如果在 @H_301_4@controller 里面调接口获取数据,那么每次该 tab 被选中时都会重新加载
@H_
301_26@各位读者自己取舍。
当脏检查遇上数组
@H_
301_26@@H_
301_4@ng-repeat!这就更有(e)趣(xin)了。通常的绑定只是去监听一个值的变化(绑定对象也是绑定到对象里的某个成员),而 @H_
301_4@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>
@H_
301_26@会
生成 4 个 @H_
301_4@li 元素
@H_
301_26@没有问题。如果我
添加一个按钮如下:
<button ng-click="array.shift()">删除第一个元素</button>
@H_
301_26@请考虑:当
用户点击这个按钮会发生什么?
@H_
301_26@我们一步一步分析。开始的时候,angular 记录了 array 的初始状态为:
[
{ "value": 1 },{ "value": 2 },{ "value": 3 },{ "value": 4 }
]
@H_
301_26@当
用户点击按钮后,数组的第一个元素被
删除了,array 变为:
[
{ "value": 2 },{ "value": 4 }
]
@H_
301_26@两者比较:
- @H_301_4@array.length = 4 => @H_301_4@array.length = 3
- @H_301_4@array[0].value = 1 => @H_301_4@array[0].value = 2
- @H_301_4@array[1].value = 2 => @H_301_4@array[1].value = 3
- @H_301_4@array[2].value = 3 => @H_301_4@array[2].value = 4
- @H_301_4@array[3].value = 4 => @H_301_4@array[3].value = undefined (@H_301_4@array[4] 为 @H_301_4@undefined,则 @H_301_4@undefined.value 为 undefined,见 Angular 表达式的说明)
@H_
301_26@如同你所见:angular 经过比较,看到的是:
- 数组长度减少了 1
- 数组第 1 个元素的 value 被改为 2
- 数组第 2 个元素的 value 被改为 3
- 数组第 3 个元素的 value 被改为 4
@H_
301_26@反应到 DOM 元素上就是:
- 第 1 个 @H_301_4@li 内容改为 2
- 第 2 个 @H_301_4@li 内容改为 3
- 第 3 个 @H_301_4@li 内容改为 4
- 第 4 个 @H_301_4@li 删掉
@H_
301_26@可以看到,
删除一个元素导致了整个 @H_
301_4@ul 序列的刷新。要知道 DOM 操作要比 JS 变量操作要慢得多,类似这样的无用操作最好能想办法避免。
@H_
301_26@那么问题出在哪里呢?
用户删除了数组的第一个元素,导致了整个数组元素前移;然而 angular 没法得知
用户做了这样一个
删除操作,只能傻傻的按下标一个一个比。
@H_
301_26@那么只要引入一种机制来
标记数组的每一项就好了吧。于是 angular 引入了 @H_
301_4@track by
@H_
301_26@用来
标记数组元素的一定是数组里类似 ID 的某个值。这个值一定要符合以下这两个特点。
- 不能重复。ID 重复了什么鬼
- 值一定要简单。ID 是用于比较相等的,有时候由于算法不同可能还要比较大小,处于速度考虑不能太复杂。
@H_
301_26@基于这两个特点。如果
用户没有给 @H_
301_4@ng-repeat 指定 @H_
301_4@track by 的表达式,则默认为内置
函数 $id。@H_
301_4@$id 会检查 @H_
301_4@item 中有没有一个名为 @H_
301_4@$$hashKey` 的成员。如有,返回其值;如没有,则
生成一个新的唯一值写入。这就是数组中那个奇怪的 `$$hashKey 成员来历,默认值是 @H_
301_4@"object:X"(你问我为什么是个字符串而不是数字?我怎么知道。。。)
@H_
301_26@还是前面的问题,引入 @H_
301_4@track by 后再来看。因为没有指定 @H_
301_4@track by,则默认为 @H_
301_4@$id(item),实际为 @H_
301_4@$$hashKey。
<ul ng-init="array = [
{ value: 1 },]">
<li ng-repeat="item in array track by $id(item)" ng-bind="item.value"></li>
</ul>
@H_
301_26@开始的时候,@H_
301_4@$id(item) 给数组中所有项创建了 @H_
301_4@$$hashKey
@H_
301_26@这时 angular 记录了 array 的初始状态为:
[
{ "value": 1,"$$hashKey": "object:1" },{ "value": 2,"$$hashKey": "object:2" },{ "value": 3,"$$hashKey": "object:3" },{ "value": 4,"$$hashKey": "object:4" }
]
@H_
301_26@当
用户点击按钮后,数组的第一个元素被
删除了,array 变为:
[
{ "value": 2,"$$hashKey": "object:4" }
]
@H_
301_26@先比较 @H_
301_4@track by 的元素,这里为 @H_
301_4@$id(item),即 @H_
301_4@$$hashKey
- @H_301_4@"object:1" => @H_301_4@"object:2"
- @H_301_4@"object:2" => @H_301_4@"object:3"
- @H_301_4@"object:3" => @H_301_4@"object:4"
- @H_301_4@"object:4" => undefined
@H_
301_26@两者对不上,说明数组被做了增删元素或者移动元素的操作。将其规整
- @H_301_4@"object:1" => undefined
- @H_301_4@"object:2" => @H_301_4@"object:2"
- @H_301_4@"object:3" => @H_301_4@"object:3"
- @H_301_4@"object:4" => @H_301_4@"object:4"
@H_
301_26@那么显然,第一个元素被
删除了。再比较剩余的元素
- @H_301_4@array[0].value = 2 => @H_301_4@array[0].value = 2
- @H_301_4@array[1].value = 3 => @H_301_4@array[1].value = 3
- @H_301_4@array[2].value = 4 => @H_301_4@array[2].value = 4
@H_
301_26@结论是:
- 原数组第一个元素被删除
- 其他没变
@H_
301_26@angular 通过将新旧数组的 @H_
301_4@track by 元素做 diff 猜测
用户的行为,最大可能的减少 DOM 树的操作,这就是 @H_
301_4@track by 的用处。
默认 track by 的坑
@H_
301_26@So far so good! 然而需求某天有变,程序员小哥决定用 filter 给数组做 map 后再渲染。
<ul ng-init="array = [
{ value: 1 },]">
<li ng-repeat="item in array | myMap" ng-bind="item.value"></li>
</ul>
@H_
301_26@map 定义如下:
xxModule.filter('map',function () {
return arr => arr.map(item => ({ value: item.value + 1 }));
});
@H_
301_26@@H_
301_4@ng-repeat 执行时先计算表达式 @H_
301_4@array | myMap 的值:
arrayForNgRepeat = [
{ value: 2 },{ value: 5 },]
@H_
301_26@注意数组 @H_
301_4@arrayForNgRepeat 和原来的数组 @H_
301_4@array 不是同一个引用,因为 @H_
301_4@filter 里的 map 操作
生成了一个新数组,每一项都是新对象,跟原数组无关。
@H_
301_26@@H_
301_4@ng-repeat 时,angular 发现
用户没有指定 @H_
301_4@track by,按照默认逻辑,使用 @H_
301_4@$id(item) 作为 @H_
301_4@track by,
添加 @H_
301_4@$$hashKey
arrayForNgRepeat = [
{ value: 2,{ value: 3,{ value: 4,{ value: 5,"$$hashKey": "object:4" },]
@H_
301_26@
生成 DOM:
@H_
301_26@这里请再次注意:数组 arrayForNgRepeat 与原始数组 array 没有任何关系,数组本身是不同的引用,数组里的每一项也是不同引用。
修改新数组的成员不会影响到原来的数组。
@H_
301_26@这时 array 的值:
array = [
{ value: 1 },]
@H_
301_26@这时
用户的某个无关操作触发了脏检查。针对 @H_
301_4@ng-repeat 表达式,首先计算 @H_
301_4@array | myMap 的值:
newArrayForNgRepeat = [
{ value: 2 },]
@H_
301_26@先比较 @H_
301_4@track by 的元素。
用户没有指定,默认为 @H_
301_4@$id(item)。
@H_
301_26@@H_
301_4@$id 发现数组中有一些元素没有 @H_
301_4@$$hashKey`,则给它们填充新 `$$hashKey,结果为
newArrayForNgRepeat = [
{ value: 2,"$$hashKey": "object:5" },"$$hashKey": "object:6" },"$$hashKey": "object:7" },"$$hashKey": "object:8" },]
@H_
301_26@这时两边的 @H_
301_4@track by 的实际结果为
- @H_301_4@"object:1" => @H_301_4@"object:5"
- @H_301_4@"object:2" => @H_301_4@"object:6"
- @H_301_4@"object:3" => @H_301_4@"object:7"
- @H_301_4@"object:4" => @H_301_4@"object:8"
@H_
301_26@两者对不上,说明数组被做了增删元素或者移动元素的操作。将其规整
- @H_301_4@"object:1" => undefined
- @H_301_4@"object:2" => undefined
- @H_301_4@"object:3" => undefined
- @H_301_4@"object:4" => undefined
- undefined => @H_301_4@"object:5"
- undefined => @H_301_4@"object:6"
- undefined => @H_301_4@"object:7"
- undefined => @H_301_4@"object:8"
@H_
301_26@结论是:
- 原数组全部 4 个元素被删除
- 新添加了 4 个元素
@H_
301_26@于是 angular 把原来所有 @H_
301_4@li
删除,再创建 4 个新的 @H_
301_4@li 元素,填充它们的 @H_
301_4@textContent,放到 @H_
301_4@ul 里
@H_
301_26@如果怀疑我说的话,请自己在浏览器里测试。你可以清楚的看到调试工具里 DOM 树的闪烁
@H_301_4@track by 与性能
@H_
301_26@不恰当的 @H_
301_4@ng-repeat 会造成 DOM 树反复重新构造,拖慢浏览器响应速度,造成
页面闪烁。除了上面这种比较极端的情况,如果一个列表频繁拉取 Server 端数据自刷新的话也一定要手工
添加 @H_
301_4@track by,因为接口给前端的数据是不可能包含 @H_
301_4@$$hashKey 这种东西的,于是结果就造成列表频繁的重建。
@H_
301_26@其实不必考虑那么多,总之
加上没坏处,至少可以避免 angular
生成 @H_
301_4@$$hashKey 这种奇奇怪怪的东西。所以
@H_
301_26@请给 @H_
301_4@ng-repeat 手工
添加 @H_
301_4@track by!
@H_
301_26@重要的事情再说一遍
@H_
301_26@请给 @H_
301_4@ng-repeat 手工
添加 @H_
301_4@track by!
@H_
301_26@通常列表都是请求接口从
数据库中读取返回的。通常
数据库中的记录都有一个 @H_
301_4@id 字段做主键,那么这时使用 @H_
301_4@id 作为 @H_
301_4@track by 的字段是最佳选择。如果没有,可以选择一些业务字段但是确保不会重复的。例如一个连表头都是动态
生成的表格,表头就可以使用其字段名作为 @H_
301_4@track by 的字段(对象的 key 是不会重复的)。
@H_
301_26@如果真的找不到用于 @H_
301_4@track by 的字段,让 angular
自动生成 @H_
301_4@$$hashKey 也不是不可以,但是切记检查有没有出现 DOM 元素不断重刷的现象,除了仔细看调试工具的 DOM 树是否闪烁之外,给列表中的元素
添加一个特别的
标记(比如 @H_
301_4@style="background: red"),也是一个行之有效的
方法(如果这个
标记被意外清除,说明原来的 DOM 元素被
删除了)。
@H_
301_26@除非真的没办法,不推荐使用 @H_
301_4@$index 作为 @H_
301_4@track by 的字段。
@H_301_4@track by 与 单次绑定 连用
@H_
301_26@@H_
301_4@track by 只是让 angular 复用已有 DOM 元素。数组每个子元素内部绑定表达式的脏检查还是免不了的。然而对于实际应用场景,往往是数组整体改变(例如
分页),数组每一项通常却不会单独变化。这时就可以通过使用单次绑定大量减少 @H_
301_4@$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>
@H_
301_26@除非 @H_
301_4@track by 字段改变造成的 DOM 树重建,@H_
301_4@item.a 等一旦
显示在
页面上后就不会再被监视。
@H_
301_26@如果每行有 5 个绑定表达式,每页
显示 20 条记录,通过这种
方法每页就可以减少 @H_
301_4@5 * 20 = 100 个绑定表达式的监视。
@H_
301_26@注意:如果在 @H_
301_4@ng-repeat 内部使用的单次绑定,就一定不要用 @H_
301_4@track by $index。否则
用户切换
下一页页面也不会更新。
使用分页减少绑定个数
@H_
301_26@这个就不多说了。能后端
分页的就后端
分页;接口
不支持分页的也要前端
分页;前端
分页时可以简单的写个 @H_
301_4@filter 用 @H_
301_4@Array.prototype.slice 实现。
@H_
301_26@能直接减少数组中项的个数就不要在 @H_
301_4@ng-repeat 中每项上写 @H_
301_4@ng-show 或 @H_
301_4@ng-if
写在最后的话
@H_
301_26@脏检查这个东西,其实在三大主流前端框架中或多或少都有涉及。React 每次
生成新的 @H_
301_4@Virtual DOM,与旧 @H_
301_4@Virtual DOM 的 diff 操作本来就可以看做一次脏检查。Vue 从相对彻底的抛弃了脏检查机制,使用 @H_
301_4@Property 主动触发 UI 更新,但是 Vue 仍然不能抛弃 @H_
301_4@track by 这个东西。
@H_
301_26@既然脏检查在三大主流框架里或多或少都有所保留,为什么唯独 Angular 的
性能被广为诟病呢?其实还是说在 Angular 1 的机制下,脏检查的执行范围过大以及频率太过频繁了。Angular 1.5 从 Angular 2+ 引入了组件(@H_
301_4@Component)的概念,然而形似而神非,其实只是一个特殊的 @H_
301_4@Directive 马甲而已,并不能将脏检查的执行范围限制在各个组件之内,所以并不能本质的改变 Angular 1 脏检查机制效率低下的现状。
@H_
301_26@也许 Angular 1 终将被淘汰。但 Angular 作为前端第一个 MVVM 框架,着实引发了前端框架更新换代的热潮。百足之虫死而不僵,不管怎么样我还得继续维护停留在电脑里的 Angular 1 项目。不过也许老板哪天大发慈悲给我们用 Vue 重构整个项目的时间,将来的事情谁知道呢?
原文链接:https://www.f2er.com/angularjs/146627.html