微前端运行时

谈到微前端绕不开的话题就是为什么不适用 iframe 作为承载微前端子应用的容器，其实从浏览器原生的方案来说，iframe 不从体验角度上来看几乎是最可靠的微前端方案了，主应用通过iframe 来加载子应用，iframe 自带的样式、环境隔离机制使得它具备天然的沙盒机制，但也是由于它的隔离性导致其并不适合作为加载子应用的加载器，iframe 的特性不仅会导致用户体验的下降，也会在研发在日常工作中造成较多困扰，以下总结了 iframe 作为子应用的一些劣势：

• 使用Iframe 会大幅增加内存和计算资源，因为 iframe 内所承载的页面需要一个全新并且完整的文档环境
• Iframe 与上层应用并非同一个文档上下文导致
• 事件冒泡不穿透到主文档树上，焦点在子应用时，事件无法传递上一个文档流
• 主应用劫持快捷键操作
• 事件无法冒泡顶层，针对整个应用统一处理时效
• 跳转路径无法与上层文档同步，刷新丢失路由状态
• Iframe 内元素会被限制在文档树中，视窗宽高限制问题
• Iframe 登录态无法共享，子应用需要重新登录
• Iframe 在禁用三方 cookie 时，iframe 平台服务不可用
• Iframe 应用加载失败，内容发生错误主应用无法感知
• 难以计算出 iframe 作为页面一部分时的性能情况
• 无法预加载缓存 iframe 内容
• 无法共享基础库进一步减少包体积
• 事件通信繁琐且限制多

基于 SPA 的微前端架构

尽管难以将 Iframe 作为微前端应用的加载器，但是却可以参考其设计思想，一个传统的 Iframe 加载文档的能力可以分为四层：文档的加载能力、HTML 的渲染、执行 JavaScript、隔离样式和 JavaScript 运行环境。那么微前端库的基础能力也可以参考其设计思想。

从设计层面采取的是基座+子应用分治的概念，部署平台负责进行服务发现和服务注册，将注册的应用列表信息下发至基座，通过基座来动态控制子系统的渲染和销毁，并提供集中式的模式来完成应用间的通信和应用的公共依赖管理，因此 Garfish 在 Runtime 层面主要提供了以下四个核心能力：
加载器（Loader）

• 负责注册平台侧提供的应用列表
• 负责加载和解析子应用入口资源
• HTML 入口类型，拆解 HTML Dom、Script、Style
• JS 入口类型，提供基础 Dom 容器
• 预加载能力
• 解析子应用导出内容

沙箱隔离（Sandbox）

• 提供代码执行能力，收集执行代码时存在的副作用
• 提供销毁收集副作用的能力
• 支持沙箱多实例，收集不同实例的副作用

路由托管（Router）

• 解决不同应用间的路由不同步问题
• 提供路由劫持能力，在主应用上管控子应用路由
• 提供路由驱动能力来拼装完整的平台的能力

子应用通信（Store）

• 建立通信桥梁
• 提供共享机制

应用生命周期

整个微前端子应用的生命周期基本可以总结为：
渲染阶段

• 主应用通过路由驱动或手动挂载的方式触发子应用渲染
• 开始加载应用的资源内容，并初始化子应用的沙箱运行时环境
• 判断入口类型
  • 若入口类型为 HTML 类型，将开始解析和拆解子应用资源
  • 若入口类型为 JS，创建子应用的挂点 DOM
• 将子应用存在”副作用“（对当前页面可能产生影响的内容）交由沙箱处理
• 开始渲染子应用的 DOM 树
• 触发子应用的渲染 Hook

销毁阶段

• 若路由变化离开子应用的激活范围或主动触发销毁函数，触发应用的销毁
• 清除应用在渲染时和运行时产生的副作用
• 移除子应用的 DOM 元素