让iframe焕发新生

作者：damyxu，腾讯 PCG 前端开发工程师

背景

前端开发中我们对 iframe 已经非常熟悉了，那么 iframe 的作用是什么？可以归纳如下：

在一个 web 应用中可以独立的运行另一个 web 应用

这个概念已经和 微前端 不谋而合，相对于目前配置复杂、高适配成本的微前端方案来说，采用 iframe 方案具有一些显著的优点：

非常简单 ，使用没有任何心智负担
隔离完美 ，无论是js、css、dom都完全隔离开来
多应用激活 ，页面上可以摆放多个 iframe 来组合业务

但是开发者又厌恶使用 iframe ，因为缺点也非常明显：

路由状态丢失 ，刷新一下，iframe的url状态就丢失了
dom割裂严重 ，弹窗只能在iframe内部展示，无法覆盖全局
通信非常困难 ，只能通过postmessage传递序列化的消息
白屏时间太长 ，对于 SPA 应用 应用来说无法接受

能否打造一个完美的 iframe ，保留所有的优点的同时，解决掉所有的缺点呢？

无界方案

无界微前端框架通过继承 iframe 的优点，解决 iframe 的缺点，打造一个接近完美的 iframe 方案

来看无界如何一步一步的解决 iframe 的问题，假设我们有A应用，想要加载B应用：

在应用A中构造一个 shadow 和 iframe ，然后将应用B的 html 写入 shadow 中， js 运行在 iframe 中， 注意 iframe 的 url ， iframe 保持和主应用同域但是保留子应用的路径信息，这样子应用的 js 可以运行在 iframe 的 location 和 history 中保持路由正确。

在 iframe 中拦截 document 对象，统一将 dom 指向 shadowRoot ，此时比如新建元素、弹窗或者冒泡组件就可以正常约束在 shadowRoot 内部。

接下来的三步分别解决 iframe 的三个缺点：

:white_check_mark: dom割裂严重的问题，主应用提供一个容器给到 shadowRoot 插拔， shadowRoot 内部的弹窗也就可以覆盖到整个应用A
:white_check_mark: 路由状态丢失的问题，浏览器的前进后退可以天然的作用到 iframe 上，此时监听 iframe 的路由变化并同步到主应用，如果刷新浏览器，就可以从url读回保存的路由
:white_check_mark: 通信非常困难的问题， iframe 和主应用是同域的，天然的共享内存通信，而且无界提供了一个去中心化的事件机制

将这套机制封装进 wujie 框架：

我们可以发现：

:white_check_mark: 首次白屏的问题， wujie 实例可以提前实例化，包括 shadowRoot 、 iframe 的创建、 js 的执行，这样极大的加快子应用第一次打开的时间
:white_check_mark: 切换白屏的问题，一旦 wujie 实例可以缓存下来，子应用的切换成本变的极低，如果采用保活模式，那么相当于 shadowRoot 的插拔

由于子应用完全独立的运行在 iframe 内，路由依赖 iframe 的 location 和 history ，我们还可以在一张页面上同时激活多个子应用，由于 iframe 和主应用处于同一个 top-level browsing context ，因此浏览器前进、后退都可以作用到到子应用：

通过以上方法，无界方案可以做到：

:white_check_mark: 非常简单 ，使用没有任何心智负担
:white_check_mark: 隔离完美 ，无论是js、css、dom都完全隔离开来
:white_check_mark: 多应用激活 ，页面上可以摆放多个 iframe 来组合业务
路由状态丢失 ，刷新一下，iframe的url状态就丢失了
dom割裂严重 ，弹窗只能在iframe内部展示，无法覆盖全局
通信非常困难 ，只能通过postmessage传递序列化的消息
白屏时间太长 ，对于 SPA 应用 应用来说无法接受

使用无界

如果主应用是 vue 框架：

安装

npm i @tencent/wujie-vue -S`

引入

mport WujieVue from "@tencent/wujie-vue";
Vue.use(WujieVue);

使用

<WujieVue
  width="100%"
  height="100%"
  name="xxx"
  url="xxx"
  :sync="true"
  :fetch="fetch"
  :props="props"
  @xxx="handleXXX"
></WujieVue>

其他框架也会在近期上线

适配成本

无界的适配成本非常低

对于主应用无需做任何改造

对于子应用：

webpack

if (window.__POWERED_BY_WUJIE__) {
  let instance;
  window.__WUJIE_MOUNT = () => {
    instance = new Vue({ router, render: (h) => h(App) }).$mount("#app");
  };
  window.__WUJIE_UNMOUNT = () => {
    instance.$destroy();
  };
} else {
  new Vue({ router, render: (h) => h(App) }).$mount("#app");
}

实现细节

实现一个纯净的 iframe

子应用运行在一个和主应用同域的 iframe 中，设置 src 为替换了主域名 host 的子应用 url ，子应用路由只取 location 的 pathname 和 hash

但是一旦设置 src 后， iframe 由于同域，会加载主应用的 html 、 js ，所以必须在 iframe 实例化完成并且还没有加载完 html 时中断加载，防止污染子应用

此时可以采用轮询监听 document.readyState 状态来及时中断，对于一些浏览器比如 safari 状态不准确，可以在 wujie 主动抛错来防止有主应用的 js 运行

iframe 数据劫持和注入

子应用的代码 code 在 iframe 内部访问 window ， document 、 location 都被劫持到相应的 proxy ，并且还会注入 $wujie 对象供子应用调用

const script = `(function(window, self, global, document, location, $wujie) {
    ${code}\n
  }).bind(window.__WUJIE.proxy)(
    window.__WUJIE.proxy,
    window.__WUJIE.proxy,
    window.__WUJIE.proxy,
    window.__WUJIE.proxy.document,
    window.__WUJIE.proxy.location,
    window.__WUJIE.provide
  );`;

iframe 和 shadowRoot 副作用的处理

iframe 内部的副作用处理在初始化 iframe 时进行，主要分为如下几部

/**
 * 1、location劫持后的数据修改回来，防止跨域错误
 * 2、同步路由到主应用
 */
patchIframeHistory(iframeWindow, appPublicPath, mainPublicPath);
/**
 * 对window.addEventListener进行劫持，比如resize事件必须是监听主应用的
 */
patchIframeEvents(iframeWindow);
/**
 * 注入私有变量
 */
patchIframeVariable(iframeWindow, appPublicPath);
/**
 * 将有DOM副作用的统一在此修改，比如mutationObserver必须调用主应用的
 */
patchIframeDomEffect(iframeWindow);
/**
 * 子应用前进后退，同步路由到主应用
 */
syncIframeUrlToWindow(iframeWindow);

ShadowRoot 内部的副作用必须进行处理，主要处理的就是 shadowRoot 的 head 和 body

shadowRoot.head.appendChild = getOverwrittenAppendChildOrInsertBefore({
    rawDOMAppendOrInsertBefore: rawHeadAppendChild
  }) as typeof rawHeadAppendChild
  shadowRoot.head.insertBefore = getOverwrittenAppendChildOrInsertBefore({
    rawDOMAppendOrInsertBefore: rawHeadInsertBefore as any
  }) as typeof rawHeadInsertBefore
  shadowRoot.body.appendChild = getOverwrittenAppendChildOrInsertBefore({
    rawDOMAppendOrInsertBefore: rawBodyAppendChild
  }) as typeof rawBodyAppendChild
  shadowRoot.body.insertBefore = getOverwrittenAppendChildOrInsertBefore({
    rawDOMAppendOrInsertBefore: rawBodyInsertBefore as any
  }) as typeof rawBodyInsertBefore

getOverwrittenAppendChildOrInsertBefore 主要是处理四种类型标签：

link/style 标签 收集 stylesheetElement 并用于子应用重新激活重建样式
script 标签 动态插入的 script 标签必须从 ShadowRoot 转移至 iframe 内部执行
iframe 标签 修复 iframe 的指向对应子应用 iframe 的 window

iframe 的 document 改造

由于 js 在 iframe 运行需要和 shadowRoot ，包括元素创建、事件绑定等等，将 iframe 的 document 进行劫持：

所有的元素的查询全部代理到 shadowRoot 内去查询
head 和 body 代理到 shadowRoot 的对应 html 元素上

iframe 的 location 改造

将 iframe 的 location 进行劫持：

由于 iframe 的 url 的 host 是主应用的，所以需要将 host 改回子应用自己的
对于 location.href 特殊逻辑的处理

总结

通过上面原理以及细节的阐述，我们可以得出无界微前端框架的几点优势：

多应用同时激活在线 框架具备同时激活多应用，并保持这些应用路由同步的能力
组件式的使用方式 无需注册，更无需路由适配，在组件内使用，跟随组件装载、卸载
应用级别的 keep-alive 子应用开启保活模式后，应用发生切换时整个子应用的状态可以保存下来不丢失，结合预执行模式可以获得类似 ssr 的打开体验
纯净无污染

无界利用 iframe 和 ShadowRoot 来搭建天然的 js 隔离沙箱和 css 隔离沙箱
利用 iframe 的 history 和主应用的 history 在同一个 top-level browsing context 来搭建天然的路由同步机制
副作用局限在沙箱内部，子应用切换无需任何清理工作，没有额外的切换成本

性能和体积兼具

子应用执行性能和原生一致，子应用实例 instance 运行在 iframe 的 window 上下文中，避免 with(proxyWindow){code} 这样指定代码执行上下文导致的性能下降，但是多了实例化 iframe 的一次性的开销，可以通过 proloadApp 提前实例化
包体积只有 11kb ，非常轻量，借助 iframe 和 ShadowRoot 来实现沙箱，极大的减小了代码量

开箱即用 不管是样式的兼容、路由的处理、弹窗的处理、热更新的加载，子应用完成接入即可开箱即用无需额外处理，应用接入成本也极低

相应的也有所不足：

内存占用较高，为了降低子应用的白屏时间，将未激活子应用的 shadowRoot 和 iframe 常驻内存并且保活模式下每张页面都需要独占一个 wujie 实例，内存开销较大
兼容性一般，目前用到了浏览器的 shadowRoot 和 proxy 能力，并且没有做降级方案
iframe 劫持 document 到 shadowRoot 时，某些第三方库可能无法兼容导致穿透

原文 https://zhuanlan.zhihu.com/p/442815952

链接: https://fly63.com/article/detial/10923