微前端:乾坤 VS 无界

1,442 阅读3分钟

共同点: 当路由切换的时候,可以去加载对应应用的代码,让其跑在容器里。

  • 具备加载和卸载子应用的能力,页面从一个子应用切换到另一个子应用时,能正常进行加载和渲染;
  • 具有路由状态保持能力,激活子应用后,浏览器刷新、前进、后退子应用的路由都可以正常工作;
  • 主应用和子应用、子应用和子应用之间可以相互进行通信
  • 每个微应用都可独立仓库管理,独立技术栈开发、独立部署、独立运行

差异点: 容器实现方案不同,乾坤是基于single-spa方案,使用function + proxy + with实现,无界是基于WebComponent + iframe来实现。

1、应用加载机制

框架特点
乾坤首先基于single-spa注册子应用,然后通过import-html-entry获取子应用的相关资源并对这些资源进行加工,随后构造和执行一些生命周期中需要执行的方法,并返回一个函数,该函数的返回值是一个包括了子应用生命周期方法的对象
无界无需注册,直接将子应用注入主应用同域的iframe中运行

2、沙箱隔离机制

框架特点
乾坤js隔离机制: SnapshotSandboxLegacySandboxProxySandbox
css隔离机制:strictStyleIsolationexperimentalStyleIsolation
无界js通过iframe来隔离,css通过webcomponent + shadowdom来隔离

3、路由保持机制

框架特点
乾坤通过props实现全局路由数据的存储及共享
无界浏览器的前进后退可以不作任何处理直接作用于子应用,通过监听iframe的路由变化可以将子应用的url同步到主应用

4、应用通信机制

框架特点
乾坤通过发布订阅模式来实现通信,状态和回调处理函数全局统一维护,全局状态发生变化时触发各个应用注册的回调函数执行,将新旧状态传递到所有应用
无界提供多种通信方式:window.parent直接通信props数据注入去中心化EventBus通信机制

5、优点和不足

框架优点不足
乾坤能监听路由自动加载和卸载当前路由对应的子应用;
具有完备沙箱方案来隔离js和css;
支持静态资源预加载;
应用间通信简单;
基于路由匹配,无法同时激活多个子应用,也不支持子应用保活;
改造成本较大,从 webpack、代码、路由等都要做一系列的适配;
css 沙箱无法绝对的隔离,js 沙箱在某些场景下执行性能下降严重;
无法支持 vite 等 ES Module 脚本运行;
无界具备qiankun的所有优点,另外还具有以下优点:
主应用使用成本及子应用适配成本低;
css沙箱和js沙箱都采用了原生隔离,无需担心污染问题;
支持路由保活和共享依赖;
具有强大插件系统,方便在运行时修改子应用代码;
目前还比较新, 社区不够活跃