共计 2771 个字符,预计需要花费 7 分钟才能阅读完成。
阿里的大佬们曾总结,「一般来说,跨端技术有 4 类场景,别离是跨设施平台(跨 Web
端和手机端)、跨操作系统(如跨 Android
和iOS
)、跨 App
以及跨渲染容器。」
而其中挪动端的跨平台技术始终以来都是很炽热的话题,在当初都不看好客户端技术天花板的背景下,客户端的将来仿佛在逐步朝着跨平台方向歪斜。
跨平台计划的劣势非常显著,对于开发者而言,能够做到一次开发,多端复用,一套代码就可能运行在不同设施上。这在很大水平上可能升高研发老本,同时可能在产品效力上做到疾速验证和疾速上线。
然而,挪动端的跨平台技术并不是仅仅思考一套代码可能运行在不同场景即可,还须要解决性能、动态性、研发效率以及一致性的问题。
性能: 如何通过前端和客户端的联合,实现更优的渲染性能以及交互性能;
动态性: 客户端怎么可能实现更低成本的发版、甚至不发版间接动静更新代码;
研发效率:如何晋升不同客户端的动静调试之类的研发效率;一致性: 如何实现一份代码的多端部署,并保障代码在多个客户端内展现状态的一致性以及兼容性问题。
现在,也曾经呈现了如WebView
、React Native
、Weex
、Flutter
、小程序等泛滥的挪动端跨平台框架。然而行业内统一呈现出群雄争霸的局势,并没有哪一种框架能够真正上说能给完满解决以上的问题,同时博众人之所长,一超多强。
1 WebView
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
的原生体验。原生体验永远是跨端技术谋求的终极目标。
2 React Native
为了谋求下面说过的原生体验的问题,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
大量实时交互的性能可能会有性能上的有余,比方动画效率,性能仍旧是不如原生的。
3 Flutter
Flutter
是谷歌外部孵化的挪动端跨平台 UI
框架,它是在 RN
被饱受质疑的时候提出,算是目前最靠近原生体验的框架。
从底层原理上来说,它既没有采纳 WebView
与H5
混编的模式,也没有采纳 JavaScript
通过 Bridge
进行桥接的模式,而是本人实现了一套 UI
框架,间接在更底层进行 UI
渲染。不仅如此,它也不再采纳 JavaScript
作为开发语言,而是抉择了 Dart
。称Dart
语言能够编译成原生代码,间接跟原生通信。
之所以抉择 Dart
,其实Flutter
团队在晚期就评估了十多种语言,并抉择了Dart
,因为感觉它合乎他们构建用户界面的形式,并且还具备以下劣势:
1
Dart
是AOT (Ahead Of Time)
编译的,编译成疾速、可预测的本地代码,使Flutter
简直都能够应用Dart
编写。\
2Dart
也能够JIT(Just In Time)
编译,开发周期异样快,工作流颠覆惯例(包含Flutter
风行的亚秒级有状态热重载);\
3Dart
能够更轻松地创立以60fps
运行的晦涩动画和转场。Dart
能够在没有锁的状况下进行对象调配和垃圾回收。\
4Dart
使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
交互的跨端一致性。