深入了解Angular中的變更檢測

本篇文章帶大家來了解Angular中的變更偵測。有一定的參考價值，有需要的朋友可以參考一下，希望對大家有幫助。

原文連結: 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並沒有改變。

核心概念-視圖View

---

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

这个方法简单的禁止了对当前视图的检测；

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: [&#39;./change-dection.component.css&#39;]
})
export class ChangeDectionComponent implements OnInit {
    name = &#39;erik&#39;;
    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;
        }
    }
}

detectChanges

Angular提供了一个方法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中的變更檢測的詳細內容。更多資訊請關注PHP中文網其他相關文章！