深入浅出解析阿里成熟的微前端框架 qiankun 源码【图文并茂】

傷城~ 2022-09-16 00:22 395阅读 0赞

![a8bf776b260e9b47e8943bc65db1dbc5.png][]

来源：leaf（a1029563229 ）

https://github.com/a1029563229/blogs/blob/master/Source-Code/qiankun/1.md

本文将针对微前端框架 `qiankun` 的源码进行深入解析，在源码讲解之前，我们先来了解一下什么是 `微前端`。

`微前端` 是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。同时，它们也可以在共享组件的同时进行并行开发——这些组件可以通过 `NPM` 或者 `Git Tag、Git Submodule` 来管理。

`qiankun（乾坤）` 就是一款由蚂蚁金服推出的比较成熟的微前端框架，基于 `single-spa` 进行二次开发，用于将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。（见下图）

![07efd1602415936f0608e6f3a7da7d2f.png][] qiankun

那么，话不多说，我们的源码解析正式开始。

## 初始化全局配置 - `start(opts)` ##

我们从两个基础 API - `registerMicroApps(apps, lifeCycles?) - 注册子应用` 和 `start(opts?) - 启动主应用` 开始，由于 `registerMicroApps` 函数中设置的回调函数较多，并且读取了 `start` 函数中设置的初始配置项，所以我们从 `start` 函数开始解析。

我们从 `start` 函数开始解析（见下图）：

![55b17466087f837448e45806640e8b8a.png][] qiankun

我们对 `start` 函数进行逐行解析：

*  `第 196 行`：设置 `window` 的 `__POWERED_BY_QIANKUN__` 属性为 `true`，在子应用中使用 `window.__POWERED_BY_QIANKUN__` 值判断是否运行在主应用容器中。
 *  `第 198~199 行`：设置配置参数（有默认值），将配置参数存储在 `importLoaderConfiguration` 对象中；
 *  `第 201~203 行`：检查 `prefetch` 属性，如果需要预加载，则添加全局事件 `single-spa:first-mount` 监听，在第一个子应用挂载后预加载其他子应用资源，优化后续其他子应用的加载速度。
 *  `第 205 行`：根据 `singularMode` 参数设置是否为单实例模式。
 *  `第 209~217 行`：根据 `jsSandbox` 参数设置是否启用沙箱运行环境，旧版本需要关闭该选项以兼容 IE。（新版本在单实例模式下默认支持 IE，多实例模式依然不支持 IE）。
 *  `第 222 行`：调用了 `single-spa` 的 `startSingleSpa` 方法启动应用，这个在 `single-spa` 篇我们会单独剖析，这里可以简单理解为启动主应用。

从上面可以看出，`start` 函数负责初始化一些全局设置，然后启动应用。这些初始化的配置参数有一部分将在 `registerMicroApps` 注册子应用的回调函数中使用，我们继续往下看。

## 注册子应用 - `registerMicroApps(apps, lifeCycles?)` ##

`registerMicroApps` 函数的作用是注册子应用，并且在子应用激活时，创建运行沙箱，在不同阶段调用不同的生命周期钩子函数。（见下图）

![84bd3facd32c674083572b650e32aec1.png][] qiankun

从上面可以看出，在 `第 70~71 行` 处 `registerMicroApps` 函数做了个处理，防止重复注册相同的子应用。

在 `第 74 行` 调用了 `single-spa` 的 `registerApplication` 方法注册了子应用。

我们直接来看 `registerApplication` 方法，`registerApplication` 方法是 `single-spa` 中注册子应用的核心函数。该函数有四个参数，分别是

*  `name（子应用的名称）`
 *  `回调函数（activeRule 激活时调用）`
 *  `activeRule（子应用的激活规则）`
 *  `props（主应用需要传递给子应用的数据）`

这些参数都是由 `single-spa` 直接实现，这里可以先简单理解为注册子应用（这个我们会在 `single-spa` 篇展开说）。在符合 `activeRule` 激活规则时将会激活子应用，执行回调函数，返回一些生命周期钩子函数（见下图）。

> 注意，这些生命周期钩子函数属于 `single-spa`，由 `single-spa` 决定在何时调用，这里我们从函数名来简单理解。（`bootstrap` - 初始化子应用，`mount` - 挂载子应用，`unmount` - 卸载子应用）

![1656378ec342853fcecfc8bd5dcfa531.png][] qiankun

如果你还是觉得有点懵，没关系，我们通过一张图来帮助理解。（见下图）

![b64198bda750b452d1196b082b7a9abf.png][] qiankun

### 获取子应用资源 - import-html-entry ###

我们从上面分析可以看出，`qiankun` 的 `registerMicroApps` 方法中第一个入参 `apps - Array<RegistrableApp<T>>` 有三个参数 `name、activeRule、props` 都是交给 `single-spa` 使用，还有 `entry` 和 `render` 参数还没有用到。

我们这里需要关注 `entry（子应用的 entry 地址）` 和 `render（子应用被激活时触发的渲染规则）` 这两个还没有用到的参数，这两个参数延迟到 `single-spa` 子应用激活后的回调函数中执行。

那我们假设此时我们的子应用已激活，我们来看看这里做了什么。（见下图）

![d598057c39dbce71fcff22607350b489.png][] qiankun

从上图可以看出，在子应用激活后，首先在 `第 81~84 行` 处使用了 `import-html-entry` 库从 `entry` 进入加载子应用，加载完成后将返回一个对象（见下图）

![98ab1e8242001d1116d1e13fde8443a1.png][] qiankun

我们来解释一下这几个字段

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>template</code></td> 
   <td>将脚本文件内容注释后的&nbsp;<code>html</code>&nbsp;模板文件</td> 
  </tr> 
  <tr> 
   <td><code>assetPublicPath</code></td> 
   <td>资源地址根路径，可用于加载子应用资源</td> 
  </tr> 
  <tr> 
   <td><code>getExternalScripts</code></td> 
   <td>方法：获取外部引入的脚本文件</td> 
  </tr> 
  <tr> 
   <td><code>getExternalStyleSheets</code></td> 
   <td>方法：获取外部引入的样式表文件</td> 
  </tr> 
  <tr> 
   <td><code>execScripts</code></td> 
   <td>方法：执行该模板文件中所有的&nbsp;<code>JS</code>&nbsp;脚本文件，并且可以指定脚本的作用域 -&nbsp;<code>proxy</code>&nbsp;对象</td> 
  </tr> 
 </tbody> 
</table>

我们先将 `template 模板`、`getExternalScripts` 和 `getExternalStyleSheets` 函数的执行结果打印出来，效果如下（见下图）：

![6cd4636a5e4cf9f9ce37090a48a825ac.png][] qiankun

从上图我们可以看到我们外部引入的三个 `js` 脚本文件，这个模板文件没有外部 `css` 样式表，对应的样式表数组也为空。

然后我们再来分析 `execScripts` 方法，该方法的作用就是指定一个 `proxy`（默认是 `window`）对象，然后执行该模板文件中所有的 `JS`，并返回 `JS` 执行后 `proxy` 对象的最后一个属性（见下图 1）。在微前端架构中，这个对象一般会包含一些子应用的生命周期钩子函数（见下图 2），主应用可以通过在特定阶段调用这些生命周期钩子函数，进行挂载和销毁子应用的操作。

![0032001eedd3667791aa3e704f87819d.png][] qiankun ![98e2d3f9cdfb2b6b0b28ace94fdd08c5.png][] qiankun

在 `qiankun` 的 `importEntry` 函数中还传入了配置项 `getTemplate`，这个其实是对 `html` 目标文件的二次处理，这里就不作展开了，有兴趣的可以自行去了解一下。

### 主应用挂载子应用 HTML 模板 ###

我们回到 `qiankun` 源码部分继续看（见下图）

![a66ca5df2d14dfc22c8e058417e42c20.png][] qiankun

从上图看出，在 `第 85~87 行` 处，先对单实例进行检测。在单实例模式下，新的子应用挂载行为会在旧的子应用卸载之后才开始。

在 `第 88 行` 中，执行注册子应用时传入的 `render` 函数，将 `HTML Template` 和 `loading` 作为入参，`render` 函数的内容一般是将 `HTML` 挂载在指定容器中（见下图）。

![13f3b73b02413f1510ed0d07be5f4fbe.png][] qiankun

在这个阶段，主应用已经将子应用基础的 `HTML` 结构挂载在了主应用的某个容器内，接下来还需要执行子应用对应的 `mount` 方法（如 `Vue.$mount`）对子应用状态进行挂载。

此时页面还可以根据 `loading` 参数开启一个类似加载的效果，直至子应用全部内容加载完成。

### 沙箱运行环境 - genSandbox ###

我们回到 `qiankun` 源码部分继续看，此时还是子应用激活时的回调函数部分（见下图）

![04ca62c03a7c3c358fa21c72848b2ace.png][] qiankun

在 `第 90~98 行` 是 `qiankun` 比较核心的部分，也是几个子应用之间状态独立的关键，那就是 `js` 的沙箱运行环境。如果关闭了 `useJsSandbox` 选项，那么所有子应用的沙箱环境都是 `window`，就很容易对全局状态产生污染。

我们进入到 `genSandbox` 内部，看看 `qiankun` 是如何创建的 `（JS）沙箱运行环境`。（见下图）

![c413950c2dea3bc1fd3a4b9bbdbfedbc.png][] qiankun

从上图可以看出 `genSandbox` 内部的沙箱主要是通过是否支持 `window.Proxy` 分为 `LegacySandbox` 和 `SnapshotSandbox` 两种。

> 扩展阅读：多实例还有一种 `ProxySandbox` 沙箱，这种沙箱模式目前看来是最优方案。由于其表现与旧版本略有不同，所以暂时只用于多实例模式。
> 
> `ProxySandbox` 沙箱稳定之后可能会作为单实例沙箱使用。

#### LegacySandbox ####

我们先来看看 `LegacySandbox` 沙箱是怎么进行状态隔离的（见下图）

![5d7fee9a6d7583162775f977ad20e750.png][] qiankun

我们来分析一下 `LegacySandbox` 类的几个属性：

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>addedPropsMapInSandbox</code></td> 
   <td>记录沙箱运行期间新增的全局变量</td> 
  </tr> 
  <tr> 
   <td><code>modifiedPropsOriginalValueMapInSandbox</code></td> 
   <td>记录沙箱运行期间更新的全局变量</td> 
  </tr> 
  <tr> 
   <td><code>currentUpdatedPropsValueMap</code></td> 
   <td>记录沙箱运行期间操作过的全局变量。上面两个&nbsp;<code>Map</code>&nbsp;用于&nbsp;<code>关闭沙箱</code>&nbsp;时还原全局状态，而&nbsp;<code>currentUpdatedPropsValueMap</code>&nbsp;是在&nbsp;<code>激活沙箱</code>&nbsp;时还原沙箱的独立状态</td> 
  </tr> 
  <tr> 
   <td><code>name</code></td> 
   <td>沙箱名称</td> 
  </tr> 
  <tr> 
   <td><code>proxy</code></td> 
   <td>代理对象，可以理解为子应用的&nbsp;<code>global/window</code>&nbsp;对象</td> 
  </tr> 
  <tr> 
   <td><code>sandboxRunning</code></td> 
   <td>当前沙箱是否在运行中</td> 
  </tr> 
  <tr> 
   <td><code>active</code></td> 
   <td>激活沙箱，在子应用挂载时启动</td> 
  </tr> 
  <tr> 
   <td><code>inactive</code></td> 
   <td>关闭沙箱，在子应用卸载时启动</td> 
  </tr> 
  <tr> 
   <td><code>constructor</code></td> 
   <td>构造函数，创建沙箱环境</td> 
  </tr> 
 </tbody> 
</table>

我们现在从 `window.Proxy` 的 `set` 和 `get` 属性来详细讲解 `LegacySandbox` 是如何实现沙箱运行环境的。（见下图）

![daf9cb5935792c1ccc40d3ab15ff4542.png][] qiankun

> 注意：子应用沙箱中的 `proxy` 对象（`第 62 行`）可以简单理解为子应用的 `window` 全局对象（代码如下），子应用对全局属性的操作就是对该 `proxy` 对象属性的操作，带着这份理解继续往下看吧。

// 子应用脚本文件的执行过程：
    eval(
      // 这里将 proxy 作为 window 参数传入
      // 子应用的全局对象就是该子应用沙箱的 proxy 对象
      (function(window) {
        /* 子应用脚本文件内容 */
      })(proxy)
    );

在 `第 65~72 行中`，当调用 `set` 向子应用 `proxy/window` 对象设置属性时，所有的属性设置和更新都会先记录在 `addedPropsMapInSandbox` 或 `modifiedPropsOriginalValueMapInSandbox` 中，然后统一记录到`currentUpdatedPropsValueMap` 中。

在 `第 73 行` 中修改全局 `window` 的属性，完成值的设置。

当调用 `get` 从子应用 `proxy/window` 对象取值时，会直接从 `window` 对象中取值。对于非构造函数的取值将会对 `this` 指针绑定到 `window` 对象后，再返回函数。

`LegacySandbox` 的沙箱隔离是通过激活沙箱时还原子应用状态，卸载时还原主应用状态（子应用挂载前的全局状态）实现的，具体实现如下（见下图）。

![8bccaea65f26db4a7167e8bacecca5cb.png][] qiankun

从上图可以看出：

*  `第 37 行`：在激活沙箱时，沙箱会通过 `currentUpdatedPropsValueMap` 查询到子应用的独立状态池（沙箱可能会激活多次，这里是沙箱曾经激活期间被修改的全局变量），然后还原子应用状态。
 *  `第 44~45 行`：在关闭沙箱时，通过 `addedPropsMapInSandbox` 删除在沙箱运行期间新增的全局变量，通过 `modifiedPropsOriginalValueMapInSandbox` 还原沙箱运行期间被修改的全局变量，从而还原到子应用挂载前的状态。

从上面的分析可以得知，`LegacySandbox` 的沙箱隔离机制利用快照模式实现，我们画一张图来帮助理解（见下图）

![b64be4476b8449a1aeb11b35d920500b.png][] qiankun

#### 多实例沙箱 - ProxySandbox ####

`ProxySandbox` 是一种新的沙箱模式，目前用于多实例模式的状态隔离。在稳定后以后可能会成为 `单实例沙箱`，我们来看看 `ProxySandbox` 沙箱是怎么进行状态隔离的（见下图）

![ebae9c29053e6f3ac525caf4848ebe0f.png][] qiankun

我们来分析一下 `ProxySandbox` 类的几个属性：

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>updateValueMap</code></td> 
   <td>记录沙箱中更新的值，也就是每个子应用中独立的状态池</td> 
  </tr> 
  <tr> 
   <td><code>name</code></td> 
   <td>沙箱名称</td> 
  </tr> 
  <tr> 
   <td><code>proxy</code></td> 
   <td>代理对象，可以理解为子应用的&nbsp;<code>global/window</code>&nbsp;对象</td> 
  </tr> 
  <tr> 
   <td><code>sandboxRunning</code></td> 
   <td>当前沙箱是否在运行中</td> 
  </tr> 
  <tr> 
   <td><code>active</code></td> 
   <td>激活沙箱，在子应用挂载时启动</td> 
  </tr> 
  <tr> 
   <td><code>inactive</code></td> 
   <td>关闭沙箱，在子应用卸载时启动</td> 
  </tr> 
  <tr> 
   <td><code>constructor</code></td> 
   <td>构造函数，创建沙箱环境</td> 
  </tr> 
 </tbody> 
</table>

我们现在从 `window.Proxy` 的 `set` 和 `get` 属性来详细讲解 `ProxySandbox` 是如何实现沙箱运行环境的。（见下图）

![d3a460caf62e5a4dc619a91b78035737.png][] qiankun

> 注意：子应用沙箱中的 `proxy` 对象可以简单理解为子应用的 `window` 全局对象（代码如下），子应用对全局属性的操作就是对该 `proxy` 对象属性的操作，带着这份理解继续往下看吧。

当调用 `set` 向子应用 `proxy/window` 对象设置属性时，所有的属性设置和更新都会命中 `updateValueMap`，存储在 `updateValueMap` 集合中（`第 38 行`），从而避免对 `window` 对象产生影响（旧版本则是通过 `diff` 算法还原 `window` 对象状态快照，子应用之间的状态是隔离的，而父子应用之间 `window` 对象会有污染）。

当调用 `get` 从子应用 `proxy/window` 对象取值时，会优先从子应用的沙箱状态池 `updateValueMap` 中取值，如果没有命中才从主应用的 `window` 对象中取值（`第 49 行`）。对于非构造函数的取值将会对 `this` 指针绑定到 `window` 对象后，再返回函数。

如此一来，`ProxySandbox` 沙箱应用之间的隔离就完成了，所有子应用对 `proxy/window` 对象值的存取都受到了控制。设置值只会作用在沙箱内部的 `updateValueMap` 集合上，取值也是优先取子应用独立状态池（`updateValueMap`）中的值，没有找到的话，再从 `proxy/window` 对象中取值。

相比较而言，`ProxySandbox` 是最完备的沙箱模式，完全隔离了对 `window` 对象的操作，也解决了快照模式中子应用运行期间仍然会对 `window` 造成污染的问题。

我们对 `ProxySandbox` 沙箱画一张图来加深理解（见下图）

![2d50124c3c4105d987732ef35cef8d20.png][] qiankun

#### SnapshotSandbox ####

在不支持 `window.Proxy` 属性时，将会使用 `SnapshotSandbox` 沙箱，我们来看看其内部实现（见下图）

![31dc9bf9c9a4f069bb8d3a616f692280.png][] qiankun

我们来分析一下 `SnapshotSandbox` 类的几个属性：

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>name</code></td> 
   <td>沙箱名称</td> 
  </tr> 
  <tr> 
   <td><code>proxy</code></td> 
   <td>代理对象，此处为&nbsp;<code>window</code>&nbsp;对象</td> 
  </tr> 
  <tr> 
   <td><code>sandboxRunning</code></td> 
   <td>当前沙箱是否激活</td> 
  </tr> 
  <tr> 
   <td><code>windowSnapshot</code></td> 
   <td><code>window</code>&nbsp;状态快照</td> 
  </tr> 
  <tr> 
   <td><code>modifyPropsMap</code></td> 
   <td>沙箱运行期间被修改过的&nbsp;<code>window</code>&nbsp;属性</td> 
  </tr> 
  <tr> 
   <td><code>constructor</code></td> 
   <td>构造函数，激活沙箱</td> 
  </tr> 
  <tr> 
   <td><code>active</code></td> 
   <td>激活沙箱，在子应用挂载时启动</td> 
  </tr> 
  <tr> 
   <td><code>inactive</code></td> 
   <td>关闭沙箱，在子应用卸载时启动</td> 
  </tr> 
 </tbody> 
</table>

`SnapshotSandbox` 的沙箱环境主要是通过激活时记录 `window` 状态快照，在关闭时通过快照还原 `window` 对象来实现的。（见下图）

![f548387ba7023ba0059ff83b96f17368.png][] qiankun

我们先看 `active` 函数，在沙箱激活时，会先给当前 `window` 对象打一个快照，记录沙箱激活前的状态（`第 38~40 行`）。打完快照后，函数内部将 `window` 状态通过 `modifyPropsMap` 记录还原到上次的沙箱运行环境，也就是还原沙箱激活期间（历史记录）修改过的 `window` 属性。

在沙箱关闭时，调用 `inactive` 函数，在沙箱关闭前通过遍历比较每一个属性，将被改变的 `window` 对象属性值（`第 54 行`）记录在 `modifyPropsMap` 集合中。在记录了 `modifyPropsMap` 后，将 `window` 对象通过快照 `windowSnapshot` 还原到被沙箱激活前的状态（`第 55 行`），相当于是将子应用运行期间对 `window` 造成的污染全部清除。

`SnapshotSandbox` 沙箱就是利用快照实现了对 `window` 对象状态隔离的管理。相比较 `ProxySandbox` 而言，在子应用激活期间，`SnapshotSandbox` 将会对 `window` 对象造成污染，属于一个对不支持 `Proxy` 属性的浏览器的向下兼容方案。

我们对 `SnapshotSandbox` 沙箱画一张图来加深理解（见下图）

![2172b6bf72897b3c3ece2a3c289f02c3.png][] qiankun

### 挂载沙箱 - `mountSandbox` ###

![6c496b487a5235b423b3caec90dd6e75.png][] qiankun

我们继续回到这张图，`genSandbox` 函数不仅返回了一个 `sandbox` 沙箱，还返回了一个 `mount` 和 `unmount` 方法，分别在子应用挂载时和卸载时的时候调用。

我们先看看 `mount` 函数内部（见下图）

![a41353de4fff29545d37363a5f323cd8.png][] qiankun

首先，在 `mount` 内部先激活了子应用沙箱（`第 26 行`），在沙箱启动后开始劫持各类全局监听（`第 27 行`），我们这里重点看看 `patchAtMounting` 内部是怎么实现的。（见下图）

![e0861cccb6392a812d41059bc73134d3.png][] qiankun

`patchAtMounting` 内部调用了下面四个函数：

*  `patchTimer（计时器劫持）`
 *  `patchWindowListener（window 事件监听劫持）`
 *  `patchHistoryListener（window.history 事件监听劫持）`
 *  `patchDynamicAppend（动态添加 Head 元素事件劫持）`

上面四个函数实现了对 `window` 指定对象的统一劫持，我们可以挑一些解析看看其内部实现。

#### 计时器劫持 - `patchTimer` ####

我们先来看看 `patchTimer` 对计时器的劫持（见下图）

![5980686739a143c24f05ba5f0cebb9ca.png][] qiankun

从上图可以看出，`patchTimer` 内部将 `setInterval` 进行重载，将每个启用的定时器的 `intervalId` 都收集起来（`第 23~24 行`），以便在子应用卸载时调用 `free` 函数将计时器全部清除（见下图）。

![276d04412f560e0366708f209d26efb0.png][] qiankun

我们来看看在子应用加载时的 `setInterval` 函数验证即可（见下图）

![902b7e3ea316e1dac8529375219d3e4e.png][] qiankun

从上图可以看出，在进入子应用时，`setInterval` 已经被替换成了劫持后的函数，防止全局计时器泄露污染。

#### 动态添加样式表和脚本文件劫持 - `patchDynamicAppend` ####

`patchWindowListener` 和 `patchHistoryListener` 的实现都与 `patchTimer` 实现类似，这里就不作复述了。

我们需要重点对 `patchDynamicAppend` 函数进行解析，这个函数的作用是劫持对 `head` 元素的操作（见下图）

![f96481d60f43ec912b1e0ec7dc715586.png][] qiankun

从上图可以看出，`patchDynamicAppend` 主要是对动态添加的 `style` 样式表和 `script` 标签做了处理。

我们先看看对 `style` 样式表的处理（见下图）

![751892f944c6ad7e00c726787fb339c5.png][] qiankun

从上图可以看出，主要的处理逻辑在 `第 68~74 行`，如果当前子应用处于激活状态（`判断子应用的激活状态主要是因为：当主应用切换路由时可能会自动添加动态样式表，此时需要避免主应用的样式表被添加到子应用`head`节点中导致出错`），那么动态 `style` 样式表就会被添加到子应用容器内（见下图），在子应用卸载时样式表也可以和子应用一起被卸载，从而避免样式污染。同时，动态样式表也会存储在 `dynamicStyleSheetElements` 数组中，在后面还会提到其用处。

![e2a68eaac81a159880f7324ec422dcb9.png][] qiankun

我们再来看看对 `script` 脚本文件的处理（见下图）

![02d622bc045b47da9538f5f2b56bdb2b.png][] qiankun

对动态 `script` 脚本文件的处理较为复杂一些，我们也来解析一波：

在 `第 83~101 行` 处对外部引入的 `script` 脚本文件使用 `fetch` 获取，然后使用 `execScripts` 指定 `proxy` 对象（作为 `window` 对象）后执行脚本文件内容，同时也触发了 `load` 和 `error` 两个事件。

在 `第 103~106 行` 处将注释后的脚本文件内容以注释的形式添加到子应用容器内。

在 `第 109~113 行` 是对内嵌脚本文件的执行过程，就不作复述了。

我们可以看出，对动态添加的脚本进行劫持的主要目的就是为了将动态脚本运行时的 `window` 对象替换成 `proxy` 代理对象，使子应用动态添加的脚本文件的运行上下文也替换成子应用自身。

`HTMLHeadElement.prototype.removeChild` 的逻辑就是多加了个子应用容器判断，其他无异，就不展开说了。

最后我们来看看 `free` 函数（见下图）

![94bccb19a610eaefae1e146eeb5bd1c1.png][] qiankun

这个 `free` 函数与其他的 `patches（劫持函数）` 实现不太一样，这里缓存了一份 `cssRules`，在重新挂载的时候会执行 `rebuild` 函数将其还原。这是因为样式元素 `DOM` 从文档中删除后，浏览器会自动清除样式元素表。如果不这么做的话，在重新挂载时会出现存在 `style` 标签，但是没有渲染样式的问题。

### 卸载沙箱 - unmountSandbox ###

我们再回到 `mount` 函数本身（见下图）

![389f327d985e2c353f04d66bbe27634f.png][] qiankun

从上图可以看出，在 `patchAtMounting` 函数中劫持了各类全局监听，并返回了解除劫持的 `free` 函数。在卸载应用时调用 `free` 函数解除这些全局监听的劫持行为（见下图）

![db0123b921f1930b80d00eba00267fb7.png][] qiankun

从上图可以看到 `sideEffectsRebuilders` 在 `free` 后被返回，在 `mount` 的时候又将被调用 `rebuild` 重建动态样式表。这块环环相扣，是稍微有点绕，没太看明白的同学可以翻上去再看一遍。

到这里，`qiankun` 的最核心部分-沙箱机制，我们就已经解析完毕了，接下来我们继续剖析别的部分。

在这里我们画一张图，对沙箱的创建过程进行一个总梳理（见下图）

![bed0b45fb43724f7aba3ab6a6b8dbc03.png][] qiankun

### 注册内部生命周期函数 ###

在创建好了沙箱环境后，在 `第 100~106 行` 注册了一些内部生命周期函数（见下图）

![ab79e99207d538a306736e235cbb2300.png][] qiankun

在上图中，`第 106 行` 的 `mergeWith` 方法的作用是将内置的生命周期函数与传入的 `lifeCycles` 生命周期函数。

> 这里的 `lifeCycles` 生命周期函数指的是全子应用共享的生命周期函数，可用于执行多个子应用间相同的逻辑操作，例如 `加载效果` 之类的。（见下图）

![8daed96c0e51072606071a69fcb3ae09.png][] qiankun

除了外部传入的生命周期函数外，我们还需要关注 `qiankun` 内置的生命周期函数做了些什么（见下图）

![9c601ab3811e9c2348dbfa99c6f7421e.png][] qiankun

我们对上图的代码进行逐一解析：

*  `第 13~15 行`：在加载子应用前 `beforeLoad`（只会执行一次）时注入一个环境变量，指示了子应用的 `public` 路径。
 *  `第 17~19 行`：在挂载子应用前 `beforeMount`（可能会多次执行）时可能也会注入该环境变量。
 *  `第 23~30 行`：在卸载子应用前 `beforeUnmount` 时将环境变量还原到原始状态。

通过上面的分析我们可以得出一个结论，我们可以在子应用中获取该环境变量，将其设置为 `__webpack_public_path__` 的值，从而使子应用在主应用中运行时，可以匹配正确的资源路径。（见下图）

![a1ad2c26d04b8bbfeb0b15f5d9897a2e.png][] qiankun

#### 触发 `beforeLoad` 生命周期钩子函数 ####

在注册完了生命周期函数后，立即触发了 `beforeLoad` 生命周期钩子函数（见下图）

![59bf9a546e9d76b22a7b0844b19b743a.png][] qiankun

从上图可以看出，在 `第 108 行` 中，触发了 `beforeLoad` 生命周期钩子函数。

随后，在 `第 110 行` 执行了 `import-html-entry` 的 `execScripts` 方法。指定了脚本文件的运行沙箱（`jsSandbox`），执行完子应用的脚本文件后，返回了一个对象，对象包含了子应用的生命周期钩子函数（见下图）。

![07f86afc5ac7daa6d8046a5155754922.png][] qiankun

在 `第 112~121 行` 对子应用的生命周期钩子函数做了个检测，如果在子应用的导出对象中没有发现生命周期钩子函数，会在沙箱对象中继续查找生命周期钩子函数。如果最后没有找到生命周期钩子函数则会抛出一个错误，所以我们的子应用一定要有 `bootstrap, mount, unmount` 这三个生命周期钩子函数才能被 `qiankun` 正确嵌入到主应用中。

这里我们画一张图，对子应用挂载前的初始化过程做一个总梳理（见下图）

![0f8c1da79bb67c9ec02e2a6910ebd77f.png][] qiankun

### 进入到 `mount` 挂载流程 ###

在一些初始化配置（如 `子应用资源、运行沙箱环境、生命周期钩子函数等等`）准备就绪后，`qiankun` 内部将其组装在一起，返回了三个函数作为 `single-spa` 内部的生命周期函数（见下图）

![cf11377cf5f5659453cf928cf56b19fc.png][] qiankun

`single-spa` 内部的逻辑我们后面再展开说，这里我们可以简单理解为 `single-spa` 内部的三个生命周期钩子函数：

*  `bootstrap`：子应用初始化时调用，只会调用一次；
 *  `mount`：子应用挂载时调用，可能会调用多次；
 *  `unmount`：子应用卸载时调用，可能会调用多次；

我们可以看出，在 `bootstrap` 阶段调用了子应用暴露的 `bootstrap` 生命周期函数。

我们这里对 `mount` 阶段进行展开，看看在子应用 `mount` 阶段执行了哪些函数（见下图）

![245340cf3d6f3ad69b4df8db4ad722d6.png][] qiankun

我们进行逐行解析：

*  `第 127~133 行`：对单实例模式进行检测。在单实例模式下，新的子应用挂载行为会在旧的子应用卸载之后才开始。（由于这里是串行顺序执行，所以如果某一处发生阻塞的话，会阻塞所有后续的函数执行）
 *  `第 134 行`：执行注册子应用时传入的 `render` 函数，将 `HTML Template` 和 `loading` 作为入参。这里一般是在发生了一次 `unmount` 后，再次进行 `mount` 挂载行为时将 `HTML` 挂载在指定容器中（见下图）
    
    > 由于初始化的时候已经调用过一次 `render`，所以在首次调用 `mount` 时可能已经执行过一次 `render` 方法。
    > 
    > 在下面的代码中也有对重复挂载的情况进行判断的语句 - `if (frame.querySelector("div") === null`，防止重复挂载子应用。

![9edac0c5c691160b97c7166cbbd2cd86.png][] qiankun

*  `第 135 行`：触发了 `beforeMount` 全局生命周期钩子函数；
 *  `第 136 行`：挂载沙箱，这一步中激活了对应的子应用沙箱，劫持了部分全局监听（如 `setInterval`）。此时开始子应用的代码将在沙箱中运行。（反推可知，在 `beforeMount` 前的部分全局操作将会对主应用造成污染，如 `setInterval`）
 *  `第 137 行`：触发子应用的 `mount` 生命周期钩子函数，在这一步通常是执行对应的子应用的挂载操作（如 `ReactDOM.render、Vue.$mount`。（见下图）

![2e3b7e39b3b6980a6ef72c449822fa43.png][] qiankun

*  `第 138 行`：再次调用 `render` 函数，此时 `loading` 参数为 `false`，代表子应用已经加载完成。
 *  `第 139 行`：触发了 `afterMount` 全局生命周期钩子函数；
 *  `第 140~144 行`：在单实例模式下设置 `prevAppUnmountedDeferred` 的值，这个值是一个 `promise`，在当前子应用卸载时才会被 `resolve`，在该子应用运行期间会阻塞其他子应用的挂载动作（`第 134 行`）；

我们在上面很详细的剖析了整个子应用的 `mount` 挂载流程，如果你还没有搞懂的话，没关系，我们再画一个流程图来帮助理解。（见下图）

![b64a79d90dc08e04bec61a3b7663a348.png][] qiankun

### 进入到 `unmount` 卸载流程 ###

我们刚才梳理了子应用的 `mount` 挂载流程，我们现在就进入到子应用的 `unmount` 卸载流程。在子应用激活阶段， `activeRule` 未命中时将会触发 `unmount` 卸载行为，具体的行为如下（见下图）

![92b7a38ca4a0ad5daafe47355a733245.png][] qiankun

从上图我们可以看出，`unmount` 卸载流程要比 `mount` 简单很多，我们直接来梳理一下：

*  `第 148 行`：触发了 `beforeUnmount` 全局生命周期钩子函数；
 *  `第 149 行`：这里与 `mount` 流程的顺序稍微有点不同，这里先执行了子应用的 `unmount` 生命周期钩子函数，保证子应用仍然是运行在沙箱内，避免造成状态污染。在这里一般是对子应用的一些状态进行清理和卸载操作。（如下图，销毁了刚才创建的 `vue` 实例）

![64f46ef8e766892876512a48108ef820.png][] qiankun

*  `第 150 行`：卸载沙箱，关闭了沙箱的激活状态。
 *  `第 151 行`：触发了 `afterUnmount` 全局生命周期钩子函数；
 *  `第 152 行`：触发 `render` 方法，并且传入的 `appContent` 为空字符串，此处可以清空主应用容器内的内容。
 *  `第 153~156 行`：当前子应用卸载完成后，在单实例模式下触发 `prevAppUnmountedDeferred.resolve()`，使其他子应用的挂载行为得以继续进行，不再阻塞。

我们对 `unmount` 卸载流程也画一张图，帮助大家理解（见下图）。

![e702fdd999e4d9669e8f1dfda8c877e8.png][] qiankun

## 总结 ##

到这里，我们对 `qiankun` 框架的总流程梳理就差不多了。这里应该做个总结，大家看了这么多文字，估计大家也看累了，最后用一张图对 `qiankun` 的总流程进行总结吧。

![34e0f954f02384fc785adb3404bf60c6.png][] qiankun

## 彩蛋 ##

![f344d07386688e67f27917290def5f52.png][] qiankun

## 展望 ##

传统的云控制台应用，几乎都会面临业务快速发展之后，单体应用进化成巨石应用的问题。我们要如何维护一个巨无霸中台应用？

上面这个问题引出了微前端架构理念，所以微前端的概念也越来越火，我们团队最近也在尝试转型微前端架构。

工欲善其事必先利其器，所以本文针对 `qiankun` 的源码进行解读，在分享知识的同时也是帮助自己理解。

这是我们团队对微前端架构的最佳实践（见下图），如果有需求的话，可以在评论区留言，我们会考虑出一篇《微前端框架 `qiankun` 最佳实践》来帮助大家搭建一套微前端架构。

![674b1635b244bb023880f039217f50b2.png][] 架构图

## 最后一件事 ##

这篇文章我花了大约半个月的时间来进行排版、梳理、画图，坚持下来一路写完确实很不容易。

如果您已经看到这里了，希望您还是点个赞再走吧~

如果本文对您有帮助的话，请点个赞和收藏吧！

您的点赞是对作者的最大鼓励，也可以让更多人看到本篇文章！

如果对 `《微前端框架 qiankun 最佳实践》` 有兴趣的话，还请在评论区留言告诉作者吧！

> github 地址: https://github.com/a1029563229/Blogs/tree/master/Source-Code/qiankun/1.md)

![17d6158fe4b282f26155a8bf6cd859c2.png][]

## 最后 ##

欢迎关注我的新号【前端热榜】，每天中午分享一篇高质量的文章

回复「电子书」，下载27本电子书，包含前端面试、思维图等！

回复「加群」，吹吹水、聊聊技术、吐吐槽！

回复「进阶」，下载进阶资料包！

如果这篇文章对你有帮助，「在看」是最大的支持

“在看和转发”就是最大的支持

[a8bf776b260e9b47e8943bc65db1dbc5.png]: /images/20220828/5a45bdc29a8e4d1c8a56e59ea48d7b28.png
[07efd1602415936f0608e6f3a7da7d2f.png]: /images/20220828/80f6cb3a18e2424cb93ea95e1d1911ef.png
[55b17466087f837448e45806640e8b8a.png]: /images/20220828/17150d8342f5483e8314476e127c2d57.png
[84bd3facd32c674083572b650e32aec1.png]: /images/20220828/62efb65bab81467ca8a102695b12db11.png
[1656378ec342853fcecfc8bd5dcfa531.png]: /images/20220828/bf17e864cf6242a0829f76450902236e.png
[b64198bda750b452d1196b082b7a9abf.png]: /images/20220828/6316377ffa3348a2a78df7463057f6d3.png
[d598057c39dbce71fcff22607350b489.png]: /images/20220828/ed86a32357094c0b9182a307ba9eed3c.png
[98ab1e8242001d1116d1e13fde8443a1.png]: /images/20220828/3b66e6eb92b246ce9c9c6a56d5a5f951.png
[6cd4636a5e4cf9f9ce37090a48a825ac.png]: /images/20220828/2b0074296ca34da18da20c5802ec9f27.png
[0032001eedd3667791aa3e704f87819d.png]: https://img-blog.csdnimg.cn/img_convert/0032001eedd3667791aa3e704f87819d.png
[98e2d3f9cdfb2b6b0b28ace94fdd08c5.png]: /images/20220828/09aebf4adc2f441e8ee3749be5cbf02e.png
[a66ca5df2d14dfc22c8e058417e42c20.png]: /images/20220828/fbfdfc19152d4f61840ceeeebcd842d9.png
[13f3b73b02413f1510ed0d07be5f4fbe.png]: /images/20220828/3353c7f2b4da421e8f319ffe660e6208.png
[04ca62c03a7c3c358fa21c72848b2ace.png]: /images/20220828/f5a22e52da95459485fa96769588930e.png
[c413950c2dea3bc1fd3a4b9bbdbfedbc.png]: /images/20220828/109d38315e9f4e35929722bdb10838ee.png
[5d7fee9a6d7583162775f977ad20e750.png]: /images/20220828/d8f1035723214428bb4c7dd6c65b43a0.png
[daf9cb5935792c1ccc40d3ab15ff4542.png]: /images/20220828/95a653459ce646b693377060bb17a281.png
[8bccaea65f26db4a7167e8bacecca5cb.png]: /images/20220828/24895aff50414da7b821a7abe08a3689.png
[b64be4476b8449a1aeb11b35d920500b.png]: /images/20220828/4838cbf7696a4335be9367c1c75b3541.png
[ebae9c29053e6f3ac525caf4848ebe0f.png]: /images/20220828/0e95a7806cb141778852de499e0f1412.png
[d3a460caf62e5a4dc619a91b78035737.png]: /images/20220828/e40462bcde044c239b95dc7864d9fdc4.png
[2d50124c3c4105d987732ef35cef8d20.png]: /images/20220828/a7c10ff5ad92469db300a488157f12ce.png
[31dc9bf9c9a4f069bb8d3a616f692280.png]: /images/20220828/8b04a440213a4b7b8fcde84b13f37147.png
[f548387ba7023ba0059ff83b96f17368.png]: /images/20220828/7b551fce9aa5475687b1fd2654b7fb51.png
[2172b6bf72897b3c3ece2a3c289f02c3.png]: /images/20220828/3c40a19a37244649ab1019a424cdf2bc.png
[6c496b487a5235b423b3caec90dd6e75.png]: /images/20220828/24661d43d6234f3889aaad6203233d27.png
[a41353de4fff29545d37363a5f323cd8.png]: /images/20220828/36544c3d4a334e7b9886023159f46be1.png
[e0861cccb6392a812d41059bc73134d3.png]: /images/20220828/71cc59f5e39d450db540953df377fa5c.png
[5980686739a143c24f05ba5f0cebb9ca.png]: /images/20220828/ce2a258e728d45eabb20a84420525aea.png
[276d04412f560e0366708f209d26efb0.png]: /images/20220828/f6e678eb2ed7458489aff558017a3032.png
[902b7e3ea316e1dac8529375219d3e4e.png]: /images/20220828/4c76f2d79fd94423aa532fa290f76f41.png
[f96481d60f43ec912b1e0ec7dc715586.png]: /images/20220828/7c2e7d8ee04b4533b6820c290d60c24c.png
[751892f944c6ad7e00c726787fb339c5.png]: /images/20220828/f8a04b4dbe6142ac9ad47d37f55a758d.png
[e2a68eaac81a159880f7324ec422dcb9.png]: /images/20220828/3df5fc4ddb2742e8ad85cdedc1bccedc.png
[02d622bc045b47da9538f5f2b56bdb2b.png]: /images/20220828/61b0df0ec86541f6b93c6f0169b213a7.png
[94bccb19a610eaefae1e146eeb5bd1c1.png]: /images/20220828/964aa4e83ea04decb195d7156b78896e.png
[389f327d985e2c353f04d66bbe27634f.png]: /images/20220828/39dbd2d0aa684b6788a9fe3cf7b192f7.png
[db0123b921f1930b80d00eba00267fb7.png]: /images/20220828/0f3a89c0402e45888fe9691982f895d2.png
[bed0b45fb43724f7aba3ab6a6b8dbc03.png]: /images/20220828/1b5a362ecde940e087a4a4c69eaae583.png
[ab79e99207d538a306736e235cbb2300.png]: /images/20220828/b0f069e3cc6e438dbffe732b10ae0e66.png
[8daed96c0e51072606071a69fcb3ae09.png]: /images/20220828/9bf69b77415d43028a0cd4d0c3696bcb.png
[9c601ab3811e9c2348dbfa99c6f7421e.png]: /images/20220828/9e6a4cd5956e47698121b92e817c1730.png
[a1ad2c26d04b8bbfeb0b15f5d9897a2e.png]: /images/20220828/1487b78373fa4d56bcbd378ff50f1ea1.png
[59bf9a546e9d76b22a7b0844b19b743a.png]: /images/20220828/6e49e10cbe234e779b07290561051081.png
[07f86afc5ac7daa6d8046a5155754922.png]: /images/20220828/030f925027fb45cbaf99d7fb45088ee1.png
[0f8c1da79bb67c9ec02e2a6910ebd77f.png]: /images/20220828/02ba1316730544b09e2a483fb83ae9c5.png
[cf11377cf5f5659453cf928cf56b19fc.png]: /images/20220828/1b7202fa0b2d4456a9a1e9acb4a1a664.png
[245340cf3d6f3ad69b4df8db4ad722d6.png]: /images/20220828/24f01d3d35574e0896683a133ff25706.png
[9edac0c5c691160b97c7166cbbd2cd86.png]: /images/20220828/fa8ab5d8bc4140ff91cefbbcfe483313.png
[2e3b7e39b3b6980a6ef72c449822fa43.png]: /images/20220828/fac4cb3628324f678eee596a2d30da80.png
[b64a79d90dc08e04bec61a3b7663a348.png]: /images/20220828/29fa31defec340bcbe3df89c194362db.png
[92b7a38ca4a0ad5daafe47355a733245.png]: /images/20220828/7715cfaa6b4e4774bca326bced235c53.png
[64f46ef8e766892876512a48108ef820.png]: /images/20220828/36d07727e28043f7ad3bf3bcd99b9c6b.png
[e702fdd999e4d9669e8f1dfda8c877e8.png]: /images/20220828/70f276e93d5b41b59128ac2584c85030.png
[34e0f954f02384fc785adb3404bf60c6.png]: /images/20220828/04265517184c49589f0284fa534c6915.png
[f344d07386688e67f27917290def5f52.png]: /images/20220828/75a567526e7649c680bf069c83622d80.png
[674b1635b244bb023880f039217f50b2.png]: /images/20220828/5ca16dd0b768471e805f96df6cb7d4b5.png
[17d6158fe4b282f26155a8bf6cd859c2.png]: /images/20220828/ffe0f65937a8418a8e3971c325be20cb.png