我的项目背景：

  1. app下架须要把所有页面都迁徙到企业微信h5
  2. 布局架构：主利用提供菜单组件和专用办法，而后微利用须要渲染到指定的容器。所以要求微前端框架提供隔离款式的性能、以及通信性能。
  3. 只给了一个月来接入主利用和子利用。子利用须要推动各部门来配合接入，月初提需要，月底上线第一批利用

技术选型规范

  1. 基于工夫紧迫，须要筛选可用，且接入成本低，社区活跃度高，遇到问题能够找到对应的解决方案的微前端框架

  2. 维度与评分

    • 老本

      • 接入老本（接入微前端框架要改变的货色）
      • 革新老本（基于这个微前端框架不反对的性能，须要本人实现的难度评估）

    • 收益

      • 微前端运行时性能完整性
      • 微前端工程化
      • 微前端运维

    • 危险

      • 社区活跃度（github star数量、已解决issue数量）
      • 可维护性（文档是否齐全、在技术社区是否能够找到对应的技术分享文章）
      • 可扩展性（随着越来越多的微利用接入，是否会导致治理上的不便）

iframe

iframe有人造的隔离性，然而隔离性太强，导致以下问题：

  1. 刷新后iframe的url状态失落，无法控制iframe页面的后退后退；
  2. 想实现子利用免登录须要跨域共享cookie，反而导致安全性升高；
  3. 全局弹窗无奈实现
  4. 企业微信h5的iframe不反对跨域申请页面，详见这里

因为 微前端运行时性能完整性 不能满足根本业务需要，间接放弃该计划。

single-spa

性能上：

  1. 兼容多框架
  2. html entry
  3. 加载和渲染原理：路由劫持，下载入口html，渲染到指标容器
  4. 不反对js隔离、款式隔离
  5. 不反对利用间通信
  6. 不反对预加载
  7. 没有思考微前端工程化和运维

老本：
接入老本：

  1. 子利用须要装置依赖，以及注册生命周期函数
  2. 主利用须要本人编写加载子利用的逻辑

革新老本：

  1. 须要本人实现js隔离、款式隔离
  2. 须要本人实现预加载
  3. 须要本人实现利用间通信

危险：

  1. 社区活跃度 github star数量 11.3k、已解决issue数量 532（2022.6.27）
  2. 文档齐全，demo多

小结：

  1. 性能上，只做了路由劫持、提供参数填写加载微利用的逻辑。须要本人实现利用隔离、预加载和利用间通信。微前端运行时性能完整性 低，得1分。没有思考 微前端工程化 和 微前端运维 相干的性能。所以在收益这个维度，得分 1/9
  2. 老本上，接入须要本人手写加载微利用的逻辑，且子利用须要额定装置依赖，接入老本高，得1分。须要本人实现利用隔离、通信、以及预加载等，革新老本高，得1分。所以在老本这个维度得分 2/6。
  3. 社区活跃度高，可维护性高；

qiankun

性能上：

  1. 基于single-spa欠缺以下性能：
    a. 利用隔离

    • js沙箱，依据Proxy的反对度以及是否多例，反对三种沙箱实现形式
    • 款式隔离：反对shadow dom计划，以及试验式款式隔离
    • 全局办法（setInterval、clearInterval、addEventListener、removeEventListener）劫持

    b. 反对预加载
    c. 基于props来实现父子通信

  2. 没有思考工程化问题：如专用依赖，组件复用
  3. 没有思考到微前端平台运维

老本上：

  1. 接入老本：子利用须要接入生命周期代码；主利用须要接入注册微利用代码；
  2. 革新老本：须要本人思考微前端工程化问题，以及微前端平台运维。

危险上：

  1. 社区活跃度：github star 数量 12.8k （统计工夫20220622）
  2. 文档齐全，demo多

emp

性能上：

  1. 思考了微前端的工程化问题，基于webapck5 MF性能解决公共依赖的问题，以及能够实现微组件共享。
  2. 不反对款式隔离和js隔离
  3. 它的设计是去中心化，每个子利用都能够再接入子利用，

老本上：
接入老本：

  1. 所有利用都要迁徙到webpack5
  2. monorepo组织几个代码仓库

革新老本：

  1. 基于webpack5 MF实现公共依赖和组件共享，须要另外做基建来对立引入这些包的入口。还有公建文档的问题。
  2. 微组件共享是基于vuera这个库来实现的，只反对vue和react的组建共享
  3. 须要本人实现利用隔离

危险上：

  1. 社区活跃度：社区活跃度不高 star 1.8k （统计工夫20220622）
  2. 文档不欠缺

小结：
emp比拟适宜大型且处于立项初期时选用。须要事先做monorepo的布局、款式统一规划。

microapp

性能上：

  1. 摈弃了路由劫持的思路，选用类web component的计划
  2. 基于CustomElement和款式隔离、js隔离来实现微利用的加载，所以子利用无需改变就能够接入
  3. 反对利用隔离
  4. 通过劫持底层接口实现了元素隔离
  5. 提供了插件零碎
  6. 反对预加载
  7. 没有思考工程化问题：如专用依赖，组件复用
  8. 没有思考到微前端平台运维

老本：
接入老本：子利用无需改变，主利用须要接入微利用代码
革新老本：须要本人思考微前端工程化问题，以及微前端平台运维。

危险：

  1. 这个框架基于CustomElement和Proxy API，前者针对低版本有polyfill，但后者没有，且目前官网文档说没有做兼容的打算
  2. 社区活跃度 star 2.7k（统计工夫20220622）
  3. 文档齐全

总结

iframe、single-spa 在功能完善度上有余，所以放弃抉择；
emp 比拟适宜在我的项目初期选型应用，用约定来躲避款式隔离和js隔离（所以 emp 没有把利用隔离思考进去），比拟适宜在大型项目中应用；
microapp 和qiankun，性能残缺度上比拟好，只管 microapp 比 qiankun 多了元素隔离性能、插件零碎，且应用了类web component的思路升高子利用的接入老本。但基于 microapp 对 Proxy目前不思考兼容，且社区活跃度上，qiankun 更胜一筹，工期短须要有肯定的保障，所以最初选了qiankun

参考资料：

https://github.com/micro-zoe/...
https://github.com/efoxTeam/e...
https://juejin.cn/post/684668...
https://github.com/efoxTeam/e...