微前端运行时
谈到微前端绕不开的话题就是为什么不适用 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 元素
