新的一年，我们如何选择更合适的技术来做业务？Web OR Native? 本文作者结合过去一年中阿里集团内的业务合作经验，跟开发者一起聊聊 Web 技术。

从历史说起

英国科学家 Tim Berners-Lee 在 1989 年发明了万维网（World Wide Web），他发明了三项关键技术：

• 统一资源标识符（URI），全球网络资源唯一认证的系统。
• 超文本传送协议（HTTP），客户端与服务器交互的协议。
• 超文本标记语言（HTML），超文本文档的结构和格式。 随着 Web 的发展，Tim Berners-Lee 意识到，只有任何人在任何地方都可以使用而无需付费或获得许可，Web 才会发挥出真正的潜力。在 1993 年他说服了 CERN 同意永久免费提供 WWW 的基础代码，极大的推动了全球开发者的创造力，协作和创新浪潮。Tim Berners-Lee 在 1994 年推动成立了万维网联盟（W3C），一个致力于开发开放式网络标准的国际社区。 Web 在设计之初，就产生了很多革命性的思想，
• 无中心： 没有中央控制节点，可以自由的在网络发布任意内容。
• 无歧视：所有网络参与者可以平等的进行交流，不受操作系统，网络运营商，等等的影响。
• 自下而上设计： 鼓励大家参与和实验，而不是由一小部分专家编写和控制。 普遍性：所有人都可以在网络上发布任何东西，不受硬件，地理位置，信仰文化，等等的影响。 共识：大家可以自由的参与规范的讨论，但必须遵循已形成标准的规范。 正是这种自由平等开放共享的精神，使得 Web 面对各种挑战，依然能一次又一次的焕发生机。

Native 技术的兴起

从 Web 的发展历史我们可以看到，W3C 标准化组织在非常早期就成立了，这对 Web 的标准化发展至关重要。但是，我们也可以看到，W3C 标准的落地周期可能非常长，提出讨论，实现，定稿，过程很漫长。而人们对性能体验等方面的需求是与时俱进的，甚至是越来越挑剔的。 那么，如果在某个时间段，使用标准的 Web 技术无法实现用户需求，怎么办呢？没有实现不了的需求，无论使用什么技术都是要解决问题的。这样我们就非常可能会使用非标准的手段去解决阶段性局部性的问题。 举个例子，在移动互联网之初，网络性能极差，资源走网络加载基本是不可接受的。这就催生了很多离线包技术，就是使用标准的 WebViewClient.shouldInterceptRequest 去拦截资源请求，返回本地离线包资源，以达到提升资源加载性能的目的。这种 Web 与 Native 技术的结合方式，其实是非常推荐的。为什么呢？因为它本质上还是标准的技术，使用了标准的接口去做资源拦截，而且是不影响前端页面的写法，前端页面还是根据 W3C 的规范去写，只不过在没有实现离线包功能的客户端里运行，就享受不到离线包的优化而已。 再举个例子，很多人认为 WebView 的渲染性能比不上 View 的渲染性能，这样就提出了类似 weex 之类的技术，通过自定义一套规范，增加一系列约束条件，而达到更好性能体验的目的。这些技术在某些阶段的确是快速解决了用户的痛点，而且也间接加速了 Web 技术的发展，但作为底层基础技术也存在一些明显的问题，比如，它不是标准的技术，意味着在某个体系之外是不可使用的；它能实现的是 CSS 的一个子集，很可能一些新特性无法支持或者需要客户端开发支持；它如果要跟进 Web 技术的发展，必然需要逐步增加功能，变得越来越臃肿，设计之初的优势就不存在了。

再谈性能与体验

在很多人的印象里，WebView 的渲染性能比不上 View 的渲染性能，是 Web 性能体验的瓶颈所在。 事实真的是这样吗？我们先看看页面的性能的组成部分，

• 资源加载 资源加载，通常会包含 HTML 文档，CSS，JS，首屏数据，模块资源和图片。
• JS 执行 JS 执行，通常会包含页面依赖的一系列 JS 执行，页面 JSON 数据解析，页面节点插入和排版。
• 页面内容渲染 页面内容渲染，通常是指文本渲染，图片解码和图片渲染。

我们跟进了非常多亿级 PV 的业务性能体验，发现页面内容渲染通常不是瓶颈，在非常低端的手机里都能在 200ms 内完成，而资源加载和 JS 执行却波动非常大，往往会成为性能瓶颈。比如，资源在离线包里，数据被预加载了，就会非常快，反之就非常慢，可能需要好几秒；再比如，JS 依赖非常多，JS 渲染的内容非常复杂，则会比较耗时。 也就是说，Native 技术宣传的 View 渲染速度并不是页面的性能瓶颈所在，资源加载和 JS 执行才是页面性能的关键。而资源加载和 JS 执行方面的优化，并不是 Native 技术的专利，如果这些优化能用在 Native 技术场景，通常也能用在 Web 技术场景。所以，我们也可以看到今年双十一天猫主会场的页面，在中高端手机上，其实 Web 的性能体验更好。 我们判断，移动端的 Web 性能体验问题，在最近两年内会彻底解决掉。我们作出这样的判断是基于，

• Web 引擎的飞速发展 渲染引擎和 JS 引擎发展迅速，V8 codecache 技术基本解决了大型 JS 解析性能问题，JS 引擎性能在不断变好，中高端手机上 JS 执行性能问题已经很小。
• 手机硬件性能快速提升 手机 CPU 性能不断提升，iPhone X 的 CPU 已经能媲美台式机了。手机内存也在不断变大，2019 年 6G 内存基本会成为标配。
• 移动网络不断变好 目前 WIFI+4G 网络，在一些端已经超过 98%，国内网络在不断的变好，流量费用也会越来越低，甚至不远的将来还会全面推进 5G 网络。

从技术优化的角度，我们也总结出了 Web 优化模型，就是首屏离线渲染方案。 所谓首屏离线渲染，就是首屏渲染需要的内容都能从本地存储获得。那么，怎么才能做到这个事情呢？首屏内容一般包括资源和数据。资源就比较简单，使用离线包技术完全可以做到离线化。 数据其实有两种，一种是描述型的 JSON 数据，一种是渲染完成的 DOM 结构数据。描述型的 JSON，一般还需要通过 JS 执行转换为 DOM 结构数据，从性能的角度当然是直接离线获取到 DOM 数据的效果更好。数据离线化一般是通过预取或者存储旧数据来实现。比如，今日头条刷新列表时，就会把列表里的文章内容都下载到本地；再比如，页面应用非首次打开，可以先从 LocalStorage 里获取前一次的数据进行渲染，再同时进行 Dom-Diff 更新。 也就是说，在移动端其实我们也有很多方案能实现首屏离线渲染，实现极速的完美 Web 体验。

Web 与 Native 的融合

那么，是不是说 Web 技术就无缺点了呢？也不是的，在一些特殊场景下，和 Native 技术结合，能带来更好的性能体验。 比如，在地图渲染的场景，在 WebView 中嵌入 NativeView 去渲染，往往可以带来更优的效果。U4 内核也实现了混合渲染技术，可以在 WebView 中嵌入 Native 对象，并和 WebView 进行混合渲染，这些技术在阿里系应用上已经有业务上线，并且推广到了 iOS 端。

在特定时期特定场景，Web 技术与 Native 技术融合，是非常推荐的。在衡量这些技术的价值时，我们往往会考虑，

• 前端是否能通过标准或者标准扩展的方式去使用这些技术
• 这些技术是否能真正为业务带来更优的体验

需要说明的是，绝大部分场景，Web 技术都已经能做得非常好，没有必要为了追求新鲜而硬往 Web 页面插入一个 Native 控件，这会让在分享传播的场景增加额外的适配逻辑。 Web 技术与 Native 技术并不是竞争关系，而是互补关系。Web 技术可以使用 Native 技术去优化特定场景的体验，Native 技术也可以借鉴 Web 技术的成果去促进自身的发展。事实上，JS 引擎和排版渲染引擎也是很多 Native 技术的核心组成部分，而这些一直都在跟随着 Web 引擎的演进而发展。

业务技术选型

我们在进行业务技术选型的时候，是选 Web 技术还是 Native 技术呢，需要考虑什么？

• 技术安全 技术安全主要是指技术是否可控，是否存在解决不了的问题。可控又包括版权，技术支持，技术团队稳定性，等等。 Web 技术天然就是开放共享的，有全世界成千上万的科学家在保驾护航，也有庞大的开源社区，还有世界顶级公司的倾力支持。这些都决定了 Web 技术的根基是非常牢固的，不会因为某些公司策略或团队变动而产生巨大影响。 那么，有没有短时间内难以解决的问题呢？这还真有，往往是因为标准落地较慢，WebView 碎片化，WebView 本身存在 BUG，等等。但是，在阿里体系内，这些其实都不是大问题，U4 内核已经基本覆盖了阿里系的 APP，能较好解决 WebView 碎片化问题，也能较好的解决业务遇到的任何疑难问题。
• 开发成本 通常业务会有非常多的跨端或分享传播需求，比如，页面要跑在支付宝，手淘，钉钉，Android 端，iOS 端，Linux，Windows，新零售终端，曲面屏，等等，这种场景 Web 技术的优势就非常明显了。我们无法预见将来会出现什么端，但我们可以预见 Web 技术能较好的适应所有的端，根源在于 Web 技术是 W3C 标准技术，这就是标准的力量。 那么，在各个端是否存在要适配多个 WebView 的问题呢？这必然是存在的，但问题可能越来越小。2018.12 微软宣布全面转向使用 Chromium Blink 内核，他们的考虑是，Blink 内核发展非常迅速，领先标准很多，如果要快速跟进则成本很大，如果不跟进则会造成 Web 的分裂，综合衡量决定转向使用 Blink 内核。这其实是一个风向标，Web 引擎正在趋向于统一，Web 引擎不想再分裂下去，期望进一步降低 Web 开发的成本。国内也是类似，国内也在快速跟进高版本 Blink 内核，绝大部分 app 里的 Blink 内核版本都超过了 M50，极大的保证了 Web 新特性在各个端的统一。
• 性能体验 性能体验问题，前面已经有比较多的讨论，总结起来就是 Web 性能体验已经能完全媲美 Native 技术。即使一些场景下还有短板，也能使用混合渲染技术去解决。
• 可维护性 可维护性一般有两个方面，长期的维护成本和解决问题的成本。长期的维护成本，其实有很多方面，技术的根基是否牢固，是否有推倒重来的风险，是否存在被禁用的风险。解决问题成本，包括在互联网上是否能快速搜索到解决方案，或者提供技术的团队是否能及时提供有效的帮助。 Native 动态技术其实存在一定的风险，iOS 很可能会禁用一些非标准的 Native 动态技术，Facebook 可能会修改 React 的授权协议。如果在一些关键的时间节点，Native 技术的版本无法上线，就影响比较大了。
• 个人与团队成长 这个就见仁见智了，不同的团队可能有不同的判断。如果从整个集团的角度去考虑，就需要综合衡量所有的点了。

在进行业务选型时，我们应该从业务本身去考虑，从整个集团去考虑，选择更加符合业务发展的技术方案。可能在不同的时期不同的场景，同一个业务有不同的业务选型，这也是很正常的。

未来的 Web 技术

从更长远的方向去看，Web Page 会往 Web App 的方向去发展，浏览器内核也会往操作系统的方向去发展。在将来，很可能浏览器内核就变成了操作系统的外壳，页面通过浏览器内核能够使用越来越多的系统底层基础能力。那个时候的 Web 可能就是现在的 Native 了，只不过它还继续保持着 Web 跨平台容易传播等天然的优点。 这样演进的优点是什么？Web 页面能具备 Native 应用的性能体验，而且不需要下载安装包，能跑在所有的平台，能快速分享传播，多么美好的事情！开发者只需遵循 W3C 标准去开发页面，就能跑在所有平台所有客户端，不需要关心页面是跑在客户端上，还是跑在操作系统上，这就是标准技术的魅力！ 无论 Web 技术如何发展，它必将会继续保持着自由平等开放共享的互联网精神，这些才是 Web 的精髓。