深入解析无界微前端框架的运行模式
wujie 极致的微前端框架 项目地址: https://gitcode.com/gh_mirrors/wu/wujie
无界微前端框架运行模式概述
无界微前端框架作为一款优秀的微前端解决方案,其核心设计理念之一就是为子应用提供了多种运行模式,以满足不同业务场景的需求。在传统微前端架构中,子应用通常随着主应用页面的切换而反复激活和销毁,而无界框架通过创新的运行模式设计,为开发者提供了更灵活的选择。
三种运行模式详解
1. 保活模式(Keep-Alive Mode)
保活模式是无界框架中一种特殊的运行状态,当子应用的alive
属性设置为true
时即进入此模式。该模式最大的特点是能够保持子应用的状态不丢失。
技术实现原理:
- 子应用仅进行首次渲染
- 页面切换时,承载子应用DOM的WebComponent会被保留在内存中
- 子应用重新激活时,无界框架会将内存中的WebComponent重新挂载到容器上
适用场景:
- 需要保持子应用状态的页面
- 频繁切换但需要保持数据一致性的场景
- 对性能要求较高的应用
注意事项:
- 保活模式下改变URL不会影响子应用路由,需要通过通信机制进行路由跳转
- 保活的子应用实例不会销毁,即使被切走也能响应总线事件
2. 单例模式(Singleton Mode)
当子应用的alive
为false
且进行了生命周期改造时,无界框架会进入单例模式。这是一种平衡了资源占用和状态管理的运行方式。
技术实现原理:
- 子应用切走时调用
window.__WUJIE_UNMOUNT
销毁当前实例 - 子应用切回时调用
window.__WUJIE_MOUNT
创建新实例 - 支持多菜单共享同一个wujie实例
核心特点:
- 路由变化会触发子应用跳转
- 可以实现实例共享,减少资源消耗
- 适合需要路由同步但不需要长期保活的场景
最佳实践: 当主应用有多个菜单使用子应用的不同页面时,为这些页面设置相同的name
属性,可以实现wujie实例和iframe的共享,同时保持路由独立性。
3. 重建模式(Recreate Mode)
当子应用既未设置保活模式,也未进行生命周期改造时,无界框架会采用最彻底的重建模式。
技术实现原理:
- 每次页面切换都会销毁WebComponent和iframe
- wujie实例和子应用实例都会被完全销毁
- 重新加载时会创建全新的实例
模式特点:
- 资源占用最少,但性能开销最大
- 每次都是全新的开始,不会保留任何状态
- URL变化会触发路由跳转,但在路由同步场景下可能受限
适用场景:
- 对状态保持无要求的简单页面
- 安全性要求极高的场景(每次都是全新环境)
- 极少切换的子应用页面
模式选择指南
在实际项目中,开发者应根据具体需求选择合适的运行模式:
- 需要保持复杂状态 → 选择保活模式
- 需要路由同步但可以接受部分状态重置 → 选择单例模式
- 对状态无要求且注重资源释放 → 选择重建模式
性能与资源考量
不同模式在性能和资源占用上有着显著差异:
- 内存占用:保活模式 > 单例模式 > 重建模式
- 切换性能:保活模式 > 单例模式 > 重建模式
- 初始化开销:重建模式 > 单例模式 > 保活模式
总结
无界微前端框架通过这三种运行模式的精细设计,为开发者提供了从极致性能到极致安全的多种选择。理解这些模式的底层原理和适用场景,能够帮助我们在实际项目中做出更合理的技术决策,构建出既高效又稳定的微前端架构。
wujie 极致的微前端框架 项目地址: https://gitcode.com/gh_mirrors/wu/wujie
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考