用友开发者中心

跨端(跨平台)开发方案如何助力企业降本增效?

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

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

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

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

   2、Flutter

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

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

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

3、React-Native/Weex 类方案

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

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

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

4、小程序运行时方案

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

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

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

2023-08-14 14:29:49