几个跨端开发神器

我们都知道的是现在很多平台都采用跨平台开发，相对于原生开发，跨平台开发有开发成本低，开发周期短，开发难度小等诸多优点。那么跨平台开发究竟是什么呢？首先我们来理解一下跨平台，像安卓，pc，苹果，ipad，我们可以称之为用户终端，也是作为我们应用程序所运行的平台，所以我们所说的跨平台开发就是使用非安卓或者非苹果技术开发安卓应用或者苹果应用，这就是跨平台。

跨端方案或多或少都能过起到研发降本增效的作用，方案各自有其优劣势。目前市面上主流跨端开发方案有以下 4 种：

1、以 Web 为基础的 H5 Hybrid 方案

这类方案简单来说就是用网页来跨端。现在绝大多数端上（甚至包括封闭的小程序生态）都支持 Webview，所以只要开发网页然后投放到多个端即可，在桌面端对应的方案就是 Electron。从开发成本低、标准统一、生态繁荣上来说，H5 Hybrid 方案优秀。但这种方案的劣势也非常明显，就是性能和体验存在显著的差距，同时 Web 的生态繁荣来自于其良好的历史兼容性，也意味着沉重的历史包袱。

2、React-Native/Weex 类方案

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

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

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

3、Flutter

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

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

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

4、小程序运行时方案

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

应用体验方面，小程序技术是前端容器技术的一种应用，其组件及 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 更好。