移动端跨平台技术之下的变与不变

一.跨平台，是想跨哪些平台？

目前（2020/7/18）来看，移动端跨平台需求主要集中在：

跨 PC 端与移动端：PC 向无线过渡的早期，希望 PC Web 与移动 Web 复用同一套代码
跨 Native 与 Web：商品详情页等要求有一套功能差不多的 Web 页能够在端外访问，需要跨 Native App 与 Web
跨 Native 双端：出于开发效率等原因，希望 Android、iOS 双端复用一套业务代码
跨 App：一些产品功能期望能在多个渠道投放上线，以工具类需求为主，如打车、买票、点餐

在可预见的未来，可能还会有这些跨平台需求：

跨轻应用：系统级即用即走的轻量级应用，如Android 快应用、iOS App Clips
跨 IoT 设备：各种有显示屏的设备都会成为新的“端”，如车载设备、智能家居
跨一切客户端：可能是伪需求，同一产品在不同平台的侧重点不同，或许并不需要把所有功能完整地搬到各式各样的客户端设备/平台渠道上，例如快应用与 Native App 的定位显然不一样

在这样的时代背景下，无论从资源成本、开发效率，还是从产品迭代、技术演进的角度来看，跨平台开发都是强需求，所以才有了层出不穷的各种跨平台方案探索

二.层出不穷的跨平台技术

细数近几年业界主流的移动端跨平台方案，可大致分为 3 类：

Web 生而跨平台：只要有浏览器或 WebView，依托 Web 技术即可轻松跨平台，如 Web App、PWA（Progressive Web Apps）、Hybrid App、PHA（Progress Hybrid App）
容器化 Native 跨端：将 Native App 改造成标准化的容器，进而允许一套代码跨多端标准容器运行，如 React Native/Weex、Flutter
小程序一码多投跨 App：国内市场中，越来越多的超级 App 支持了小程序，但各自的小程序框架并没有统一标准，于是有了Taro、kbone、uni-app等一系列跨小程序框架的方案来满足跨 App 投放产品功能的需求

跨平台：Web 与生俱来

跨平台是 Web 与生俱来的优势，浏览器和 WebView 都是 W3C 规范下的标准化 Web 容器，因此 Web 页面能够轻松投放到端外浏览器、端内 WebView、以及其它 App 提供的 WebView 中

单从成本角度来看，Web 方案是跨平台的不二之选：

没有额外的学习成本：一套基础技术吃遍端内、端外、甚至 PC 浏览器、电视机顶盒
不依赖特殊的配套设施：开发、调试、构建、发布、监控、运维等所有工程化环节都是通用的
坐拥庞大的既有生态：npm 百万模块，应有尽有
Web 基于开放标准：走出去引进来都不是难事

并且，Web 本身就是一个平台，退可守，技术风险更低

但在另一些方面，依靠 Web 技术跨端也存在其局限性：

平台能力：受限于 Web 标准容器，无法满足平台能力相关的需求，如相机、蓝牙、多媒体等
体验：移动端 Web 体验远不及 Native，主要体现在首屏加载慢、动画卡顿、长页滚动闪烁等场景
性能：内存消耗大、GPU 利用率低

加上 Web 标准更迭慢，新特性兼容性差（如Push API过去许多年了，仍然无法放心使用），Web 基础能力难以满足 Native 端的需求。因此，在传统 Web App 的基础上，展开了更多的探索：

PWA（Progressive Web Apps）：离线缓存、系统通知、主屏图标等类 Native App 能力加持之下的 Web App，但兼容性并不乐观
Hybrid App：Web 与 Native 混合的方案，将由 Native 实现的平台能力（比如扫描二维码）注入到 WebView 环境供 Web App 使用，以扩展 Web 的平台能力
PHA（Progressive Hybrid App）：PWA 与 Hybrid 思想的结合，通过 Hybrid 手段让 Web 的性能和体验接近 Native

PWA 标准化似乎走不通，即便走通了能够真正放心用起来可能也是数年之后了。Hybrid App 解决了一部分问题（平台能力扩展），但还不够。PHA 是这两种思路的延续，借助 Native 技术实现 PWA 的梦想

但无论 PHA 还是 HA，引入 Native 依赖都意味着 Web 开放性的损失，继而带来跨端、跨 App 方面的问题

跨端：容器化 Native

除 Web 天然跨端之外，另一种统一多端的思路是将 Native 定制成标准容器，让同一份代码跑在一个个标准容器中，例如：

Android 容器：Native 壳 App
iOS 容器：Native 壳 App
Web 容器：Web Runtime

React Native 跨 Android、iOS、Web、Windows 四端，Weex 跨 Android、iOS、Web 三端，Flutter 以类似的方式跨 Android、iOS、Web、Linux 四端

从技术角度来看，RN 与 Weex 在 Native 容器中提供了 JavaScript 运行环境，以及布局引擎，渲染层都采用 Native 控件，因此 UI 交互上仍然存在系统差异。而 Flutter 方案更彻底一些，连渲染层也换成了基于图形引擎自绘 UI 控件，从而保证 UI 交互的跨端一致性

然而，由于容器化 Native 的方案是从 Native 出发，没有跨端天赋，除了要想办法支持 Web，还面临一个更难解决的问题——跨 App

跨 App：小程序一码多投

技术视角下，小程序跨 Native App 仍然是依靠 Web 方案，那么，为什么不直接用 Web App 呢？

由于商业竞争等因素，闯入别人家地盘的 Web App 通常会遭到一些限制，如安全警告、权限控制、甚至干脆禁止访问（所以才有了口令分享等弯弯绕绕的方式）

小程序则不同，其初衷是开放的，欢迎大家入驻（当然，也要遵守规则），并且国内的许多大型 App 也都相继开放了小程序能力，小程序逐渐成为跨 App 的正规方式。但小程序平台多起来之后，框架标准不统一的问题也暴露了出来，都叫小程序，但都大同小异，于是，如何快速产出多种小程序变成了一个值得探索的技术课题

实现原理上分为两种，编译转换与运行时适配，前者能够达到等同于原生小程序的性能但带来了诸多限制（编译期难以识别的写法都不支持），现有的 Web App 不那么容易迁移成跨 App 小程序，例如 Taro、uni-app 等。后者牺牲性能换取了更多的可能性，现有的 Web App 能够相对容易地迁移过来，例如 Taro Next、kbone 等

P.S.当然，也可以有动静结合的思路，理想情况下，绝大多数基础业务走运行时平迁，个别高性能要求的部分走编译转换

三.重重变化之中，什么才是不变量？

渠道/端/平台、业务代码、工程化配套设施似乎都在快速地发生变化，没有哪个是稳定不变的

既然全都在变，就换个角度看，哪个部分一定会发生变化？

容器：新的渠道/端/平台都是新的容器
跨容器技术：新容器的出现，意味着新的跨容器技术要求

哪个部分是不必要跟着变的？

业务代码：技术方案的更迭、新渠道/端/平台的出现，通常伴随着业务代码的迁移，Native 切 React Native 切 Flutter……乐此不疲，但从成本上看，业务代码并不一定也并不应该跟着变
工程化配套设施：大多与技术栈强相关，例如 Web App 的开发、调试、构建、发布、监控、运维与 Native App 存在诸多差异，但其中更基础的部分是技术无关，而流程相关的，例如构建-发布流程、监控运维服务等并不需要跟着变
容器中的平台能力：无论何种跨容器的方案，平台能力扩展需求都是一致的，对应的 Native 模块封装不应该跟着变

业务代码迁移的成本是非常高的（涉及技术栈变化时更痛），配套设施的推倒重建也绝对是大工程，那么，有没有办法把这些不应该跟着变的部分固定下来？

有，将变化的部分抽象出去。依赖抽象而不依赖具体，上层就不用跟着变了：

标准框架   \
---------  |  配套设施
标准容器   /

在这样的抽象模型下，上层业务代码依赖标准业务框架，而不直接依赖容器能力，从而允许业务框架以下的部分能够替换。业务框架依赖抽象的标准容器，而不与具体的特定容器相绑定，可替换为遵循容器标准的其它容器

基于标准框架，能够提供配套的脚手架、组件库、可视化搭建等配套开发工具。基于标准容器，能够建立性能诊断、事件追踪等配套调试能力，从而覆盖到工程化的整个链路，配套设施也几乎不用跟着变了

至于平台能力扩展，作为标准容器中的重要部分，也应该抽象出标准 API（类比浏览器提供的 BOM 系 API），供上层业务使用

四.跨平台技术的未来

预见不到未来，所以这里抛出几个可能性：

移动跨端只跨 Native 两端：对许多移动产品而言，体验细腻、性能优异的 Native App 仍是目前最重要的应用形态，并且双端功能完全一致，同等重要，所以只跨 Android、iOS 两端，统一移动端 Native 开发是相对合理的方案
小程序跨 App 自成一体：如果小程序不能真正标准化，跨 App 投放需求催生出的跨小程序框架方案就有必要存在
Web 仍是 Web，Hybrid 仍将持续：Web 特性更迭周期太长，移动设备的更迭太慢，等不及 Web 以年为单位的进化速度，依靠 Native 增强 Web 的 Hybrid 过渡方案很可能长期“过渡”下去

P.S.小程序已经在标准化进程中了，小程序框架成为标准化的容器也不是没有可能，毕竟小程序框架不存在 WebView、浏览器一样的慢周期阻力

不看好一招吃遍天下的跨全端的方案，因为无论 universal 组件还是 universal API 都是最小交集，无法满足实际需要。并且，真的需要让一套代码运行在所有渠道、端、平台上吗？

同一产品在不同平台的侧重点不同，或许并不需要把所有功能完整地搬到各式各样的客户端设备/平台渠道上，例如快应用与 Native App 的定位显然不一样

参考资料

Why Rax?

有所得、有所惑，真好

关注「前端向后」微信公众号，你将收获一系列「用心原创」的高质量技术文章，主题包括但不限于前端、Node.js以及服务端技术

本文首发于 ayqy.net ，原文链接：http://www.ayqy.net/blog/%e7%...