多端小程序和多合一小程序会是未来几年小程序技术框架发展方向吗？
2020-08-14 10:52:17分类：APP开发
阅读()
目前来看，移动端跨平台需求主要集中在：
在可预见的未来，可能还会有这些跨平台需求：
在这样的时代背景下，无论从资源成本、开发效率，还是从产品迭代、技术演进的角度来看，跨平台开发都是强需求，所以才有了层出不穷的各种跨平台方案探索
细数近几年业界主流的移动端跨平台方案，可大致分为 3 类：
跨平台是 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 方面的问题
除 Web 天然跨端之外，另一种统一多端的思路是将 Native 定制成标准容器，让同一份代码跑在一个个标准容器中，例如：
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
技术视角下，小程序跨 Native App 仍然是依靠 Web 方案，那么，为什么不直接用 Web App 呢？
由于商业竞争等因素，闯入别人家地盘的 Web App 通常会遭到一些限制，如安全警告、权限控制、甚至干脆禁止访问（所以才有了口令分享等弯弯绕绕的方式）
小程序则不同，其初衷是开放的，欢迎大家入驻（当然，也要遵守规则），并且国内的许多大型 App 也都相继开放了小程序能力，小程序逐渐成为跨 App 的正规方式。但小程序平台多起来之后，框架标准不统一的问题也暴露了出来，都叫小程序，但都大同小异，于是，如何快速产出多种小程序变成了一个值得探索的技术课题
实现原理上分为两种，编译转换与运行时适配，前者能够达到等同于原生小程序的性能但带来了诸多限制（编译器难以识别的写法都不支持），现有的 Web App 不那么容易迁移成跨 App 小程序，例如 Taro、uni-app 等。后者牺牲性能换取了更多的可能性，现有的 Web App 能够相对容易地迁移过来，例如 Taro Next、kbone 等
P.S.当然，也可以有动静结合的思路，理想情况下，绝大多数基础业务走运行时平迁，个别高性能要求的部分走编译转换
渠道/端/平台、业务代码、工程化配套设施似乎都在快速地发生变化，没有哪个是稳定不变的
既然全都在变，就换个角度看，哪个部分一定会发生变化？
哪个部分是不必要跟着变的？
业务代码迁移的成本是非常高的（涉及技术栈变化时更痛），配套设施的推倒重建也绝对是大工程，那么，有没有办法把这些不应该跟着变的部分固定下来？
有，将变化的部分抽象出去。依赖抽象而不依赖具体，上层就不用跟着变了：
标准框架 \
--------- | 配套设施
标准容器 /
在这样的抽象模型下，上层业务代码依赖标准业务框架，而不直接依赖容器能力，从而允许业务框架以下的部分能够替换。业务框架依赖抽象的标准容器，而不与具体的特定容器相绑定，可替换为遵循容器标准的其它容器
基于标准框架，能够提供配套的脚手架、组件库、可视化搭建等配套开发工具。基于标准容器，能够建立性能诊断、事件追踪等配套调试能力，从而覆盖到工程化的整个链路，配套设施也几乎不用跟着变了
至于平台能力扩展，作为标准容器中的重要部分，也应该抽象出标准 API（类比浏览器提供的 BOM 系 API），供上层业务使用
预见不到未来，所以这里抛出几个可能性：
P.S.小程序已经在标准化进程中了，小程序框架成为标准化的容器也不是没有可能，毕竟小程序框架不存在 WebView、浏览器一样的慢周期阻力
不看好一招吃遍天下的跨全端的方案，因为无论 universal 组件还是 universal API 都是最小交集，无法满足实际需要。并且，真的需要让一套代码运行在所有渠道、端、平台上吗？
同一产品在不同平台的侧重点不同，或许并不需要把所有功能完整地搬到各式各样的客户端设备/平台渠道上，例如快应用与 Native App 的定位显然不一样
热门服务
最新新闻
