老照片修复、寻找系外行星……
|
技术视角下,小程序跨 Native App 仍然是依靠 Web 方案,那么,为什么不直接用 Web App 呢? 由于商业竞争等因素,闯入别人家地盘的 Web App 通常会遭到一些限制,如安全警告、权限控制、甚至干脆禁止访问(所以才有了口令分享等弯弯绕绕的方式) 小程序则不同,其初衷是开放的,欢迎大家入驻(当然,也要遵守规则),并且国内的许多大型 App 也都相继开放了小程序能力,小程序逐渐成为跨 App 的正规方式。但小程序平台多起来之后,框架标准不统一的问题也暴露了出来,都叫小程序,但都大同小异,于是,如何快速产出多种小程序变成了一个值得探索的技术课题 实现原理上分为两种,编译转换与运行时适配,前者能够达到等同于原生小程序的性能但带来了诸多限制(编译器难以识别的写法都不支持),现有的 Web App 不那么容易迁移成跨 App 小程序,例如 Taro、uni-app 等。后者牺牲性能换取了更多的可能性,现有的 Web App 能够相对容易地迁移过来,例如 Taro Next、kbone 等
P.S.当然,也可以有动静结合的思路,理想情况下,绝大多数基础业务走运行时平迁,个别高性能要求的部分走编译转换 除 Web 天然跨端之外,另一种统一多端的思路是将 Native 定制成标准容器,让同一份代码跑在一个个标准容器中,例如:
从技术角度来看,RN 与 Weex 在 Native 容器中提供了 JavaScript 运行环境,以及布局引擎,渲染层都采用 Native 控件,因此 UI 交互上仍然存在系统差异。而 Flutter 方案更彻底一些,连渲染层也换成了基于图形引擎自绘 UI 控件,从而保证 UI 交互的跨端一致性 然而,由于容器化 Native 的方案是从 Native 出发,没有跨端天赋,除了要想办法支持 Web,还面临一个更难解决的问题——跨 App
跨 App:小程序一码多投 跨平台是 Web 与生俱来的优势,浏览器和 WebView 都是 W3C 规范下的标准化 Web 容器,因此 Web 页面能够轻松投放到端外浏览器、端内 WebView、以及其它 App 提供的 WebView 中 单从成本角度来看,Web 方案是跨平台的不二之选:
并且,Web 本身就是一个平台,退可守,技术风险更低 但在另一些方面,依靠 Web 技术跨端也存在其局限性:
加上 Web 标准更迭慢,新特性兼容性差(如Push API过去许多年了,仍然无法放心使用),Web 基础能力难以满足 Native 端的需求。因此,在传统 Web App 的基础上,展开了更多的探索:
PWA 标准化似乎走不通,即便走通了能够真正放心用起来可能也是数年之后了。Hybrid App 解决了一部分问题(平台能力扩展),但还不够。PHA 是这两种思路的延续,借助 Native 技术实现 PWA 的梦想 但无论 PHA 还是 HA,引入 Native 依赖都意味着 Web 开放性的损失,继而带来跨端、跨 App 方面的问题
跨端:容器化 Native (编辑:阜阳站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


