前言

微信推出小程序平台以来，国内各大公司陆续跟进，带来了小程序的繁荣。从开发者的视角，我们看到小程序开发者变多，各种小程序技术方案不断出现。

• 小程序增强型开发框架的出现
• 小程序原生框架能力扩充，典型的有 wepy/mpvue
• 小程序跨端开发框架的出现
  * 通过编写一套代码，实现多个小程序平台运行，典型的有 taro/uniapp
• 小程序与 web/native（app）融合的技术需求出现
  * 因 小程序/web/native 平台差异较大，虽然有许多框架进行了尝试，但还处于蛮荒时代，未出现得到一致认可的方案

而这繁荣的背后也显得杂乱，影响开发者选择适合的技术方案。基于此，我们做了一次小程序跨平台开发方向的调研，并得出如下建议：

 

原生小程序如何实现多平台投放？

从我们的了解来看，目前小程序市场，大部分还是微信小程序应用，其次是支付宝小程序，百度小程序。对这几端的融合也是目前比较切合需求场景的需求。基于此，我们调研了从微信小程序到其它端的转换的情况，帮助大家了解如何快速实现微信小程序到其它小程序的迁徙。

说明： 以下测试结果基于微信官方微信小程序 demo 调研而得

Antmove 小程序转换器

• 官网：ant-move.github.io/guide/
• Github：github.com/ant-move/An…

Antmove 是目前小程序转换开源解决方案里成熟度最高的，通过 Antmove 转换器，可以一键将微信小程序转换为其它平台小程序，也可以将支付宝小程序转换为其它平台小程序，目前还在持续维护更新。

基于 Antmove 的多端开发相关介绍可以从这里了解

taro

介绍：Taro 是一套遵循 React 语法规范的 多端开发 解决方案。

Github: github.com/NervJS/taro…

Taro 本质上是一套自定义语法的跨端开发方案，但官方提供了微信小程序转换为 taro 代码的工具，基于此，用户可以借助于 taro 将微信小程序转换为 taro 代码，然后再将其转换为对应平台的小程序代码。

不足

• 需要进行两次转换才能可以得到对应平台的代码

• 功能支持情况不是很理想，如下为将微信小程序官方 demo 转换为 taro，再转换其它平台的测试情况

• 转支付宝：

  • 目前转码后点击事件失效，转码后框架上函数有报错，逻辑需要重新写
  • setData函数运行失败，项目没办法使用

• 转百度小程序

  • 界面（不支持，需要修改的）
    • flex相关样式设置失败
    • button报错，getLaunchOptionsSync没有处理
    • map
    • 显示隐藏指南针
    • 开启俯视功能
  • 接口（不支持，需要修改的）
    • 登陆
    • 支付
    • 客服消息
    • 生物认证
    • 蓝牙
    • iBeacon
    • 搜索WIFI
    • 上传视频和图片
    • 动态加载字体
    • 储存数据报错
    • 多线程计算

• 转头条小程序

  • 目前转码后点击事件失效，转码后框架上函数有报错，逻辑需要重新写
  • setData函数运行失败，项目没办法使用

注： 目前转码工具初始化微信小程到taro代码会有图片路径处理错误，需要手动修改一下

总结

• 工具整体体验流畅，其设计核心是用react语法使用工具提供的API和组件完成项目开发，然后一键生成多端小程序
• 目前对原生小程序（微信）转到taro的问题比较多，但是整体能够完成转码，只是转码后需要花费一定的精力重新处理各种问题

uniapp

介绍： uni-app 是一个使用 Vue.js 开发所有前端应用的框架，开发者编写一套代码，可发布到iOS、Android、H5、以及各种小程序（微信/支付宝/百度/头条/QQ/钉钉）等多个平台

Github： github.com/dcloudio/un…

微信小程序转换 uniapp 代码指南

总结

• 需要手工将微信小程序改造成 uniapp 应用
• 非官方版本有一个转换工具，但转换不理想，测试微信官方 demo 转换报错
• 单纯开发多端小程序这个框架还是比较好用的，但是转码微信小程序没有一键转码功能，需要手动配置大量的文件，其开发成本比较高

mpx

介绍：相同风格的语言开发开发多端小程序的开发框架，语言风格类似小程序，支持双向数据绑定 Github：github.com/didi/mpx.gi…

结论

• 不同的小程序需要搭建不同的开发环境，并做好相应的配置，
• 不支持原生小程序转换，但支持使用原生小程序组件/页面，对于完整的小程序转换成本较高

说明：除了 Antmove 转换器外，其它方案解决方案的初衷是基于 react/vue 或自定义语法的角度来实现多端，所以微信小程序转换到多端这一转换流程并不包含来这些框架的所有能力和优势，对于原生小程序迁移到其它平台本文调研结果可以参考。

非小程序语法多端方案对比

这里主要指采用非小程序语法开发小程序应用。 非小程序语法开发业务代码方案已有诸多的调研和说明，可参考如下链接：

• 小程序开发：用原生还是选框架（wepy/mpvue/uni-app/taro）？
• Chameleon
• 深入测试一周，主流多端框架大比武~by DCloud

关于小程序跨平台开发的看法

存在的问题

从上面我们可以看到随着小程序的繁荣，跨端融合这个概念被提得越来越多，也出现了许多解决该问题的框架。但这真的代表着跨端开发的繁荣吗？

我觉得还不是，小程序和 web，小程序和 native app存在着天然的差异化，这是很难弥补的，虽然社区上有出现了很多的方案，但都还不能说成熟。

只考虑小程序这一平台，差异性会小一点，但想做到完全的一套代码，多个小程序平台运行还是很难。这里有以下几个原因：

• 各大厂商采用自己的小程序技术框架，难以进行标准化
• 小程序会自带厂商基因，能力差异化

虽然有如上的差异，但依然小程序间的跨平台还是看到了一定的可能性，这也是目前小程序跨端方案出现这么多的原因。

展望未来

虽然上面提及了跨平台开发的不足，但其优势依然存在，一套代码多处运行充满了诱惑。当我们将全端的要求降低，只考虑某些平台的情况下，已经出现了较为成熟的方案。

大多数情况下其实我们需要的只是某一端或是几端的融合，在 taro 的统计示例中我们可以发现，微信小程序应用占比达 90%，即大多数的应用只用 taro 开发了微信小程序。uniapp 也提到绝大多数应用只用其来开发其中一端的应用。在 Antmove 的统计中，绝大部分的用户也只是微信小程序和支付宝小程序两端的融合要求。

在小程序之前，多端融合就已经被提及推出，在前端领域中，react 在这方面做得比较成功。在 react 学习一遍，即可多处编写的理念下，较低成本的实现了多端的需求，如 react-web/react-native/react-sketch 等，也因此构建了丰富的 react 生态。

除了 react 体系外，如下的方案则切实的实现了某些平台的跨端

• flutter - 高性能移动端跨平台框架
• electron - PC 应用跨平台开发工具
• QT
• 小程序
  • taro/uniapp/Antmove/rax/mpx/cml

畅想未来，设备复杂化是个必然的趋势，而这也更考验着跨端技术方案是否足够成熟。