小程序|移动端跨平台技术之下的变与不变( 三 )
容器中的平台能力：无论何种跨容器的方案 ， 平台能力扩展需求都是一致的 ， 对应的 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 的定位显然不一样
推荐阅读
- 猎豹|猎豹移动蒙眼狂奔十年，终究逃不过时代魔掌？
- 便携|TEGIC迷我移动电源，小巧便携，随时随地，想充就充
- 电脑使用技巧|微软重新发布补丁对Windows 10更新：修复磁盘优化程序等
- 妈咪爱数码|TEGIC迷我移动电源，小巧便携，随时随地，想充就充
- 行业互联网|商丘移动：“千兆城市”让市民“智”享极速生活
- 移动网络|走出“脆弱”时代，毫米波迎来商用新机遇
- 移动网络|【关注】中国广电推动我国首批5G 700MHz设备完成型号核准入网工作
- 移动网络|电信唐建军:LWDM技术优势明显，产业链支撑有力
- |某程序员面试支付宝P7，面试已通过，却因为背调没过
- 移动网络|有人搞定了6G，首批6G芯片首次亮相，目前环境测试中设法达11Gbps