你應該知道的前端趨勢——前端技術浪潮與應用

  本次主要會從前端基建和前端新方向與你們一塊兒聊聊當下前端那些事兒。

前端基建

  首先聊一下前端傳統方向，也就是咱們常說的前端基建。什麼是基建？一切有利於研發效能提高的、直接或者間接助力於業務開展的能力建設皆爲基建。

  基建涉及的話題不少，好比組件庫、規範、打包等等。本次，我會從這四方面來聊一聊前端基建行業現狀、應用領域、行業內解決方案（行業已有輪子）。廢話很少說，先來看看前端可視化。

01.前端可視化

  前端可視化可分爲兩大類，即頁面可視化搭建和數據可視化：

• 頁面可視化也就是WebIDE；
• 數據可視化，顧名思義對數據進行可視化展現，給人看。

01-1.頁面可視化搭建

  前端行業提效分析，主要分爲四大類：

• pro code
• low code
• no code
• auto code

  能夠從下圖看看這幾種方式的流程差異。基於這樣一個提效分析，我完成了業界對頁面可視化提效所作的輪子的調研，大概調研了22+個輪子，都有哪些呢？請看上回分解：前端可視化搭建工具業界的輪子。

①頁面可視化背景-前端行業提效分析

②業界-前端行業提效輪子

  上圖可能不夠清晰，具體能夠參考：前端可視化搭建工具業界的輪子。

③背景-提效輪子總結概括

  這些可能你們都比較熟悉了，調研了這麼多也有比較新穎的想法和解決方案，好比淘寶的imgcook，站在更前沿去解決低效問題，下面來介紹下業界比較前沿的一個可視化搭建工具imgcook，是如何上了智能化的班車來作前端的提效工具的。

④智能化相關行業提效分析

  在看這個imgcook以前咱們先來看看下面幾張圖片。

  上面這兩張圖是智能化的工業4.0的演進、組成和支撐；下面兩張圖展現的是智能工業話的真實案例和收益；可見智能化對這些行業的影響是很是大的；彙總來看，各個行業智能化以後，會提效降本，某類人員會減小，某類人員會轉型升級，並帶來質量的提高或業務增量。

  因此類比到前端行業，智能化幾年以後，總體會大大提效，一部分簡單重複性工做會被智能化所取代，也可能會誕生一些新的職位，如業務邏輯配置師（和代碼生成機器人協做）之類的，前端升級作更有挑戰性的工做內容。因此若是可以智能化一鍵生成代碼，確定也會給前端帶來巨大的收益。

簡單分析：

  圖1.圖2.好比近幾年提出的以智能化爲背景的工業 4.0，工業 4.0 的核心策略抓手大概有製造過程智能化、可視化、標準化管理協做、跨領域上下有集成整合，以達到高效生產；類比到前端行業同樣，依賴的底層設施正在雲化並逐步標準化（數據標準化、服務標準化等）、前端工程化成熟、跨 PD /設計師/服務端的協做研發一體化、業務個性化定製、生產可視化、智能化，這些策略在前端行業也都存在。

  圖3.再來看智能化帶來的成果，其領頭羊項目廈門遠海全自動化智能碼頭，一線人員減小 70%，效率提高 20%；

  圖4.被譽爲行業之母的金融行業，其典型的智能銀行網點，其操做類櫃檯人員佔比降低 15%；操做類櫃檯人員轉型後的複合型人才提高至 90%；新增超級櫃檯機、自助購匯機、虛擬櫃員機以後，減網點面積、減櫃員，進一步減小成本。

⑤舉例可視化搭建其中的一個例子來看前端可視化——imgcook

  可視化搭建工具業界太多了，只拿一個我以爲站在智能化這個前沿技術基礎上比較新奇且有創意的來詳細說說，你們看看下圖，看看這個可視化搭建新在哪兒？

  imgcook的目標：就是從（設計稿、原型稿、PRD、APIHub、CodeHub 等資源）經過智能化的手段直接生成代碼。

  imgcook的核心功能：imgcook 目前對外的核心功能是 從設計稿 經過 CV/NLP 等深度學習、傳統機器學習、專家規則系統、算法工程 等綜合手段直接生成代碼。

  下面介紹一下產品運行流程，你們能夠對照圖片閱讀後文講解：

  具體來看看目前的產品使用流程，導入設計稿後能夠一鍵生成代碼，能夠所見所得地在可視化編輯器中進行干預編輯，而後能夠生成各類 DSL（React/Vue/Rax/小程序DSL等） 的代碼，而後代碼能夠經過 VS Code 插件、imgcook-cli 等直接引入到本身的項目工程中，每一個團隊項目可能有本身的工程目錄規範，經過 Plugin 擴展也支持自定義，imgcook 的團隊高級自定義能力支持各個維度的自定義能力，以知足不一樣場景的生成代碼需求。

• 步驟一：導入設計稿
• 步驟二：可視化干預
• 步驟三：查看生成代碼（可選）
• 步驟四：進工程鏈路（vs code 插件直接導入）
• 可選步驟：團隊高級自定義（Plugin設置）

  從下到上分別是：

• ①基於算法工程框架和產品；
• ②基於視覺稿 CV 分析 和 NLP 分析；
• ③多維度識別要生成代碼的要素；
• ④識別後可視化呈現出來；
• ⑤若是識別出錯就進行可視化干預，並可視化補充額外邏輯；
• ⑥（左一）而後應用集成到各自的工程鏈路（VSCode 插件、WebIDE插件、imgcook-cli）中；
• ⑦（右一）生成的代碼也支持自定義，最經常使用的是 DSL（React/vue/小程序 DSL…）和 Plugin（不一樣的團隊有不一樣的目錄規範等）自定義；
• ⑧（右二）同時整個技術體系咱們最關注的的是技術方面的度量指標，如代碼真實可用率、模型準確度和提效數據等。

  下面來介紹下核心技術難點：

  咱們來看看這張技術大圖裏面，實現複雜度比較高的部分：智能識別表達拆解，從直觀上分析，爲了生成表達所需代碼，須要多維度的信息輸入和提取，須要各類詳盡的元信息（圖像、文本、樣式、屬性等），同時須要提取出不一樣顆粒度的可複用的單元（物料），以及抽取背後的動態邏輯（動態字段、循環、交互邏輯等）。

  首先是這裏智能識別表達的拆解問題，直接端到端業界可用解決方案目前尚未，業界也有相似 pix2code，screenshot2code 的方案，一個是顆粒度太大，適合解決組件識別的問題，一個是可用度不高，尤爲對於 C 端的視覺稿還原度，C 端設計師是不接受像素級誤差的。

  具體咱們來看看怎麼拆解成可解的問題，從直觀上分析，爲了生成表達所須要代碼，須要多維度的信息輸入和提取，須要各類詳盡的元信息（圖像、文本、樣式、屬性等），同時須要提取出不一樣顆粒度的可複用的單元（物料），以及抽取背後的動態邏輯（動態字段、循環、交互邏輯等）。

  首先從上到下，先將設計稿中輸入，進行圖層信息處理，各層具體以下：

• 圖層處理層：主要將設計稿或者圖像中圖層進行分離處理，並結合上一層的識別結果，整理好圖層元信息。
• 物料識別層：主要經過圖像識別能力識別圖像中的物料（模塊識別、原子模塊識別、基礎組件識別、業務組件識別）。
• 圖層再加工層：對圖層處理層的圖層數據作進一步的規範化處理。
• 佈局算法層：轉換二維中的絕對定位圖層佈局爲相對定位和 Flex 佈局。
• 語義化層：經過圖層的多維特徵對圖層在生成代碼端作語義化表達。
• 字段綁定層：對圖層裏的靜態數據結合數據接口作接口動態數據字段綁定映射。
• 業務邏輯層：對已配置的業務邏輯經過業務邏輯識別和表達器來生成業務邏輯代碼協議。
• 可視化編排：最後輸出通過各層智能化處理好的代碼協議，用可視化引擎所見所得呈現處理，能夠進行可視化干預和補充。
• 出碼引擎層：最後通過人工干預後的更準確的協議內部，通過表達能力（協議轉代碼的引擎）輸出各類 DSL 代碼。
• 工程鏈路層：最後經過 vs code 插件、webIDE 插件， 輸出各個工程項目環境中。

01-2.數據可視化

①數據可視化-行業現狀

  這張圖是2020年技術和市場大圖：這個圖上分了不少模塊你們可能看不太清楚，我給你們理一下，他會主要分紅這麼多組：

• 前三個我標出來的：圖數據庫（底層存儲）、圖計算引擎（中間層裁剪加工）、圖可視化（圖分析），這三個其實是整個圖技術的核心技術；
• 下面這四個恰好是圖技術所表明的應用領域：好比知識圖譜領域其實已經有不少商業化的產品出來了，還有像反欺詐、社交網絡分析、還有網絡安全等等，這四個在這個大圖裏面有了應用很是普遍的領域。

  那麼基於這樣一個領域咱們聊聊下一話題，數據可視化應用領域-核心技術流程和挑戰。

②應用領域：核心技術流程與挑戰

• ①數據可視化咱們有哪些落地場景：除了前四個是圖中已經有的，還有監管合規、我的安全守護，除了這些業務其實不少公司也有不少成熟的產品，基於這樣一個應用領域的核心流程：數據存儲、數據處理、最後到可視化展現和應用；
• ②基於這樣的領域，咱們發現其實核心流程都是同樣的。剛提到那三種：數據獲取、結構化裝載、最後到一個存儲、存儲完咱們還會對數據進行一個裝載分析最後會到達一個可視化展現和應用的階段；

• ③那在這個裏面前端同窗就會遇到很大的挑戰：從一個圖的caseStudy怎麼到圖的可視化？這裏面一共有三個痛點問題：

  • 1、可看：圖數據巨大如何很好可視化出來；
  • 2、可理解：有了數據如何去理解；
  • 3、可分析：理解以後如何分析洞察。

  咱們把剛纔說的形象化一點，舉個例子：好比這是一個100個節點圖數據，傳統去看會很是麻煩，若是簡單經過圖可視化技術，就會發現是很是容易的。

③應用領域：理想的圖可視化能力大圖

  這就是剛纔提到的可視化前端的三個難點詳情：可看、可理解、可分析。

  實際上就是把節點和邊怎麼快速渲染出來，除了常規的數據關係以外，咱們還會有一些時序數據、位置好比地圖位置信息還有海量的數據都須要一整套的引擎去作，包闊對節點、樣式等的規範。

④AntV螞蟻金服-可視化解決方案

  針對可視化的一個介紹，其實阿里有一整套關於數據可視化的解決方案：AntV螞蟻金服-可視化解決方案。

  G2/G6/F2/L7分別處理不一樣的數據來解決不一樣的數據可視化問題，好比對統計圖表的技術選型，可以使用 G2 棧，關於怎麼技術選型及細節差異你們能夠本身看官網，這裏就不一一介紹了。

⑤數據可視化-業界解決方案及輪子總結

  來看看除了阿里業界還有哪些數據可視化的產品。

  其中菜鳥的數字空間用到了2020年新興技術趨勢圖 Gartner中提到的數字孿生，這個是業界比較前沿的探索了。

  數字孿生是什麼呢？數字孿生是充分利用物理模型、傳感器更新、運行歷史等數據，集成多學科、多物理量、多尺度、多機率的仿真過程，在虛擬空間中完成映射，從而反映相對應的實體裝備的全生命週期過程。數字孿生是一種超越現實的概念，能夠被視爲一個或多個重要的、彼此依賴的裝備系統的數字映射系統。

02.前端跨端跨棧

  提到物聯網，你們可能首先會想到各類各樣的設備，咱們的跨端場景就是須要跑在各類各樣的設備上。

①前端跨端跨棧-場景

  跨端開發方案：主要解決技術棧碎片的問題；而剛纔提到的可視化搭建：主要解決平碎片功能以及UI碎片的問題。二者結合能夠更加降本提效。

②前端跨端跨站-跨端特色

  跨端跨棧的特色：咱們應用特色就是強交互、功能種類多、設備多的特色，它的業務場景是不同的，咱們在不一樣設備領域去作技術沉澱週期比較長，因此咱們須要對咱們的應用，從一個比較長的時間線去看咱們應用的發展。

  跨端跨棧優勢：一套代碼多端複用、更高效的發佈流程、平臺一致性。儘管有上述各類優勢，但它也毫不是一點缺點沒有，它的主要缺點包括性能可能較低及略差的用戶體驗和用戶界面等。

③前端跨端跨站-跨端方案思考

  如何實現跨端的最大化複用？

  當咱們要開發的應用，它的生命週期比較長的時候，嘗過一些技術棧迭代的時候，咱們就要考慮怎麼使咱們的應用可以跟隨技術棧的升級去不斷的更新咱們的技術棧，而不是綁死在一個框架上。對應用進行技術職責維度的橫向拆解，拆解完根據每一塊的技術特色進行不一樣的跨端處理。

④前端跨端跨站-跨端方案

  如何擺脫歷史包袱，對跨端方案進行持續升級？

  這張圖簡單展現了對模塊管理的簡單示意，咱們開發了一個模塊管理的系統，去管理咱們源代碼，編譯出來各個平臺上的代碼的模塊。跨端跨站大體思路大概是如上圖這樣。

⑤前端跨端跨棧-業界框架

  那業界基於上面提到的跨端跨棧有那些優秀的框架呢，你們能夠看一下。

  跨端開發⽅⾯，RN ⽣態已經⾮常成熟，或者說看不到太多發展前景，由於目前還停留在0.61版本，彷佛1.0版本仍然遙遙無期。所以，今年不少團隊轉戰⾕歌⽣態的 Flutter，特別是 Flutter for Web 的第⼀個 Release，⼜讓 Web 前端重燃但願、躍躍欲試。

  同時，蘋果公司也發佈了全新的 UI 系統——SwiftUI；開源社區中 SwiftUI for Web也已經在路上了，SwiftUI for Android 還會遠嗎？

  下面我拿其中的一個Taro來作一個簡單介紹。

⑥前端跨端跨站Demo

Taro的架構

  Taro 是一款開源的多端統一開發框架，它讓咱們只編寫一份代碼，就可讓這份程序運行在各個小程序端、H5端、RN端，在開源兩年多以來收穫了業界的不少關注，而後如今在 github 上面的 Star 數有 25,000 +，同時業界也有很是多的團隊正在使用 Taro 框架進行開發。

  首先來看一下目前 Taro 的總體架構，它分爲兩個部分，第一部分是編譯時，第二部分是運行時。

  編譯時會先對用戶的 React 代碼進行編譯，轉換成各個端上的小程序均可以運行的代碼，而後再在各個小程序端上面都配上一個對應的運行時框架進行適配，最終讓這份代碼運行在各個小程序端上面。

  可是這個架構也有一些問題：編譯時候JSX 支持程度不完美、不支持 source-map調試不方便、維護和迭代十分困難等小的問題，因而又有一個Taro Next出現了。

Taro Next架構

  這是Taro Next 的總體架構圖。編譯時候JSX 支持程度不完美、不支持 source-map調試不方便問題被Taro Next所有解決，這個Tara Next更強大、迅速、靈活一些。

⑦前端跨端跨站-其餘的架構

  附上uni-app和滴滴Chameleon的架構圖，你們本身有興趣能夠查資料看詳情原理。

⑧前端跨端跨站-總結

  上面總結了業界有這麼多跨端跨站的方案、技術選型那其實沒有最好的方案，只有最適合的方案，各有利弊，適合的纔是最好的。

03.微前端

  下面來看下前端傳統基建中的微前端。

  首先我會簡單介紹一下微前端的概念，所謂的微前端具體是一個什麼樣的概念，我以爲仍是有必要進行一個初步的瞭解。

①微前端-概念介紹

  微前端早在 2016 年 的一個技術論壇上提出，它實際上是脫胎於後端微服務的概念。之前單體 web 應用，通常一個團隊總體來負責，包括前端和後端的部分。

  隨着技術的發展，職責分工上更加針對領域進行細分後，一個項目的負責團隊會分化成前端團隊和後端團隊。這種場景下後端能力實際上是聚合在一塊兒的。

  而隨着微服務理念出現以後，後端會按功能維度對後端的一些能力進行拆分，而後在先後交互的時候中間層加設一層聚合層，好比graphQL 或者依賴一些 BFF 層去作數據的聚合，包括一些網關的處理。

  微前端做爲一個相似微服務的架構，它其實就是把微服務這樣的理念應用到了瀏覽器端，咱們把單體的一個前端 web 應用也去按功能維度進行拆分，而後再聚合到一個總體的應用架構下面，這即是微前端的理念。

  微前端是一種相似微服務的架構，它將微服務的概念應用於瀏覽器端。

  那什麼樣的場景上會須要這樣一套技術架構？主要的場景有兩個。

②微前端業務背景-業務困境

  第一個場景，工做臺的場景，基於產品體驗的緯度；第二個場景，大型單體應用，這種場景更側重於想從技術維度進行優化。

  工做臺場景，其實說的就是一些公司內部會存在不少的系統平臺，而平常運營流程中會涉及到跨系統的操做，那不一樣系統間會存在體驗交互不一致的問題、一些無謂的頁面跳轉也會致使的操做效率低下。並且，在多獨立系統無論是在 BFF 層 或一些中間網關處理層，仍是前端的一些基礎能力上，都會存在有不少的重複建設。多個系統相互獨立，大部分系統實際上是沒法管控到它具體的實現邏輯。

  第二個場景的話相對來講更常見一點，大型單體應用也就是就是咱們一般講的一些巨石應用。這類應用的特色很明顯的，它的系統體量是很是大的。好比單從 bundle 構建出來的文件大小來看的話，單文件可能都會超過 10M。這樣的構建量，在平常調試開發的時候便會嚴重影響開發體驗和效率。

  另外一個比較關鍵的問題是，當業務上須要進行功能迭代，或者說技術架構升級的時候，對一個巨石應用而言，它開發和協做的成本都很高。由於體量大直接致使改動帶來的影響面也很是的廣。

  最後一點，若是存在一些二方的需求和功能，想直接複用這塊能力的時候，基於目前的 SPA 的架構實際上是很難作到，基本上是須要往現有系統上再去實現一樣的代碼邏輯。

  綜合上面的兩種場景的問題，咱們就更但願可以有合適的技術架構，能協助業務去創建一套體驗良好且可持續維護的系統。

③微前端-業務背景-技術選型

  基於上述的一些訴求，擺在咱們面前的技術方案有哪些。

​
  簡單的歸納了一下，其實四種方式的各有優缺點。微前端方案核心解決的業務場景，更多的是在體驗和效率上找到一個平衡點。

• 巨石應用：隨着頁面增多，開發效率與穩定性沒法知足要求 🤕
• iframe：除了用戶體驗問題，實際上是個很不錯的方案 💀
• 框架組件：不知足一個系統的心智，同時長期維護成本高 💩
• 微前端：在大型系統的業務場景下，體驗和效率的平衡點 🚀

  基於上面的調研和對比，不少業務會最終決定去選擇微前端的技術方案，來對業務架構進行升級。

  上面是淘寶落地的一個微前端架構，比較有表明意義的場景。

  那微前端架構爲何能作到這樣集成多系統的能力？接下來我將介紹下微前端其中的一個方案 icestark 在架構設計上面的能力和思考。

④eg.icestark 架構設計

icestark-前端方案

  接下來咱們先看一下微前端的總體方案會包括哪些內容。下圖一張總體的微前端方案大圖，微前端 icestark 主要會根據路由變化對應用進行分發，包括應用生命週期管理、應用加載，通訊、隔離，還有沙箱運行。框架應用去接入微前端的時候不用關心微應用相關的處理，核心只須要完成微應用的配置。框架應用裏面處理微應用配置以外可能還會涉及到一些鑑權的邏輯或者應用埋點邏輯等業務上的實踐方案。

  下面會針對 icestark 架構提供的能力進行拆解。

icestark- 架構設計理念

  icestark 作爲一個微前端方案，它的架構設計秉承了四個理念。

• 第一點，技術棧無關，一個微應用接入的時候咱們並不關心它的技術棧是什麼樣的，不管是使用 React 仍是 Vue，或者 Angular，甚至說它是一個上古的代碼（jQuery），應用都可以被接入。但爲何在實踐上又推薦單一技術體系的技術棧統一呢？看上去是兩個相悖的概念，但實際上咱們的思考是，微前端可以經過技術棧無關的能力，將一些獨立的系統或者應用，都集成在一個系統中。在集成的過程當中，更多的但願它可以去作一些技術上的統一，而不是不去作任何管控，讓它野蠻生長。因此在微前端架構具體實踐過程當中，咱們秉持的理念就是在單一地體系下，須要技術上的統一，即使當下基於成本考慮不去遷移，長遠來看確定是逐步收斂技術體系。好比說咱們部門在技術架構要求使用 React，那如今存量的 Vue 系統，也會把它集成進來，但在後續的增量需求開發的時候，確定慢慢被 React 的技術體系迭代升級掉。以往作這個事情須要考慮多技術棧共存的問題，而微前端的架構自然支持，爲系統平滑遷移提供了基礎的保障。
• 第二個設計理念就是開發體驗一致，今天技術架構上引入一套微前端方案，並不會意味着要有不少新概念去學習，包括新的語法、構建邏輯，甚至總體的編碼方式都發生變化，這是咱們不指望看到的。因此在設計的時候，核心的一個命題就是低成本甚至零成本的遷移，開發者不須要額外去學習一些新的概念和流程，保持跟原先的開發邏輯一致。
• 第三點實際上是微前端方案中核心的一個能力 - 路由能力，在 icestark 當中，路由實際上是一箇中心化的管理，全部的路由信息都是在框架應用中維護，根據路由的變化去作路由的分發和管理。
• 第四點獨立開發部署，其實在必定程度上會反映出上面提到的開發體驗一致問題。以前的應用是獨立開發、獨立部署的，如今依舊保持原樣，和微前端架構接入以前沒有變化。

icestark-核心概念

  icestark 裏面引入的核心概念，主要兩個點：框架應用和微應用。

• ①框架應用就負責總體的 Layout 跟微應用配置與註冊渲染。從上面這張圖上能夠看到，框架應用會有的一個通用的頭部 Header，側邊欄siderBar，除了 Layout 以外，還須要配置微應用的信息，好比 bundle url 、基準路由等信息。
• ②微應用其實就是按業務維度拆分開來的一些應用，一般來說它可能就是一個 SPA 應用，而且會包含至少一到多個頁面或路由。

  框架應用只作兩件事情：系統總體 Layout 的設計、全部微應用的配置與註冊；框架應用儘可能避免包含具體頁面的 UI 代碼，若是框架應用作了過多的事情會帶來如下問題：

• 框架應用樣式代碼太多，會增長微應用和框架應用樣式衝突機率；
• 框架應用爲微應用提供其餘能力好比一些全局 API，會破壞微應用的獨立性，增長相互的耦合；
• 框架應用本質是一箇中心化的部分，變動後原則上須要迴歸全部微應用，所以須要保證職責的簡單，越簡單的東西越穩定

icestark - 工做原理-微應用註冊

  上圖就是代碼層面上框架應用註冊微應用信息的方式。

  配置信息中 path 表明基準路由，也就是聲明訪問什麼路由地址時這個微應用將會加載，另外一個是 url，表明應用的 bundle 資源。

  bundle 資源裏面的類型多是多樣的，它能夠是一個 JS 資源，也有可能包含 CSS bundle，

  另外除了 JS 跟 CSS 以外，特別像 Angular 這類框架在運行時強依賴 html 的內容邏輯的場景，iceSrarck也提供了直接設置 entry 的方式把 html 引入進來。

icestark - 工做原理 - 流程

  首先咱們總體看一下接入微前端架構後的工做流程。這張圖咱們能夠從兩個視角去看：微應用獨立開發流程、框架應用訪問流程。

• ①一個視角就是左邊微應用的開發模式。微應用開發有獨立的倉庫，獨立的開發、測試、佈署流程。開發測試部署完以後，將應用的發佈產物統一註冊到框架應用裏面，這些產物多是 JS bundle 或 html 資源。
• ②右邊是一個框架應用的總體流程，框架應用會維護微應用的註冊信息。用戶在訪問系統的時候，根據它以前註冊的路由信息，它可以精確地匹配到當前須要加載的應用信息，根據相應的信息去加載應用的資源並最終渲染應用。

  用戶點擊觸發跳轉的時候，若是路由變化觸發的是一個內部應用跳轉，那應用將會直接根據應用內部的路由邏輯渲染頁面。若是涉及到一些跨應用的跳轉，則又從新回到了上面路由的查找流程當中。

icestark - 工做原理 - 路由規則

  接下來咱們會針對框架應用裏面的核心流程進行一些拆解，首先來了解一下路由劫持這塊是怎麼作的。路由劫持是微前端方案中比較重要的一塊能力，若是不去劫持應用的路由，就沒法斷定當前須要加載哪個應用資源，也沒法決定渲染什麼界面。

  icestark 裏面的路由規則，相對來講比較簡單，熟悉 react-router 的同窗，不難發現二者在配置上實際上是有不少類似的地方。好比說 path、exact 的配置規則都與 react-router 相似。

  當咱們訪問到框架應用頁面時，icestark 內部會去作一個路由的分發。上圖註冊三個微應用配置，當訪問 /seller 路由時，匹配到了第一個註冊信息，當訪問 /data 或者 /message 的時候呢？結果而言，匹配到的是第三個路由，注意第一個註冊配置中的 excat 屬性。若是你在微應用架構裏面去設置了 path 爲 / 的一個微應用，那它實際上是做爲整個系統的一個兜底路由，全部不匹配已註冊的路由配置都會由兜底路由進行渲染。兜底路由在使用的場景上會做爲登錄頁面， 404 頁面或者說退出頁面的渲染兜底，通常狀況都會是通用頁面，跟框架應用會有比較強的耦合。因此實踐上面咱們也將兜底路由做爲框架應用自身路由的渲染。

  爲何可以完成這樣的路由分發操做？

  經過一個 url 的變化，內部到底是怎麼劫持處理的，如何判斷出須要加載的是註冊的哪一個應用？這個就涉及到咱們的路由劫持原理。

icestark - 工做原理 - 路由劫持

• ①icestark 對兩類路由事件進行了劫持，一類爲 history API 中的 popstate 和 hashChange，另外一類是 window 上的路由事件 pushState 和 replaceState，這兩個事件在瀏覽器上進行前進後退操做的時候會觸發。
• ②一旦應用間發生跳轉，經過上述事件的劫持可以拿到對應的路由信息，再根據路由的匹配來決定哪一個微應用進行掛載。
• ③一個微應用可能會有多個路由設置，若是在沒有發生應用間跳轉的狀況下，因爲匹配到的是當前的微應用，因此不會再次加載資源，內部路由跳轉邏輯則根據微應用自身路由配置決定渲染。
• ④若是整個框架應用的微應用配置發生卸載，這個時候會將劫持的內容都給移除，恢復到原始狀態，這樣就完成了整個應用從路由基礎到 url 變化監聽再到微應用加載的一個過程。

icestark - 應用通訊

  接下來，咱們簡單聊一下應用通訊的方案。

  在 @ice/stark-data npm 包中提供了應用通訊的能力，核心實際上是一個 EventBus 的機制，框架應用跟微應用之間的通信，以 window 這樣一個全局變量做爲橋樑。這樣無論是微應用添加的事件或數據，仍是框架應用添加的事件或數據均可以訪問到。

  框架應用跟微應用之間，或者說是微應用跟微應用之間，是否是可以去作一些通訊或者作一些事件監聽？其實從微前端的設計原則上來講，咱們並不但願微應用太多地去依賴框架應用或者其它微應用提供的能力。以前遇到有一些場景，有些開發者但願把一些很重的邏輯，好比通用的 utils 邏輯，經過應用間的通訊方式，實現不一樣應用間的函數共享。技術上是行得通的，但這樣的設計會對應用的維護性形成很大影響。

  以前咱們提到過，每個微應用，都但願是獨立開發、獨立部署、獨立發佈的。若是微應用強依賴一些外部能力，那在你獨立開發的時候，就須要你去 mock 一個開發環境，這樣開發體驗和改形成本都會增長。

  icestark 提供了一個應用通訊機制，在實際開發過程當中推薦應該更加輕量的去使用。好比說這通訊機制僅僅讓框架應用和微應用的多語言設置保持一致，多語言設置發生切換時，微應用可以監聽到這個變化。另一個就是應用間的事件通訊，大部分場景是微應用系統通知框架應用去主動獲取數據。基於這樣的場景，咱們能夠利用應用通訊的能力，來完成一些輕量的通知。

微前端 - 業務價值

大型系統

  第一種就是大型單體應用場景，它的頁面量級很大的、開發效率也所以受到影響，包括它的技術棧遷移成本也會變高。結合微前端架構，咱們能夠按功能維度把它拆分紅一個個獨立應用。不管是增量業務仍是技術架構的升級均可以低成本地在拆分開的應用中進行。

工做臺場景

  第二種是工做臺場景，更可能是去解決產品體驗和操做效率的問題。微前端架構可以帶來獨立 SPA 的體驗，同時又不破壞其獨立開發獨立部署的研發流程。同時不一樣的應用統一接入到框架應用，也使得對接入的應用有了必定的管控，避免一些重複建設和不受控的技術選型。

  基於上述的兩個場景，微前端架構都可以給出它的答卷。

⑤業界還有哪些微前端的輪子

• 螞蟻：乾坤
• 淘寶：iceStark
• 阿里雲：阿里店小蜜
• 字節跳動：沙盒
• 宋小菜：菜籃子入駐平臺
• 飛豬：飛豬一體化運營工做臺星辰
• 阿里雲：阿里雲
• 美團：單門店多門店投放系統

04.前端穩定性/質量保障體系

  關於前端穩定性，能夠分爲四步：開發中、自測中、測試中和上線後四個階段，每一個階段能夠用不一樣的辦法去保證質量和穩定性。

  咱們來看看第一個上線後的處理也就是前端監控。

①前端監控--上線後

  設計之初咱們應該考慮的是前端監控的基本目的是什麼？

前端監控的基本目的

  前端監控的基本目的在咱們看來是如下幾點：

• 開發出來的應用有沒有用戶使用，有多少用戶使用；
• 用戶在使用過程當中遇到了什麼樣的問題；
• 做爲開發者和運營者應該如何追蹤定位到這些問題並及時解決；
• 同時從中吸收經驗避免再犯。

  從用戶訪問頁面開始，到基於這些數據作出必要的決策結束，整個數據流進來一步步處理掉，能夠分爲 採集、轉發、解密、持久化和處理這幾個核心流程。

前端監控基礎模塊

  整個監控跟蹤，從採集到跟蹤，從產品的視角，能夠拆分出來以下幾個功能模塊。

  若是決定自研之後就應該考慮如何設計系統了：

• 數據應該如何採集，採集哪些端，哪些數據；
• 數據應該如何存儲，上報和保存的數據結構應該是怎樣的；
• 報警系統應該如何設計，如何嗅探錯誤，如何通知到負責人；
• 如何對上報的異常進行歸類，從而進行管理；
• 如何展示。

系統架構

  端目前覆蓋到了 PC/H五、RN 應用、小程序。日誌處理通過三層：

• 第一層考慮到流量較大采用集羣的方式分散壓力，同時對數據作初次處理；
• 第二層 主要是使用 kafka 集羣進行 buffer，下降 ES 寫日誌的壓力，同時也具備緩存數據的功能，避免 ES 宕機形成的數據丟失，Filebeat 則是在應付 kafka 出問題時的 Backup原始數據則在通過處理後存放在 Elasticsearch 中；

• 第三層數據處理端上的埋點數據通過處理後會存放在數據倉庫內，這是後端同窗的工做了，從前端蒐集到的錯誤數據則是在監控系統後臺作處理的，數據展示層則主要包括兩個部分：

  • 一是埋點數據的展示，是在後端同窗處理後由咱們前端的可視化報表系統進行展示的；
  • 二是監控錯誤數據的展示，監控看板。

系統各模塊間的數據流向

  實現層面，整個監控跟蹤的技術架構圖以下：

  基於目前已有的監控能力，還能夠用什麼手段對前端監控作更多事情，解決業務痛點？
目前還有哪些痛點？業界都有哪些手段解決？

• 如何把蒐集到的數據轉化成咱們能可用的數據指標去解決業務問題呢？
• 如何從採集到的一大堆js等前端報錯信息，快速定位問題解決問題呢？
• 如何對監控的那麼多錯誤、異常等，作數據清洗，從中找出真的存在問題的數據呢？

②混沌工程——測試中

  混沌工程能夠理解成一種主動防護的能力，可以提早找到未知的問題，提升系統韌性。

  總結一下混沌工程是：

• 一種擁抱失敗的技術文化；
• 一套抽象嚴謹的實踐原則；
• 一種主動防護的穩定性手段；
• 一個高速發展的技術領域。

  對於人員：

• 對於架構師來講，能夠驗證系統架構的容錯能力，好比驗證如今提倡的面向失敗設計的系統；
• 對於開發和運維，能夠提升故障的應急效率，實現故障告警、定位、恢復的有效和高效性；
• 對於測試來講，能夠彌補傳統測試方法留下的空白，以前的測試方法基本上是從用戶的角度去作，而混沌工程是從系統的角度進行測試，下降故障複發率；
• 對於產品和設計，經過混沌事件查看產品的表現，提高客戶使用體驗。因此說混沌工程面向的不只僅是開發、測試，擁有最好的客戶體驗是每一個人的目標。

  因此實施混沌工程，能夠提前發現生產環境上的問題，而且能夠以戰養戰，提高故障應急效率和能夠使用體驗，逐漸建設高可用的韌性系統。

  混沌工程能夠理解成一種主動防護的能力，可以提早找到未知的問題，提升系統韌性。reactChaos是前端對混沌工程領域所作的一個產品。

  前端小demo：React Chaos

③單元測試--自測中 與 代碼檢測--開發中

  關於開發中和自測中的質量保證，這個你們能夠看這個概括圖自行選擇工具，另外也提供兩個參考文檔JavaScript 測試框架比較（英文） (JS)、開發中-代碼檢測工具。

05.總結

前端基礎建設的業界概括圖

  最後一張圖來總結一下上面所介紹的前端傳統方向也就是基礎建設。

  基礎設施：雲端能力成爲各大互聯網的基礎能力，能夠想象將來雲端會愈來愈強大，能夠提供更多標準化的能力，前端能夠自主作更多的事情。

  服務層：BFF/SSR是前端服務層的主要做用，從技術棧而言，Node->GraphQL->Serverless會是一個大趨勢，尤爲是Serverless的出現讓你們看到前端更加獨立放飛自個人可能性。

  應用層：在前端三大框架React、Vue、Angular之上，造成了一系列強約束性、架構標準化、插件化擴展的應用層開發框架，這類應用框架的出現對於大廠技術棧能力沉澱起到很是重要的做用。

  UI組件庫：組件庫再也不是簡單的UI組件的封裝，而是一套完整的設計語言。同時隨着端的豐富，組件庫也從PC端來到移動端、小程序，形態上也更多出現了數據可視化等更爲豐富的表現。

  小程序：小程序是國內的一種特殊產物，隨着微信、支付寶小程序的興起，各大App都開始小程序容器化的建設，但對於應付多個小程序平臺研發也變得苦不堪言。因而出現了類React/Vue開發方式的mpvue、wepy等框架方便你們延續原有前端開發模式，而後又有了多端統一的框架Taro、uni-app等等，解決多端統一的問題。

  跨平臺動態化：跨平臺和動態化始終是一個關於研發效率與用戶體驗如何平衡的熱門話題，不管是Hybrid的Web容器加強仍是RN、Flutter這類虛擬運行環境的解決方案，都有着不一樣的應用場景。在國內，對於研發效率和動態化能力執着追求下，在用戶體驗妥協下，RN、Flutter技術獲得長足的發展，RN目前已經進入了成熟期，各大公司的基礎建設也相對完善；Flutter則是當紅炸子雞，處於技術泡沫期，但其將來前景有可能更好，其跨平臺的願景更爲宏大，將來可期。

  工程智能化：大前端研發早就進入到大規模、多團隊協做的工做模式，所以工程化的基礎建設對於研發效率、規範落地、線上異常性能監控等方面都起到很是重要的做用。目前阿里在雲端化的建設，例如Web IDE、雲構建等，進一步提高了前端工程化的能力。同時前端智能化這個方向也很是熱門，在Pro Code/Low Code/No Code三個方向都有不少突破，前端同窗在自我革命的道路上越走越決絕了。

業界基礎建設

前端行業新資訊

①前端新方向-Gartner發佈2020年新興技術趨勢圖

  根據全球領先的信息技術研究和顧問公司Gartner最新研究報告 「Hype Cycle for Emerging Technologies, 2020」 ，介紹了30項須重點關注的技術，這些技術可實現可編組企業，有望重拾社會對於技術的信任並改變人腦的狀態。

  這個圖中咱們能夠看見不少新興技術：好比5G、AI、數字孿生、知識圖譜、數據分析、機器學習等。

  咱們經過這個圖能夠看見每一個技術都會經歷幾個發展階段：技術萌芽 → 指望膨脹 → 泡沫破滅 → 啓蒙期 & 穩步爬升 & 生產成熟。

  而5G、AI正處在一個啓蒙+穩步爬升的時期。

②前端新方向-5G引起的新浪潮

  在互聯網發展的60年中，每隔十年都會有一個比較有表明性的技術，好比說60-70年咱們互聯網有一個基礎技術開始興起，到70-80年咱們會發現TCP/IP這樣基礎協議出來；再到80-90電子郵件出來，90-00屬於web1.0階段咱們常見的像一些搜索門戶，校園類的BBS都已經出來了；00-10這十年實質上是web2.0一個高速發展階段，表明的技術就是05年出現的AJAX技術，他實現了服務端和web端的一個通訊，這時候像一些大型的網站淘寶都已經興起了；10年以後，你會發現這是互聯網高速發展的十年，那其實他已經把咱們的衣食住行都囊括進來了。

  那這條曲線咱們能看出一個什麼樣的東西呢？

  咱們會發現其實在曲線的右邊實際上是咱們的一個網絡社會，咱們的網絡社會在不斷地擴大，一樣的他也在擠佔着咱們的現實社會，由於每一次技術的發展都是對咱們現實社會一個深度的刻畫，好比說web2.0階段你會發現咱們傳統社會中的社交需求會被經過qq、淘寶這些取代掉，包括移動互聯網咱們是最優體感的，咱們現實生活中的問題都已經被滴滴美團這樣的應用在現實或者網絡上都能解決；推測一下20年以後咱們會發生什麼？

  會迎來智能物聯時代：這會對咱們現實社會進行進一步的刻畫，而咱們的現實社會自己就是一個充滿關係的社會，無時無刻不在產生着關係數據，那咱們是但願經過現實社會中產生數據構建這樣的網絡社會，網絡社會中咱們經過這些數據的分析可以產生一些關係的洞見，從而去治理咱們的社會；

  5G 帶寬的⼤幅提高帶來傳統 Web ⻚⾯複雜度的進⼀步提高，如同 2G 到 4G 變⾰過程當中⻚⾯從 WAP 的純⽂本超連接時代變⾰到 4G 全圖⽚視頻時代。5G 對於⻚⾯的變⾰必將是巨⼤的，但確定不會⼀蹴⽽就。由於相應的配套設施也須要逐步完善，如硬件性能和瀏覽器的處理速度。⽽服務端渲染（SSR）確定是其中⼀個捷徑，輕前端重後臺，5G 是橋樑，把渲染放後臺，不像同構那麼簡單，須要關注和優化渲染性能。

  WebAssembly 或許會在這個機遇下獲得快速發展，由於它能夠⽆縫對接後臺多種語⾔，⽽後臺渲染的優化也會帶來前端⻚⾯研發模式和技術架構的變⾰。

③5G到來引起的新浪潮

  先來看看5G到來引起的新浪潮：

• 5G 帶寬的⼤幅提高帶來傳統 Web ⻚⾯複雜度的進⼀步提高

  • 服務端渲染（SSR）
  • 優化渲染性能
  • WebAssembly

• 5G 帶來的萬物互聯，將帶來有別於智能⼿機和普通 PC 的多樣化的應⽤場景，會把 Web 帶⼊各類各樣的垂直領域

  • VR（WebGL、Three.js）：WebVR《Supermedium團隊WebVR瀏覽器》《天文愛好者》、社交VR《Facebook》、看房VR《貝殼》、繪畫VR《A-Painter》…

    • VR周邊設備
    • WebVR
    • A-Frame
  • 可穿戴設備
  • ⻋載系統
  • 智能投影
  • 智能交互等

再來看看業界的一些比較新的案例

再來看看VR的將來

• ①一項新興技術的成熟曲線每每要經歷新技術誕生、指望膨脹、泡沫化、穩步爬升、實質生產這5個階段，目前 VR 正處於啓蒙期階段，內容創做成本還沒有下降，設備保有量還沒有造成規模。
• ②在 2016 年高盛發佈的《VR 與 AR 報告：下一個通用計算平臺》中，對於 2025 年 VR/AR 9大應用領域規模的預期，只有視頻遊戲、事件直播和視頻娛樂3大領域將徹底由消費者推進，佔總體 VR/AR 營收預期的 60%，剩餘 40% 由企業和公共部門推進。

④WebAssembly

  剛纔提到WebAssembly 或許會在這個機遇下獲得快速發展，由於它能夠⽆縫對接後臺多種語⾔，⽽後臺渲染的優化也會帶來前端⻚⾯研發模式和技術架構的變⾰。WebAssembly成爲繼HTML、CSS 和 JavaScript 以後的web的第4種語言，已通過去接近一年了。它的性能優點會給前端生態帶來哪些嶄新的變化呢？咱們又該如何在項目裏擁抱WebAssembly，使其爲咱們所用呢。

WebAssembly-簡介

1.WebAssembly起源

  WebAssembly起源於 Mozilla 的一個項目：ASM.js，這個簡單的說就是 JS 的一個輕簡版子集，去除了動態類型、對象、垃圾回收等損耗性能的部件。它的做用是成爲 C/C++ 的編譯目標，從而能將大中型遊戲引入瀏覽器，事實證實效果不錯。然而 ASM.js 畢竟仍然是 JS，它不具有原生代碼的一些功能，如 SIMD、線程、共享內存等，所以 ASM.js 進一步發展，就成了 WebAssembly。

2.webassembly是什麼？

  WebAssembly 是一種二進制格式的類彙編代碼,能夠被瀏覽器加載合併進一步編譯成可執行的機器碼，從而在客戶端運行。它的縮寫是」.wasm」，.wasm 爲文件名後綴，是一種新的底層安全的二進制語法。它被定義爲「精簡、加載時間短的格式和執行模型」，而且被設計爲Web 多編程語言目標文件格式。 這意味着瀏覽器端的性能會獲得極大提高，它也使得咱們可以實現一個底層構建模塊的集合，例如，強類型和塊級做用域。

3.爲何出現webassembly？

  JS 存在性能瓶頸，JIT優化天花板不夠高。隨着高計算量 Web 應用（3D圖形、遊戲、VR等）的出現，JavaScript 的速度又一次顯得不夠用了。WebAssembly 的目的就是讓瀏覽器多一種運行更快速的代碼。

  WebAssembly 比 JS 快這是顯然的，一個接近 native code，另外一個是動態類型的解釋型語言，徹底無法比。

  WebAssembly 不只運行更快，傳輸也更快，由於它是二進制格式的，壓縮率更高，體積更小。引用 Opera CTO 羅志宇的說法，WebAssembly 就是對 JS 性能問題的終極填坑方案。

WebAssembly-技術現狀

  獲得 .wasm 文件以後怎麼用呢？目前 .wasm 須要由 JS 引入後才能運行，JS 中有一個用於操做二進制代碼的 API：ArrayBuffer，JS 使用 ArrayBuffer 加載 .wasm，而後調用編譯方法，而後再建立實例。

  WebAssembly 尚未集成 Web API，要調用 Web API，就必須藉助 JS。將來計劃容許 WebAssembly 直接調用 Web API，而且讓 .wasm 模塊像 ES6 模塊同樣易於使用。

  目前 Chrome、FF、Edge、Safari 最新版都已支持 WebAssembly，對於不支持 WebAssembly 的瀏覽器，會有 polyfill 把 WebAssembly 從新翻譯爲 JavaScript。

業界比較成熟的案例

• 當你的視頻還在上傳中，已經能夠自由選擇AI推薦的封面。這裏採用了webassembly+AI的前端整合。

  • webassembly 負責讀取本地視頻，生成圖片；
  • tensorflow.js 負責加載AI訓練過的model，讀取圖片並打分。
  • 從徹底的服務端架構 => 前端架構 && 服務端兜底。
  • Webassembly支持解析99%以上的視頻編碼格式，速度提高體驗惠及約50%的web投稿用戶。
• Magnum 是一款輕量級和模塊化的遊戲、數據可視化 OpenGL 圖形處理引擎，支持 C++11/C++14。桌面環境一共支持 Linux、indows 及 Mac，移動環境也支持了 iOS 和 Android，而且整合了嵌入式 Linux，而在網頁環境則必須經過編譯器 Emscripten 將代碼編譯成 Asm.js、WebAssembly 格式。該工具所支持的圖片 API，包含了 OpenGL、OpenGL ES 及 WebGL。
• 在2017年5月時，白鷺引擎宣佈開始支持 WebAssembly，而利用 WebAssembly，白鷺引擎能夠將 HTML 5 代碼編譯爲機器碼運行，讓遊戲運行性能提高 300%。若使用者瀏覽器不支持 WebAssembly，該引擎也會自動轉換成 Java 版本。中國熱門手遊，如：莽荒紀同名手遊、三生三世十里桃花同名手遊、貓來了、夢道、坦克風雲等都採用了 Egret Engine。

• webassembly的優勢

  • 體積小：因爲瀏覽器運行時只加載編譯成的字節碼，同樣的邏輯比用字符串描述的 JS 文件體積要小不少；
  • 加載快：因爲文件體積小，再加上無需解釋執行，WebAssembly 能更快的加載並實例化，減小運行前的等待時間；
  • 兼容性問題少：WebAssembly 是很是底層的字節碼規範，制訂好後不多變更，就算之後發生變化,也只需在從高級語言編譯成字節碼過程當中作兼容。可能出現兼容性問題的地方在於 JS 和 WebAssembly 橋接的 JS 接口。

• WebAssembly 目前還存在如下問題：

  • 瀏覽器兼容性很差，只有最新版本的瀏覽器支持，而且不一樣的瀏覽器對 JS WebAssembly 互調的 API 支持不一致；
  • 生態工具不完善不成熟，目前還不能找到一門體驗流暢的編寫 WebAssembly 的語言，都還處於起步階段；
  • 學習資料太少，還須要更多的人去探索去踩坑。

  本文爲轉載，有整理改動。

• 原做者：小圓臉兒
• 原文連接：2020年前端技術浪潮與應用
• 來源：掘金
• 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。