San介紹以及在百度APP的實踐

本篇文章是 San 系列文章的第一篇，後面會持續更新一批 San 相關的文章，喜歡的朋友請持續關注咱們後續的更新。

前端開發的演進

在過去的 10 到 15 年中，Javascript 無疑是發展最快的編程語言之一，它再也不使用醜陋的、非結構化的代碼和插件在網站上編寫簡單的邏輯，而是發展爲具備構建功能完備的跨平臺應用程序能力的強大生態。

隨着對 web 平臺的需求變得愈來愈複雜，前端開發者確實須要從新設計新的輪子。一些優秀的 JavaScript 框架和庫陸續登上舞臺：

隨着 Angular、React、Vue 等框架和庫的興起，前端開發人員的焦點也從「如何編寫代碼」轉移到了「選擇哪一種開發框架」。

San 的誕生

記得在 2016 年以前的時候，我所在部門的同窗雖然對 React、Vue、Angular 等主流框架都有所嘗試，但最終核心業務裏面用的仍然是 jQuery。從咱們業務的用戶數據來看，IE8 - 仍佔據着必定的市場份額：https://gs.statcounter.com/browser-market-share/all/china/2016。

若是把 Vue、React 這些 MVVM 框架比作洋槍大炮，那 jQuery 只能算是大刀長矛，面對洋槍大炮，低版本 IE 兼容性問題讓作 2C 業務的同窗只能摩拳擦掌、望洋興嘆。IE 兼容性相關的問題將來終將再也不是問題，可是咱們已經等不及要解決它了；出於對現狀的不滿意，咱們開始了 San 的研發，並於 2016 正式推出。PC 端瀏覽器的 兼容性是個繞不開的理由，San 爲這類的業務需求提供了技術選型方案。

若是拿車來比喻，咱們想造的是一臺陸巡。相比轎車甚至多數 SUV，它沒有那麼好開，看不到不少 2.0T 的車尾燈；相比牧馬人和 benz G，他越野能力和經過性也沒那麼強。可是它很可靠，能穩妥當當、溫馨地帶你到任何想去的地方。(@Erik)

San 的特性介紹

San 是一個作了無數減法後誕生的東西，它專一於一個輕快的，注重性能和兼容性的，數據爲驅動形式的 UI 框架，配合相應的狀態管理等庫來造成生態。從功能上來看，San 並無出奇的地方，其設計初衷是更好的性能、體積和兼容性，提升應用的天花板，減小應用開發者的後顧之憂。

San 經過聲明式的類 HTML 視圖模板，在支持全部原生 HTML 的語法特性外，還支持了數據到視圖的綁定指令、業務開發中最常使用的分支、循環指令等，在保持良好的易用性基礎上，由框架完成基於字符串的模板解析，並構建出視圖層的 節點關係樹，經過高性能的視圖引擎快速生成 UI 視圖。San 中定義的數據會被封裝，使得當數據發生有效變動時通知 San 組件，San 組件依賴模板編譯階段生成的節點關係樹，肯定須要變動的最小視圖，進而完成視圖的異步更新，保證了視圖更新的高效性。

組件是 San 的基本單位，是獨立的數據、邏輯、視圖的封裝單元。從頁面角度看，組件是 HTML 元素的擴展；從功能模式角度看，組件是一個 ViewModel。San 組件提供了完整的生命週期，與 WebComponent 的生命週期相符合，組件間是可嵌套的樹形關係，完整的支持了組件層級、組件間的通訊，方便組件間的數據流轉。San 的組件機制，能夠有效支撐業務開發上的組件化需求。

San 支持組件反解，以此提供服務端渲染能力，能夠解決純前端渲染致使的響應用戶交互時延長、SEO 問題。除此以外，San 還提供了一些周邊開源產品，與 San 配合使用，能夠幫助開發者快速搭建可維護的大型 SPA 應用。

做爲一個 MVVM 的組件框架。它體積小巧，兼容性好（IE6），性能卓越，是一個可靠、可依賴的實現響應式用戶界面的解決方案。對於用過 Vue 或者 React 的開發者來講，San 框架很是容易上手，學習成本很低。

Size 對比

性能對比

數據來源：https://krausest.github.io/js-framework-benchmark/current.html

淺談其餘框架

San 尤爲適合前端業務邏輯相對簡單的業務。目前，在百度內部已有多個產品線把 San 定爲業務首選前端開發框架，相關的業務已服務於億級用戶，這足以證實 San 是可靠、可依賴的前端框架。

而框架之間的對比彷佛又是一個繞不過的話題，咱們不能無視房間裏面的大象。

對比 React

React 是通過實戰檢驗的領導者，獲得了企業和龐大的開源社區的支持。該庫能夠更好地擴展，讓你建立複雜的企業級應用。從虛擬 DOM 到 JSX，從 Immutable 到 React Hooks，React 社區提出了不少偉大的革命性的想法。React 做爲一個庫而不是框架，許多依賴都源於由社區構建和支持的第三方庫，不管是技術選型仍是應用開發，都有着極大的靈活性，它的學習曲線相對也更加陡峭。

對比 Vue

Vue 使用一種更傳統的方法，能夠用簡潔的模板語法來聲明式地將數據渲染進 DOM 系統。還提供單文件組件的模塊化方式，將 HTML 模板、樣式和 JS 代碼經過標籤分隔。這種開發方式容易讓前端開發人員更親切，也使得框架易於學習。另外，Vue 的文檔和生態方面，堪稱業界典範。

San 汲取了 Vue 的一些優秀設計，同時也體現了一些新的思路。例如：在 Vue 中，數據直接置於組件下，methods 被規約。而在 San 中，method 直接置於組件下，數據被規約（其實已經被封裝）。

相較於 Vue，San 在 API 的設計上更加節制。Vue 在組件通信上，就提供了至少 6 種方案（參考 https://juejin.cn/post/6844903784963899405）；而 San 則只提供 4 種方案（https://baidu.github.io/san/practice/），包含 store。San 不提倡使用 mixin，mixin 意味着組件有隱式依賴，組件在不一樣的 mixin 環境下，渲染結果和行爲可能不一樣，同一個組件在不一樣環境下是不可預期的。目前 Vue3 也推薦使用 Composition api 來取代 mixin。

San 的生態建設

圍繞着 San 生態的建設也在持續進行中，目前已經有了包括 San CLI、無極組件庫、Santd、San DevTools、San SSR 等，周邊生態已基本和 Vue 等業內主流框架對齊，足以知足當前的業務需求。固然，繁榮程度還有很大差距。須要廣大開發者跟咱們一塊兒，共同建設繁榮的 San 技術生態。

目前 San 跟 Vue/React 的主流框架生態對好比下：

San CLI

CLI 工具致力於將打包構建等基礎工具標準化，使開發人員專一於業務開發，沒必要花太多時間在 webpack、babel、postcss 等工具配置上。CLI 工具經歷了 Hulk CLI1.0、Hulk CLI2.0、San CLI 三個版本的迭代（Hulk 是一開始作的偏業務的公司內部版本），現已對外開源。

目前 San-CLI 的主要功能：

• 提供交互式項目腳手架，開箱即用。支持 Smarty 和 HTML 兩種模板

• 集成前端生態經常使用工具，初始化 Webpack 經常使用配置

• 內置 Webpack，提供插件化系統支持自定義擴展

• 圖形化的建立和管理 San 項目的 Web 界面，可集成經常使用輔助開發工具

（san cli 的可視化界面）

UI 組件庫

San 無極組件庫是公司內部一套基於無極產品設計中臺規範而開發的 San 版本的 UI 組件，主要用於百度各個產品線的 C 端業務。

Santd（官網 https://ecomfe.github.io/santd/）是一套基於 Ant Design 設計規範的 UI 組件庫，目前主要用在多個內部的後臺系統。

Santd 開源地址：https://github.com/ecomfe/santd

San DevTools

San DevTools 是前端開發工具中的利器，它能輔助開發者快速定位問題，發現性能瓶頸。
當你沒法快速找到自定義事件 (Event) 在哪一個組件上觸發，消息（message）被哪一個組件捕獲，出了問題的界面對應哪一個數據字段時，DevTools 都能助你一臂之力。

開源地址：https://github.com/baidu/san-devtools

San SSR

爲 San 提供一個 SSR 代碼框架和工具，將組件渲染爲服務器端的 HTML 代碼，實現同一組件同時運行在服務端和瀏覽器中，實現先後端同構。

San SSR 開源地址：https://github.com/baidu/san-ssr

San 在百度 APP 中的應用

這些年，隨着移動開發技術的發展，咱們的業務和團隊都獲得了長足的發展，可是技術棧卻愈來愈亂，這是十分糟糕的。

對於一個大的研發團隊來講，統一技術棧能夠加深前端團隊技術沉澱，防止重複造輪子，也有利於架構和解決方案的遷移，從而提高總體代碼質量和開發效率，避免重複踩坑。

2018 年末開始，百度 APP 高工開始推進前端技術棧的統一，基於前端技術選型作項目腳手架、開發 CLI 工具、封裝公共函數庫、業務通用組件庫。終極目標是實現一套代碼，多端統一，前後用 San 作 H五、小程序、San-native 方案、San-SSR 服務端渲染等。

技術選型：爲何是 San

選擇 San 做爲統一技術棧的前端框架，主要基於如下幾個緣由：

首先是業務特色，百度 APP 的業務主要是以展示爲主，核心業務的前端頁面都是多 Webview 隔開的多頁面的，交互相對比較簡單，因此一個輕量和靈活的框架是首選；業務上咱們不只僅有移動端還有功能相同的 PC 頁面，San 出色的兼容性，能輕鬆實現 PC 和移動端組件複用，咱們能夠作到一套組件在 PC 和移動上均可用。

其次，移動端採用開源方案（Vue/React）也是能夠考慮的，外部庫的好處在於發展的很是快，常常會有些新的 feature。但這也將會是個很大的風險，開源庫的快速迭代意味着隨時有新的最佳實踐取代舊的模式而頻繁的破壞性更改，讓早期採用者承擔重構成本。

最後，San 是一個普適性的前端框架，咱們的小程序、San-native（相似 react-native）和 San SSR 都是基於 San，實現底層架構框架統一，真正作到從「Learn Once，Write Anywhere」到「 Write Once，Run AnyWhere」。

目前 San 做爲主流的前端框架，被普遍應用到百度 APP 下包括百度 APP Feed 落地頁（包括 PC）、移動端搜索結果頁（百度搜索結果頁，包括 PC）、我的動態落地頁、用戶我的主頁（包括 PC 版）、話題、百度 APP 和搜索頻道（san-native）等多個產品業務方向之中。

San 技術棧典型落地場景

Wise 搜索前端

• 面向用戶：C 端

• 用戶規模：億級

• 技術選型

  • san

  • san-ssr

  • san-ssr-target-php

基於 San SSR 的改造，搜索業務實現了跨平臺的同時，保證了老版架構遷移的平滑過渡：

1. 組件化：把歷史 Smarty 模板遷移 San 組件定義；

2. 過渡期：經過跨平臺的 SSR，一份代碼分別編譯到 PHP、 Node.js；

3. 最終態：SSR 只編譯到 Node.js，業務代碼無需重寫。

San 採起和 Vue/React 徹底不一樣的方式進行 SSR，把解析和編譯工做移到編譯期，進一步減少運行時開銷。

數據來源：https://github.com/searchfe/san-ssr-target-php/tree/master/test/perf

項目收益

1. 提高開發效率：經過架構升級，從舊的技術棧遷移到 San，實現業務的組件化，下降了後續的維護成本；

2. 性能小幅提高：從測試數據來看 San SSR + PHP 和 Smarty+PHP 在一些場景下互有優劣，而在實際的業務場景（搜索結果頁）有必定的是正向收益。

百度 APP Feed 圖文落地頁前端

• 面向用戶：C 端

• 用戶規模：億級

• 技術選型

  • san + san-store + san-update

  • san-ssr

  • san-cli

老的 feed 圖文落地頁須要同時維護 smarty + react 兩份模板代碼，維護成本高。因爲開發人員的變更，對於一些歷史業務邏輯都很模糊。經過使用 san 技術棧的重構，取得了不錯的收益：

項目收益

1. 代碼開發從開發雙語言代碼遷移爲統一語言，落地無極規範，減小樣式問題的開發量，將開發效率提高 30% 以上；

2. 首字節到達時間減小 26%，同步內容渲染結束時間減小 56%，各項性能耗時減小 20% 以上；

3. HTML 平均內容體積減少 16%。

Feed 頻道 / 搜索六合頻道

• 面向用戶：C 端

• 用戶規模：億級

• 技術選型

• san

• san-native

• san-native-cli

• talos

Talos 是百度研發的一套動態 Native 視圖框架，渲染引擎融合 Webview 和 NA，能同時支持 NA 和 Hybrid 的開發需求。它既能知足獨立 App 的開發，也能知足平臺型 App 內嵌。它專一性能優化，主要指標均優於同類框架。

San Native 做爲 Talos 中的一種 DSL, 採用 San UI 框架做爲底層驅動，經過重寫 Document 以及 Element 類來驅動端渲染，使得 Web 前端工程師能夠十分方便的編寫原生移動應用，一套代碼多端運行。目前主要應用在百度 APP 首頁 Feed 頻道和搜索結果頁六合頻道。

Talos 與 Hippy 性能對比 ：

百度小程序

• 面向用戶：小程序開發者 / C 端

• 用戶規模：億級

• 技術選型

• san

• talos

• san-native

San 做爲百度小程序底層渲染框架，提供了小程序所需的渲染機制，保證可以以組件化的方式進行小程序開發。同時提供了不少性能優化機制，很好的提高總體的運行性能。

San 底層提供簡潔清晰的模板結構 ANode，可以被小程序框架所修飾，從而實現部分高頻基礎組件原生化，使得運行時渲染性能提高 50%。

San 提供壓縮模板線下打包機制，將 template 編譯成 ANode，能夠避免在瀏覽器端進行 template 解析，提升初始裝載性能。同時提供一種壓縮方式將其轉化成 APack，讓其體積更小、網絡傳輸成本更低，小程序接入後啓動時間將縮短 20ms+。

附：San 生態相關

San 核心庫

• san : 一個快速、輕量、靈活的 JavaScript 組件框架

• san-router: 支持 hash 和 html5 模式的 router，單頁或同構的 Web 應用一般須要它。

• san-factory: 組件工廠能幫助你在不一樣環境下更靈活的裝配組件。

• san-store: 應用狀態管理套件，其理念是相似 flux 的單向流。

• san-update: Immutable 的對象更新庫，和 san-store 配合進行應用狀態數據更新。

工具鏈

• san-cli: 幫助你快速搭建 San 應用的命令行工具，讓你專一於應用自己，避免在配置上花費太多時間。

• san-loader: San 單文件組件的 Webpack loader。

• san-hot-loader: 提供熱更新功能，讓開發調試更方便。

• san-ssr: 服務端渲染框架與工具庫。

• san-devTools: 基於 Chrome 擴展的開發者工具。

• drei: VSCode 插件。

• san-test-utils: San 的單元測試實用工具庫。

• san-anode-utils: 一些工具方法可以幫助你處理 ANode.

• docit: 基於 san 的 Markdown 文檔建站工具

UI 庫

• 無極產品設計中臺: 服務於百度生態產品的產品設計中臺，基於肯定和天然的設計價值觀上的模塊化解決方案

• santd: 基於 Ant-Design 設計規範的組件庫

• san-mui: 基於 Material Design 設計規範的組件庫

跨端方案

• 基於 san-native 的動態視圖框架 talos

延伸閱讀

• San - 一個傳統的 MVVM 組件框架：https://efe.baidu.com/blog/san-a-traditional-mvvm-component-framework/

• San 爲何會這麼快：https://efe.baidu.com/blog/san-perf/

• 如何評價百度新造的 MVVM 輪子 San？https://www.zhihu.com/question/65498751/answer/294265707

最後

歡迎參與 San 周邊的開發：

• 爲 San 相關的類庫貢獻有價值的 issue（https://github.com/baidu/san）；

• 貢獻 san-cli 的 plugin，能夠將經常使用的 webpack 插件，集成到 san-cli（瞭解更多 https://ecomfe.github.io/san-cli/#/architecture）；

• 貢獻 san-cli-ui 的 plugin，能夠將經常使用的工具集成到 san-cli 的可視化界面 (瞭解更多 https://ecomfe.github.io/san-cli/#/ui/structure)。