Angular中的变更检测

JavaScript015

Angular中的变更检测,第1张

变更检测就是Angular检测视图与数据模型之间绑定的值是否发生了改变,当检测到模型中绑定的值发生改变时,就把数据同步到视图上。

我们先看下面这个例子

通过以上例子我们可以总结出来,在异步事件发生的时候可能会使数据模型发生变化。可是angular是如何检测到异步事件发生了呢?这还要说起zone.js。

官方定义zone.js是javascript的线程本地存储技术,猛地一听感觉好高大上,其实zone.js就是一种用来拦截和跟踪异步工作,为JavaScript提供执行上下文的插件。

那么它是如何感知到异步事件呢,其实方法相当简单粗暴,zone.js采用一种叫做猴子补丁 (Monkey-patched)的方式,将JavaScript中的异步任务都进行了包装,这使得这些异步任务都能运行在Zone(一个全局的对象,用来配置有关如何拦截和跟踪异步回调的规则)的执行上下文中,每个异步任务在 Zone 中都是一个任务(Task),除了提供了一些供开发者使用的钩子外,默认情况下Zone重写了以下方法:

zone.js部分源码

通过打印window对象我们可以发现zone.js对异步方法进行了封装,非异步方法并没有处理。

zone.js本身比较庞大复杂,这里不做深入研究,对它的原理感兴趣的可以看一下这篇文章-zone.js。我们这里主要是了解它是怎么配合Angular工作的即可。

在 Angular 源码中,有一个 ApplicationRef 类,其作用是当异步事件结束的时候由 onMicrotaskEmpty执行一个 tick 方法 提示 Angular 执行变更检测及更新视图。

调用tick方法。其中this._zone 是NgZone 的一个实例, NgZone 是对zone.js的一个简单封装。

tick函数对所有附在 ApplicationRef上的视图进行脏检查。

Ok,我们现在已经知道Angular怎么监听异步事件了,那么当监测到异步事件后是怎么判断是否需要更新视图呢?其实比较简单,Angular通过脏检查来判断是否需要更新视图。脏检查其实就是存储所有变量的值,每当可能有变量发生变化需要检查时,就将所有变量的旧值跟新值进行比较,不相等就说明检测到变化,需要更新对应视图。当然,实际情况肯定不是这么简单,Angular会通过自己的算法来对数据进行检查,对算法感兴趣的可以参考这篇文章-Angular的脏检查算法。

Angular 应用是一个响应系统,首次检测时会检查所有的组件,其他的变化检测则总是从根组件到子组件这样一个从上到下的顺序开始执行,它是一棵线性的有向树,任何数据都是从顶部往底部流动,即单向数据流。怎么证明呢?看这个例子

运行以后我们会得到如下结果,可以看到首次检测时检查了所有组件,包括ReferComponent,检测从上到下逐个检测。点击改名按钮后再次检测时则只检测有变化的那一侧组件(RankParentComponent,RankChildrenComponent)。其中我们可以观察到,虽然在AppComponent中输入属性也发生了变化并且也更新了视图,但是ngOnChanges钩子却没有检测到变化,注意这是一个坑。

那么什么是单向数据流呢?其实简单理解就是angular检测到数据变化到更新完视图的过程中数据是不应该被改变的,如果我们在这期间更改了数据,Angular便会抛出一个错误,举个例子,我们在RankChildrenComponent的ngAfterViewChecked钩子函数中更改childName的值,在控制台会看到如下错误。

如果必须要更改这个属性的值,能不能做呢?答案是可以的。结合刚次提到的单向数据流,如果我们把这次数据变更放到下一轮Angular变更检测中,就能解决这个问题了。怎么做呢?刻意异步一下就行了。是不是很神奇?

至于angular为什么要采用单向数据流,其实也很好理解,最主要的就是防止数据模型和视图不统一,同时也可以提高渲染的性能。

讲了这么多,所以到底有什么用呢?其实在 Angular 中,每一个组件都都它自己的检测器(detector),用于负责检查其自身模板上绑定的变量。所以每一个组件都可以独立地决定是否进行脏检查。默认情况下,变化检测系统将会走遍整棵树(defalut策略),但我们可以使用OnPush变化检测策略,利用 ChangeDetectorRef实例提供的方法,来实现局部的变化检测,最终提高系统的整体性能。

来,举个例子。在ReferComponent中,我们设个定时器2秒以后更新一个非输入属性的值,在默认策略时,可以发现2秒以后视图中的值发生了改变,但是当我们把策略改为Onpush时,除了在AppComponent点击按钮改变输入属性justRefer外,其他属性改变不会引起视图更新,ReferComponent组件的检测也被略过。我们可以这么总结:OnPush 策略下,若输入属性没有发生变化,组件的变化检测将会被跳过。

可是我就是要更改非输入属性怎么办呢?别急,Angular早就为你想好了。在Angular中,有这么一个class:ChangeDetectorRef ,它是组件的变化检测器的引用,我们可以在组件中的通过依赖注入的方式来获取该对象,来手动控制组件的变化检测行为。它提供了以下方法供我们调用

现在我们来试试解决刚才那个问题,我们对ReferComponent做如下改造。

ok,现在看到在Onpush策略下手动修改非输入属性的值,视图也可以及时更新了。其他的几个方法也都大同小异,感兴趣的可以逐个试试。

window.document.body.clientHeight就可以

window.screen.availWidth 返回当前屏幕宽度(空白空间)

window.screen.availHeight 返回当前屏幕高度(空白空间)

window.screen.width 返回当前屏幕宽度(分辨率值)

window.screen.height 返回当前屏幕高度(分辨率值)

window.document.body.offsetHeight返回当前网页高度

window.document.body.offsetWidth返回当前网页宽度

我们这里说说四种浏览器对 document.body 的 clientHeight、offsetHeight 和 scrollHeight 的解释。

这四种浏览器分别为IE(Internet Explorer)、NS(Netscape)、Opera、FF(FireFox)。

clientHeight

大家对 clientHeight 都没有什么异议,都认为是内容可视区域的高度,也就是说页面浏览器中可以看到内容的这个区域的高度,一般是最后一个工具条以下到状态栏以上的这个区域,与页面内容无关。

offsetHeight

IE、Opera 认为 offsetHeight = clientHeight + 滚动条 + 边框。

NS、FF 认为 offsetHeight 是网页内容实际高度,可以小于 clientHeight。

scrollHeight

IE、Opera 认为 scrollHeight 是网页内容实际高度,可以小于 clientHeight。

NS、FF 认为 scrollHeight 是网页内容高度,不过最小值是 clientHeight。

简单地说

clientHeight 就是透过浏览器看内容的这个区域高度。

NS、FF 认为 offsetHeight 和 scrollHeight 都是网页内容高度,只不过当网页内容高度小于等于 clientHeight 时,scrollHeight 的值是 clientHeight,而 offsetHeight 可以小于 clientHeight。

IE、Opera 认为 offsetHeight 是可视区域 clientHeight 滚动条加边框。scrollHeight 则是网页内容实际高度。

同理

clientWidth、offsetWidth 和 scrollWidth 的解释与上面相同,只是把高度换成宽度即可。

=======================================================================

clientHeight与offsetHeight的区别

许多文章已经介绍了clientHeight和offsetHeight的区别,就是clientHeight的值不包括scrollbar的高度,而offsetHeight的值包括了scrollbar的高度。然而,clientHeight和offsetHeight的值到底由什么组成的呢?如何计算这两个数的值?

1. clientHeight和offsetHeight的值由什么决定?

假如我们有以下的DIV,主要显示的文字为"This is the main body of DIV"。

如上图所示,clientHeight的值由DIV内容的实际高度和CSS中的padding值决定,而offsetHeight的值由DIV内容的实际高度,CSS中的padding值,scrollbar的高度和DIV的border值决定;至于CSS中的margin值,则不会影响clientHeight和offsetHeight的值。

2. CSS中的Height值对clientHeight和offsetHeight有什么影响?

首先,我们看一下CSS中Height定义的是什么的高度。如在本文最后部分“APPENDIX示例代码”(注:以下称为“示例代码”)中,innerDIVClass的Height值设定为50px,在IE下计算出来的值如下所示。也就是说,在IE里面,CSS中的Height值定义了DIV包括padding在内的高度(即offsetHeight的值);在Firefox里面,CSS中的Height值只定义的DIV实际内容的高度,padding并没有包括在这个值里面(70 = 50 + 10 * 2)。

in IE:

innerDiv.clientHeight: 46

innerDiv.offsetHeight: 50

outerDiv.clientHeight: 0

outerDiv.offsetHeight: 264

in Firfox:

innerDiv.clientHeight: 70

innerDiv.offsetHeight: 74

outerDiv.clientHeight: 348

outerDiv.offsetHeight: 362

在上面的示例中,也许你会很奇怪,为什么在IE里面outerDiv.clientHeight的值为0。那是因为示例代码中,没有定义outerDIVClass的Height值,这时,在IE里面,则clientHeight的值是无法计算的。同样,在示例代码中,如果将innerDIVClass中的Height值去年,则innerDIV.clientHeight的值也为0。(注:在Firefox下不存在这种情况)。

如果CSS中Height值小于DIV要显示内容的高度的时候呢(当CSS中没有定义overflow的行为时)?在IE里面,整个clientHeight(或者offsetHeight)的值并没有影响,DIV会自动被撑大;而在Firefox里面,DIV是不会被撑开的。如在示例代码中,将innerDivClass的Height值设为0,则计算结果如下所示。IE里面的DIV被撑开,其clientHeight值等于内容的高度与padding*2的和;而Firefox里面,文字将溢出DIV的边界,其clientHeight值正好是padding值的两倍。

In IE:

innerDiv.clientHeight: 38

innerDiv.offsetHeight: 42

outerDiv.clientHeight: 0

outerDiv.offsetHeight: 256

In Firefox:

innerDiv.clientHeight: 20

innerDiv.offsetHeight: 24

outerDiv.clientHeight: 298

outerDiv.offsetHeight: 312

使用map标签,参考http://www.w3school.com.cn/tags/att_img_usemap.asp,不知道是不是你想要的效果,这是测试页面:http://www.w3school.com.cn/tiy/t.asp?f=html_areamap