关于javascript:百度技术分享San介绍以及在百度APP的实践

导读：San 是百度自研的高性能 MVVM 框架，它是一个疾速、轻量、灵便的 JavaScript 组件框架，体积玲珑，兼容性好，性能卓越，目前已落地百度 APP 包含搜寻、feed、小程序等外围业务，服务于亿级用户，开源社区已超过 36 位贡献者，Star 数量超过 4.3K。

一、前端开发的演进

在过来的 10 到 15 年中，Javascript 无疑是倒退最快的编程语言之一，它不再应用俊俏的、非结构化的代码和插件在网站上编写简略的逻辑，而是倒退为具备构建性能齐备的跨平台应用程序能力的弱小生态。

随着对 web 平台的需要变得越来越简单，前端开发者的确须要从新设计新的轮子。一些优良的 JavaScript 框架和库陆续登上舞台：

随着 Angular、React、Vue 等框架和库的衰亡，前端开发人员的焦点也从「如何编写代码」转移到了「抉择哪种开发框架」。

二、San 的诞生

记得在 2016 年之前的时候，我所在部门的同学尽管对 React、Vue、Angular 等支流框架都有所尝试，但最终外围业务外面用的依然是 jQuery。从咱们业务的用户数据来看，IE8 – 仍占据着肯定的市场份额：https://gs.statcounter.com/br…。

如果把 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…

四、浅谈其余框架

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/684490…）；而 San 则只提供 4 种计划（https://baidu.github.io/san/p…），蕴含 store。San 不提倡应用 mixin，mixin 意味着组件有隐式依赖，组件在不同的 mixin 环境下，渲染后果和行为可能不同，同一个组件在不同环境下是不可预期的。目前 Vue3 也举荐应用 Composition api 来取代 mixin。

五、San 的生态建设

围绕着 San 生态的建设也在继续进行中，目前曾经有了包含 San CLI、无极组件库、Santd、San DevTools、San SSR 等，周边生态已根本和 Vue 等业内支流框架对齐，足以满足以后的业务需要。当然，凋敝水平还有很大差距。须要宽广开发者跟咱们一起，独特建设繁荣的 San 技术生态。

目前 San 跟 Vue/React 的支流框架生态比照如下：
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-…

San SSR

为 San 提供一个 SSR 代码框架和工具，将组件渲染为服务器端的 HTML 代码，实现同一组件同时运行在服务端和浏览器中，实现前后端同构。

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

六、San 在百度 APP 中的利用

这些年，随着挪动开发技术的倒退，咱们的业务和团队都失去了长足的倒退，然而技术栈却越来越乱，这是非常蹩脚的。

对于一个大的研发团队来说，对立技术栈能够加深前端团队技术积淀，避免反复造轮子，也有利于架构和解决方案的迁徙，从而晋升整体代码品质和开发效率，防止反复踩坑。

2018 年底开始，百度 APP 高工开始推动前端技术栈的对立，基于前端技术选型做我的项目脚手架、开发 CLI 工具、封装公共函数库、业务通用组件库。终极目标是实现一套代码，多端对立，先后用 San 做 H5、小程序、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/s…

我的项目收益

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/sa…
• San 为什么会这么快：https://efe.baidu.com/blog/sa…
• 如何评估百度新造的 MVVM 轮子 San？https://www.zhihu.com/questio…

最初欢送参加 san 周边的开发：

• 为 san 相干的类库奉献有价值的 issue（https://github.com/baidu/san）；
• 奉献 san-cli 的 plugin，能够将罕用的 webpack 插件，集成到 san-cli（理解更多 https://ecomfe.github.io/san-…）；
• 奉献 san-cli-ui 的 plugin，能够将罕用的工具集成到 san-cli 的可视化界面 (理解更多 https://ecomfe.github.io/san-…。

原文链接：https://mp.weixin.qq.com/s/cS…

百度架构师

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注！

​