跨平台：Web与生俱来
跨平台是Web与生俱来的优势，浏览器和WebView都是W3C规范下的标准化Web容器，因此Web页面能够轻松投放到端外浏览器、端内WebView、以及其它App提供的WebView中
单从成本角度来看，Web方案是跨平台的不二之选：
没有额外的学习成本：一套基础技术吃遍端内、端外、甚至PC浏览器、电视机顶盒
不依赖特殊的配套设施：开发、调试、构建、发布、监控、运维等所有工程化环节都是通用的
坐拥庞大的既有生态：npm百万模块，应有尽有
Web基于开放标准：走出去引进来都不是难事
并且，Web本身就是一个平台，退可守，技术风险更低
但在另一些方面，依靠Web技术跨端也存在其局限性：
平台能力：受限于Web标准容器，无法满足平台能力相关的需求，如相机、蓝牙、多媒体等
体验：移动端Web体验远不及Native，主要体现在首屏加载慢、动画卡顿、长页滚动闪烁等场景
性能：内存消耗大、GPU利用率低
加上Web标准更迭慢，新特性兼容性差（如PushAPI过去许多年了，仍然无法放心使用），Web基础能力难以满足Native端的需求。因此，在传统WebApp的基础上，展开了更多的探索：
PWA（ProgressiveWebApps）：离线缓存、系统通知、主屏图标等类NativeApp能力加持之下的WebApp，但兼容性并不乐观
HybridApp：Web与Native混合的方案，将由Native实现的平台能力（比如扫描二维码）注入到WebView环境供WebApp使用，以扩展Web的平台能力
PHA（ProgressiveHybridApp）：PWA与Hybrid思想的结合，通过Hybrid手段让Web的性能和体验接近Native
PWA标准化似乎走不通，即便走通了能够真正放心用起来可能也是数年之后了。HybridApp解决了一部分问题（平台能力扩展），但还不够。PHA是这两种思路的延续，借助Native技术实现PWA的梦想
但无论PHA还是HA，引入Native依赖都意味着Web开放性的损失，继而带来跨端、跨App方面的问题
跨端：容器化Native
除Web天然跨端之外，另一种统一多端的思路是将Native定制成标准容器，让同一份代码跑在一个个标准容器中，例如：
Android容器：Native壳App
iOS容器：Native壳App
Web容器：WebRuntime
ReactNative跨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：小程序一码多投
技术视角下，小程序跨NativeApp仍然是依靠Web方案，那么，为什么不直接用WebApp呢？
由于商业竞争等因素，闯入别人家地盘的WebApp通常会遭到一些限制，如安全警告、权限控制、甚至干脆禁止访问（所以才有了口令分享等弯弯绕绕的方式）
小程序则不同，其初衷是开放的，欢迎大家入驻（当然，也要遵守规则），并且国内的许多大型App也都相继开放了小程序能力，小程序逐渐成为跨App的正规方式。但小程序平台多起来之后，框架标准不统一的问题也暴露了出来，都叫小程序，但都大同小异，于是，如何快速产出多种小程序变成了一个值得探索的技术课题
实现原理上分为两种，编译转换与运行时适配，前者能够达到等同于原生小程序的性能但带来了诸多限制（编译期难以识别的写法都不支持），现有的WebApp不那么容易迁移成跨App小程序，例如Taro、uni-app等。后者牺牲性能换取了更多的可能性，现有的WebApp能够相对容易地迁移过来，例如TaroNext、kbone等
P.S.当然，也可以有动静结合的思路，理想情况下，绝大多数基础业务走运行时平迁，个别高性能要求的部分走编译转换
三.重重变化之中，什么才是不变量？移动端跨平台技术之下的变与不变
渠道/端/平台、业务代码、工程化配套设施似乎都在快速地发生变化，没有哪个是稳定不变的
既然全都在变，就换个角度看，哪个部分一定会发生变化？
容器：新的渠道/端/平台都是新的容器
跨容器技术：新容器的出现，意味着新的跨容器技术要求
哪个部分是不必要跟着变的？
业务代码：技术方案的更迭、新渠道/端/平台的出现，通常伴随着业务代码的迁移，Native切ReactNative切Flutter……乐此不疲，但从成本上看，业务代码并不一定也并不应该跟着变
工程化配套设施：大多与技术栈强相关，例如WebApp的开发、调试、构建、发布、监控、运维与NativeApp存在诸多差异，但其中更基础的部分是技术无关，而流程相关的，例如构建-发布流程、监控运维服务等并不需要跟着变
容器中的平台能力：无论何种跨容器的方案，平台能力扩展需求都是一致的，对应的Native模块封装不应该跟着变
业务代码迁移的成本是非常高的（涉及技术栈变化时更痛），配套设施的推倒重建也绝对是大工程，那么，有没有办法把这些不应该跟着变的部分固定下来？
有，将变化的部分抽象出去。依赖抽象而不依赖具体，上层就不用跟着变了：
标准框架\
---------|配套设施
标准容器/
在这样的抽象模型下，上层业务代码依赖标准业务框架，而不直接依赖容器能力，从而允许业务框架以下的部分能够替换。业务框架依赖抽象的标准容器，而不与具体的特定容器相绑定，可替换为遵循容器标准的其它容器
基于标准框架，能够提供配套的脚手架、组件库、可视化搭建等配套开发工具。基于标准容器，能够建立性能诊断、事件追踪等配套调试能力，从而覆盖到工程化的整个链路，配套设施也几乎不用跟着变了
至于平台能力扩展，作为标准容器中的重要部分，也应该抽象出标准API（类比浏览器提供的BOM系API），供上层业务使用
四.跨平台技术的未来 移动端跨平台技术之下的变与不变
预见不到未来，所以这里抛出几个可能性：
移动跨端只跨Native两端：对许多移动产品而言，体验细腻、性能优异的NativeApp仍是目前最重要的应用形态，并且双端功能完全一致，同等重要，所以只跨Android、iOS两端，统一移动端Native开发是相对合理的方案
小程序跨App自成一体：如果小程序不能真正标准化，跨App投放需求催生出的跨小程序框架方案就有必要存在
Web仍是Web，Hybrid仍将持续：Web特性更迭周期太长，移动设备的更迭太慢，等不及Web以年为单位的进化速度，依靠Native增强Web的Hybrid过渡方案很可能长期“过渡”下去
