基于 iframe 的微前端框架 —— 擎天
vivo 互聯(lián)網(wǎng)前端團(tuán)隊(duì)- Jiang Zuohan
一、背景
VAPD是一款專為團(tuán)隊(duì)協(xié)作辦公場(chǎng)景設(shè)計(jì)的項(xiàng)目管理工具，實(shí)踐敏捷開(kāi)發(fā)與持續(xù)交付，以「項(xiàng)目」為核心，融合需求、任務(wù)、缺陷等應(yīng)用，使用敏捷迭代、小步快跑的方式進(jìn)行開(kāi)發(fā)及質(zhì)量跟蹤，簡(jiǎn)化工作流程，幫助團(tuán)隊(duì)快速迭代并高效完成產(chǎn)品開(kāi)發(fā)交付。
但早期VAPD以“一切皆可配置”的設(shè)計(jì)理念開(kāi)發(fā)運(yùn)行了兩年，整個(gè)前端代碼復(fù)雜混亂，組件龐大（需要支持多種配置），狀態(tài)混亂，前端代碼打包出來(lái)有50M之巨。這個(gè)項(xiàng)目難以為繼，bug多、維護(hù)困難、新增功能處處受限，總之產(chǎn)品不滿意、測(cè)試不滿意、用戶不滿意。
因此改版是必然的選擇，而改版的要求就是不能耽誤用戶繼續(xù)使用，必須保證網(wǎng)站可用、逐步更新，因此微前端是必然的選擇。
VAPD改版思路就是：
使用微前端框架，未改版部分作為子應(yīng)用存在，繼續(xù)為用戶服務(wù)；
將項(xiàng)目模塊制定系統(tǒng)應(yīng)用，并逐個(gè)改版，降低項(xiàng)目復(fù)雜度；
逐步舍棄舊項(xiàng)目代碼，將功能轉(zhuǎn)移到新項(xiàng)目中，提升項(xiàng)目整體性能，提高代碼可維護(hù)性。
二、什么是微前端
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. —— Micro Frontends.
微前端是一種多個(gè)團(tuán)隊(duì)通過(guò)獨(dú)立發(fā)布功能的方式來(lái)共同構(gòu)建現(xiàn)代化 web 應(yīng)用的技術(shù)手段及方法策略。
微前端將微服務(wù)的理念應(yīng)用于瀏覽器端，即將單頁(yè)面前端應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)榘讯鄠€(gè)小型前端應(yīng)用聚合為一的應(yīng)用，各個(gè)前端應(yīng)用獨(dú)立開(kāi)發(fā)、獨(dú)立部署。
微前端架構(gòu)旨在解決單體應(yīng)用在一個(gè)相對(duì)長(zhǎng)的時(shí)間跨度下，由于參與的人員、團(tuán)隊(duì)的增多、變遷，從一個(gè)普通應(yīng)用演變成一個(gè)巨石應(yīng)用(Frontend Monolith)后，隨之而來(lái)的應(yīng)用不可維護(hù)的問(wèn)題。這類問(wèn)題在企業(yè)級(jí) Web 應(yīng)用中尤其常見(jiàn)。
現(xiàn)行最出名的微前端是阿里的qiankun，qiankun 是一個(gè)基于 single-spa 的微前端實(shí)現(xiàn)庫(kù)，旨在幫助大家能更簡(jiǎn)單、無(wú)痛的構(gòu)建一個(gè)生產(chǎn)可用微前端架構(gòu)系統(tǒng)。
但我嘗試試用qiankun后發(fā)現(xiàn)qiankun 的npm包常常滯后于qiankun源碼，有些issue解決了但還要等待其發(fā)版；首次加載子應(yīng)用頁(yè)面出現(xiàn)抖動(dòng)；子應(yīng)用更新后報(bào) ChunkLoadError 問(wèn)題 。
同時(shí)它存在微前端框架常有的性能問(wèn)題及沖突問(wèn)題：
1、加載慢
基本上所有的微前端框架都需要先加載父框架，再加載子應(yīng)用，都要經(jīng)歷如下圖的流程。整個(gè)流程是串行的，相同流程需要走兩遍，也就比普通的非微前端框架要慢1倍左右，直接影響了用戶體驗(yàn)。
2、切換慢，每次切換都要重新走一次流程
微前端框架中不同子應(yīng)用切換，需要銷(xiāo)毀當(dāng)前子應(yīng)用，然后加載其他子應(yīng)用。子應(yīng)用又需要進(jìn)行“下載html --> 下載javascript文件 --> 運(yùn)行javascript代碼 --> 請(qǐng)求服務(wù)端數(shù)據(jù) --> 頁(yè)面展示"整個(gè)流程，導(dǎo)致微前端框架切換應(yīng)用卡頓不流暢。
3、容易出現(xiàn)樣式?jīng)_突，不同子應(yīng)用容易影響
傳統(tǒng)微前端框架中所有子應(yīng)用都在同一上下文中，如出現(xiàn)全局樣式、全局監(jiān)聽(tīng)、全局變量，便會(huì)對(duì)其他子應(yīng)用有影響，容易出現(xiàn)樣式?jīng)_突，內(nèi)存泄漏，或者不可預(yù)知的bug。
三、Why Not Iframe
iframe 最大的特性就是提供了瀏覽器原生的硬隔離方案，不論是樣式隔離、JS隔離這類問(wèn)題統(tǒng)統(tǒng)都能被完美解決。
那為啥不使用iframe呢？
qiankun 團(tuán)隊(duì)也給出了原因：看這里 Why Not Iframe。
總結(jié)起來(lái)就是：
url 不同步。瀏覽器刷新 iframe url 狀態(tài)丟失、后退前進(jìn)按鈕無(wú)法使用。
UI 不同步，DOM 結(jié)構(gòu)不共享。想象一下屏幕右下角 1/4 的 iframe 里來(lái)一個(gè)帶遮罩層的彈框，同時(shí)我們要求這個(gè)彈框要瀏覽器居中顯示，還要瀏覽器 resize 時(shí)自動(dòng)居中..
全局上下文完全隔離，內(nèi)存變量不共享。iframe 內(nèi)外系統(tǒng)的通信、數(shù)據(jù)同步等需求，主應(yīng)用的 cookie 要透?jìng)鞯礁蛎疾煌淖討?yīng)用中實(shí)現(xiàn)免登效果。
慢。每次子應(yīng)用進(jìn)入都是一次瀏覽器上下文重建、資源重新加載的過(guò)程。
其中有的問(wèn)題比較好解決(問(wèn)題1)，有的問(wèn)題我們可以睜一只眼閉一只眼(問(wèn)題4)，但有的問(wèn)題我們則很難解決(問(wèn)題3)甚至無(wú)法解決(問(wèn)題2)，而這些無(wú)法解決的問(wèn)題恰恰又會(huì)給產(chǎn)品帶來(lái)非常嚴(yán)重的體驗(yàn)問(wèn)題， 最終導(dǎo)致我們舍棄了 iframe 方案。
四、擎天框架設(shè)計(jì)
4.1 設(shè)計(jì)理論
基于以上微前端缺陷，設(shè)計(jì)新型的微前端框架需要滿足以下要求：
快 —— 頁(yè)面加載速度、應(yīng)用切換速度是前端極致的追求，用戶操作的響應(yīng)速度永遠(yuǎn)是第一體驗(yàn)。
完全隔離 —— 不同子應(yīng)用完全隔離，只在子應(yīng)用項(xiàng)目初始化時(shí)設(shè)置一次，之后不需要在后續(xù)開(kāi)發(fā)中及后期維護(hù)中考慮，降低開(kāi)發(fā)的心智負(fù)擔(dān)。
4.2 架構(gòu)設(shè)計(jì)
擎天框架架構(gòu)分為三層，分別是用戶入口（瀏覽器地址欄），主應(yīng)用層以及子應(yīng)用集合層。
（1）瀏覽器（地址欄）是用戶入口，用戶通過(guò)輸入U(xiǎn)RL進(jìn)入該系統(tǒng)，同時(shí)瀏覽器地址欄URL根據(jù)應(yīng)用頁(yè)面進(jìn)行變化，方便用戶復(fù)制分享二次進(jìn)入。
（2）主應(yīng)用是擎天框架的關(guān)鍵部分，主要是由以下兩部分組成：
路由引擎：實(shí)現(xiàn)瀏覽器地址欄與子應(yīng)用展示隱藏的協(xié)調(diào)控制，用來(lái)控制用戶第一次進(jìn)入展示某個(gè)應(yīng)用，當(dāng)用戶切換頁(yè)面時(shí)需同步瀏覽器地址欄（方便用戶復(fù)制，再次進(jìn)入同一頁(yè)面），并根據(jù)頁(yè)面URL展示隱藏子應(yīng)用。
數(shù)據(jù)共享引擎：實(shí)現(xiàn)子應(yīng)用間的數(shù)據(jù)共享，保證各個(gè)應(yīng)用間數(shù)據(jù)統(tǒng)一，如登錄信息，用戶信息等。用戶在某個(gè)應(yīng)用修改共享數(shù)據(jù)后，會(huì)同步到數(shù)據(jù)共享引擎，再分發(fā)給其他應(yīng)用，從而保證共享數(shù)據(jù)一致。
（3）子應(yīng)用集合層
該層為系統(tǒng)提前設(shè)置好的子應(yīng)用集合，子應(yīng)用由全屏iframe加載，同一時(shí)刻僅有一個(gè)子應(yīng)用處于可視狀態(tài)，其他子應(yīng)用隱藏。當(dāng)需要應(yīng)用切換時(shí)，隱藏當(dāng)前應(yīng)用，顯示需要展示的應(yīng)用，瞬間切換。
子應(yīng)用響應(yīng)擎天的路由引擎及數(shù)據(jù)共享引擎，做到實(shí)時(shí)的路由同步與數(shù)據(jù)同步，保證整個(gè)微前端項(xiàng)目路由及數(shù)據(jù)統(tǒng)一。
五、擎天框架實(shí)現(xiàn)
擎天框架突破了 iframe UI不同步、URL不同步、數(shù)據(jù)不共享以及加載慢等問(wèn)題，并將iframe作為頁(yè)面容器存在，在實(shí)現(xiàn)硬隔離的同時(shí)做到了子應(yīng)用瞬間切換，解決了微前端框架一直以來(lái)的通病，從而實(shí)現(xiàn)單應(yīng)用級(jí)別的操作體驗(yàn)。
5.1全屏iframe、共同組件
解決問(wèn)題：UI 不同步
全屏iframe是指整個(gè)瀏覽器窗口全部給子應(yīng)用iframe，子應(yīng)用接管瀏覽器所有功能，無(wú)論是全局拖動(dòng)、全部蒙層、resizie等，由此UI不同步的問(wèn)題便不存在了。
但不同應(yīng)用有個(gè)相同的公用部分，因此需要把公共部分做成統(tǒng)一組件，發(fā)到npm包中，在每一個(gè)應(yīng)用中引入就行。
5.2 父子應(yīng)用異步加載
解決問(wèn)題：加載慢
在前端靜態(tài)頁(yè)面中預(yù)留子應(yīng)用dom節(jié)點(diǎn)，如下圖 所示，每一個(gè)div有唯一id，代表一個(gè)預(yù)制子應(yīng)用。同時(shí)該id對(duì)應(yīng)子應(yīng)用路由pathname，如New對(duì)應(yīng)/New/*路由，即以New開(kāi)頭的路由全部對(duì)應(yīng)id為"New"的子應(yīng)用。
當(dāng)用戶進(jìn)入頁(yè)面后，父框架拿到瀏覽器url，并獲取到pathname，從而知道需要首先加載那個(gè)子應(yīng)用。并且直接創(chuàng)建iframe，并直接掛到對(duì)應(yīng)的dom節(jié)點(diǎn)中，父應(yīng)用和子應(yīng)用異步加載。
加載完首個(gè)子應(yīng)用后，開(kāi)始加載其他子應(yīng)用，并使用display: none將它們隱藏到頁(yè)面dom結(jié)構(gòu)中。最終dom節(jié)點(diǎn)如下圖所示。
5.3 子應(yīng)用iframe瞬間切換
解決問(wèn)題：子應(yīng)用切換卡頓
用戶進(jìn)行多個(gè)子應(yīng)用切換時(shí)，擎天框架監(jiān)聽(tīng)瀏覽器url地址，如pathname從/New/*變成/Web/*，則將/New/*對(duì)應(yīng)的子應(yīng)用iframe隱藏起來(lái)，將/Web/對(duì)應(yīng)的子應(yīng)用iframe顯示出來(lái)，實(shí)現(xiàn)應(yīng)用的瞬間切換。
用戶可視范圍內(nèi)只能看一個(gè)應(yīng)用，切換時(shí)僅僅是將New應(yīng)用隱藏不可見(jiàn)，Web應(yīng)用頁(yè)面可見(jiàn)。
5.4 路由引擎，同步切換
解決方案：URL不同步
受vue2中數(shù)組方法（如push、shift）響應(yīng)式處理的啟發(fā)，擎天對(duì)前端路由框架進(jìn)行特殊處理，重寫(xiě)了vue-router的push、replace等方法，當(dāng)監(jiān)聽(tīng)到子應(yīng)用使用以上方法進(jìn)行路由切換時(shí)，會(huì)同步到父框架進(jìn)行操作。
父子應(yīng)用簡(jiǎn)單配置后，父子路由同步便做好了。路由切換分為單應(yīng)用以及多應(yīng)用間路由切換。
（1）單應(yīng)用路由切換
單應(yīng)用子iframe路由切換，如/New/b 切換到/New/c，其pathname結(jié)構(gòu)一致，是單應(yīng)用的路由切換。子應(yīng)用先切換路由，隨后發(fā)送syncRoute給父框架，父框架使用replace方法改變?yōu)g覽器地址欄即可，具體流程如下圖所示。
（2）多應(yīng)用間路由切換
如/New/b 切換到/Web/c，其pathname結(jié)構(gòu)不一致。子應(yīng)用先切換路由，隨后發(fā)送syncRoute消息給父框架，父框架使用replace方法改變?yōu)g覽器地址欄，同時(shí)將應(yīng)用A隱藏起來(lái)，并發(fā)送消息到子應(yīng)用B中。子應(yīng)用B獲得消息后修改其本身路由。
5.5 數(shù)據(jù)共享
解決問(wèn)題：內(nèi)存變量不共享
父應(yīng)用將需要共享的數(shù)據(jù)放到store中，并使用syncStore進(jìn)行注冊(cè)。
子應(yīng)用通過(guò)類vuex似的 mapGlobalState 方法可以獲取父應(yīng)用store中數(shù)據(jù)，同時(shí)該數(shù)據(jù)為響應(yīng)式，數(shù)據(jù)變更可觸發(fā)UI重新渲染。
通過(guò)mapGlobalMutations獲取修改數(shù)據(jù)的方法，通過(guò)該方法可以修改父應(yīng)用store數(shù)據(jù)，修改成功后擎天共享數(shù)據(jù)引擎將修改好的數(shù)據(jù)分發(fā)給各個(gè)子應(yīng)用，保證共享數(shù)據(jù)一致。
其內(nèi)部邏輯是：
父應(yīng)用將需要共享的數(shù)據(jù)放到store中，并暴露getTopStore（獲取store數(shù)據(jù)）、syncTopMutation(更新store數(shù)據(jù))、syncTopStore(分發(fā)store數(shù)據(jù))等接口。
系統(tǒng)加載時(shí)子應(yīng)用通過(guò)getTopStore方法可以獲取store中數(shù)據(jù)，并賦值到子應(yīng)用$pstore中，從而獲得數(shù)據(jù)響應(yīng)式等能力。
當(dāng)某個(gè)子應(yīng)用需要修改共享數(shù)據(jù)時(shí)，調(diào)用syncTopMutation方法進(jìn)行修改，修改成功后擎天通過(guò)syncTopStore分發(fā)給各個(gè)子應(yīng)用，保證共享數(shù)據(jù)一致。
六、總結(jié)
擎天基于全屏Iframe與搭建公共組件等方式，解決了iframe UI不同步的難題，并充分發(fā)揮了iframe作為頁(yè)面容器的優(yōu)勢(shì)，實(shí)現(xiàn)了父子應(yīng)用異步加載、子應(yīng)用瞬間切換的能力，從而達(dá)到單應(yīng)用項(xiàng)目的體驗(yàn)。
往期推薦
最后
歡迎加我微信，拉你進(jìn)技術(shù)群，長(zhǎng)期交流學(xué)習(xí)...
歡迎關(guān)注「前端Q」,認(rèn)真學(xué)前端，做個(gè)專業(yè)的技術(shù)人...
