Angular 17+ 高级教程 – Component 组件 の Dependency Injection & NodeInjector

回到 getNodeInjectable 函数

继续

factory.factory 长啥样？

回顾 class NodeInjectorFactory 

回顾 configureViewWithDirective 函数

小总结一下，

到这里，已经 set 了全局变量 inject implementation 函数，这样组件内就可以使用 inject 函数了。

另外 NodeInjector.factory() 便是 AppComponent.ɵfac()，其内部便是 new AppComponent()

好，inject 函数我们下一个 part 在单独讲解，因为查找 Provider 的过程还会涉及到 Bloom Filter，异常的复杂，我们先把这个环节的大流程走完。

回到 createRootComponent 函数

回到 ComponentFactory.create 函数

App 组件实例化后，下一个阶段就是渲染它的 Template。

renderView 的源码我就不展开了，因为它和这篇的主题 DI 没有那么深的关系了，我大概讲一些就好。

renderView 函数内部会执行 App template 方法 by create mode。

template 方法里有 ɵɵelementStart，ɵɵText，这些就会去创建 DOM nodes。

如果有子组件，那它也会经历一遍类似（注：过程不完全一样，但这里我们不需要在意）创建 App 组件那样的过程，

比如：创建 TVIew，LView > 把 providers 资料放入 parent LView > 实例化子组件 > 然后又继续下一个 renderView 函数。整个渲染过程会一直渲染到所有后裔组件。

好，到目前为止所有的组件都被实例化了，LView Tree 也成型了。

但是渲染还没有完成，因为现在只是做了 create 的部分，Angular 渲染分 2 个部分，一个 create 一个 update，这个在之前的 Change Detection 文章中 有提到过。

我们继续看完它。

回到 ApplicationRef.bootstrap 函数

_loadComponent 方法

上面我们有提到，到目前为止，我们只完成了 create 部分的渲染，还有 update 没有完成。

这个 _loadComponent 就是执行 update 渲染过程的，在 Change Detection 文章中，我们学过 tick 就是从 Root LView 开始往下遍历后裔 LView 并且 refreshView。

这样所有 binding data 就会渲染进最终的 DOM 了。.

至此 Angular bootstrapApplication 结束，整个过程：

1. 创建 Platform Injector
2. 创建 Root Injector
3. 创建 Root View Injector (ChainedInjector)
4. 创建 Host RNode <app-root>
5. 创建 Root TView
6. 创建 Root LView
7. 创建 App TNode
8. 创建 App TView
9. 创建 App LView
10. 创建 App Injector 资料, 写进 Root T/LView
11. 弄 App.providers 资料写进 App Injector 资料
12. 弄 class App as Provider 资料写进 App Injector 资料
13. 通过 injection 手法实例化 App 组件
14. 渲染 App 模板 (create mode) 以及模板里的后裔组件。
15. 添加 App hostView 到 ApplicationRef
16. ApplicationRef.tick 渲染模板 (update mode)

至关重要的点

我觉得有几个点是蛮重要的，理解了这些就不会再有困惑。

1. 不要把 NodeInjector 比作 R3Injector。

   R3Injector 对象是整个 DI 的核心。它保存 providers 也保存 parent injector 资料。

   而 NodeInjector 只是一个不起眼的小对象，它没有任何 providers 的资料，也没有 parent injector 的资料，正真存放 provider 和 parent injector 资料的地方是在 TView 和 LView 里。

   所以在组件内 NodeInjector 也好，inject 函数也好都只是一个代理，它们是去 TView 和 LView 里面找资料而已。

2. 每个组件都有一份 NodeInjector 资料，不是 NodeInjector 对象哦，是资料。这些资料被存放在这个组件的 parent TView 和 LView 里。

题外话，关于 componentRef.hostView

虽然这个知识跟 DI 没有关系，但上面既然已经提到了，我们就顺便说一说把，也好为下一篇 Dynamic Component 做准备。

App 组件的 hostView 里面装着 Root LView。目前我们有三个词有点傻傻分不清楚。

1. hostView
2. Root LView
3. Parent LView

我们来理清楚一下。

首先要知道，创建组件有 2 种方式。

第一种是 componentFactory.create，这也是创建 App 组件的方式。它被称为动态创建组件 dynamic create component。

第二种是在渲染模板的时候（上面提到的 renderView 函数）遇到子组件时创建它。这两种创建组件的过程几乎是一样的，只有一个地方不同。

那就是第一种方式，在创建组件的时候，它会生成 2 个 LView，而第二种方式只会生成一个 LView（也就是组件本身的 LView）。

那为什么会这样呢？

首先，每个组件是一定要有一个 Parent LView 的，因为组件 providers 不是记入在组件本身的 LView，而是记入在它的 Parent LView。

而第二种方式是发生在渲染模板阶段，这也意味着此时肯定已经有一个 LView 存在，不然怎么渲染模板，那这个已存在的 LView 自然可以成为组件的 Parent LView。

但第一种方式却不同，它发生的时候是完全没有 LView 存在的，于是一定要先创建一个 LView，然后把这个 LView 作为组件的 Parent LView。

好，那我们来整理一下。

componentFactory.create 用于动态创建组件，它会返回一个 ComponentRef (Ref 是 reference 的意思，简单说就是一个对象里面包裹了组件信息)，

ComponentRef 里有一个 hostVIew，hostView 的类型是 ViewRef (又一个 Ref，顾名思义就是个对象，里面包裹了 View 信息)

hostView._lView 便是在创建过程中生成的两个 LView 中的第一个，我们可以称它为 Host LView，它也就是这个组件的 Parent LView。所以 hostView 包裹了 Host LView 而 Host LView === Parent LView。

如果说这个组件是 App 组件，那这个 Host LView 同时也是整个 LView Tree 的 Root LView。

所以在 App 组件的视角下 Host LView === Parent LView === Root LView。

如果不是 App 组件，那就不一定是 Root LView，如果不是动态组件就没有 Host LView。

总之，记住两点：

1. 只有动态创建的组件才有 hostView 的概念。template 方法过程中创建的组件没有这个概念。

2. 动态创建组件会同时生成 2 个 LView。一个是组件 LView，一个是组件 Host / Parent LView。

Bloom Filter 详解

上面我们逛源码时，我刻意跳过了 Bloom Filter 算法和 inject 函数，这里补上 Bloom Filter。

Bloom Filter 是什么？

推荐看这篇解答：被删 – Angular冷知识--布隆过滤器

我用视频中的例子稍微解释一下

假设有个弱密码的数据库表，当用户要设置密码时，程序会先查看这个表，如果用户设置的是弱密码，那就不允许。

程序通过网路链接服务器查找数据库，这个过程有两个点值得注意

1. 需要通过网路，用户会感觉慢

2. 会增加服务器的负担

这时就可以利用 Bloom Filter 做优化。它的原理是这样的。

假设我们的弱密码有这些 ['a', 'b', 'c', 'd', 'e']

首先拿 'a' 进行 bloom 算法得出一个编号（比如：0 0 0 0 0 0 0 1，这个编号的长度（有多少个 0）depend on bloom 算法的设置，通常总数据量越长它就越长，但也不会有多长啦，有点像 sha256 的概念）

再拿第二个值 'b' 进行 bloom 算法得出另一个编号。

接着把这 2 个编号累加在一起。依此类推直到全部弱密码都处理完，得到一个总编号。

bloom 算法 + 累加最神奇的地方是它的总编号不会越来越长，不管数据有多少，长度始终控制在一个非常小的范围，就像 sha256 那样。

当想要查找的时候，首先把要查找的值进行 bloom 算法得出一个编号，然后拿这个编号去匹配总编号。

这个匹配会得出 2 种结论。

1. 这个值，绝对没有在集合中

2. 这个值，有可能在集合中

绝对没有就表示用户输入的不是弱密码，可以通过。

有可能在集合中，那程序就需要再去服务器查找，做最后的确认。

为什么一个是绝对，一个只是有可能呢？

因为算法为了维持大小，牺牲掉了准确性。所以总编号才能一直保存很小的 length。

总结

Bloom Filter 是个优化方案，它可以把一个大集合压缩成一个小编号，通过比对小编号，我们可以快速的知道一个值是否绝对没有在集合中。

但如果它有可能在集合中，那我们依然需要去查询集合做确认。

所以这个优化方案并不是那种绝对的优化，它只是在部分情况下可以得到优化。

Angular 跟 Bloom Filter 的关系

参考：Angular 作者 MIŠKO HEVERY – Bloom Filters Can Speed Up Your Code

在上面逛源码时，我们看到 Angular 在处理 NodeInjector 资料时，会搞一个 bloom 算法得出一个编号，初始值是 8 个零。

它的目的就是要搞 Bloom Filter 做性能优化。想象一下，所有的组件 providers 就是那个大集合，每一个都会被 bloom 算法累加到一个总编号。

当我们想 inject(Provider) 时，Angular 会先去总编号比对一下，如果绝对不在集合里，那 Angular 会跳过所有组件的 providers，直接去 Root LView Injector (ChainedInjector) 里找。

虽然我觉得这个性能优化有点小题大做，但这确实是 Angular 团队或者说 MIŠKO HEVERY 的一贯风格啦。

Angular Bloom 算法

在上面源码中，有一个 bloomAdd 函数，它就是负责 Angular Bloom 算法的。我们看看它具体干了什么。

第一点，每一个组件的 providers，不管是 class 还是 InjectionToken 都会被设置一个静态属性 "__NG_ELEMENT_ID__"。它是一个累加的 ID，从 0 开始一直往上加。

第二点，每一个 NodeInjector 都有一个编号，默认值是 8 个零。

假设，我们的 App 组件有 3 个 Service。

包括 App 组件本身，一共有 4 个 Provider。它们的 ID 分别是 0、1、2、3。

在算法还没有跑之前，App NodeInjector 的编号 是 8 个零。0 0 0 0 0 0 0 0。

下面这个就是它的 Bloom 算法

// 1. 假设 App 组件有 4 个 Provider（AppComponent、ServiceA、ServiceB、ServiceC）
//    id 从 0 开始累加
const ids = [0, 1, 2, 3];
// 2. App NodeInjector 的 Bloom 编号，初始值是 8 个零
const nodeInjectorBloomCode = [0, 0, 0, 0, 0, 0, 0, 0];

// 3. 把每一个 id 经过 bloom 算法，然后累加进 NodeInjector Bloom 编号
for (let id of ids)
{
  // 4. Bloom 的配置，这个是 Angular 自己定的
  const BLOOM_SIZE = 256;
  const BLOOM_MASK = BLOOM_SIZE - 1;
  const BLOOM_BUCKET_BITS = 5;

  // 5. 算法开始
  const bloomHash = id & BLOOM_MASK;
  const mask = 1 << bloomHash;
  // 6. 插入第几个位置
  const slot = bloomHash >> BLOOM_BUCKET_BITS;
  // 7. 插入 & 累加
  nodeInjectorBloomCode[slot] |= mask;
}

// 8. 最终 App NodeInjector 的编号
console.log('injector', nodeInjectorBloomCode); // [15, 0, 0, 0, 0, 0, 0, 0]

为了方便看，我把源码抽出来做了一些整理。

如果你想搞明白每一个细节，可以把 ids 设置成 0...256，然后把每一次 nodeInjectorBloomCode 打印出来看它的变化。

里头的二进制操作符，不熟悉的朋友也可以看这篇 C# and TypeScript – Enum Flags。

好，我们来验证看最终结果是不是这样。

进入 Root TView.data[26-33] 就可以看到 App NodeInjector Bloom 编号了。

我们再来看一个带有 parent NodeInjector 的例子。

组件结构是这样，App 组件 > Parent 组件 > Child 组件。

Provider 的 ids

它们各个的 NodeInjectorBloomCode

这些是 TView.data 的记入，我们再看看 LView 的记入。LView 记入的是累加的 Parent Injector 的资料。

Parent 的 15 来自 App TView.data 的 15

Child 的 63 来自 App + Parent TView.data，也就是 15 | 48 = 63。

inject 函数查找过程

inject 的查找过程有点复杂，有点绕，我们先不看源码，看例子比较容易理解。

有 4 个不同的例子

例子一：Child 组件注入 Child Provider

第 1 步 

第 2 步 

拿 id 跑 Bloom 算法。得出编号 128 0 0 0 0 0 0 0。

第 3 步

有了 Provider 编号，接下来要找出 Child NodeInjector 的编号。

拿 current TNode（也就是 Child 组件的 TNode）。

TNode 属性 injectorIndex 表示 Child NodeInjector 在 Parent TView 的 index。(再次提醒，Child NodeInjector 资料是记入在 Parent TView 和 LView 里，而不是 Child 本身的 TVIew 和 LView)

第 4 步

有了 injector index 就去拿 injector 编号。

Child NodeInjector 的编号是 192。(注：因为这些例子 Provider 数量都很少，用不到后面的 7 个位，所以我省略掉了后面的 7 个零)

第 5 步

对比 Service5 id 的编号和 Child NodeInjector 的编号

const childNodeInjector = 192;
const service5 = 128;
const matched = (childNodeInjector & service5) > 0; // true

matched 表示 Provider 有可能在这个 NodeInjector 内。

第 6 步

找出 Provider index。

NodeInjector 有 8 个位置，紧跟着的便是这个 NodeInjector 的 providers。

从 36 开始一个一个找。

36 是 Child TNode，37 是 class Service5。index 37 就是我们要的。

第 7 步

到 Parent LView[37] 获取 NodeInjectorFactory

调用这个 factory 就可以获得 Service5 实例了。至此 inject 查找和实例化就完成了。

例子二：Child 组件注入 App 组件。

第 1 步

拿出 App 的 id（AppComponent['__NG_ELEMENT_ID__']）。id 是 0。

第 2 步

拿 id 跑 Bloom 算法。编号是 1 0 0 0 0 0 0 0。

第 3 步

和例子 1 一样，Child NodeInjector index = 28。

第 4 步

和例子 1 一样，Child NodeInjector 的编号是 192。

第 5 步

对比 App id 的编号和 Child NodeInjector 的编号

const childNodeInjector = 192;
const app = 1;
const matched = (childNodeInjector & app) > 0; // false

unmatched 表示 Provider 不在这个 NodeInjector 内。我们需要往 Parent NodeInjector 找。

第 6 步

用 Child NodeInjector index 到 LView[28] 拿 Injector 资料

第 28 位的 63 是 Parent NodeInjector 的累加编号。我们一样拿它来比对。

const parentAccumulateNodeInjector = 63;
const app = 1;
const matched = (parentAccumulateNodeInjector & app) > 0; // true

matched 表示 Provider 有可能在 Parent NodeInjector 里。

第 7 步

我们要找出 Parent NodeInjector 的 Index。上面那一张图是 Parent LView 中 Child NodeInjector 位置

第 36 位的 65564 是 Parent NodeInjector 的坐标。

const INJECTOR_INDEX_MASK = 0b111111111111111; // 相等于十进制 32767
const parentNodeInjectorIndex = 65564 & INJECTOR_INDEX_MASK; // 28

把坐标换算成 index。Parent NodeInjector Index = 28。

第 8 步

找 Parent NodeInjector。

当前 LView 的 28 位是 Child NodeInjector，这也就意味着 Parent NodeInjector 不可能在这个 LView 里，因为 28 位已经是 Child NodeInjector 了。那 Parent NodeInjector 肯定是在上一层的 LView（也就是 App LView）。

注意：一个 LView 里面是有可能出现超过 1 个 NodeInjector 的。Parent NodeInjector 也有可能和 Child NodeInjector 在同一个 LView 里。这个场景我下面会特别讲解。现阶段我们没有这个场景，暂时不需要太在意。

现在去上一层 LView，也就是 App LView。

然后去 App TView[28] 获取 Parent NodeInjector 编号

第 9 步

这边就一直重复第 5 到第 7 步，一直到 match 到为止。

拿 Parent NodeInjector 编号和 Provider 编号比对

const parentNodeInjector = 48;
const app = 1;
const matched = (parentNodeInjector & app) > 0; // false

一样是 unmatched。继续往上找

这个是 App LView 

const appAccumulateNodeInjector = 15;
const app = 1;
const matched = (appAccumulateNodeInjector & app) > 0; // true

matched 表示 Provider 可能在 App NodeInjector 里。

const INJECTOR_INDEX_MASK = 0b111111111111111; // 相等于十进制 32767
const appNodeInjectorIndex = 65562 & INJECTOR_INDEX_MASK; // 26

到 Root TView.data[26] 

const appNodeInjector = 15;
const app = 1;
const matched = (parentNodeInjector & app) > 0; // true

总算是 match 到了。所以 AppCompoent Provider 有可能在 App NodeInjector 里。

第 9 步

和例子 1 的第 6，第 7 步一样。

例子三：Child 组件注入 Root Injector Provider

我们把 Service5 换成 provide 给 Root Injector。

第 1 步

拿出 Service5 的 id（Service5['__NG_ELEMENT_ID__']）。id 是 undefined。

因为 Service5 不是组件的 providers，所以它自然就没有 __NG_ELEMENT_ID__。

第 2 步

直接通过 LView[9] 获取 Root LView Injector (ChainedInjector) 做查找，它会一路找到 Root > Platform > NullInjector。

例子四：Not in Ancestor NodeInjector

这个例子的组件结构和前几个例子不同。它有两条分支。

Parent1 有 providers: [Service1]，Child2 尝试 inject(Service1)。

通过前面几个例子，相信大家对流程都蛮熟悉了，我这里划重点就好。

第 1 步

Service1 是 Parent1 组件的 Provider，所以 Service1 会有 id。

第 2 步

拿 Service1 id 比对 Child2 NodeInjector 结果是 unmatched。这表示 Service1 不在 Child2 NodeInjector 的 Provider 里。

第 3 步

拿 Service1 id 比对 Parent2 Accumulate NodeInjector 结果也是 unmatched。这表示 Service1 不在任何祖先 NodeInjector 的 Provider 里。

第 4 步

直接通过 LView[9] 获取 Root LView Injector (ChainedInjector) 做查找，它会一路找到 Root > Platform > NullInjector。

inject 函数源码逛一逛

查找流程已经讲的那么清楚了，其实没有必要再逛源码了，不过有始有终呗，我们就稍微逛一下就好。

组件内会调用 inject 函数

inject 函数源码在 injector_compatibility.ts

ɵɵinject 函数

getInjectImplementation 函数的源码在 inject_switch.ts

回到 ɵɵinject 函数，进入 injectInjectorOnly 函数的源码在 injector_compatibility.ts

回到 ɵɵinject 函数

我们之前就讲过很多次了，inject 函数只可以在 injection context 内被执行。

那怎样才算是在 injection context 呢？就是 inject 执行前，已经 set 好一个全局 Injector 或者 inject implementation 函数。

下面是一个 runInInjectionContext 例子

class ServiceA {}
const injector = Injector.create({
  providers: [ServiceA],
});
runInInjectionContext(injector, () => {
  const serviceA = inject(ServiceA);
});

runInInjectionContext 函数会先把参数 1 injector set 去全局 injector，然后才调用参数 2 的函数。所以参数 2 内就可以使用 inject 函数。

在 Angular bootstrapApplication 过程中有一个阶段是 getNodeInjectable 函数

它是在实例化 App 组件之前发生的，它把 全局的 inject implementation 函数 set 成了 ɵɵdirectiveInject 函数。

所以在 App 组件 constructor 里面，调用 inject 函数等同于调用了 ɵɵdirectiveInject 函数。

ɵɵdirectiveInject 函数源码在 di.ts

getOrCreateInjectable 函数源码在 di.ts

lookupTokenUsingNodeInjector 函数

export class AppComponent {
  constructor() {
    inject(ChangeDetectorRef);
    inject(ElementRef);
    inject(TemplateRef);
    inject(ViewContainerRef);
    inject(Renderer2);
    inject(Injector);
  }
}

let hostTElementNode: TNode|null =
    flags & InjectFlags.Host ? lView[DECLARATION_COMPONENT_VIEW][T_HOST] : null;

<app-item name="iPhone 14" />

export class ItemComponent {
  constructor(
    // 1. 在 constructor 使用 @Attribute decorator 获取 name attribute
    @Attribute('name') name: string,
  ) {
    console.log(name); // 'iPhone 14'
  }
}

yarn run ngc -p tsconfig.json