原文

Angular脏值查看

本文提供了您须要理解的无关变更检测的所有必要信息。通过应用本文构建的演示我的项目来解释angular 的变更检测机制。

Angular的变更检测是该框架的外围机制，但（至多以我的教训）很难了解。更可怜的是，官方网站上没有对于此主题的官网指南。

What Is Change Detection

Angular的两个次要指标是可预测和高效。框架须要通过组合状态和模板来在UI上复制应用程序的状态：

如果状态产生任何更改，也必须更新DOM。将HTML与咱们的数据同步的机制称为“更改检测”。每个前端框架都应用其实现，例如React应用虚构DOM，Angular应用更改检测等等。我能够举荐文章“ JavaScript框架中的更改及其检测”，该文章很好地概述了此主题。

更改检测：数据更改后更新DOM的过程

作为开发人员，大多数时候咱们不须要关怀变更检测，除非咱们须要优化应用程序的性能。如果处理不当，更改检测会升高大型应用程序的性能。

How Change Detection Works 变更检测是如何工作的

变更检测周期能够分为两个局部：

  • 开发人员更新应用程序模型
  • Angular通过从新渲染来同步DOM中的更新模型

让咱们更具体地看一下这个过程：

  1. 开发人员更新数据模型，例如通过更新组件绑定
  2. angular 检测变动
  3. 变更检测从上到下查看组件树中的每个组件，以查看相应的模型是否已更改
  4. 如果有新值，它将更新组件的视图（DOM）

    以下GIF以简化的形式演示了此过程：

该图显示了Angular组件树及其在应用程序疏导过程中为每个组件创立的更改检测器（CD）。该检测器将以后值与属性的先前值进行比拟。如果该值已更改，它将==isChanged==设置为==true==。查看框架代码中的实现，这只是与NaN的非凡解决进行的===比拟。

Zone.js

个别状况下，zone能够跟踪并拦挡任何异步工作。

Zone 通常具备以下阶段：

  • 开始稳固
  • 如果工作在区域中运行，它将变得不稳固,
  • 如果工作实现，它将再次变得稳固

Angular在启动时修补了几个低级浏览器API，以便可能检测到应用程序中的更改。这是应用zone.js实现的，该区域修补了EventEmitter，DOM事件侦听器，XMLHttpRequest，Node.js中的fs API等API。

简而言之，如果产生以下事件之一，则框架将触发更改检测

  • 任何浏览器事件（单击，键入等）
  • setInterval() and setTimeout()
  • HTTP 申请

Angular应用其称为NgZone的区域。仅存在一个NgZone，并且仅针对此区域中触发的异步操作触发更改检测。

Performance 性能

默认状况下，如果模板值已更改，则“Angular Change Detection ”将从上至下查看所有组件。

Angular对每个组件执行更改检测的速度十分快，因为它能够应用内联缓存在毫秒内执行数千次查看，内联缓存可生成VM优化代码。

如果您想对此主题有更深刻的阐明，建议您观看Victor Savkin对于“重塑变化检测”的演讲。

只管Angular在后盾进行了大量优化，然而在大型应用程序上性能依然会降落。在下一章中，您将学习如何通过应用不同的变更检测策略来被动进步Angular性能。

Change Detection Strategies 变更检测策略

Angular提供了两种策略来运行更改检测：

  • Default
  • OnPush

让咱们看一下每种变化检测策略。

Default Change Detection Strategy

默认状况下，Angular应用ChangeDetectionStrategy.Default更改检测策略。每当事件触发更改检测（例如用户事件，计时器，XHR，promise等）时，此默认策略都会从上到下查看组件树中的每个组件。这种不对组件的依赖项做任何假如的激进查看办法称为脏查看。它可能会对蕴含许多组件的大型应用程序的性能产生负面影响。

OnPush Change Detection Strategy

通过将changeDetection属性增加到组件装璜器元数据中，咱们能够切换到ChangeDetectionStrategy.OnPush更改检测策略：

@Component({    selector: 'hero-card',    changeDetection: ChangeDetectionStrategy.OnPush,    template: ...})export class HeroCard {    ...}

这种更改检测策略能够跳过对此组件及其所有子组件的不必要查看。
下一个GIF演示了应用OnPush更改检测策略跳过组件树的各个局部：

应用此策略，Angular晓得仅在以下状况下才须要更新组件：

  • 输出属性已更改, 标记为@Input() 的属性；
  • 该组件或其子组件之一触发事件处理程序
  • 手动触发变化检测

  • 通过异步管道链接到模板的可察看对象收回新值， 如 data | async

    让咱们认真看看这些事件类型。

    Input Reference Changes

    在默认的更改检测策略中，每当@Input（）数据被更改或批改时，Angular将运行更改检测器。应用OnPush策略，仅当新援用作为@Input（）值传递时，才会触发更改检测器。

    JavaScript中的所有内容都是按援用传递的，然而所有基元都是不可变的，并且它们的文字示意均指向雷同的基元实例/援用。批改对象属性或数组条目不会创立新援用，因而不会触发OnPush组件上的更改检测。要触发变更检测器，您须要传递一个新的对象或数组援用。

您能够应用简略DEMO测试此行为：

  1. 应用ChangeDetectionStrategy.Default批改HeroCardComponent的 age
  2. 验证带有ChangeDetectionStrategy.OnPush的HeroCardOnPushComponent不能反映更改的age（通过组件四周的红色边框显示）
  3. 在“批改英雄”面板中单击“创立新对象援用”
  4. 验证是否通过更改检测查看了具备ChangeDetectionStrategy.OnPush的HeroCardOnPushComponent

为避免更改检测谬误，在所有中央仅应用不可变的对象和列表应用OnPush更改检测来构建应用程序可能会很有用。不可变对象只能通过创立新的对象援用来批改，因而咱们能够保障：

  • 每次更改都会触发OnPush更改检测
  • 咱们不要忘了创立一个新的对象援用，否则可能导致谬误；

Immutable.js是一个不错的抉择，该库为对象（地图）和列表（列表）提供了长久不变的数据结构。通过npm装置库提供了类型定义，以便咱们能够在IDE中利用类型泛型，谬误检测和主动实现性能。

Event Handler Is Triggered

如果OnPush组件或其子组件之一触发事件处理程序（例如单击按钮），则将触发更改检测（针对组件树中的所有组件）。

请留神，以下操作不会触发应用OnPush更改检测策略的更改检测：

  • setTimeOut
  • setInterval
  • Promise.resolve().then(), (of course, the same for Promise.reject().then())

  • this.http.get('...').subscribe() (in general, any RxJS observable subscription)

    You can test this behavior using the simple demo:

    1. Click on "Change Age" button in HeroCardOnPushComponent which uses ChangeDetectionStrategy.OnPush
    2. 验证触发了变更检测并查看所有组件

Trigger Change Detection Manually 手动触发变更检测

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

  • ChangeDetectorRef的detectChanges（）通过牢记更改检测策略在此视图及其子级上运行更改检测。它能够与detach（）联合应用以实现本地更改检测查看。
  • ApplicationRef.tick（）通过恪守组件的更改检测策略来触发整个应用程序的更改检测
  • ChangeDetectorRef上的markForCheck（）不会触发更改检测，但会将所有OnPush先人标记为要查看一次，作为以后或下一个更改检测周期的一部分。即便已标记的组件应用OnPush策略，它也将运行更改检测。
手动运行变更检测不是黑客，但您只能在正当的状况下应用它,

下图以可视示意模式显示了不同的ChangeDetectorRef办法：

您能够在DEMO中应用“ DC”（detectChanges（））和“ MFC”（markForCheck（））按钮来测试其中一些操作。

### Async Pipe

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

每次收回新值时，AsyncPipe外部都会调用markForCheck，请参见其源代码：

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

如图所示，AsyncPipe应用OnPush更改检测策略主动运行。因而，倡议尽可能应用它，以便当前执行从默认更改检测策略到OnPush的切换。

您能够在异步演示中看到这种行为。

第一个组件通过AsyncPipe将可察看对象间接绑定到模板

<mat-card-title>{{ (hero$ | async).name }}</mat-card-title>
 hero$: Observable<Hero>;  ngOnInit(): void {    this.hero$ = interval(1000).pipe(        startWith(createHero()),        map(() => createHero())      );  }

而第二个组件订阅可察看对象并更新数据绑定值：

<mat-card-title>{{ hero.name }}</mat-card-title>
  hero: Hero = createHero();  ngOnInit(): void {    interval(1000)      .pipe(map(() => createHero()))        .subscribe(() => {          this.hero = createHero();          console.log(            'HeroCardAsyncPipeComponent new hero without AsyncPipe: ',            this.hero          );        });  }

如您所见，没有AsyncPipe的实现不会触发更改检测，因而咱们须要为可察看对象收回的每个新事件手动调用detectChanges（）

防止变化检测循环和ExpressionChangedAfterCheckedError

Angular包含一种检测变化检测循环的机制。在开发模式下，框架运行两次更改检测，以查看自第一次运行以来该值是否已更改。在生产模式下，更改检测仅运行一次即可取得更好的性能。

我在ExpressionChangedAfterCheckedError演示中强加了该谬误，如果关上浏览器控制台，则能够看到它：

在此演示中，我通过更新ngAfterViewInit生命周期挂钩中的hero属性来强制执行谬误：

ngAfterViewInit(): void {    this.hero.name = 'Another name which triggers ExpressionChangedAfterItHasBeenCheckedError';  }

要理解为什么这会导致谬误，咱们须要查看更改检测运行期间的不同步骤：

如咱们所见，在出现了以后视图的DOM更新之后，将调用AfterViewInit生命周期挂钩。如果咱们更改此挂钩中的值，则它将在第二次更改检测运行中具备不同的值（如上所述，这是在开发模式下主动触发的），因而Angular将抛出ExpressionChangedAfterCheckedError。

我能够强烈推荐Max Koretskyi撰写的无关Angular中的更改检测所需的所有常识，它具体探讨了驰名的ExpressionChangedAfterCheckedError的根底实现和用例。

没有更改检测的运行代码

能够在NgZone内部运行某些代码块，以便它不会触发更改检测。

  constructor(private ngZone: NgZone) {}  runWithoutChangeDetection() {    this.ngZone.runOutsideAngular(() => {      // the following setTimeout will not trigger change detection      setTimeout(() => doStuff(), 1000);    });  }

这个简略的演示提供了一个按钮来触发Angular区域之外的动作：

您应该看到该操作已记录在控制台中，然而HeroCard组件未选中，这意味着它们的边框不会变成红色。

此机制对于由量角器运行的E2E测试很有用，特地是如果您在测试中应用browser.waitForAngular。将每个命令发送到浏览器后，量角器将期待，直到区域变得稳固为止。如果应用setInterval，则区域将永远不会变得稳固，并且测试可能会超时。

RxJS可察看对象可能产生雷同的问题，然而您须要依照Zone.js对非标准API的反对中所述，将修补版本增加到polyfill.ts中：

import 'zone.js/dist/zone';  // Included with Angular CLI.import 'zone.js/dist/zone-patch-rxjs'; // Import RxJS patch to make sure RxJS runs in the correct zone

如果没有此修补程序，则能够在ngZone.runOutsideAngular外部运行可察看的代码，但仍能够作为工作在NgZone外部运行

停用变更检测

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

constructor(private ref: ChangeDetectorRef) {    ref.detach(); // deactivate change detection    setInterval(() => {      this.ref.detectChanges(); // manually trigger change detection    }, 10 * 1000);  }

在Angular应用程序的疏导过程中，也能够齐全停用Zone.js。这意味着主动更改检测性能已齐全停用，咱们须要手动触发用户界面更改，例如通过调用ChangeDetectorRef.detectChanges（）。

首先，咱们须要正文掉从polyfills.ts导入的Zone.js：

import 'zone.js/dist/zone';  // Included with Angular CLI.

接下来，咱们须要在main.ts中传递noop区域：

platformBrowserDynamic().bootstrapModule(AppModule, {      ngZone: 'noop';}).catch(err => console.log(err));

无关停用Zone.js的更多详细信息，请参见文章没有Zone.Js的Angular Elements。

Ivy

从Angular 9开始，Angular默认应用Ivy，它是Angular的下一代编译和渲染管道。

Ivy依然以正确的程序解决所有框架生命周期挂钩，以便更改检测像以前一样工作。因而，您仍将在应用程序中看到雷同的ExpressionChangedAfterCheckedError。

Max Koretskyi在文章中写道：

如您所见，所有相熟的操作仍在这里。然而操作程序仿佛曾经扭转。例如，当初看来Angular首先查看子组件，而后才查看嵌入式视图。因为目前没有编译器能够生成适宜于测验我的假如的输入，因而我不确定。

您能够在此博文开端的“举荐文章”局部中找到另外两个与Ivy相干的乏味文章。

最初

Angular Change Detection是一种弱小的框架机制，可确保咱们的UI以可预测和高效的形式示意咱们的数据。能够必定地说，更改检测仅实用于大多数应用程序，尤其是当它们不蕴含50多个组件时。

作为开发人员，您通常须要深入探讨此主题，起因有两个：

  • 您收到一个ExpressionChangedAfterCheckedError并须要解决它
  • 您须要进步应用程序性能

我心愿本文能够帮忙您更好地理解Angular的变更检测。随便应用我的演示我的项目来试用不同的变更检测策略。

举荐文章

  • Angular Change Detection - How Does It Really Work?
  • Angular OnPush Change Detection and Component Design - Avoid Common Pitfalls
  • A Comprehensive Guide to Angular onPush Change Detection Strategy
  • Angular Change Detection Explained
  • Angular Ivy change detection execution: are you prepared?
  • Understanding Angular Ivy: Incremental DOM and Virtual DOM