“前端技術演進及框架介紹”
什麼是前端技術？
前端技術是指在瀏覽器中運行的技術，負責與用戶互動並顯示資料。它包括了 HTML、CSS 和 JavaScript，這三者共同構成了現代網頁的基礎。
傳統 Web 前端技術的局限性
隨著互聯網的發展，Web 技術也經歷了多次變革，但仍存在一些局限性：
資源加載：傳統的 Web 技術依賴於遠端伺服器上的靜態資源，這些資源需要動態地異步拉取。這意味著每次用戶訪問網頁時，都需要等待這些資源的下載，導致初始化效率低於 Native 應用。
渲染機制：在瀏覽器中，JavaScript 的執行、頁面布局和繪製（Paint）都在同一個主線程上進行，無法並行化。這種設計限制了 JS 的性能，特別是在執行複雜邏輯時，容易出現卡頓，進而阻塞 UI 的更新。
頁面切換：傳統的瀏覽器缺乏路由概念，頁面之間的切換完全依賴於瀏覽器提供的功能。這導致了在頁面切換時需要反覆加載資源，影響用戶體驗。
API 能力：瀏覽器的安全機制基於同源策略的沙箱機制，這限制了前端開發者對原生系統功能的使用。只能使用 W3C 標準定義的功能，而這些功能在不同終端上的支持情況往往不一致。
交互性能：瀏覽器的實時交互性能相對較差，特別是在複雜交互場景中，大規模的重排會限制 UI 的幀率，這在中低端移動設備中尤為明顯。
腳本語言，動態解析執行：JavaScript 是一門即時編譯（JIT）的語言，需要動態解析執行，相比預先編譯為機器碼的 AOT 語言，其執行性能較差。
傳統客戶端技術的局限性
動態性：客戶端開發通常有固定的版本發布計劃，且受制於應用商店的審核規則，版本發布的不確定性受政策影響很大。一旦發現線上問題，需要再次發版，容錯成本高。
開發成本：客戶端的開發成本高於 Web 開發，且生態不如 Web 豐富。Web 上有大量的開源包和活躍的開發者社區，而客戶端的生態系統則相對封閉。
跨端一致性：傳統客戶端開發需要為 Android 和 iOS 各自編寫一套代碼，兩者之間的操作系統差異導致同一需求需要不同的實現，增加了業務成本。
混合式前端開發
為什麼會出現混合式前端開發？
隨著 iOS 和 Android 確立了移動操作系統的統治地位，前端開發者也在尋找使用這些操作系統進行業務開發的模式。Web 的開發方式比 iOS 和 Android 更加方便和高效，各種 Web 框架和工具也比原生開發的工具更加靈活。
從阿里巴巴的角度看，中台化的理念逐漸被接受，業務需要快速發展，前台的 UI 和需求會隨著商業決策快速迭代，前端和客戶端的分工也愈加明確。前端作為業務方的唯一接口，逐漸演變為大前端的業務層，負責定義規範並封裝解決方案和工程能力。客戶端則轉為大前端的架構層，提供系統級 API 和宿主應用的能力。
在這種背景下，各種混合開發技術層出不窮，我們將其分為三個階段：
階段一：JSBridge
在這個階段，以 WebView 為主，配合 JSBridge 提供 Native 與 JS 之間的通信鏈路。基於這個通信基礎，Native 可以暴露一些標準服務 API 提供給 JS 調用，JS 也可以封裝一些 API 給 Native 調用。前端開發者使用傳統的 JS + HTML + CSS 進行頁面開發，並調用 JSBridge API 驅動客戶端功能。
JSBridge 方案的主要缺點在於性能和高級組件擴展能力的缺失，流暢性始終無法與 Native 媲美。
階段二：原生 UI
Web 的動態性和高效開發效率是原生開發無法比擬的，但瀏覽器技術的瓶頸也非常明顯：
- W3C 標準的包袱：歷史悠久的 W3C 標準顯著拖慢了瀏覽器性能。
- WebView 的渲染引擎設計缺陷：渲染流水線過長，導致合成動畫和非合成動畫的性能差異。
- 單線程模型：無法充分發揮現代硬件（特別是 ARM 架構多核心）的性能。
- 異步光柵化設計：在長列表滾動時不可避免地出現白屏現象。
React Native 和 Weex 的出現為前端開發者帶來了一道曙光。這些框架利用 JS 引擎調用 Native 端的組件，實現相應功能，允許前端開發者使用 JS 進行業務邏輯開發，使用 VDOM 描述文檔結構，並配合 CSS 子集定制樣式。
Weex 透過 JS Thread、Layout Thread 和 MainThread 的並行執行，解決了 WebView 單線程模型帶來的性能問題。在阿里巴巴，Weex 大規模應用，支撐了雙十一的億級流量。
階段三：自繪引擎
自繪引擎不依賴於操作系統提供的布局和原生組件能力，直接調用 GPU 或底層抽象層進行繪製。例如，Flutter 通過 Dart 語言構建跨平台的開發組件，所有組件基於 Skia 引擎自繪，在性能上媲美 Native 平台的 View，同時解決了雙端一致性問題。
Flutter 缺乏動態更新特性，但社區上有一些項目在探索動態化的可能性。我們團隊也在實現面向前端的動態化 Flutter 引擎——Kraken，從底層擴展了 W3C 標準的 API，使得它更像一個瀏覽器，降低了 Web 開發者的使用門檻。
前端框架介紹
React
優點：
- 高效的虛擬 DOM，優化了性能。
- 單向數據流，便於調試和預測應用行為。
- 強大的社區支持和豐富的生態系統。
缺點：
- 學習曲線較陡，特別是對於新手來說。
- 需要額外的工具來管理狀態（如 Redux）。
- 項目設定和配置可能較為複雜。
Angular
優點：
- 提供了完整的框架，包含路由、表單管理等功能。
- 強大的依賴注入系統。
- 良好的模塊化設計，便於維護和擴展。
缺點：
- 學習曲線陡峭，尤其是對於新手來說。
- 開發過程中涉及大量的樣板代碼。
- 更新較頻繁，可能需要經常重構代碼。
Vue.js
優點：
- 較為簡單的學習曲線，適合新手入門。
- 靈活的設計，易於集成到其他項目中。
- 良好的文檔和社區支持。
缺點：
- 生態系統相對於 React 和 Angular 稍弱。
- 社區包質量參差不齊，需要謹慎選擇。
- 大型應用中可能需要額外的工具來管理狀態。
API 的演進歷程與比較
API（應用程式介面）是指不同軟體之間進行溝通的介面。隨著技術的發展，API 的設計和使用方式也經歷了顯著的變革。
REST API
優點：
- 基於 HTTP 協議，簡單且廣泛應用。
- 使用 JSON 作為數據交換格式，輕量且易於解析。
- 無狀態性，簡化了伺服器端的設計。
缺點：
- 對於實時性要求較高的應用，性能可能不佳。
- 缺乏標準化，可能導致不同實現之間的不兼容。
GraphQL
優點：
- 客戶端可以靈活地查詢所需數據，減少了數據傳輸量。
- 強類型系統，便於調試和自動生成文件。
- 支持實時數據更新，適合動態應用。
缺點：
- 學習曲線較陡，特別是對於 REST 熟悉的開發者來說。
- 伺服器端的實現較為複雜，需要處理數據解析和驗證。
- 性能問題需要特別注意，特別是在大規模查詢中。
gRPC
優點：
- 基於 HTTP/2，支持多路複用和實時數據傳輸。
- 使用 Protocol Buffers 作為數據交換格式，性能高效。
- 支持多種編程語言，跨平台能力強。
缺點：
- 配置和設置較為複雜，學習曲線陡峭。
- Debug 和監控較為困難，需要額外的工具支持。
- 不如 REST 和 GraphQL 那麼直觀，特別是對於前端開發者來說。
API 比較表格
| API 類型 | 優點 | 缺點 |
|---|---|---|
| REST API | 簡單且廣泛應用，使用 JSON，無狀態性 | 性能可能不佳，缺乏標準化 |
| GraphQL | 客戶端靈活查詢，強類型系統，支持實時更新 | 學習曲線陡，伺服器端實現複雜，性能問題 |
| gRPC | 基於 HTTP/2，高效性能，跨平台能力強 | 配置複雜，學習曲線陡，Debug 困難 |
未来展望
隨著技術的發展，Web 技術有望解決性能和體驗問題，成為更通用的 UI 編程標準。PWA（Progressive Web Application）是 Google 推出的概念，通過在移動端瀏覽器提供標準化框架，在 Web App 中實現與 Native App 接近的用戶體驗。