移动端跨平台技术演进之路

移动端高速发展的这些年，伴随着企业对研发效率、动态能力的诉求不断增加，跨平台技术也如雨后春笋层出不穷。那么，在这篇文章中将向大家分享移动端跨平台技术演进之路。首先我们看为什么需要跨平台技术？

为什么需要跨平台技术？

为什么需要跨平台技术

一方面伴随着移动互联网的高速发展，公司间竞争越来越激烈，如何将业务快速落地、快速试错，成为备受关注的问题。
另一方面，提升研发效率、缩短研发周期，保障产品快速试错并能快速迭代新功能，让新产品新功能以更快的速度同触达 Android、iOS 等多端用户是当今企业的一致的诉求。

众所周知，Android 应用需要采用 Java/Kotlin 来编写，iOS 应用需要采用 Objective-C/Swift 来编写，Web 需要端采用 HTML /CSS/JavaScript 来编写。这就导致当需要开发支持多端的应用，每一端都需要独立研发、测试，一直到上线，以及后续的维护工作，工作量成倍增涨，势必延长研发周期，拖慢产品迭代的节奏。

为了解决多端需要独立开发的问题，跨平台技术便应运而生，国内外互联网公司为此都投入大量人力，于是出现了各种跨平台技术框架。

跨平台框架发展总览

移动端跨平台技术演进之路

石器时期

这个时期还没有相应的跨平台开发框架，开发者使用的是最原始的HTML + CSS + JS的方式进行的应用开发。

HTML

时间：1993

HTML是一种用于创建网页的标准标记语言。HTML + CSS + JS 这样的组合是历史上最成功跨平台开发的例子。

在这个时期存在的最大的问题还是开发体验问题，你无法想象开发一个功能，代码要适配N个不同版本的浏览器。
这个在iOS上还好，在Android上因为其碎片化的问题，使得开发适配成本很大；有过前端开发经验的小伙伴会深有感触。

Hybrid时期

在这个时期开始陆陆续续有一些跨平台开发框架出来，比较有代表性的有：Cordova、Ionic。

Cordova

时间：2009

Cordova的前身是PhoneGap，通过它可以使用HTML, CSS & JS进行移动App开发。

Ionic

时间：2013

Ionic是基于AngularJS和Cordova构建的一个轻量的手机UI库，具有速度快，界面现代化、美观等特点。

虽然在Hybrid时期，开发体验提升了；但是APP的实际运行性能和流畅度和原生APP还是没法比。
于是呢，不少公司和开发者开始琢磨如何既能兼顾开发体验又能提升APP的运行性能。其实，制约Hybrid应用的性能的主要因素是：

网络传输速度，造成前端数据呈现延迟（css，js等资源）；
webview 容器带来的限制和JavaScript的单线程；

浏览器解析渲染 DOM Tree 和 CSS Tree，解析执行 JavaScript，几乎所有的操作都是在主线程中进行。

当认识到Hybrid应用的性能瓶颈之后，我们不妨有个大胆的想象：

是否可以将业务代码和UI用JS+CSS来实现，而渲染交给原生来处理，这样就可以摆脱webview的束缚，做到开发体验和性能兼得。

来自大洋彼岸的FB的工程师们做到了，他们将这个方案叫做React Native；React指的是React.js一个前端开发框架，通过JS+CSS开发；后面加个Native主要有两层含义：

这些"JS+CSS"最终会被解释称原生控件；
有着Native的性能体验；

RN的出现这标志值移动端跨平台开发进入OEM时期。

从这个案例中告诉我们：作为工程师来说永远不要限制自己的想象；要能够大胆的假设，万一实现了。

OEM时期

在这个时期框架会进行DSL层的封装，UI最终会被渲染成Android/iOS原生的控件。

React Native

时间：2015

React Native是Facebook开源的一套基于React的跨平台开发框架。它的出现标志着跨平台开发框架进入了OEM时代。

RN的开源掀起了国内的跨平台开发的热潮，国内一些互联网大厂纷纷投入RN的阵营；
有实力的大厂也开始对RN做些魔改，使其能够适应自己公司的业务；比较有代表性的就是阿里的Weex；
当然也有些很多大厂基于RN做了一些封装，但没有开源，所以大家可能不知道，比如：携程的CRN，就是携程内部的RN；

Weex

时间：2016

Weex是阿里开源的一套使用流行的 Web 开发体验来开发高性能原生应用的框架。

Weex可是说是国内的RN，它和RN最大的不同是它天生支持bundle拆分，一个页面一个JS bundle更加适合国内企业的使用场景；
另外，Weex支持Vue.js和Rax框架开发，Rax是阿里的一套基于React协议的轻量，高性能，易上手的前端开发框架；

看似OEM时期的方案很完美，但是还是有不少的问题：

OEM框架本身的维护成本高：
- 主要是因为这些OEM框架提供的组件依赖于原生的空间，那么这些Android和iOS控件可不是一成不变的，系统厂商会时不时地做一些迭代，那么一旦有了这些迭代
  OEM的组件也不得不做出适配，这个适配成本是很高的；
- 另外，因为最终呈现给用户的这些控件是系统厂商提供的，而Android和iOS又有着天然的行为和特性上的一些差异，所以导致OEM框架要想抹平这些系统的差异，不仅成本高而且有些是根本做不到的
  ，比如：RN的一个日期选择组件，有不止一个小伙伴问过我，为什么RN的日期选择组件在Android和iOS上运行的效果差别这么大呢。
重平台特性和产品追求一致的体验的矛盾：
- OEM框架是比较重平台特性特性的，其实"重平台特性特性"这句话是来自RN团队的，可以看出RN团队对外宣称RN的重平台特性是无奈的；
- 因为RN框架本身的特性限制了它不得不重平台特性，这就导致了它和大部分产品所期望的在不同平台能够有一致的体验所矛盾；有很多团队和公司为了解决这个矛盾，不得不通过自定义组件来解决，自定义组件的成本是很高的，需要有原生开发经验的Android和iOS同学才能搞得定；

自渲染时期

在这个时期框架不在做OEM时期控件的搬运工，而是另起炉灶，自己不仅负责上层UI的封装，而且也负责底层界面的渲染。

Flutter

时间：2017

Flutter是一个由谷歌开发的跨平台开发工具包，用于为Android、iOS、 Windows、Mac、Linux、Google Fuchsia开发应用。

我在这里时间标的是17年，17年可不是它真正诞生的时间，17年是它被大众所熟知的一年；
在《移动端架构师成长体系课》中有讲到，如果追溯Flutter的起源的话可以到2014年，那时它还叫Sky，Sky是它当时的一个发开代号；在2015年的时候才被改名为Flutter；
在2017年Google I/O大会上，Google正式向外界公布了Flutter，这个时候Flutter才正式走进大家的视野；
Flutter不同于OEM时期的框架是，它采用Dart来实现上层UI，然后底层基于Skia来进行渲染，从而摆脱了Android和iOS 传统控件的束缚；

参考

移动端架构师

以上就是移动端跨平台技术演进之路的全部内容，喜欢❤️的小伙伴可以点赞关注一下哦😘。