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

一、跨平台，是想跨哪些平台?

目前来看，移动端跨平台需求主要集中在：

• 跨 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 过渡方案很可能长期“过渡”下去