原文链接: https://blog.angularindepth.com/everything-you-need-to-know-about-change-detection-in-angular-8006c51d206f
这篇文章只是作者自己一边看原文一边随手翻译的，个中错误以及表述多有不正确，阅读原文才是最佳选择。
如果你也像我一样想对angular的变更检测有更深入的了解，去看源码无疑是必须的选择，因为网络上相关的信息实在是太少了。大多数文章都只是指出每个组件都有自己的变更检测器，但是并没有继续深入，他们大多关注于不可变对象和变更检测策略的使用。所以这篇文章的目的是告诉你，为什么使用不可变对象会有效？变更检测策略是如何影响到检测的？同时，这篇文章也能让你能对不同场景下提出相应的性能优化方法。
这篇文章由两部分组成，第一部分技术性较强且有很多源码部分的引用。主要解释了变更检测在底层的工作细节。基于angular-4.0.1。需要注意的是，2.4.1之后版本的变更检测策略有较大的变化。如果你对以前版本的变更检测有兴趣，可以阅读这篇回答。
相关教程推荐：《angular教程》
第二部分主要讲解了如何在应用中使用变更检测，这部分对于angular2+都是相同的。因为angular的公共api并没有发生变化。
核心概念-视图viewangular的文档中通篇都提到了一个angular应用是一个组件树。但是angular底层其实使用了一个低级抽象-视图view。视图view和组件之间的关系很直接-一个视图与一个组件相关联，反之亦然。每个视图都在它的component属性中保持了一个与之关联的组件实例的引用。所有的类似于属性检测、dom更新之类的操作都是在视图上进行的。因此，技术上而言把angular应用描述成一个视图树更加准确，因为组件是视图的一个高阶描述。在源码中有关视图是这么描述的：
a view is a fundamental building block of the application ui. it is the smallest grouping of elements which are created and destroyed together.
视图是组成应用界面的最小单元，它是一系列元素的组合，一起被创建，一起被销毁。
properties of elements in a view can change, but the structure (number and order) of elements in a view cannot. changing the structure of elements can only be done by inserting, moving or removing nested views via a viewcontainerref. each view can contain many view containers.
视图中元素的属性可以发生变化，但是视图中元素的数量和顺序不能变化。如果想要改变的话，需要通过virecontainerref来执行插入，移动和删除操作。每个视图都会包括多个view container。
在这篇文章中，组件和组件视图的概念是互相可替代的。
需要注意的是：网络上很多文章都把我们这里所描述的视图作为了变更检测对象或者changedetectorref。事实上，angular中并没有一个单独的对象用来做变更检测，所有的变更检测都在视图上直接运行。
export interface viewdata { def: viewdefinition; root: rootdata; renderer: renderer2; // index of component provider / anchor. parentnodedef: nodedef|null; parent: viewdata|null; viewcontainerparent: viewdata|null; component: any; context: any; // attention: never loop over this, as this will // create a polymorphic usage site. // instead: always loop over viewdefinition.nodes, // and call the right accessor (e.g. `elementdata`) based on // the nodetype. nodes: {[key: number]: nodedata}; state: viewstate; oldvalues: any[]; disposables: disposablefn[]|null;}
视图的状态每个视图都有自己的状态，基于这些状态的值，angular会决定是否对这个视图和他所有的子视图运行变更检测。视图有很多状态值，但是在这篇文章中，下面四个状态值最为重要：
// bitmask of statesexport const enum viewstate { firstcheck = 1 << 0, checksenabled = 1 << 1, errored = 1 << 2, destroyed = 1 << 3}
如果checkedenabled值为false或者视图处于errored或者destroyed状态时，这个视图的变更检测就不会执行。默认情况下，所有视图初始化时都会带上checkenabled，除非使用了changedetectionstrategy.onpush。有关onpush我们稍后再讲。这些状态也可以被合并使用，比如一个视图可以同时有firstcheck和checkenabled两个成员。
针对操作视图，angular中有一些封装出的高级概念，详见这里。一个概念是viewref。他的_view属性囊括了组件视图，同时它还有一个方法detectchanges。当一个异步事件触发时，angular从他的最顶层的viewref开始触发变更检测，然后对子视图继续进行变更检测。
changedectionref可以被注入到组件的构造函数中。这个类的定义如下：
export declare abstract class changedetectorref { abstract checknochanges(): void; abstract detach(): void; abstract detectchanges(): void; abstract markforcheck(): void; abstract reattach(): void;}export abstract class viewref extends changedetectorref { /** * destroys the view and all of the data structures associated with it. */ abstract destroy(): void; abstract get destroyed(): boolean; abstract ondestroy(callback: function): any}
变更检测操作负责对视图运行变更检测的主要逻辑属于checkandupdateview方法。他的大部分功能都是对子组件视图进行操作。从宿主组件开始，这个方法被递归调用作用于每一个组件。这意味着当递归树展开时，在下一次调用这个方法时子组件会成为父组件。
当在某个特定视图上开始触发这个方法时，以下操作会依次发生：
如果这是视图的第一次检测，将viewstate.firstcheck设置为true，否则为false；
检查并更新子组件/指令的输入属性-checkandupdatedirectiveinline
更新子视图的变更检测状态(属于变更检测策略实现的一部分)
对内嵌视图运行变更检测(重复列表中的步骤)
如果绑定的值发生变化，调用子组件的onchanges生命周期钩子；
调用子组件的oninit和docheck两个生命周期钩子(oninit只在第一次变更检测时调用)
在子组件视图上更新contentchildren列表-checkandupdatequery
调用子组件的aftercontentinit和aftercontentchecked(前者只在第一次检测时调用)-callproviderlifecycles
如果当前视图组件上的属性发生变化，更新dom
对子视图执行变更检测-callviewaction
更新当前视图组件的viewchildren列表-checkandupdatequery
调用子组件的afterviewinit和afterviewchecked-callproviderlifecycles
对当前视图禁用检测
在以上操作中有几点需要注意
深入这些操作的含义假设我们现在有一棵组件树：
在上面的讲解中我们得知了每个组件都和一个组件视图相关联。每个视图都使用viewstate.checksenabled初始化了。这意味着当angular开始变更检测时，整棵组件树上的所有组件都会被检测；
假设此时我们需要禁用acomponent和它的子组件的变更检测，我们只要将它的viewstate.checksenabled设置为false就行。这听起来很容易，但是改变state的值是一个很底层的操作，因此angular在视图上提供了很多方法。通过changedetectorref每个组件可以获得与之关联的视图。
class changedetectorref { markforcheck() : void detach() : void reattach() : void detectchanges() : void checknochanges() : void}
detach这个方法简单的禁止了对当前视图的检测；
detach(): void { this._view.state &= ~viewstate.checksenabled;}
在组件中的使用方法：
export class acomponent { constructor( private cd: changedectectorref, ) { this.cd.detach(); }}
这样就会导致在接下来的变更检测中acomponent及子组件都会被跳过。
这里有两点需要注意：
虽然我们只修改了acomponent的state值，但是他的子组件也不会被执行变更检测；由于acomponent及其子组件不会有变更检测，因此他们的dom也不会有任何更新下面是一个简单示例，点击按钮后在输入框中修改就再也不会引起下面的p标签的变化，外部父组件传递进来的值发生变化也不会触发变更检测：
import { component, oninit, changedetectorref } from '@angular/core';@component({ selector: 'app-change-dection', template: ` <input [(ngmodel)]="name"> <button (click)="stopcheck()">停止检测</button> <p>{{name}}</p> `, styleurls: ['./change-dection.component.css']})export class changedectioncomponent implements oninit { name = 'erik'; constructor( private cd: changedetectorref, ) { } ngoninit() { } stopcheck() { this.cd.detach(); }}
reattach文章第一部分提到：如果acomponent的输入属性aprop发生变化，onchanges生命周期钩子仍会被调用，这意味着一旦我们得知输入属性发生变化，我们可以激活当前组件的变更检测并在下一个tick中继续detach变更检测。
reattach(): void { this._view.state |= viewstate.checksenabled; }
export class changedectioncomponent implements oninit, onchanges { @input() aprop: string; name = 'erik'; constructor( private cd: changedetectorref, ) { } ngoninit() { } ngonchanges(change) { this.cd.reattach(); settimeout(() => { this.cd.detach(); }); }}
上面这种做法几乎与将changedetectionstrategy改为onpush是等效的。他们都在第一轮变更检测后禁用了检测，当父组件向子组件传值发生变化时激活变更检测，然后又禁用变更检测。
需要注意的是，在这种情况下，只有被禁用检测分支最顶层组件的onchanges钩子才会被触发，并不是这个分支的所有组件的onchanges都会被触发，原因也很简单，被禁用检测的这个分支内不存在了变更检测，自然内部也不会向子元素变更所传递的值，但是顶层的元素仍可以接受到外部变更的输入属性。
译注：其实将retach()和detach()放在ngonchanges()和onpush策略还是不一样的，onpush策略的确是只有在input值的引用发生变化时才出发变更检测，这一点是正确的，但是onpush策略本身并不影响组件内部的值的变化引起的变更检测，而上例中组件内部的变更检测也会被禁用。如果将这段逻辑放在ngdocheck()中才更正确一点。
maskforcheck上面的reattach()方法可以对当前组件开启变更检测，然而如果这个组件的父组件或者更上层的组件的变更检测仍被禁用，用reattach()后是没有任何作用的。这意味着reattach()方法只对被禁用检测分支的最顶层组件有意义。
因此我们需要一个方法，可以将当前元素及所有祖先元素直到根元素的变更检测都开启。changedetectorref提供了markforcheck方法：
let currview: viewdata|null = view;while (currview) { if (currview.def.flags & viewflags.onpush) { currview.state |= viewstate.checksenabled; } currview = currview.viewcontainerparent || currview.parent;}
在这个实现中，它简单的向上迭代并启用对所有直到根组件的祖先组件的检查。
这个方法在什么时候有用呢？禁用变更检测策略之后，ngdocheck生命周期还是会像ngonchanges一样被触发。当然，跟onchanges一样，docheck也只会在禁用检测分支的顶部组件上被调用。但是我们就可以利用这个生命周期钩子来实现自己的业务逻辑和将这个组件标记为可以进行一轮变更检测。
由于angular只检测对象引用，我们需要通过对对象的某些属性来进行这种脏检查：
// 这里如果外部items变化为改变引用位置，此组件是不会执行变更检测的// 但是如果在docheck()钩子中调用markforcheck// 由于onpush策略不影响docheck的执行，这样就可以侦测到这个变更component({ ..., changedetection: changedetectionstrategy.onpush})mycomponent { @input() items; prevlength; constructor(cd: changedetectorref) {} ngoninit() { this.prevlength = this.items.length; } ngdocheck() { // 通过比较前后的数组长度 if (this.items.length !== this.prevlength) { this.cd.markforcheck(); this.prevlenght = this.items.length; } }}
detectchangesangular提供了一个方法detectchanges，对当前组件和所有子组件运行一轮变更检测。这个方法会无视组件的viewstate，也就是说这个方法不会改变组件的变更检测策略，组件仍会维持原有的会被检测或不会被检测状态。
export class acomponent { @input() inputaprop; constructor(public cd: changedetectorref) { this.cd.detach(); } ngonchanges(values) { this.cd.detectchanges(); }}
通过这个方法我们可以实现一个类似angular.js的手动调用脏检查。
checknochanges这个方法是用来当前变更检测没有产生任何变化。他执行了文章第一部分1，7，8三个操作，并在发现有变更导致dom需要更新时抛出异常。
结束！哈！
更多编程相关知识，请访问：编程视频！！
以上就是深入了解angular中的变更检测的详细内容。