` in an `ngFor` *hero* repeater
managed by the parent `SpyComponent`.
我们把`SpyDirective`应用到父组件里的`ngFor`*英雄*重复器(repeater)的`
`里面。
tr(style=top)
td
OnChanges
td
:marked
See how Angular calls the `ngOnChanges` hook with a `changes` object
every time one of the component input properties changes.
Shows how to interpret the `changes` object.
这里将会看到：每当组件的输入属性发生变化时，Angular会如何以`changes`对象作为参数去调用`ngOnChanges`钩子。
展示了该如何理解和使用`changes`对象。
tr(style=top)
td
DoCheck
td
:marked
Implements an `ngDoCheck` method with custom change detection.
See how often Angular calls this hook and watch it post changes to a log.
实现了一个`ngDoCheck`方法，通过它可以自定义变更检测逻辑。
这里将会看到：Angular会用什么频度调用这个钩子，监视它的变化，并把这些变化输出成一条日志。
tr(style=top)
td
AfterView
td
:marked
Shows what Angular means by a *view*.
Demonstrates the `ngAfterViewInit` and `ngAfterViewChecked` hooks.
显示Angular中的*视图*所指的是什么。
演示了`ngAfterViewInit`和`ngAfterViewChecked`钩子。
tr(style=top)
td
AfterContent
td
:marked
Shows how to project external content into a component and
how to distinguish projected content from a component's view children.
Demonstrates the `ngAfterContentInit` and `ngAfterContentChecked` hooks.
展示如何把外部内容投影进组件中，以及如何区分“投影进来的内容”和“组件的子视图”。
演示了`ngAfterContentInit`和`ngAfterContentChecked`钩子。
tr(style=top)
td
p Counter
p 计数器
td
:marked
Demonstrates a combination of a component and a directive
each with its own hooks.
演示了组件和指令的组合，它们各自有自己的钩子。
In this example, a `CounterComponent` logs a change (via `ngOnChanges`)
every time the parent component increments its input counter property.
Meanwhile, we apply the `SpyDirective` from the previous example
to the `CounterComponent` log and watch log entries be created and destroyed.
在这个例子中，每当父组件递增它的输入属性`counter`时，`CounterComponent`就会通过`ngOnChanges`记录一条变更。
同时，我们还把前一个例子中的`SpyDirective`用在`CounterComponent`上，来提供日志，可以同时观察到日志的创建和销毁过程。
:marked
We discuss the exercises in further detail over this chapter as we learn more about the lifecycle hooks.
接下来，我们将详细讨论这些练习，以学习更多关于生命周期钩子的知识。
a(id="peek-a-boo")
.l-main-section
:marked
## Peek-a-boo: all hooks
## Peek-a-boo：全部钩子
The `PeekABooComponent` demonstrates all of the hooks in one component.
`PeekABooComponent`组件演示了组件中所有可能存在的钩子。
In real life, we'd rarely if ever implement all of the interfaces like this.
We do so in peek-a-boo in order to watch Angular call the hooks in the expected order.
现实中，我们几乎永远不会像这里一样实现所有这些接口。
我们之所以在peek-a-boo中这么做，只是为了观看Angular是如何按照期望的顺序调用这些钩子的。
In this snapshot, we clicked the *Create...* button and then the *Destroy...* button.
在下面这个快照中，我们先点击了*Create...*按钮，然后点击了*Destroy...*按钮。
figure.image-display
img(src="/resources/images/devguide/lifecycle-hooks/peek-a-boo.png" alt="Peek-a-boo")
:marked
The sequence of log messages follows the prescribed hook calling order:
`OnChanges`, `OnInit`, `DoCheck` (3x), `AfterContentInit`, `AfterContentChecked` (3x),
`AfterViewInit`, `AfterViewChecked` (3x), and `OnDestroy`.
日志信息的日志和所规定的钩子调用顺序是一致的：
`OnChanges`、`OnInit`、`DoCheck` (3x)、`AfterContentInit`、`AfterContentChecked` (3x)、
`AfterViewInit`、`AfterViewChecked` (3x)和`OnDestroy`
.l-sub-section
:marked
The constructor isn't an Angular hook *per se*.
We log in it to confirm that input properties (the `name` property in this case) have no assigned values at construction.
构造函数本质上不应该算作Angular的钩子。
我们把它记录在这里只是为了确认在创建期间那些输入属性(这里是`name`属性)没有被赋值。
:marked
Had we clicked the *Update Hero* button, we'd have seen another `OnChanges` and two more triplets of
`DoCheck`, `AfterContentChecked` and `AfterViewChecked`.
Clearly these three hooks fire a *lot* and we must keep the logic we put in these hooks
as lean as possible!
如果我们点击*Update Hero*按钮，就会看到另一个`OnChanges`和至少两组`DoCheck`、`AfterContentChecked`和`AfterViewChecked`钩子。
显然，这三种钩子被触发了*很多次*，所以我们必须让这三种钩子里的逻辑尽可能的精简！
Our next examples focus on hook details.
我们的下一个例子就聚焦于这些钩子的细节上。
.a(id="spy")
.l-main-section
:marked
## Spying *OnInit* and *OnDestroy*
## 窥探*OnInit*和*OnDestroy*
We're going undercover for these two hooks. We want to know when an element is initialized or destroyed,
but we don't want *it* to know we're watching.
我们将揭开这两个钩子的奥秘。我们想知道一个元素是什么时候被初始化或销毁的，但我们不希望*它*知道我们正在监视它。
This is the perfect infiltration job for a directive.
Our heroes will never know it's there.
指令是一种完美的渗透方式，我们的英雄永远不会知道该指令的存在。
.l-sub-section
:marked
Kidding aside, we're emphasizing two key points:
不开玩笑了，我们要强调的是两点：
1. Angular calls hook methods for *directives* as well as components.
1. 就像对组件一样，Angular也会对*指令*调用这些钩子方法。
2. A spy directive can gives us insight into a DOM object that we cannot change directly.
Obviously we can't change the implementation of a native `div`.
We can't modify a third party component either.
But we can watch both with a directive.
2. 一个侦探(spy)指令可以让我们在无法直接修改DOM对象实现代码的情况下，透视其内部细节。
显然，我们不能修改一个原生`div`元素的实现代码。
我们同样不能修改第三方组件。
但我们用一个指令就能监视它们了。
:marked
Our sneaky spy directive is simple, consisting almost entirely of `ngOnInit` and `ngOnDestroy` hooks
that log messages to the parent via an injected `LoggerService`.
我们这个鬼鬼祟祟的侦探指令很简单，几乎完全由`ngOnInit`和`ngOnDestroy`钩子组成，它通过一个注入进来的`LoggerService`来把消息记录到父组件中去。
+makeExample('lifecycle-hooks/ts/app/spy.directive.ts', 'spy-directive')(format=".")
:marked
We can apply the spy to any native or component element and it'll be initialized and destroyed
at the same time as that element.
Here we attach it to the repeated hero `
`
我们可以把这个侦探指令写到任何原生元素或组件元素上，它将与所在的组件同时初始化和销毁。
这里我们把它附加到用来重复显示英雄数据的这个`
`上。
+makeExample('lifecycle-hooks/ts/app/spy.component.html', 'template')(format=".")
:marked
Each spy's birth and death marks the birth and death of the attached hero `
`
with an entry in the *Hook Log* as we see here:
每个“侦探”的出生和死亡也同时标记出了存放英雄的那个`
`的出生和死亡。*钩子记录*中的结构看起来是这样的：
figure.image-display
img(src='/resources/images/devguide/lifecycle-hooks/spy-directive.gif' alt="Spy Directive")
:marked
Adding a hero results in a new hero `
`. The spy's `ngOnInit` logs that event.
We see a new entry for each hero.
添加一个英雄就会产生一个新的英雄`
`。侦探的`ngOnInit`记录下了这个事件。
我们看到每添加一个英雄都产生了一条新的日志结构。
The *Reset* button clears the `heroes` list.
Angular removes all hero divs from the DOM and destroys their spy directives at the same time.
The spy's `ngOnDestroy` method reports its last moments.
*Reset*按钮清除了这个`heroes`列表。
Angular从DOM中移除了所有英雄的div，并且同时销毁了附加在这些div上的侦探指令。
侦探的`ngOnDestroy`方法汇报了它自己的临终时刻。
The `ngOnInit` and `ngOnDestroy` methods have more vital roles to play in real applications.
Let's see why we need them.
在真实的应用程序中，`ngOnInit`和`ngOnDestroy`方法扮演着更重要的角色。
来看看我们为什么需要它们。
### OnInit
We turn to `ngOnInit` for two main reasons:
我们会因为两个主要理由而求助于`ngOnInit`：
1. To perform complex initializations shortly after construction
1. 在构造函数之后马上执行复杂的初始化逻辑
1. To set up the component after Angular sets the input properties
1. 在Angular设置完输入属性之后，对该组件进行准备。
An `ngOnInit` often fetches data for the component as shown in the
[Tutorial](../tutorial/toh-pt4.html#oninit) and [HTTP](server-communication.html#oninit) chapters.
`ngOnInit`通常用来为组件获取数据，就像在[教程](../tutorial/toh-pt4.html#oninit)和[HTTP](server-communication.html#oninit)中所展示的那样。
We don't fetch data in a component constructor. Why?
Because experienced developers agree that components should be cheap and safe to construct.
We shouldn't worry that a new component will try to contact a remote server when
created under test or before we decide to display it.
Constructors should do no more than set the initial local variables to simple values.
我们没有在组件的构造函数中获取数据。为什么呢？
因为有经验的开发者都同意，组件应该能被“便宜”而且安全的被构造出来。
在测试环境下新建组件时或在我们决定显示它之前，我们不应该担心它会尝试联系远程服务器。
构造函数中除了使用简单的值对局部变量进行初始化之外，什么都不应该做。
When a component must start working _soon_ after creation,
we can count on Angular to call the `ngOnInit` method to jumpstart it.
That's where the heavy initialization logic belongs.
如果组件必须在创建之后_很快_就开始工作，我们可以等Angular调用`ngOnInit`方法来启动它。
该方法中才是放重量级初始化逻辑的地方。
Remember also that a directive's data-bound input properties are not set until _after construction_.
That's a problem if we need to initialize the directive based on those properties.
They'll have been set when our `ngOninit` runs.
另外还要记住，在指令的_构造函数完成之前_，那些被绑定的输入属性还都没有值。
如果我们需要基于这些属性的值来初始化这个指令，这种情况就会出问题。
而当`ngOnInit`执行的时候，这些属性都已经被正确的赋值过了。
.l-sub-section
:marked
Our first opportunity to access those properties is the `ngOnChanges` method which
Angular calls before `ngOnit`. But Angular calls `ngOnChanges` many times after that.
It only calls `ngOnit` once.
我们访问这些属性的第一次机会，实际上是`ngOnChanges`方法，Angular会在`ngOnInit`之前调用它。
但是在那之后，Angular还会调用`ngOnChanges`很多次。而`ngOnInit`只会被调用一次。
:marked
### OnDestroy
Put cleanup logic in `ngOnDestroy`, the logic that *must* run before Angular destroys the directive.
一些清理逻辑*必须*在Angular销毁指令之前运行，把它们放在`ngOnDestroy`中。
This is the time to notify another part of the application that this component is going away.
这是在该组件消失之前，可用来通知应用程序中其它部分的最后一个时间点。
This is the place to free resources that won't be garbage collected automatically.
Unsubscribe from observables and DOM events. Stop interval timers.
Unregister all callbacks that this directive registered with global or application services.
We risk memory leaks if we neglect to do so.
这里是用来释放那些不会被垃圾收集器自动回收的各类资源的地方。
取消那些对可观察对象和DOM事件的订阅。停止定时器。注销该指令曾注册到全局服务或应用级服务中的各种回调函数。
如果我们不这么做，就会有导致内存泄露的风险。
.l-main-section
:marked
## OnChanges
We monitor the `OnChanges` hook in this example.
Angular calls its `ngOnChanges` method whenever it detects changes to ***input properties*** of the component (or directive).
在这个例子中，我们监听了`OnChanges`钩子。
一旦检测到该组件(或指令)的***输入属性***发生了变化，Angular就会调用它的`ngOnChanges`方法。
Here is our implementation of the hook.
这里是我们对此钩子的实现。
+makeExample('lifecycle-hooks/ts/app/on-changes.component.ts', 'ng-on-changes', 'OnChangesComponent (ngOnChanges)')(format=".")
:marked
The `ngOnChanges` method takes an object that maps each changed property name to a
[SimpleChange](../api/core/index/SimpleChange-class.html) object with the current and previous property values.
We iterate over the changed properties and log them.
`ngOnChanges`方法获取了一个对象，它把每个发生变化的属性名都映射到了一个[SimpleChange](../api/core/index/SimpleChange-class.html)对象，
该对象中有属性的当前值和前一个值。我们在这些发生了变化的属性上进行迭代，并记录它们。
The input properties for our example `OnChangesComponent` are `hero` and `power`.
我们这个例子中的`OnChangesComponent`组件的输入属性是`hero`和`power`。
+makeExample('lifecycle-hooks/ts/app/on-changes.component.ts', 'inputs')(format=".")
:marked
The parent binds to them like this:
父组件中绑定了它们，就像这样：
+makeExample('lifecycle-hooks/ts/app/on-changes-parent.component.html', 'on-changes')
:marked
Here's the sample in action as we make changes.
下面是此例子中的当我们做出更改时的操作演示：
figure.image-display
img(src='/resources/images/devguide/lifecycle-hooks/on-changes-anim.gif' alt="OnChanges")
:marked
We see log entries as the string value of the *power* property changes. But the `ngOnChanges` did not catch changes to `hero.name`
That's surprising at first.
当*power*属性的字符串值变化时，我们看到了相应的日志。但是`ngOnChanges`并没有捕捉到`hero.name`的变化。
这是第一个意外。
Angular only calls the hook when the value of the input property changes.
The value of the `hero` property is the *reference to the hero object*.
Angular doesn't care that the hero's own `name` property changed.
The hero object *reference* didn't change so, from Angular's perspective, there is no change to report!
Angular只会在输入属性的值变化时调用这个钩子。
而`hero`属性的值是一个*到英雄对象的引用*。
Angular不会关注这个英雄对象的`name`属性的变化。
这个英雄对象的*引用*没有发生变化，于是从Angular的视角看来，也就没有什么需要报告的变化了。
.l-main-section
:marked
## DoCheck
We can use the `DoCheck` hook to detect and act upon changes that Angular doesn't catch on its own.
我们可以使用`DoCheck`钩子来检测那些Angular自身无法捕获的变更并采取行动。
.l-sub-section
:marked
With this method we can detect a change that Angular overlooked.
What we do with that information to refresh the display is a separate matter.
用这个方法我们可以检测到那些被Angular忽略的更改。
至于如何用此信息来刷新显示就是另一个问题了。
:marked
The *DoCheck* sample extends the *OnChanges* sample with this implementation of `DoCheck`:
*DoCheck*范例通过下面的`DoCheck`实现扩展了*OnChanges*范例：
+makeExample('lifecycle-hooks/ts/app/do-check.component.ts', 'ng-do-check', 'DoCheckComponent (ngDoCheck)')(format=".")
:marked
We manually check everything that we care about, capturing and comparing against previous values.
We write a special message to the log when there are no substantive changes
to the hero or the power so we can keep an eye on the method's performance characteristics.
我们手动检测了自己关心的一切，捕获当前值并与以前的值进行比较。
当英雄或他的超能力发生了非实质性改变时，我们就往日志中写一条特殊的消息，以便看到该方法的工作特征。
The results are illuminating:
其结果就像下面展示的这样：
figure.image-display
img(src='/resources/images/devguide/lifecycle-hooks/do-check-anim.gif' alt="DoCheck")
:marked
We now are able to detect when the hero's `name` has changed. But we must be careful.
我们现在可以监测到英雄的`name`什么时候发生了变化。但我们必须小心。
The `ngDoCheck` hook is called with enormous frequency —
after _every_ change detection cycle no matter where the change occurred.
It's called over twenty times in this example before the user can do anything.
`ngDoCheck`钩子被非常频繁的调用 —— 在_每次_变更检测周期之后，发生了变化的每个地方都会调它。
在这个例子中，用户还没有做任何操作之前，它就被调用了超过二十次。
Most of these initial checks are triggered by Angular's first rendering of *unrelated data elsewhere on the page*.
Mere mousing into another input box triggers a call.
Relatively few calls reveal actual changes to pertinent data.
Clearly our implementation must be very lightweight or the user experience may suffer.
大部分检查的第一次调用都是在Angular首次渲染该页面中*其它不相关数据*时触发的。
仅仅把鼠标移到其它输入框中就会触发一次调用。
只有相对较少的调用才是由于对相关数据的修改而触发的。
显然，我们的实现必须非常轻量级，否则将损害用户体验。
.l-sub-section
:marked
We also see that the `ngOnChanges` method is called in contradiction of the
[incorrect API documentation](../api/core/index/DoCheck-class.html).
我们还看到，`ngOnChanges`方法的调用方式与[API文档](../api/core/index/DoCheck-interface.html)中是不一样的，这是因为API文档过时了。
(译注：这是经过与官方开发组沟通得到的消息，由于代码快速迭代，因此API文档现在的更新不够及时，将来会进行一次系统的梳理和更正)
.l-main-section
:marked
## AfterView
The *AfterView* sample explores the `AfterViewInit` and `AfterViewChecked` hooks that Angular calls
*after* it creates a component's child views.
*AfterView*例子展示了`AfterViewInit`和`AfterViewChecked`钩子，Angular会在每次创建了组件的子视图后调用它们。
Here's a child view that displays a hero's name in an input box:
下面是一个子视图，它用来把英雄的名字显示在一个输入框中：
+makeExample('lifecycle-hooks/ts/app/after-view.component.ts', 'child-view', 'ChildComponent')(format=".")
:marked
The `AfterViewComponent` displays this child view *within its template*:
`AfterViewComponent`把这个子视图显示*在它的模板中*：
+makeExample('lifecycle-hooks/ts/app/after-view.component.ts', 'template', 'AfterViewComponent (template)')(format=".")
:marked
The following hooks take action based on changing values *within the child view*
which we can only reach by querying for the child view via the property decorated with
[@ViewChild](../api/core/index/ViewChild-var.html).
下列钩子基于*子视图中*的每一次数据变更采取行动，我们只能通过带[@ViewChild](../api/core/index/ViewChild-var.html)装饰器的属性来访问子视图。
+makeExample('lifecycle-hooks/ts/app/after-view.component.ts', 'hooks', 'AfterViewComponent (class excerpts)')(format=".")
.a(id="wait-a-tick")
:marked
### Abide by the unidirectional data flow rule
### 遵循单向数据流规则
The `doSomething` method updates the screen when the hero name exceeds 10 characters.
当英雄的名字超过10个字符时，`doSomething`方法就会更新屏幕。
+makeExample('lifecycle-hooks/ts/app/after-view.component.ts', 'do-something', 'AfterViewComponent (doSomething)')(format=".")
:marked
Why does the `doSomething` method wait a tick before updating `comment`?
为什么在更新`comment`属性之前，`doSomething`方法要等上一拍(tick)？
Because we must adhere to Angular's unidirectional data flow rule which says that
we may not update the view *after* it has been composed.
Both hooks fire after the component's view has been composed.
因为我们必须遵守Angular的“单向数据流”规则，这条规则是说我们不能在一个视图已经被组合好*之后*再更新视图。
而这两个钩子都是在组件的视图已经被组合好之后触发的。
Angular throws an error if we update component's data-bound `comment` property immediately (try it!).
如果我们立即更新组件中被绑定的`comment`属性，Angular就会抛出一个错误(试试!)。
block tick-methods
:marked
The `LoggerService.tick` methods, which are implemented by a call to `setTimeout`, postpone the update one turn of the of the browser's JavaScript cycle ... and that's long enough.
`LoggerService.tick`方法，是通过调用`setTimeout`的方式实现的 —— 如果想推迟到浏览器的下一轮JavaScript周期中执行，这样就够了。
:marked
Here's *AfterView* in action
这里是*AfterView*的操作演示：
figure.image-display
img(src='/resources/images/devguide/lifecycle-hooks/after-view-anim.gif' alt="AfterView")
:marked
Notice that Angular frequently calls `AfterViewChecked`, often when there are no changes of interest.
Write lean hook methods to avoid performance problems.
注意，Angular会频繁的调用`AfterViewChecked`，甚至在并没有需要关注的更改时也会触发。
所以务必把这个钩子方法写得尽可能精简，以免出现性能问题。
.l-main-section
:marked
## AfterContent
The *AfterContent* sample explores the `AfterContentInit` and `AfterContentChecked` hooks that Angular calls
*after* Angular projects external content into the component.
*AfterContent*例子展示了`AfterContentInit`和`AfterContentChecked`钩子，Angular会在外来内容被投影到组件中*之后*调用它们。
### Content projection
### 内容投影
*Content projection* is a way to import HTML content from outside the component and insert that content
into the component's template in a designated spot.
*内容投影*是从组件外部导入HTML内容，并把它插入在组件模板中指定位置上的一种途径。
.l-sub-section
:marked
Angular 1 developers know this technique as *transclusion*.
Angular 1的开发者大概知道一项叫做*transclusion*的技术，对，这就是它的马甲。
:marked
We'll illustrate with a variation on the [previous](#afterview) example
whose behavior and output is almost the same.
在[前一个](#afterview)例子中，我们解说过此功能的一个变体，它的行为和输出与这个例子完全相同。
This time, instead of including the child view within the template, we'll import it from
the `AfterContentComponent`'s parent. Here's the parent's template.
这次，我们不再通过模板来把子视图包含进来，而是改从`AfterContentComponent`的父组件中导入它。下面是父组件的模板。
+makeExample('lifecycle-hooks/ts/app/after-content.component.ts', 'parent-template', 'AfterContentParentComponent (template excerpt)')(format=".")
:marked
Notice that the `
` tag is tucked between the `` tags.
We never put content between a component's element tags *unless we intend to project that content
into the component*.
注意，``标签被包含在``标签中。
永远不要在组件标签的内部放任何内容 —— *除非我们想把这些内容投影进这个组件中*。
Now look at the component's template:
现在来看下``组件的模板：
+makeExample('lifecycle-hooks/ts/app/after-content.component.ts', 'template', 'AfterContentComponent (template)')(format=".")
:marked
The `` tag is a *placeholder* for the external content.
They tell Angular where to insert that content.
In this case, the projected content is the `` from the parent.
``标签是外来内容的*占位符*。
它告诉Angular在哪里插入这些外来内容。
在这里，被投影进去的内容就是来自父组件的``标签。
figure.image-display
img(src='/resources/images/devguide/lifecycle-hooks/projected-child-view.png' width="230" alt="Projected Content")
:marked
.l-sub-section
:marked
The tell-tale signs of *content projection* are (a) HTML between component element tags
and (b) the presence of `` tags in the component's template.
下列迹象表明存在着*内容投影*：(a) 在组件的元素标签中有HTML；(b) 组件的模板中出现了``标签。
:marked
### AfterContent hooks
### AfterContent钩子
*AfterContent* hooks are similar to the *AfterView* hooks. The key difference is the kind of child component
that we're looking for.
*AfterContent*钩子和*AfterView*相似。关键的不同点是子组件的类型不同。
* The *AfterView* hooks concern `ViewChildren`, the child components whose element tags
appear *within* the component's template.
* *AfterView*钩子所关心的是`ViewChildren`，这些子组件的元素标签会出现在该组件的模板*里面*。
* The *AfterContent* hooks concern `ContentChildren`, the child components that Angular
projected into the component.
* *AfterContent*钩子所关心的是`ContentChildren`，这些子组件被Angular投影进该组件中。
The following *AfterContent* hooks take action based on changing values in a *content child*
which we can only reach by querying for it via the property decorated with
[@ContentChild](../api/core/index/ContentChild-var.html).
下列*AfterContent*钩子基于*子级内容*中值的变化而采取相应的行动，这里我们只能通过带有[@ContentChild](../api/core/index/ContentChild-var.html)装饰器的属性来查询到“子级内容”。
+makeExample('lifecycle-hooks/ts/app/after-content.component.ts', 'hooks', 'AfterContentComponent (class excerpts)')(format=".")
:marked
### No unidirectional flow worries
### 这里不用担心单向数据流规则
This component's `doSomething` method update's the component's data-bound `comment` property immediately.
There's no [need to wait](#wait-a-tick).
该组件的`doSomething`方法立即更新了组件被绑定的`comment`属性。
它[不用等](#wait-a-tick)下一拍。
Recall that Angular calls both *AfterContent* hooks before calling either of the *AfterView* hooks.
Angular completes composition of the projected content *before* finishing the composition of this component's view.
We still have a window of opportunity to modify that view.
回忆一下，Angular在每次调用*AfterView*钩子之前也会同时调用*AfterContent*。
Angular在完成当前组件的视图合成之前，就已经完成了被投影内容的合成。
所以我们仍然有机会去修改那个视图。