这篇文章主要介绍Angular中变更检测的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
Angular的文档中通篇都提到了一个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 states
export 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(): 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();
}
}文章第一部分提到：如果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()中才更正确一点。
上面的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;
}
}
}Angular提供了一个方法detectChanges，对当前组件和所有子组件运行一轮变更检测。这个方法会无视组件的ViewState，也就是说这个方法不会改变组件的变更检测策略，组件仍会维持原有的会被检测或不会被检测状态。
export class AComponent {
@Input() inputAProp;
constructor(public cd: ChangeDetectorRef) {
this.cd.detach();
}
ngOnChanges(values) {
this.cd.detectChanges();
}
}通过这个方法我们可以实现一个类似Angular.js的手动调用脏检查。
这个方法是用来当前变更检测没有产生任何变化。他执行了文章第一部分1，7，8三个操作，并在发现有变更导致DOM需要更新时抛出异常。
以上是“Angular中变更检测的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
