共计 3007 个字符，预计需要花费 8 分钟才能阅读完成。
随着子组件的增多和嵌套，遇到数据扭转，然而组件页面没有渲染的问题开始变多。
例如:
此页面为子组件，关上该页面后，本来应该显示已存在的附件，然而当初却显示空。
正确显示：
问题显示：没有渲染
此问题的呈现往往是因为变更检测器没有检测到组件的数据变更，没有进行变更检测。
到底为什么没有检测到，探索了一段时间也没有探究出产生问题根本原因是什么。
但往往 能够过手动变更检测来解决，如下述代码的第 9 行，调用 ChangeDetectorRef 的 detectChanges 函数。明天就来讲一讲对于 ChangeDetectorRef 的相干常识。
1 constructor(private attachmentService: AttachmentService,
2 private ref: ChangeDetectorRef) {3}
4 getAttachmentByIds() {5 this.attachmentService.getAttachmentByIds(this.attachmentIds)
6 .subscribe(attachments => {
7 this.attachments = attachments;
8 // 进行强制变更检测 避免页面不显示 attachments 的变更
9 this.ref.detectChanges();
10 })
11 }变更检测
先来说说 angular 变更检测的两种策略。
DefaultOnPush
Default 策略
Angular 的组件能够依赖其余的组件来构建应用程序的页面逻辑，最初造成一棵组件树。每个组件都有本人的变更检测器（change detector）。因而，变更检测器的构造也是一棵同构的树
当某个组件的状态产生扭转时，Angular 会从这棵树的根节点开始遍历，登程所有组件节点的变更检测器，这样 Angular 就晓得那些组件的状态产生了扭转，须要更新相应的 UI。
这个过程看似开销很大，但 Angular 曾经进行了大量优化，理论变更检测的速度很快。这种策略在咱们利用组件过多时会对咱们的利用产生性能的影响, 不过在不相熟相干细节的状况下，Default 策略是咱们最好的抉择。
OnPush 策略
OnPush 策略我目前没有尝试用过，但能够作为理解。
Angular 还提供了一种 OnPush 策略，咱们可 以批改组件装璜器的 changeDetection 属性来更改变化检测的策略。如下述代码的第 4 行。
1 @Component({
2 selector: 'app-A',
3 // 设置变化检测的策略
4 changeDetection: ChangeDetectionStrategy.OnPush,
5 template: ...
6 })
7 export class AComponent {
8 ...
9 }在 OnPush 策略下，只有这几种状况能够触发以后组件的变更检测：
- 组件的输出属性（绑定）的援用被扭转
- 组件外部触发了异步事件
- 手动触发变更检测
- 以后组件或子组件之一触发了事件, 如 click
简略谈谈第一点，这是 angular 中比拟经典的解决办法。其余的都比拟直观。
例如父组件向子组件应用 @Input 传入一个对象
@Component({
template: `
<child [people]="people"></child>
`
})
export class AppComponent {
people = {name: '张三'};
onClick1() {this.people.name = '李四';}
onClick2() {this.people = { name: '李四'};
}
}
父组件调用 onClick1 函数并不会触发变更检测，因为这仅仅是扭转了对象的属性，并没有扭转对象的援用。
而 onClick2 函数才会触发变更检测。
咱们能够通过以下的图察看 onPush 策略下的行为。
当默认变更检测进行时，变更检测器并没有去更新 onPush 策略那一边的子树。在咱们对组件的变更检测非常理解的状况下，应用这种行为能够缩小不必要的变更检测从而进步性能。
总结：
为了自动检测变动，Angular 默认应用 ChangeDetectionStrategy.Default 策略，可确保咱们的 UI 以可预测和高性能的形式显示，在变更组件不超过 50 个时，实用于大多数应用程序
对于较大的应用程序，能够思考应用 ChangeDetectionStrategy.OnPush 策略。
ChangeDetectorRef
接下来说说手动变更检测。
手动变更检测应用到了 angular 给咱们提供的 ChangeDetectorRef 类，定义了以下几种公共接口。
class ChangeDetectorRef {markForCheck() : void
detach() : void
reattach() : void
detectChanges() : void
checkNoChanges() : void}假如咱们有如下组件树
detach()
容许咱们操作状态的第一个办法是detach，它只是单纯禁用对以后视图的检测。
应用办法也很简略。
export class AComponent {constructor(public cd: ChangeDetectorRef) {this.cd.detach();
}这确保了在运行以下更改检测时，AppComponent 将跳过以 结尾的左分支（不会查看背景为黄色的组件）。
同时如果 AComponent 的状态产生了扭转，它的子组件也不会进行查看。
reattach
将先前拆散的视图从新附加到更改检测树。
例如咱们应用 reattach() 办法，就能够将下面应用 detach（）禁用的视图从新增加进来。
例如：
@Input()
set live(value: boolean) {if (value) {this.ref.reattach();
} else {this.ref.detach();
}
}
markForCheck
该办法实用于应用 OnPush 策略的时候。
当视图应用 OnPush (checkOnce) 更改检测策略时，显式将视图标记为脏，以便再次对其进行查看。
从搜寻到的材料来看，它只是向上迭代并启用对每个父组件直至根的查看。
detectChanges
对以后组件及其所有子组件运行一次更改检测, 也是咱们最罕用的。
checkNoChanges
可确保在以后的变更检测运行中不会产生任何更改。如果发现更改的绑定或确定应该更新 DOM，则抛出异样。
组合操作
比方组件的数据预计会一直变动，每秒屡次。为了进步性能，咱们心愿检查和更新列表的频率低于理论产生更改的频率。为此，咱们能够拆散组件的更改检测器并每五秒执行一次查看。
@Component({
selector: 'giant-list',
template: `
<li *ngFor="let d of dataProvider.data">Data {{d}}</li>
`,
})
class GiantList {constructor(private ref: ChangeDetectorRef, public dataProvider: DataListProvider) {ref.detach();
setInterval(() => {this.ref.detectChanges();
}, 5000);
}
}总结：了解 ChangeDetectorRef 类，能够很好地帮忙咱们对变更检测的原理和行为，当默认变更检测满足不了咱们的想法时，能够让咱们手动地去调整视图的更新。
