基於全屏iframe的微前端框架--擎天，解決了iframe UI不同步、URL不同步、數據不共用的難題，並充分發揮了iframe作為頁面容器的優勢，實現了父子應用非同步載入、子應用瞬間切換的能力，從而將微前端項目達到單體應用的體驗。 ...

vivo 互聯網前端團隊- Jiang Zuohan

一、背景

VAPD是一款專為團隊協作辦公場景設計的項目管理工具，實踐敏捷開發與持續交付，以「項目」為核心，融合需求、任務、缺陷等應用，使用敏捷迭代、小步快跑的方式進行開發及質量跟蹤，簡化工作流程，幫助團隊快速迭代並高效完成產品開發交付。

但早期VAPD以“一切皆可配置”的設計理念開發運行了兩年，整個前端代碼複雜混亂，組件龐大（需要支持多種配置），狀態混亂，前端代碼打包出來有50M之巨。這個項目難以為繼，bug多、維護困難、新增功能處處受限，總之產品不滿意、測試不滿意、用戶不滿意。

因此改版是必然的選擇，而改版的要求就是不能耽誤用戶繼續使用，必須保證網站可用、逐步更新，因此微前端是必然的選擇。

VAPD改版思路就是：

使用微前端框架，未改版部分作為子應用存在，繼續為用戶服務；
將項目模塊制定系統應用，並逐個改版，降低項目複雜度；
逐步捨棄舊項目代碼，將功能轉移到新項目中，提升項目整體性能，提高代碼可維護性。

二、什麼是微前端

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. —— Micro Frontends.

微前端是一種多個團隊通過獨立發佈功能的方式來共同構建現代化 web 應用的技術手段及方法策略。

微前端將微服務的理念應用於瀏覽器端，即將單頁面前端應用由單一的單體應用轉變為把多個小型前端應用聚合為一的應用，各個前端應用獨立開發、獨立部署。

微前端架構旨在解決單體應用在一個相對長的時間跨度下，由於參與的人員、團隊的增多、變遷，從一個普通應用演變成一個巨石應用(Frontend Monolith)後，隨之而來的應用不可維護的問題。這類問題在企業級 Web 應用中尤其常見。

現行最出名的微前端是阿裡的qiankun，qiankun 是一個基於 single-spa 的微前端實現庫，旨在幫助大家能更簡單、無痛的構建一個生產可用微前端架構系統。

但我嘗試試用qiankun後發現qiankun 的npm包常常滯後於qiankun源碼，有些issue解決了但還要等待其發版；首次載入子應用頁面出現抖動；子應用更新後報 ChunkLoadError 問題。

同時它存在微前端框架常有的性能問題及衝突問題：

1、載入慢

基本上所有的微前端框架都需要先載入父框架，再載入子應用，都要經歷如下圖的流程。整個流程是串列的，相同流程需要走兩遍，也就比普通的非微前端框架要慢1倍左右，直接影響了用戶體驗。

2、切換慢，每次切換都要重新走一次流程

微前端框架中不同子應用切換，需要銷毀當前子應用，然後載入其他子應用。子應用又需要進行“下載html --> 下載javascript文件 --> 運行javascript代碼 --> 請求服務端數據 --> 頁面展示"整個流程，導致微前端框架切換應用卡頓不流暢。

3、容易出現樣式衝突，不同子應用容易影響

傳統微前端框架中所有子應用都在同一上下文中，如出現全局樣式、全局監聽、全局變數，便會對其他子應用有影響，容易出現樣式衝突，記憶體泄漏，或者不可預知的bug。

三、Why Not Iframe

iframe 最大的特性就是提供了瀏覽器原生的硬隔離方案，不論是樣式隔離、JS隔離這類問題統統都能被完美解決。

那為啥不使用iframe呢？

qiankun 團隊也給出了原因：看這裡 Why Not Iframe。

總結起來就是：

url 不同步。瀏覽器刷新 iframe url 狀態丟失、後退前進按鈕無法使用。
UI 不同步，DOM 結構不共用。想象一下屏幕右下角 1/4 的 iframe 里來一個帶遮罩層的彈框，同時我們要求這個彈框要瀏覽器居中顯示，還要瀏覽器 resize 時自動居中..
全局上下文完全隔離，記憶體變數不共用。iframe 內外系統的通信、數據同步等需求，主應用的 cookie 要透傳到根功能變數名稱都不同的子應用中實現免登效果。
慢。每次子應用進入都是一次瀏覽器上下文重建、資源重新載入的過程。

其中有的問題比較好解決(問題1)，有的問題我們可以睜一隻眼閉一隻眼(問題4)，但有的問題我們則很難解決(問題3)甚至無法解決(問題2)，而這些無法解決的問題恰恰又會給產品帶來非常嚴重的體驗問題，最終導致我們捨棄了 iframe 方案。

四、擎天框架設計

4.1 設計理論

基於以上微前端缺陷，設計新型的微前端框架需要滿足以下要求：

快 —— 頁面載入速度、應用切換速度是前端極致的追求，用戶操作的響應速度永遠是第一體驗。
完全隔離 —— 不同子應用完全隔離，只在子應用項目初始化時設置一次，之後不需要在後續開發中及後期維護中考慮，降低開發的心智負擔。

4.2 架構設計

擎天框架架構分為三層，分別是用戶入口（瀏覽器地址欄），主應用層以及子應用集合層。

（1）瀏覽器（地址欄）是用戶入口，用戶通過輸入URL進入該系統，同時瀏覽器地址欄URL根據應用頁面進行變化，方便用戶複製分享二次進入。

（2）主應用是擎天框架的關鍵部分，主要是由以下兩部分組成：

路由引擎：實現瀏覽器地址欄與子應用展示隱藏的協調控制，用來控制用戶第一次進入展示某個應用，當用戶切換頁面時需同步瀏覽器地址欄（方便用戶複製，再次進入同一頁面），並根據頁面URL展示隱藏子應用。
數據共用引擎：實現子應用間的數據共用，保證各個應用間數據統一，如登錄信息，用戶信息等。用戶在某個應用修改共用數據後，會同步到數據共用引擎，再分發給其他應用，從而保證共用數據一致。

（3）子應用集合層

該層為系統提前設置好的子應用集合，子應用由全屏iframe載入，同一時刻僅有一個子應用處於可視狀態，其他子應用隱藏。當需要應用切換時，隱藏當前應用，顯示需要展示的應用，瞬間切換。

子應用響應擎天的路由引擎及數據共用引擎，做到實時的路由同步與數據同步，保證整個微前端項目路由及數據統一。