江苏龙网

  1. 首页 > 资讯 > 科技 > >

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


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 存在诸多差异 ， 但其中更基础的部分是技术无关 ， 而流程相关的 ， 例如构建-发布流程、监控运维服务等并不需要跟着变


推荐阅读


上一篇：大众新闻|东莞名家具展即将开幕，尚驰科技馆智能3D上演蓝色梦幻装

下一篇：逸科技|有家，有爱，有生活--家的味道，卓力BG578手持挂烫机使用分享