大家好，我是 Beezen，在跨端领域已经摸爬滚打七、八年了，今天想从跨端的历史来和大家聊一聊，我对跨端未来方向的一些小看法。
首先，“跨端”这个概念，我认为早期可以追溯到 1995 年的 SunWorld 大会，随后开发工程师们才越来越多的加入到跨端技术的研究上。在过去的二十年间，出现过非常多的优秀跨端技术方案，比较红火的例如：Cordova、React native 、Weex、小程序技术等等。不过随着时间的推移，前端技术的发展，很多在往日被称为是颠覆性的技术，也变的不再活跃了。这也说明了，每一个跨端技术方案其实都是在解决特定时期的一些跨端问题，至于”跨端“技术的完美解决方案一直没有出现。
有人说过：“重视历史、研究历史、借鉴历史，可以给人类带来很多了解昨天、把握今天、开创明天的智慧。”，那么作为跨端开发研究者的我们，也需要先了解跨端的历史，才能更好把握跨端的未来方向。
跨端技术的历史演进
1995 年 5 月 23 日，在 Sun world 会议上第一次发布 Java。Java 不同于一般的编译语言或解释型语言，它首先将源代码编译成字节码，再依赖各种不同平台上的虚拟机来解释执行字节码，从而具有“一次编写，到处运行”的跨平台特性，这也是我认为较早期的跨端概念。不得不说一下，Java 初期成功的最大原因，就是因为它无与伦比的跨平台能力。
不过，我们今天所要聊的“跨端”技术，还是以当前的互联网环境为背景，特指能适配到各个移动设备终端的技术。
移动互联网早期
在移动互联网早期，我们的手机基本上只有打电话和发短信的功能。不过，在 2008 年 6 月，苹果公司推出了第二代 iPhone 3G ，它是一款智能手机，操作系统为 iOS，能对接应用市场。紧接着 App Store 于 2008 年 7 月 10 日开放，并提供了 500 个手机应用程序。与此同时，另一个操作系统 Android（安卓）也紧随其后被推出，并且门户开放，它的第一款商用运行手机是 HTC Dream。
从此刻开始，我们对手机的使用习惯，正在从电话和短信慢慢转变为社交和娱乐，移动终端系统也正式步入了 iOS 和 Android 二分天下的时代。
附一张各代 iPhone 型号的时间轴图（可供考古）：
（图片来源于互联网）
在这个时期，所有应用的开发，都以原生技术为主，iOS 系统应用的开发语言为 Object-c，Android 系统应用的开发语言为 Java。这也就意味着，我们开发一个 APP 应用程序，至少需要投入 1 个会 Object-c 和 1 个会 Java 的原生开发人员。不过纯原生开发技术，也带来了一些问题，一方面，我们需要花费大量的精力，来保持 iOS 和 Android 两端应用的开发效率和内容表现同步。另一方面，使用原生技术开发的应用，它的迭代周期比较长，并且不再具备热更新能力，每一次功能的改动，都需要重新向应用商店提交审核。整体而言，就是不太能够满足初期业务的快速发展。
于是，大家就不得不怀念起了 Web 技术，它实时更新和快捷开发的优点，能够满足业务快速发展的需求。所以，我们迫切需要原生技术和 Web 技术的融合， PhoneGap 技术大概就是这么来的。
（图片来源于互联网）
最早的 PhoneGap 起步于 2009 年。当时，在旧金山召开的 iPhoneDevCamp 大会上，Nitobi 的工程师在 iOS 系统内架设起 Web 接口和 Objective-C 之间的桥梁，让开发人员得以使用 HTML5、JavaScript、CSS 等 Web 标准技术来便捷的开发原生程序，实现了“一次编译，到处执行”的能力。其中，“桥接 Web 与 iPhone SDK 之间缝隙”的理念得到了大家的广泛认同。
而后 2011 年 10 月 4 日 Adobe 正式宣布收购 Nitobi 软件，PhoneGap 的代码也被贡献给了 Apache 软件基金会，随即 PhoneGap 被正式改名为 Apache Cordova。
所以 PhoneGap 和 Cordova 这两个技术方案是同源的，本质就是针对不同平台的 WebView 做了扩展和封装，使得 WebView 这个原生组件，变成了可访问设备本地 API 的强大浏览器。正是基于这个架构，开发人员才能在 Cordova 框架下，通过 html 和 css 绘制渲染页面，使用 JavaScript 去调用到原生功能。
（图片来源于互联网）
Cordova 技术火热的很大原因，是因为互联网早期积累了大量的 Web 开发从业者，而它的出现，几乎可以让这部分开发者零成本的转型为移动应用开发者。
Cordova 相较于传统 Web 技术，它可以通过 Bridge 访问硬件，比如加速度、相机、指南针、GPS、文件访问等等，这在很大程度上，提升了 Web 应用程序的横向能力和整体的交互体验。同时，它本质是通过 Webview 进行渲染的，在所有的应用设备上都能够兼容使用。而且，应用的内容更新也不再受限。不得不说，Cordova 打开了跨端领域的一个新大门，Bridge 的思想被广泛传播。
不过那几年，移动互联网发展的非常迅速。一开始，大家对移动应用的要求只是简单好用。慢慢的，就开始要求各种交互要流畅，动画要酷炫。而在体验这块，Cordova 应用 比之原生应用确实差了不少，比如：
- 1、运行速度慢，程序载入和 UI 界面交互的反应都要比原生的慢。
- 2、内存消耗大。
- 3、动画效果卡顿，体验差。
从本质上讲，Cordova 技术依旧属于 Web 技术，只是在 Webview 容器上拓展了部分调用原生的能力。于是，大家就开始思考，既然 Web 渲染满足不了体验，那么是否可以将 Web 技术转为原生渲染。
移动互联网中期
React Native (简称 RN)是 Facebook 于 2015 年 4 月开源的跨平台移动应用开发框架。它是 Facebook 早先开源的 JS 框架 React 在原生移动应用平台的衍生产物，支持 iOS 和安卓两大平台。RN 使用 Javascript 语言（类似于 HTML 的 JSX 语法），以及 CSS 来开发移动应用，因此熟悉 Web 前端开发的技术人员只需很少的学习成本，就可以进入移动应用开发领域。
Weex 是阿里巴巴于 2016 年 6 月 30 日开源的跨平台移动应用开发框架，开发者只需要在自己的 APP 中嵌入 Weex 的 SDK，就可以通过撰写 HTML/CSS/JavaScript 来开发 Native 级别的 Weex 界面，同 React Native 类似。值得一提，它的核心思想来源于 RN ，而开发语法基本于 vue 一致，所以也有人戏称为 “Vue Native”。
React Native 和 Weex 技术的出现都是为了解决 Web 容器加载、解析和渲染慢的这些问题，他们都是放弃了采用浏览器控件渲染，而由原生接管绘制的方案。坦白来讲，这两个跨端技术的受关注度高，在一定程度上是受益于它们各自的 DSL 语言，React Native 技术衍生于 React，Weex 技术衍生于 Vue。它们都是采用了响应式编程方式（为你应用的每一个状态设计简洁的视图，当数据变动时，框架能高效更新并渲染合适的组件），从而让开发者创建交互式 UI 变得轻而易举。
原生渲染技术原理如下图：
因为用 React Native 和 Weex 跨端技术开发的 APP 应用，交互体验与原生 APP 相差不大，而且开发效率非常高。所以，从该类技术出现后，国内外的公司都投入了大量的人力和物力，进行各类 APP 的研发，来抢占市场先机。随之而来的现象就是，各大应用商店上架的 APP 数量，一下子出现了爆发式的增长，各种混合包，马甲包（一种利用应用商店规则漏洞，通过技术手段多次上架同一款产品的方法。）占据了主要数据，这就导致了应用商店的产品质量被极大的降低，用户频繁吐槽和举报下载了假的 APP。
很快，各大应用商店采取了相应的措施，对这部分用 RN、Weex 混合技术开发的应用，提高了审核通过的要求。一时间，大量的 APP 上不了架，严重的影响了各家业务的发展。于是，有心人就开始思考，能不能自己做应用市场，那不就不再受限于 APP 审核了嘛。
2017 微信小程序正式发布，而它是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户通过扫一扫或搜一下即可打开应用。它一方面解决了用户想在短时间内获取服务，而不需要下载 APP 的问题。另一方面，它开发了一个新的商业模式，借助微信 APP 本身的大流量很方便的帮助商家从线上引流，扩大营销渠道，沉淀用户的需求。于是乎，那些拥有巨大流量 APP 的背后巨头也纷纷效仿，开发自己的小程序平台。
各个平台小程序分布图：
（图片来源于互联网）
2018 年，阿里、百度、字节跳动、手机厂商等各大巨头纷纷发布自己的小程序。这里有个小插曲，同年 12 月，Flutter 1.0 在 Flutter Live 活动中发布，是该框架的第一个“稳定”版本，不过因为在小程序发展时期，它在国内没有得到应有的热度。2019 年，QQ 也加入战局，各家小程序全面开花，从此正式进入终端碎片化时代。
附上小程序基础架构图：
这个时期，我认为还是相对混乱的，市面上端的形态多种多样，Web、React Native、微信小程序、支付宝小程序、快应用等各种端大行其道。当业务要求同时在不同的端都要求有所表现的时候，针对不同的端去编写多套代码的成本显然非常高。而且很多开发者也苦不堪言，一会写微信小程序语法，一会写快应用语法，一会又写 Web 和 React Native，可能自己都不清楚自己到底擅长哪个技术了。
这时候只编写一套代码就能够适配到多端的能力就显得极为需要。于是，各种基于 react、vue、原生小程序或者自定义 DSL 语法的跨端框架如雨后春笋般出现。
各种跨端框架（此处只列举部分热度较高框架），按照出现的时间排列如下：
- WePY，一款类 vue 语法规范的小程序框架，第一个版本是腾讯团队在 2016 年 12 发布。
- Mpvue，是一个使用 Vue.js 开发小程序的前端框架，由美团团队在 2018 年 3 月开源。
- Taro，是一个开放式跨端跨框架解决方案，由京东的凹凸实验室团队在 2018 年 6 月开源。
- Uni-app，是一个使用 Vue.js 开发所有前端应用的框架，由 DCloud 团队在 2018 年 7 月开源。
- Mpx， 是一款具有优秀开发体验和深度性能优化的增强型跨端小程序框架，由滴滴团队在 2018 年 12 月开源。
- Chameleon，是一个有理想的能适应不同环境的跨端整体解决方案，由滴滴团队在 2019 年 8 月开源。
- Remax，是使用 React 构建跨平台小程序的框架，由蚂蚁金服在 2019 年 8 月开源。
大概经过了 3~4 年的跨端技术发展，我们可以很清晰的看到，目前较为活跃的跨端框架还剩下 Taro 和 uni-app。Taro 在 github 的 Star 31.1k+，Fork 4.2k+， Issue 8k+。 Uni-app 在 github 的 Star 36.7k+，Fork 3.3k+，Issue 3k+。Taro 和 uni-app 各自的官方技术交流群总人数也都超 1W+，日常各种帖子和讨论也非常活跃。(数据统计时间：2022 年 6 月)
附两个跨端框架的介绍图：
移动互联网后期
在移动互联网后期，我们不难发现很多框架技术也开始归于稳定了。
在国外的环境下，移动端跨端技术在经历数年沉浮之后，如今还能在舞台聚光灯下雀跃的，只剩下 React Native 和 Flutter 了。
Flutter 是性能与构建思路几乎最接近原生开发的框架，又能够满足跨端开发的需求，所以社区一直对它保持着持续的关注（虽然在国内不够火）。React Native 虽然它的热度已经大不如前，期间还爆出 Airbnb 要弃 React Native 坑而逃，回归原生技术开发的各种消息，但是它积累的开发者数量是极其巨大的，而且技术背后的 Facebook 公司依然不轻言放弃，俗话说“瘦死的骆驼比马大”，所以 React Native 技术依然有很多使用者。
在国内的环境下，当下话题最多的，无疑是小程序技术，各个巨头也都是打着全民拥抱小程序的口号，各个头部 APP 也不停的衍生出各类的小程序应用。毫无疑问，Taro 和 uni-app 这两个一直保持着较高热度的小程序跨端开发框架，是小程序时代的明星。
小结
移动互联网早期，主要采用的是原生应用内嵌浏览器控件 WebView（iOS 为 UIWebView 或者 WKWebView，Android 为 WebView）的方式进行 HTML5 页面渲染，并定义 HTML5 与原生代码交互协议，将部分原生系统能力暴露给 HTML5，从而扩展 HTML5 的边界。
移动互联网中期，优化了早期 Web 容器的加载、解析和渲染这三大过程，把影响他们独立运行的 Web 标准进行了裁剪，以相对简单的方式支持了构建移动端页面必要的 Web 标准；同时，这个时代的解决方案基本上完全放弃了浏览器控件渲染，而是由原生接管绘制。小程序技术算是另一种跨端技术方向，采用了双线程运行机制，同层渲染技术。各种跨端技术也是遍地生花，有老牌技术，有自绘引擎的，有通过框架混合开发的等等。
移动互联网后期，各大框架归于稳定，RN、flutter、Taro、uni-app 还保持着活跃。
附上各个技术出现的时间线图：
跨端技术的未来方向
我们回顾了跨端开发的历史，从早期的纯原生和纯 Web 技术演变为 Web 容器技术，再到后来的泛 Web 容器技术，直至重回原生渲染技术以及小程序技术。可以发现在早期我们更注重的是开发效率，而慢慢的我们越来越重视交互和性能，直至现在因为各种端的精细化，我们需要不仅重视开发效率，同时也要重视应用性能。
覆盖更多的终端
1、IoT 方向发展。
IoT 是由互联互通的设备所组成的网络，网络中的设备通过传感器、软件或其他技术的嵌入，能够与其他设备和系统进行数据交换。而现阶段，IoT 行业正在加速演化发展。
得益于技术爆炸和市场需求的不断扩大，IoT 拥有可观的市场前景。根据 IDC 预测，到 2025 年，全球 IoT 设备数量将达到 416 亿个，并产生 79.4 ZB（泽字节）的数据，在 2018-2025 年，IoT 设备数据量的复合年增长率（CAGR）预计将高达 28.7%。Gartner 物联网研究副总兼分析师 Alfonso Velosa 认为，在未来几年里，IoT 的增长率将持续高于 30%。
物联网可以很好地提高效率和节约成本，像我们熟悉的智能家电，家里的空调、电饭煲、电风扇、音响等，都已经可以方便的联网。同时就杭州这个城市来说，已经有很多东西开始联网了，比如红绿灯、路灯、交通治安摄像头、垃圾分类箱、公交等等。
很多人都相信，未来人工智能机器将取代人类的绝大部分工作，人将不再需要工作，会进入到一种类似于共产主义的社会，专心生活。
那么对于开发者来说，端的概念就不再局限于手机和电脑端，而将是会覆盖到 TV、车载、家用电器等等。而前端的 JavaScript 作为一门脚本语言，它在各种端、各种平台上面都有一致性的实现，在服务端、网页、无线客户端、嵌入式里面都可以一致的使用，目前热度比较高的是 ruff 技术（支持 JavaScript 开发应用的物联网操作系统）。所以我们预测在 IoT 的方向发展上，跨端技术一定有它的一席之地。
一个阿里云 Ruff 接入的例子（空气质量监控应用）：
2、桌面端小程序。
现在，桌面设备在很多情况下已经成了生产力工具，如果在工作场景下能够脱离手机，不在设备间来回跳转，是一种非常顺畅的体验。
在有了微信桌面端小程序后，我们不用在电脑版微信上对着「「收到一个小程序，请在手机上查看」的提示时，无奈地再去找手机了，特别是现在已经习惯了将某个功能，以小程序的形式分享给朋友。
为了适应快节奏的社会，我们越来越注重，移动终端和桌面设备的数据同步，在移动终端上的应用功能也希望能够在桌面终端上同时使用。目前就小程序来说，我们预测未来会产生大量的桌面端小程序，而框架开发者需要将支持功能同步生效到移动端和桌面端，业务开发者则需要多覆盖桌面应用一端。
3、更多中大型 APP 支持小程序形态。
在国内市场环境的影响下，各个头部 APP 利用小程序技术已经收获了大量的红利。那么，接下来必然有更多的中大型 APP 团队，会相继发布自己的小程序技术平台，例如：小红书、知乎、大众点评，携程等等。
一个小程序平台的背后，它需要涵盖三个方面的技术。第一个是底层的平台服务，主要负责小程序的审核发布，资源托管，以及资源更新。第二个是小程序容器，因为小程序是运行在 APP 里的，所以需要一个特定的 APP 容器来解析小程序，以及让小程序能够通过容器调用 APP 的原生能力。第三个是小程序编译时和运行时框架，负责将特定的 DSL 语法解析为 Webview 能够运行的应用程序。
以上这些内容对于平台方来说，如果选择自研则需要投入大量的开发资源，如果不想自研，则可以使用头部公司对外发布的小程序容器 SDK 技术，例如：GMU、FinClip、mPaaS、Unisdk 等。不过不管如何，在未来一定需要更多的跨端开发者来支持这些新生的小程序形态。
同时，在平台方发布了自己的小程序平台后，如果想让更多的开发者参与进来，可能还需要对接像 Taro 和 uni-app 这类跨端框架。不难发现，Taro 的开发介绍中，现在所支持的三方小程序平台也是越来越多，因为小程序技术发展实在太快了，Taro 团队无法做到对所有的小程序平台技术的及时跟进，所以为此开放了插件机制，能够让各个小程序平台通过插件的机制接入到跨端框架中。
近期各大厂商都在组织小程序语法的标准制定，但恰恰微信没有积极的去参与，所以短期内肯定无法做到标准统一。那么对于开发者而言，每新增一个小程序平台，我们则需要接触和学习一种新的小程序语法。所以对跨端技术整体而言，在很长一段时间里，会要花费大量的精力去做各个小程序平台语言的兼容适配。（感觉在走浏览器老路(＞ x ＜) ）
注重更高的性能
传统的 RN、Weex 技术等，都是采用了 JS 逻辑引擎计算，原生渲染引擎再次渲染绘制的方式。如果通信的数据量极大，又或者通信数据频率极高，就必然会面临通讯阻塞或者缓慢的问题，从而一定程度上导致 APP 的使用卡顿。所以在渲染引擎，亦或是逻辑引擎的算法和通信架构设计上急需一次突破。
小程序技术与 RN 或 Weex 相比，在技术上大同小异，在渲染上的区别是小程序是通过 Webview 的浏览器内核来进行渲染，其中部分组件采用同层渲染的技术方式优化体验，所以在整体体验上还是差于 RN 和 Weex 不少。那么对于小程序技术而言，未来也必然会着重于渲染引擎和逻辑引擎的架构设计，甚至会优化渲染技术方案。
Flutter 技术采用了自绘引擎的方式，可能是为跨端技术给出了一个新的方向，目前在 Github 上的 star 数为 142k，已经远超 react-native 的 103k。那我们是否需要转型到 Flutter ？目前可以先进行研究和验证，虽然 Fullter 的整体性能是完全优于 RN 的，但毕竟整体的生态还是差了 RN 不少，还不够便捷。
同时还有阿里巴巴-染陌在 GOTC 大会上分享的 Kraken，它和 Flutter 一样也是采用了自绘引擎的方式，来提升数据交互效率，以及使跨端一致性更高。其实 Kraken 可以理解为只对前端层进行了 DSL 的解析，然后生成了可以被 Flutter 框架渲染的 RenderObject Tree，后面的逻辑和 Flutter 就一致了。
Flutter 的出现对于跨端开发者的启发，可能不局限于探索自绘引擎，甚至可以考虑放下历史包袱，从零点重新设计。
持续提升开发效率
现阶段我们通过跨端框架 Taro，uni-app 已经能够使用一套代码，同构编译到各类平台应用产品，这种方式可以极大的降低开发和维护成本。这类跨端框架能够帮助开发者抹平各个平台小程序的细微语法差异，以及通过自定义插件的形式，可以让更多的新生平台小程序接入，以及会衍生出更多的定制化配套功能。所以在后续的一段时间里，定然还会是一个极其热门的研究方向。
而另一方面则是智能化领域，市面上各种智能化的底层概念大概有 D2C、P2C、S2C、C2C、F2C 等，对应的工具和产品有 imgcook、deco、imove 等等，而基于这些搭建的轻服务例如：阿里云函数计算、字节跳动轻服务、腾讯云函数、AWS Lambda 等等。从团队的组织架构也可以发现大厂都有研究低代码，AI 智能化的对应团队，所以能够明显感觉到，智能化平台会在未来一段时间里持续发力。它的核心思想是输入偏向于商业的内容或者模型然后通过一系列自动化手段，智能输出对应的产品。它可以帮助企业降低产品整体的开发成本，同样让更多的工程师们可以聚焦到业务开发中，回归商业的本质。
那么，我们可以将跨端框架和智能化平台相结合，假设我们能够通过智能化平台拖拽生成一个项目模板，然后再通过跨端框架将其编译成对应的平台小程序或者 APP，这就极大的提升了开发效率，并能够降低开发跨端项目所需要的技术人员的能力门槛，也从侧面降低了研发成本，我认为这一定也是一个非常有价值的研究方向。
