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

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

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

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

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

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

  • Web 生而跨平台：只要有浏览器或 WebView，依托 Web 技术即可轻松跨平台，如 Web App、Hybrid App
  • 容器化 Native 跨端：将 Native App 改造成标准化的容器，进而允许一套代码跨多端标准容器运行，如 React Native/Flutter

  • 小程序一码多投跨 App：国内市场中，越来越多的超级 App 支持了小程序，但各自的小程序框架并没有统一标准，于是有了Taro、uni-app等一系列跨小程序框架的方案来满足跨 App 投放产品功能的需求

    跨平台：Web 与生俱来

    跨平台是 Web 与生俱来的优势，浏览器和 WebView 都是 W3C 规范下的标准化 Web 容器，因此 Web 页面能够轻松投放到端外浏览器、端内 WebView、以及其它 App 提供的 WebView 中
    单从成本角度来看，Web 方案是跨平台的不二之选：

  • 没有额外的学习成本：一套基础技术吃遍端内、端外、甚至 PC 浏览器、电视机顶盒

  • 不依赖特殊的配套设施：开发、调试、构建、发布、监控、运维等所有工程化环节都是通用的
  • 坐拥庞大的既有生态：npm 百万模块，应有尽有
  • Web 基于开放标准：走出去引进来都不是难事

并且，Web 本身就是一个平台，退可守，技术风险更低
但在另一些方面，依靠 Web 技术跨端也存在其局限性：

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

加上 Web 标准更迭慢，新特性兼容性差，Web 基础能力难以满足 Native 端的需求。因此，在传统 Web App 的基础上，展开了更多的探索：

  • Hybrid App：Web 与 Native 混合的方案，将由 Native 实现的平台能力（比如扫描二维码）注入到 WebView 环境供 Web App 使用，以扩展 Web 的平台能力

    跨端：容器化 Native

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

  • Android 容器：Native 壳 App

  • iOS 容器：Native 壳 App

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 模块封装不应该跟着变

业务代码迁移的成本是非常高的（涉及技术栈变化时更痛），配套设施的推倒重建也绝对是大工程，那么，有没有办法把这些不应该跟着变的部分固定下来？
有，将变化的部分抽象出去。依赖抽象而不依赖具体，上层就不用跟着变了：

  1. 标准框架   \
  2. ---------  |  配套设施
  3. 标准容器   /

在这样的抽象模型下，上层业务代码依赖标准业务框架，而不直接依赖容器能力，从而允许业务框架以下的部分能够替换。业务框架依赖抽象的标准容器，而不与具体的特定容器相绑定，可替换为遵循容器标准的其它容器
基于标准框架，能够提供配套的脚手架、组件库、可视化搭建等配套开发工具。基于标准容器，能够建立性能诊断、事件追踪等配套调试能力，从而覆盖到工程化的整个链路，配套设施也几乎不用跟着变了
至于平台能力扩展，作为标准容器中的重要部分，也应该抽象出标准 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 的定位显然不一样