小程序|移动端跨平台技术之下的变与不变


作者:黯羽轻扬 来源:前端向后

小程序|移动端跨平台技术之下的变与不变
本文插图

一.跨平台 , 是想跨哪些平台?
目前来看 , 移动端跨平台需求主要集中在:
跨 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 的平台能力


推荐阅读