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

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

一.跨平台,是想跨哪些平台?

目前(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 支持了小程序,但各自的小程序框架并没有统一标准,于是有了Tarokboneuni-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 的定位显然不一样

参考资料

上一篇:项目实战总结以及接入U-APM


下一篇:拼不过 GO?阿里如何重塑云上的 Java