关于angular:Angular-变化检测详解

变化检测是前端框架中很乏味的一部分内容，各个前端的框架也都有本人的一套计划，个别状况下咱们不太须要过多的理解变化检测，因为框架曾经帮咱们实现了大部分的工作。不过随着咱们深刻的应用框架，咱们会发现咱们很难防止的要去理解变化检测，理解变化检测能够帮忙咱们更好的了解框架、排查谬误、进行性能优化等等。

简略的来说，变化检测就是通过检测视图与状态之间的变动，在状态产生了变动后，帮忙咱们更新视图，这种将视图和咱们的数据同步的机制就叫变化检测。

咱们理解了什么是变化检测，那何时触发变化检测呢？咱们能够看看上面这两个简略的 Demo

Demo1:

一个计数器组件，点击按钮 Count 会始终加 1

@Component({
  selector: "app-counter",
  template: `
    Count：{{count}}
    <br />
    <button (click)="increase()">Increase</button>
  `,
})
export class CounterComponent {
  count = 0;

  constructor() {}

  increase() {this.count = this.count + 1;}
}

Demo2：

一个 Todo List 的组件，通过 Http 获取数据后渲染到页面


  @Component({
    selector: "app-todos",
    template: ` <li *ngFor="let item of todos">{{item.titme}}</li> `,
  })
  export class TodosComponent implements OnInit {public todos: TodoItem[] = [];

    constructor(private http: HttpClient) {}

    ngOnInit() {this.http.get<TodoItem[]>("/api/todos").subscribe((todos: TodoItem[]) => {this.todos = todos;});
    }
  }

从下面的两个 Demo 中咱们发现，在两种状况下触发了变化检测：

点击事件产生时
通过 http 申请近程数据时

认真思考下，这两种触发的形式有什么共同点呢? 咱们发现这两种形式都是异步操作，所以咱们能够得出一个论断：只有产生了异步操作，Angular 就会认为有状态可能发生变化了，而后就会进行变化检测。

这个时候可能大家会想到 setTimeout setInterval ，是的，它们同样也会触发变化检测。

@Component({
  selector: "app-counter",
  template: `
    Count：{{count}}
    <br />
    <button (click)="increase()">Increase</button>
  `,
})
export class CounterComponent implements OnInit {
  count = 0;

  constructor() {}
  
  ngOnInit(){setTimeout(()=>{this.count= 10;});
  }

  increase() {this.count = this.count + 1;}
}

简而言之，如果产生以下事件之一，Angular 将触发变化检测：

任何浏览器事件（click、keydown 等）
setInterval() 和 setTimeout()
HTTP 通过 XMLHttpRequest 进行申请

方才咱们理解到，只有产生了异步操作，Angular 就会进行变化检测，那 Angular 又是如何订阅到异步事件的状态，从而触发变化检测的呢？这里咱们就要聊一聊 zone.js 了。

Zone.js 提供了一种称为 区域（Zone） 的机制，用于封装和拦挡浏览器中的异步流动、它还提供 异步生命周期的钩子 和 对立的异步错误处理机制。

Zone.js 是通过 Monkey Patching（猴子补丁） 的形式来对浏览器中的常见办法和元素进行拦挡，例如 setTimeout 和 HTMLElement.prototype.onclick 。Angular 在启动时会利用 zone.js 修补几个低级浏览器 API，从而实现异步事件的捕捉，并在捕捉工夫后调用变化检测。

上面用一段简化的代码来模仿一下替换 setTimeout 的过程：

function setTimeoutPatch() {
  // 存储原始的 setTimeout
  var originSetTimeout = window['setTimeout'];
  // 对浏览器原生办法的包裹封装
  window.setTimeout = function () {return global['zone']['setTimeout'].apply(global.zone, arguments);
  };
  // 创立包裹办法，提供给下面重写后的 setTimeout 应用Ï
  Zone.prototype['setTimeout'] = function (fn, delay) {
      // 先调用原始办法
    originSetTimeout.apply(window, arguments);
    // 执行完原始办法后就能够做其余拦挡后须要进行的操作了
    ...
   };
}

Zone.js 提供了一个全局区域，能够被 fork 和扩大以进一步封装 / 隔离异步行为，Angular 通过创立一个 fork 并应用本人的行为扩大它，通常来说，在 Angular APP 中，每个 Task 都会在 Angular 的 Zone 中运行，这个 Zone 被称为 NgZone。一个 Angular APP 中只存在一个 Angular Zone，而变更检测只会由运行于这个 **NgZone** 中的异步操作触发。

简略的了解就是：Angular 通过 Zone.js 创立了一个本人的区域并称之为 NgZone，Angular 利用中所有的异步操作都运行在这个区域中。

咱们理解 Angular 的外围是 组件化 ，组件的嵌套会使得最终造成一棵 组件树。

Angular 在生成组件的同时，还会为每一个组件生成一个变动检测器 changeDetector ，用来记录组件的数据变动状态，因为一个 Component 会对应一个 changeDetector，所以 changeDetector 同样也是一个树状构造的组织。

在组件中咱们能够通过注入 ChangeDetectorRef 来获取组件的 changeDetector

@Component({
  selector: "app-todos",
  ...
})
export class TodosComponent{constructor(cdr: ChangeDetectorRef) {}}

咱们在创立一个 Angular 利用后，Angular 会同时创立一个 ApplicationRef 的实例，这个实例代表的就是咱们以后创立的这个 Angular 利用的实例。ApplicationRef 创立的同时，会订阅 ngZone 中的 onMicrotaskEmpty 事件，在所有的微工作实现后调用所有的视图的 detectChanges() 来执行变化检测。

下是简化的代码：

class ApplicationRef {
  // ViewRef 是继承于 ChangeDetectorRef 的
  _views: ViewRef[] = [];
  constructor(private _zone: NgZone) {
    this._zone.onMicrotaskEmpty.subscribe({next: () => {this._zone.run(() => {this.tick();
        });
      },
    });
  }

  // 执行变化检测
  tick() {for (let view of this._views) {view.detectChanges();
    }
  }
}

什么是单向数据流？

方才咱们说了每次触发变化检测，都会从根组件开始，沿着整棵组件树从上到下的执行每个组件的变更检测，默认状况下，直到最初一个叶子 Component 组件实现变更检测达到稳固状态。在这个过程中，一但父组件实现变更检测当前，在下一次事件触发变更检测之前，它的子孙组件都不容许去更改父组件的变化检测相干属性状态的，这就是单向数据流。

咱们看一个示例：

@Component({
  selector: "app-parent",
  template: `
    {{title}}
    <app-child></app-child>
  `, 
})
export class ParentComponent {title = "我的父组件";}

@Component({
  selector: "app-child",
  template: ``, 
})
export class ChildComponent implements AfterViewInit {constructor(private parent: ParentComponent) {}

  ngAfterViewInit(): void {this.parent.title = "被批改的题目";}
}

为什么呈现这个谬误呢？

这是因为咱们违反了单向数据流，ParentComponent 实现变化检测达到稳固状态后，ChildComponent 又扭转了 ParentComponent 的数据使得 ParentComponent 须要再次被查看，这是不被举荐的数据处理形式。在开发模式下，Angular 会进行二次查看，如果呈现上述情况，二次查看就会报错：ExpressionChangedAfterItHasBeenCheckedError，在生产环境中，则只会执行一次查看。

并不是在所有的生命周期去调用都会报错，咱们把方才的示例批改一下：

@Component({
  selector: "app-child",
  template: ``, 
})
export class ChildComponent implements OnInit {constructor(private parent: ParentComponent) {}

  ngOnInit(): void {this.parent.title = "被批改的题目";}
}

批改后的代码运行失常，这是为什么呢？这里要说一下 Angular 检测执行的程序：

更新所有子子组件绑定的属性
调用所有子组件生命周期的钩子 OnChanges, OnInit, DoCheck，AfterContentInit
更新以后组件的 DOM
调用子组件的变换检测
调用所有子组件的生命周期钩子 ngAfterViewInit

ngAfterViewInit 是在变化检测之后执行的，在执行变化检测后咱们更改了父组件的数据，在 Angular 执行开发模式下的第二次查看时，发现与上一次的值不统一，所以报错，而 ngOnInit 的执行在变化检测之前，所以一切正常。

这里提一下 AngularJS，AngularJS 采纳的是双向数据流，盘根错节的数据流使得它不得不屡次查看，使得数据最终趋势稳固。实践上，数据可能永远不稳固。AngularJS 的策略是，脏查看超过 10 次，就认为程序有问题，不再进行查看。

方才咱们聊了变化检测的工作流程，接下来我想说的是变化检测的性能，默认状况下，当咱们的组件中某个值产生了变动触发了变化检测，那么 Angular 会从上往下查看所有的组件。 不过 Angular 对每个组件进行更改检测的速度十分快，因为它能够应用内联缓存在几毫秒内执行数千次查看，其中内联缓存可生成对 VM 敌对代码。

只管 Angular 进行了大量优化，然而遇到了大型利用，变化检测的性能依然会降落，所以咱们还须要用一些其余的形式来优化咱们的利用。

Angular 提供了两种运行变更检测的策略：

Default
OnPush

默认状况下，Angular 应用 ChangeDetectionStrategy.Default 变更检测策略，每次事件触发变化检测（如用户事件、计时器、XHR、promise 等）时，此默认策略都会从上到下查看组件树中的每个组件。这种对组件的依赖关系不做任何假如的激进查看形式称为 脏查看，这种策略在咱们利用组件过多时会对咱们的利用产生性能的影响。

Angular 还提供了一种 OnPush 策略，咱们能够批改组件装璜器的 changeDetection 来更改变化检测的策略

@Component({
    selector: 'app-demo',
    // 设置变化检测的策略
    changeDetection: ChangeDetectionStrategy.OnPush,
    template: ...
})
export class DemoComponent {...}

设置为 OnPush 策略后，Angular 每次触发变化检测后会跳过该组件和该组件的所以子组件变化检测

OnPush 模式下变化检测流程

在 OnPush 策略下，只有以下这几种状况才会触发组件的变化检测：

输出值（@Input）更改
以后组件或子组件之一触发了事件
手动触发变化检测
应用 async 管道后，observable 值产生了变动

在默认的变更检测策略中，Angular 将在 @Input() 数据产生更改或批改时执行变化检测，应用该 OnPush 时，传入 @Input() 的值 必须是一个新的援用 才会触发变化检测。

JavaScript 有两种数据类型，值类型和援用类型，值类型包含：number、string、boolean、null、undefined，援用类型包含：Object、Arrary、Function，值类型每次赋值都会调配新的空间，而援用类型比方 Object，间接批改属性是援用是不会发生变化的，只有赋一个新的对象才会扭转援用。

var a= 1;
var b = a;
b = 2;
console.log(a==b); // false

var obj1 = {a:1};
var obj2 = obj1;
obj2.a = 2;
console.log(obj1); // {a:2}
console.log(obj1 === obj2); //true

obj2= {...obj1};
console.log(obj1 === obj2); //false

如果 OnPush 组件或其子组件之一触发事件，例如 click，则将触发变化检测（针对组件树中的所有组件）。

须要留神的是在 OnPush 策略中，以下操作不会触发变化检测：

setTimeout()
setInterval()
Promise.resolve().then()
this.http.get(‘…’).subscribe()

有三种手动触发更改检测的办法：

detectChanges(): 它会触发以后组件和子组件的变化检测
markForCheck()： 它不会触发变化检测，然而会把以后的 OnPush 组件和所以的父组件为 OnPush 的组件 标记为须要检测状态，在以后或者下一个变化检测周期进行检测
ApplicationRef.tick() : 它会依据组件的变化检测策略，触发整个应用程序的更改检测

能够通过在线 Demo，更直观的理解这几种触发变化检测的形式

内置的 AsyncPipe 订阅一个 observable 并返回它收回的最新值。

每次收回新值时的外部 AsyncPipe 调用 markForCheck

private _updateLatestValue(async: any, value: Object): void {if (async === this._obj) {
    this._latestValue = value;
    this._ref.markForCheck();}
}

方才咱们聊了变化检测的策略，咱们能够应用 OnPush 的策略来优化咱们的利用，那么这就够了吗？在咱们理论的开发中还会有很多的场景，咱们须要通过一些其余的形式来持续优化咱们的利用。

场景 1：

如果咱们在实现一个回车搜寻的性能：

@Component({
  selector: "app-enter",
  template: `<input #input type="text" />`,
})
export class EnterComponent implements AfterViewInit {@ViewChild("input", { read: ElementRef})
  private inputElementRef: any;

  constructor() {}

  ngAfterViewInit(): void {
    this.inputElementRef.nativeElement.addEventListener(
      "keydown",
      (event: KeyboardEvent) => {
        const keyCode = event.which || event.keyCode;
        if (keyCode === 13) {this.search();
        }
      }
    );
  }

  search() {// ...}
}

大家从下面的示例中能够发现什么问题呢？

咱们晓得事件会触发 Angular 的变化检测，在示例中绑定 keydown 事件后，每一次键盘输入都会触发变化检测，而这些变化检测大多数都是多余的检测，只有当按键为 Enter 时，才须要真正的进行变化检测。

在这种状况下，咱们就能够利用 NgZone.runOutsideAngular() 来缩小变化检测的次数。

@Directive({selector: '[enter]'
})
export class ThyEnterDirective implements OnInit {@Output() enter = new EventEmitter();

    constructor(private ngZone: NgZone, private elementRef: ElementRef<HTMLElement>) {}

    ngOnInit(): void {
        // 包裹代码将运行在 Zone 区域之外
        this.ngZone.runOutsideAngular(() => {this.elementRef.nativeElement.addEventListener('keydown', (event: KeyboardEvent) => {
                const keyCode = event.which || event.keyCode;
                if (keyCode === 13) {this.ngZone.run(() => {this.enter.emit(event);
                    });
                }
            });
        });
    }
}

场景 2：

如果咱们应用 WebSocket 将大量数据从后端推送到前端，则相应的前端组件应仅每 10 秒更新一次。在这种状况下，咱们能够通过调用 detach() 和手动触发它来停用更改检测 detectChanges()：

constructor(private cdr: ChangeDetectorRef) {cdr.detach(); // 停用变化检测
    setInterval(() => {this.cdr.detectChanges(); // 手动触发变化检测
    }, 10 * 1000);
  }

当然应用 ngZone.runOutsideAngular() 也能够解决这种场景。

之前咱们说了 Angular 能够主动帮咱们进行变化检测，这次要是基于 Zone.js 来实现，那么很多人潜意识会工作 Zone.js 就是 Angular 是一部分，Angular 的应用程序必须基于 Zone.js，其实不然，如果咱们对利用有极高的性能要求时，咱们能够抉择移除 Zone.js，移除 Zone.js 将会晋升利用的性能和打包的体积，不过带来的结果就是咱们须要次要去调用变化检测。

在 Ivy 之后，咱们有一些新的 API 能够更不便的调用变化检测

ɵmarkDirty: 标记一个组件为 dirty 状态 (须要从新渲染) 并将在将来某个工夫点安顿一个变更检测

ɵdetectChanges： 因为某些效率方面的起因，外部文档不举荐应用 ɵdetectChanges 而举荐应用 ɵmarkDirty ，ɵdetectChanges 会触发组件以子组件的变更检测。

移除 Zone.js 后变化检测由利用本人来管制，极大的缩小了不必要的变化检测次数，同时打包后的提及也缩小了 36k

移除前：

移除后：

咱们先来看一个组件绑定的例子：

按咱们失常开发组件的想法，当看到这个示例的时候肯定认为这个 Case 是 Ok 的，然而在运行测试后咱们发现这个 Case 失败了。

在生产环境中，当 Angular 创立一个组件，就会主动进行变更检测。然而在测试中， **TestBed.createComponent()** 并不会进行变化检测，须要咱们手动触发。

批改一下下面的 Case:

从下面的示例中能够理解到，咱们必须通过调用 fixture.detectChanges() 来通知 TestBed 执行数据绑定。

如果咱们在测试中动静扭转了绑定值，同样也须要调用 fixture.detectChanges()。

it("should update title", () => {
    component.title = 'Test Title';
    fixture.detectChanges();
    const h1 = fixture.nativeElement.querySelector("h1");
    expect(h1.textContent).toContain('Test Title');
});

咱们发现写测试过程中须要频繁的调用 fixture.detectChanges() ，可能会感觉比拟繁琐，那 Angular 可不可以在测试环境中主动运行变化检测呢？

咱们能够通过配置 ComponentFixtureAutoDetect 来实现

TestBed.configureTestingModule({declarations: [ BannerComponent],
  providers: [{ provide: ComponentFixtureAutoDetect, useValue: true}
  ]
});

而后再回头看看方才的示例：

下面的示例咱们并没有调用 fixture.detectChanges() ，然而测试仍然通过了，这是因为咱们开启了主动变化检测。

再看一个示例：

下面的示例中，咱们在测试代码中动静批改了 title 的值，测试运行失败，这是因为 Angular 并不知道测试扭转了组件，ComponentFixtureAutoDetect 只对异步操作进行主动变化检测，例如 Promise、setTimeout、click 等 DOM 事件等，如果咱们手动更改了绑定值，咱们仍然还须要调用 fixture.detectChanges() 来执行变化检测。

下面这个示例，绑定值批改后调用了 fixture.detectChanges() , 然而运行测试后依然报错，这是为什么呢？

查看 Angular 源码后咱们发现 ngModel 的值是通过异步更新的，执行 fixture.detectChanges() 后尽管触发了变化检测，然而值还并未批改胜利。

批改一下测试：

批改后咱们将断言包裹在了 fixture.whenStable() 中，而后测试通过，那 whenStable() 是什么呢？

whenStable(): Promise<any>：当夹具稳固时解析的承诺当事件已触发异步流动或异步变更检测后，可用此办法继续执行测试。

当然除了用 fixture.whenStable() 咱们也能够用 tick() 来解决这个问题

tick()：为 fakeAsync Zone 中的计时器模仿异步工夫流逝在此函数开始时以及执行任何计时器回调之后，微工作队列就会耗尽

下面这个示例，咱们在批改属性后调用了 fixture.detectChanges() ，然而测试未通过，这是为什么呢？咱们发现这个示例与第一个示例惟一的区别就是这个组件是一个 OnPush 组件，之前咱们说过默认变化检测会跳过 OnPush 组件的，只有在特定的几种状况下才会触发变化检测的，遇到这种状况如何解决呢？

咱们能够手动获取组件的 ChangeDetectorRef 来被动触发变化检测。

Angular Ivy 是一个新的 Angular 渲染器，它与咱们在支流框架中看到的任何货色都截然不同，因为它应用增量 DOM。增量 DOM 是什么呢？它与虚构 Dom 有什么不同呢？

首先说一下虚构 DOM，咱们要理解在浏览器中，间接操作 Dom 是非常损耗性能的，而虚构 DOM 的次要概念是将 UI 的虚构示意保留在内存中，通过 Diff 操作比照以后内存和上次内存中视图的差别，从而缩小不必要的 Dom 操作，只针对差别的 Dom 进行更改。

虚构 DOM 执行流程：

当 UI 发生变化时，将整个 UI 渲染到 Virtual DOM 中。
计算先前和以后虚构 DOM 示意之间的差别。
应用更改更新实在的 DOM。

虚构 DOM 的长处：

高效的 Diff 算法。
简略且有助于进步性能。
没有 React 也能够应用
足够轻量
容许构建应用程序且不思考状态转换

增量 Dom 的次要概念是将组件编译成一系列的指令，这些指令去创立 DOM 树并在数据更改时就地的更新它们。

例如：

@Component({
  selector: 'todos-cmp',
  template: `
    <div *ngFor="let t of todos|async">
        {{t.description}}
    </div>
  `
})
class TodosComponent {todos: Observable<Todo[]> = this.store.pipe(select('todos'));
  constructor(private store: Store<AppState>) {}}

编译后：

var TodosComponent = /** @class */ (function () {function TodosComponent(store) {
    this.store = store;
    this.todos = this.store.pipe(select('todos'));
  }

  TodosComponent.ngComponentDef = defineComponent({
    type: TodosComponent,
    selectors: [["todos-cmp"]],
    factory: function TodosComponent_Factory(t) {return new (t || TodosComponent)(directiveInject(Store));
    },
    consts: 2,
    vars: 3,
    template: function TodosComponent_Template(rf, ctx) {if (rf & 1) { // create dom
        pipe(1, "async");
        template(0, TodosComponent_div_Template_0, 2, 1, null, _c0);
      } if (rf & 2) { // update dom
        elementProperty(0, "ngForOf", bind(pipeBind1(1, 1, ctx.todos)));
      }
    },
    encapsulation: 2
  });

  return TodosComponent;
}());

增量 DOM 的长处：

渲染引擎能够被 Tree Shakable，升高编译后的体积
占用较低的内存

Tree Shaking 是指在编译指标代码时移除上下文中未援用的代码，增量 DOM 充分利用了这一点，因为它应用了基于指令的办法。正如示例所示，增量 DOM 在编译之前将每个组件编译成一组指令，这有助于辨认未应用的指令。在 Tree Shakable 过程中，能够将这些未应用的的指令删除掉。

与虚构 DOM 不同，增量 DOM 在从新出现应用程序 UI 时不会生成实在 DOM 的正本。此外，如果应用程序 UI 没有变动，增量 DOM 就不会调配任何内存。大多数状况下，咱们都是在没有任何重大批改的状况下从新出现应用程序 UI。因而，依照这种办法能够极大的缩小设施内存应用。

至此，Angular 变化检测相干的内容就介绍完了，这是我在公司外部 2 个小时的分享内容，在筹备的过程中参考了很多优良的材料，本人也学习到了更深层，更细节的一些技术点。如果大家有不了解的，欢送在评论区沟通，如果有须要改过的中央，也欢送大家指出，心愿这篇文章能够帮忙大家更好的了解 Angular 的变化检测。

https://indepth.dev/posts/1305/the-last-guide-for-angular-change-detection-youll-ever-need

https://blog.bitsrc.io/quantum-angular-maximizing-performance-by-removing-zone-e0eefe85b8d8

https://blog.nrwl.io/understanding-angular-ivy-incremental-dom-and-virtual-dom-243be844bf36

https://blog.bitsrc.io/incremental-vs-virtual-dom-eb7157e43dca

https://blog.angular-university.io/how-does-angular-2-change-detection-really-work/

https://angular.io/guide/testing-components-scenarios

https://zhuanlan.zhihu.com/p/27901766

关于angular:Angular-变化检测详解

前言

什么是变化检测 ?

变化检测触发机会

Angular 如何订阅异步事件执行变化检测？

Zone.js

NgZone

变化检测是如何工作的？

单向数据流

变化检测的性能

变化检测的策略

Default 策略

OnPush 策略

输出值（@Input）更改

以后组件或子组件之一触发了事件

手动触发变化检测

应用 async 管道

缩小变化检测次数

脱离 Zone.js 开发

如何移除 Zone.js?

手动调用变化检测

移除后的性能

测试与变化检测

组件绑定

主动变更检测

常见的坑

ngModel

测试 OnPush 组件

延长

虚构 DOM 与增量 DOM

虚构 DOM

增量 DOM

为什么可渲染引擎能够被 Tree Shakable？

缩小内存的应用

总结

参考资料