关于客户端:跨端技术都这么牛了客户端还有前途吗

6次阅读

共计 2771 个字符，预计需要花费 7 分钟才能阅读完成。

阿里的大佬们曾总结，「一般来说，跨端技术有 4 类场景，别离是跨设施平台（跨 Web 端和手机端）、跨操作系统（如跨 Android 和iOS）、跨 App 以及跨渲染容器。」

而其中挪动端的跨平台技术始终以来都是很炽热的话题，在当初都不看好客户端技术天花板的背景下，客户端的将来仿佛在逐步朝着跨平台方向歪斜。

跨平台计划的劣势非常显著，对于开发者而言，能够做到一次开发，多端复用，一套代码就可能运行在不同设施上。这在很大水平上可能升高研发老本，同时可能在产品效力上做到疾速验证和疾速上线。

然而，挪动端的跨平台技术并不是仅仅思考一套代码可能运行在不同场景即可，还须要解决性能、动态性、研发效率以及一致性的问题。

性能： 如何通过前端和客户端的联合，实现更优的渲染性能以及交互性能;

动态性： 客户端怎么可能实现更低成本的发版、甚至不发版间接动静更新代码；
研发效率：如何晋升不同客户端的动静调试之类的研发效率；

一致性： 如何实现一份代码的多端部署，并保障代码在多个客户端内展现状态的一致性以及兼容性问题。

现在，也曾经呈现了如WebView、React Native、Weex、Flutter、小程序等泛滥的挪动端跨平台框架。然而行业内统一呈现出群雄争霸的局势，并没有哪一种框架能够真正上说能给完满解决以上的问题，同时博众人之所长，一超多强。

WebView简略来说就是用来展现 HTML 的容器，用官网的话讲，叫做：

A View that displays web pages. This class is the basis upon which you can roll your own web browser or simply display some online content within your Activity. It uses the WebKit rendering engine to display web pages and includes methods to navigate forward and backward through a history, zoom in and out, perform text searches and more.

来给大家翻译一下：

用来显示网页的视图。这是用来运行你本人的 Web 浏览器或只再在利用中显示一些线上内容的根底。它应用 WebKit 渲染引擎显示网页，并包含在浏览历史中导航，放大和放大以及执行文本搜寻等办法。

所以简略来说，WebView就像是一个浏览器，可能在外面加载和渲染各种 HTML 的页面。而同时，WebView个别继承于原生客户端的 UI 基类。所以，对于原生利用来说，WebView自身通过加载 h5 页面、通过 Chromium/WebKit 内核解析并进行 UI 合成，生成客户端原生的 UI 类，而后上屏展现。

而 html 页面与 native 的沟通交互则是通过所谓的 JSB (JavaScript Bridge) 来实现的。客户端将原生零碎级的接口进行封装，而后通过 JSB 裸露给 WebView 中前端页面进行调用。实质上这就是原生零碎 API 与前端页面 Javascript 的通信。
这样一来，前端开发者也能够很快地实现页面跨端，通过 JSB 与原生零碎进行沟通，保障跨端利用在整体上的能力买通和互相调用。

只不过，这样的机制劣势也很显著，就是前端页面与原生零碎的通信齐全取决于 JSB 的结构，如果 JSB 中短少调用原生能力的接口，那跨段能力也会间接受限。这种状况下仍旧须要别离裁减原生利用中的 JSB 接口，反而升高了开发效率。

此外，WebView对 UI 的渲染依赖于浏览器内核，而浏览器内核又独立于零碎组件，所以无奈保障跨端 UI 的原生体验。原生体验永远是跨端技术谋求的终极目标。

为了谋求下面说过的原生体验的问题，Facebook在 2015 年则推出了非常炽热的React Native，简称RN。

RN相较于 WebView，最大的区别就是不再应用浏览器内核进行UI 渲染，而是应用一个叫做 Virtual DOM 的货色来进行跨端 UI 渲染的治理。

Virtual DOM和 DOM 实际上差不多，都是一个树形构造，在不同节点上记录了 UI 的不同元素。只不过 Virtual DOM 将渲染工作是交给了原生渲染引擎，比方 web 浏览器、iOS、Android，去解决。之后，不同平台仍旧是通过对应的 Bridge 来创立不同的 Native 视图。

这样以来，体验有肯定的晋升。只不过 React Native 和原生交互依赖的只有一个 Bridge，而且JS 和Native交互是异步的，所以对须要和 Native 大量实时交互的性能可能会有性能上的有余，比方动画效率，性能仍旧是不如原生的。

Flutter是谷歌外部孵化的挪动端跨平台 UI 框架，它是在 RN 被饱受质疑的时候提出，算是目前最靠近原生体验的框架。

从底层原理上来说，它既没有采纳 WebView 与H5混编的模式，也没有采纳 JavaScript 通过 Bridge 进行桥接的模式，而是本人实现了一套 UI 框架，间接在更底层进行 UI 渲染。不仅如此，它也不再采纳 JavaScript 作为开发语言，而是抉择了 Dart。称Dart 语言能够编译成原生代码，间接跟原生通信。

之所以抉择 Dart，其实Flutter 团队在晚期就评估了十多种语言，并抉择了Dart，因为感觉它合乎他们构建用户界面的形式，并且还具备以下劣势：

1 Dart是 AOT (Ahead Of Time) 编译的，编译成疾速、可预测的本地代码，使 Flutter 简直都能够应用 Dart 编写。\
2 Dart也能够 JIT(Just In Time) 编译，开发周期异样快，工作流颠覆惯例（包含 Flutter 风行的亚秒级有状态热重载）；\
3 Dart能够更轻松地创立以 60fps 运行的晦涩动画和转场。Dart能够在没有锁的状况下进行对象调配和垃圾回收。\
4 Dart使 Flutter 不须要独自的申明式布局语言，如 JSX 或XML，或独自的可视化界面构建器，因为 Dart 的申明式编程布局易于浏览和可视化。

Flutter与上述 Recat Native、WebView 容器实质上都是不同的，它没有应用 WebView、JavaScript 解释器或者零碎平台自带的原生控件，而是有一套本人专属的 Widget，所有组件基于Skia 引擎自绘。

Flutter因为是通过本人的引擎进行 UI 渲染，因而在 iOS 和Android的成果基本一致。相比之下，RN是将 UI 控件转换为对应平台的原生控件，所以不可避免的会存在肯定差别。

从技术角度来看，RN 实际上就是在 Native 容器中提供了 JavaScript 的运行环境，然而其布局引擎，渲染层都采纳的是 Native 的控件，因而 UI 交互上依然存在零碎差别。而 Flutter 计划更彻底一些，连渲染层也换成了基于图形引擎自绘 UI 控件，从而保障 UI 交互的跨端一致性。

正文完