这是我参与第五届青训营伴学笔记创作活动的第十三天

跨端指的是跨终端，例如：跨PC端，跨多Native平台，跨Web，跨POS机，跨手表设备等。

跨端开发，就是使用非封闭式系统语言开发，使得应用能够在多个封闭式操作系统中运行。

跨端开发方案

跨端开发方案有以下4种：

这类方案简单来说就是用网页来跨端。现在绝大多数端上（甚至包括封闭的小程序生态）都支持 Webview，所以只要开发网页然后投放到多个端即可，在桌面端对应的方案就是Electron。

从开发成本低、标准统一、生态繁荣上来说，H5 Hybrid 方案优秀。但这种方案的劣势也非常明显，就是性能和体验存在显著的差距，同时Web的生态繁荣来自于其良好的历史兼容性，也意味着沉重的历史包袱。

React-Native/Weex 这类方案通过尽可能的取长补短，综合了Web生态和Native组件，让JS 执行代码后用 Native的组件进行渲染，以解决抛弃Web历史包袱的问题。

方案同样存在一些缺陷：iOS/Android 双端本身不一致的组件和布局机制，让双端一致性难以得到保障；依赖于 Native 机制也让一些CSS 属性实现起来比较困难，例如z-index问题。

另外，这套方案也需要非常高的维护支持成本：如借用了 Web的生态但并不完全是Web生态，很多地方不一致，例如惯用的CSS 布局方式无法使用。

Flutter不继续在Web 生态上借力，从设计之初也并没有把 Web 生态考虑进去。相比于RN依赖Native View渲染，Flutter则是自绘组件，通过 Skia绘制到屏幕上。

由于可以完全发挥 GPU 的能力，也不需要去 Native 绕一圈。Flutter 理论上能做到更好的性能和两端一致性，这一意味着理论上未来可能基于 Flutter 的 JS 动态化方案能够在样式上支持的比 WEEX 更好。

但从前端开发视角看，Flutter更像是一个Native开发方案而非跨端方案（虽然其实是跨 Android/iOS 的）。目前最主要的问题是Flutter for Web 从技术原理上来说离生产可用可能还非常遥远，动态化能力的确实也会让部分场景不适用。

这个方案可以说是笔者认为目前性价比最高的方案，没有之一。

应用体验方面，小程序技术是前端容器技术的一种应用，其组件及UI都有明确的规范，开发者不用考虑兼容性及类似H5开发时复杂工具及框架的选择。同时，由于组件及UI都是预设的，展示体验也会更佳。

应用框架支持方面，某些运行时方案不仅支持纯 wxml 微信小程序运行，还支持包括 uniapp、 Taro、kbone 等第三方框架集成的小程序。

宿主环境结合方面，小程序是基于App端实现的应用，其获取系统(App)的权限也会多于H5；随着微信小程序的潮流引领，各大主流互联网平台的追随，小程序技术的发展已经趋于成熟，市面上小程序以运行时已经开始出现多智能终端设备的适配（基于Andriod系统的多终端屏幕适配）。

我们无法奢望一个技术方案就能解决所有的跨端问题，只能选择更适合自己业务增长的长效技术治理方案。跨端开发的本质是实现降本增效，在对于业务支撑做新的技术方案选型的同时，更重要的是如何让这种提效真的长治久安，让我们的提效不会变成从一个新方案跳到另外一个新方案。

这里想给大家介绍一下FinClip小程序运行时项目。

FinClip是小程序容器技术，上述说的跨端技术优势都具备，包括：应用体验由于H5，应用框架支持多种主流框架生成的小程序，多终端设备（宿主）环境友好且兼容。

另外，视图层与逻辑层分离也带来了许多好处：

1、方便多个小程序页面之间的数据共享和交互。在小程序的生命周期中具有相同的上下文可以为具备原生应用程序开发背景的开发人员提供熟悉的编码体验；

2、Service和View的分离和并行实现可以防止JS执行影响或减慢页面渲染，这有助于提高渲染性能；

3、因为JS在Service层执行，所以JS里面操作的DOM将不会对View层产生影响，所以小程序不能操作DOM结构的，这也使得小程序的性能比传统的H5更好。