1、跨平台，你想跨哪些平台？目前移动跨平台的需求主要集中在：跨PC和移动：PC到无线的过渡早期希望PCWeb和移动Web能够跨Native和Web复用同一套代码:商品详情页等需求需要一组类似功能的网页可以在终端外访问，需要跨NativeApp和Web跨Native双终端：出于开发效率等原因，希望Android和iOS能够跨APP双用一套业务代码：一些产品功能预计会在多个渠道上线，主要是基于工具需求，比如打车、门票、订单等在可预见的未来,可能还有这些跨平台需求：ays将成为跨所有客户端的车载设备、智能家居等新“端”：可能是虚假需求，同一个产品在不同平台上有不同的侧重点，未必需要将所有功能全部搬到一个平台上各种客户端设备/平台渠道，例如快应用和原生应用的定位明显不同。在这个时代，无论从资源成本、开发效率，还是产品迭代和技术演进的角度来看，跨平台开发都是一种强烈的需求。因此，各种跨平台的解决方案探索不尽。第二，层出不穷的跨平台技术。近年来，业界主流的移动端跨平台解决方案大致可以分为三类：浏览器或WebView，依靠Web技术轻松跨平台，如WebApp、PWA（ProgressiveWebApps）、HybridApp,PHA(ProgressHybridApp)containerizedNativecross-end:将NativeApp变成一个标准化的容器，让一套代码运行在多端标准容器上，比如ReactNative/Weex,Flutter小程序一码多用跨APP：在国内市场，越来越多的超级APP支持小程序，但是各自的小程序框架并没有统一的标准，所以出现了Taro、kbone、kbone、和uni-app满足跨App交付产品功能的需求。跨平台：Web与生俱来的跨平台性是Web与生俱来的优势。浏览器和WebView是W3C规范下的标准化Web容器，因此可以轻松地将网页传递到设备外浏览器、设备内WebView以及其他应用程序提供的WebView。从成本的角度，web方案是最好的跨平台可选：无额外学习成本：一套基础技术，终端内外都可以使用，甚至PC浏览器和电视机顶盒也不依赖特殊配套设施：开发、调试、构建、发布、监控、运维等，所有工程环节都是通用的。坐拥庞大的现有生态系统：npm拥有数百万个模块，应有尽有。Web基于开放标准：推出并引入它并不困难。而且Web本身就是一个平台，可退可守，技术风险较低。但在另外一些方面，依赖Web技术跨终端也有其局限性：平台能力：受限于Web标准容器，无法满足平台能力相关需求，如摄像头、蓝牙、多媒体体验：移动Web体验远不如Native，主要体现在首屏加载慢、动画卡顿、页面长滚动闪烁等场景表现：内存消耗大、GPU利用率低、Web标准变化慢、兼容性差新特性（比如PushAPI已经用了很多年了，还是不靠谱。因此，在传统WebApp的基础上，进行了更多的探索：PWA（ProgressiveWebApps）：离线缓存，系统通知、主屏图标等NativeApp能力HybridApp：混合Web和Native的解决方案，注入Native实现的平台能力（如scanningQRcodes）放到WebView环境中供WebApp使用，从而扩展Web的平台能力。PHA（ProgressiveHybridApp）：PWA和Hybrid思想的结合。通过Hybrid方式将Web性能和体验标准化接近NativePWA似乎行不通。即使它有效，也可能需要数年时间才能放心使用。HybridApp解决了部分问题（平台能力的扩展），但还不够。PHA是这两个思想的延续。借助Native技术，可以实现PWA的梦想。但是，无论是PHA还是HA，引入Native依赖就意味着Web开放性的丧失，进而带来跨终端、跨app的问题。跨终端：容器化除了Web天然的跨终端，Native还有一个统一和多终端的思想，就是将Native自定义为一个标准容器，让相同的代码可以运行在各个标准容器中，例如：Android容器：NativeShellAppiOS容器：NativeShellAppWeb容器：WebRuntimeReactNative跨Android、iOS、Web、Windows，Weex跨Android、iOS、Web，Flutter跨Android、iOS、Web，和Linux以类似的方式。从技术角度来看，RNWeex和Weex在Native容器中提供了JavaScript运行环境和布局引擎，渲染层使用Native控件，所以在UI交互上还是存在系统差异。Flutter的方案更彻底，甚至渲染层都换成了基于图形引擎的自绘UI控件，保证了UI交互的跨终端一致性。但是，由于容器化的Native解决方案是从Native开始的，所以并没有跨终端的人才，除了想找到一种支持Web的方式，我们还面临着一个比较难解决的问题——跨app和跨app：从一码多投小程序的技术角度来看，小程序的跨原生app还是依赖web方案，为什么不直接使用webapp呢？由于商业竞争等因素，闯入他人网站的WebApp通常会受到一些限制，比如安全警告、权限控制，甚至干脆禁止访问（所以才会有密码共享等波折）。小程序不同，它的初衷是开放的，欢迎大家入驻（当然要遵守规则），国内很多大型APP也陆续开放了小程序能力，小程序逐渐成为正式的跨应用方式。但是，在小程序平台数量增多之后，框架标准不一致的问题也暴露了出来。都叫小程序，但都大同小异。因此，如何快速制作出各种小程序成为了一个值得探讨的技术课题。分为两种，编译转换和运行时适配，前者可以达到和原生小程序一样的性能但是带来很多限制（不支持编译器难以识别的写法），现有的WebApp就没那么容易了迁移到跨App的小程序，比如Taro、uni-app等，后者牺牲性能换取更多的可能性。已有的WebApp可以相对容易地迁移，例如TaroNext、kbone等。P.S.当然也可以有动静结合的思路。理想情况下，大部分基础业务采用Runtime翻译，对一些高性能需求进行编译转换。3.在众多变化中，什么是不变量？渠道/终端/平台、业务代码、工程配套似乎都在日新月异。哪个稳定？既然一切都在变化，那么换个角度来看，哪一部分肯定会发生变化呢？容器：新的渠道/端点/平台都是新的容器跨容器技术：新容器的出现意味着新的跨容器技术需求有哪些是不需要改变的？业务代码：技术方案的改变，新渠道/端/平台的出现，通常伴随着业务代码的迁移，NativecutReactNativecutFlutter...百看不厌，但是从成本上来说，业务代码不一定也不应该跟着工程配套的变化：大部分都与强大的技术栈相关，比如WebApp和NativeApp的开发、调试、构建、发布、监控、运维。但更基础的部分是技术无关的，和流程相关的，比如构建-发布流程，监控运维服务等，不需要遵循容器中的平台能力：不管是哪种跨容器解决方案，平台能力扩展需求都是一致的。对应的Native模块包不要跟着业务代码的变化。迁移的成本非常高（涉及到技术栈变更时更痛苦），而且配套设施的拆除和重建绝对是一个大工程。那么，有没有什么办法可以整合这些不应该修改的部分呢？是的，变化的部分应该被抽象掉。依靠抽象而不是具体，上层不需要改变：标准框架\--------|配套设施标准容器/在这样的抽象模型下，上层业务代码依赖于标准业务框架而不是直接依赖容器能力，让业务框架下面的部分可以被替换。业务框架依赖抽象的标准容器，不绑定具体的具体容器。可以用其他符合容器标准的容器代替。基于标准框架，可提供脚手架、组件库、可视化构建等配套开发工具。基于标准容器，可以建立性能诊断、事件跟踪等配套调试能力，覆盖整个工程环节，几乎不需要改变配套设施。至于平台能力的扩展，作为标准容器的重要组成部分，也应该抽象出来。提供标准API（类比浏览器提供的BOMAPI）供上层业务使用。4.跨平台技术的未来无法预见，这里有几种可能：仍然是目前最主要的应用形态，而且两端的功能完全一致，同等重要，所以只跨Android和iOS两端统一开发Native在移动端是比较合理的-containedacrossapps：如果小程序不能真正标准化，跨app交付需求产生的跨app框架解决方案必须存在Web仍然是Web，Hybrid将继续：Web特性变化周期太长，移动设备的变化是太慢了，我们等不及Web以年为单位的进化。依靠Native增强Web的Hybrid过渡方案很可能“过渡”很长时间。附言小程序已经在标准化的过程中，小程序框架已经成为一个标准化的容器。这并非不可能。毕竟小程序框架没有WebView和浏览器一样的慢循环抗性。我不看好跨全球通用的全终端解决方案，因为通用组件和通用API都是最小的交集，不能满足实际需求。而且，真的有必要一套代码跑全渠道、全端、全平台吗？
