Taro vs uni-app选型对比经历

梦里梦外; 2022-10-11 12:06 234阅读 0赞

公司新产品要求发布到各家小程序，最近研究对比了社区主流的几家小程序开发框架，独坑不如拉人众坑，分享给各位，欢迎和我一起入坑:)

## 背景 ##

最近老板不知怎的很重视各种小程序平台，感觉要靠小程序完成今年大半kpi。。。  
产品和运营自然找我们要方案，一方面要快速铺开各种小程序，另一头hr又不给前端团队加headcount，我只能![@@][math_formula_40_40_E2_80_8B]  
目前几杆枪，主要在微信和H5上，若按照各家规范进行原生小程序开发，肯定是不够的；  
所幸业内有人在做跨各种小程序的框架，趁机研究一番，看看到底做的怎么样。

## 可选的小程序框架 ##

我们主要分析了如下小程序开发框架（应该差不多全了），主要包括：

<table> 
 <thead> 
  <tr> 
   <th>框架</th> 
   <th>技术栈</th> 
   <th>案例</th> 
   <th>微信小程序</th> 
   <th>支付宝小程序</th> 
   <th>百度小程序</th> 
   <th>头条小程序</th> 
   <th>H5</th> 
   <th>App</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Taro</td> 
   <td>React</td> 
   <td>丰富</td> 
   <td>⭕</td> 
   <td>⭕</td> 
   <td>⭕</td> 
   <td>⭕</td> 
   <td>⭕</td> 
   <td>⭕</td> 
  </tr> 
  <tr> 
   <td>娜娜奇</td> 
   <td>React</td> 
   <td>少</td> 
   <td>⭕</td> 
   <td>⭕️</td> 
   <td>⭕️</td> 
   <td>⭕️</td> 
   <td>⭕️</td> 
   <td>❌</td> 
  </tr> 
  <tr> 
   <td>wepy</td> 
   <td>Vue</td> 
   <td>丰富</td> 
   <td>⭕</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
  </tr> 
  <tr> 
   <td>mpvue</td> 
   <td>Vue</td> 
   <td>丰富</td> 
   <td>⭕</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>⭕️</td> 
   <td>❌</td> 
  </tr> 
  <tr> 
   <td>uni-app</td> 
   <td>Vue</td> 
   <td>丰富</td> 
   <td>⭕</td> 
   <td>⭕️</td> 
   <td>⭕️</td> 
   <td>⭕</td> 
   <td>⭕️</td> 
   <td>⭕</td> 
  </tr> 
  <tr> 
   <td>megalo</td> 
   <td>Vue</td> 
   <td>少</td> 
   <td>⭕</td> 
   <td>⭕️</td> 
   <td>⭕️</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
  </tr> 
  <tr> 
   <td>OKAM</td> 
   <td>Vue</td> 
   <td>少</td> 
   <td>⭕</td> 
   <td>⭕</td> 
   <td>⭕</td> 
   <td>⭕</td> 
   <td>❌</td> 
   <td>❌</td> 
  </tr> 
  <tr> 
   <td>Mpx</td> 
   <td>Vue</td> 
   <td>少</td> 
   <td>⭕</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
   <td>❌</td> 
  </tr> 
 </tbody> 
</table>

我们的筛选权重：

*  跨端：权重最高，毕竟第一诉求就是覆盖各家小程序，故wepy、mpx这种针对微信小程序的增强型开发框架首先排除，其次mpvue虽支持 H5 平台代码复用，但未跟进其它几家小程序，也放弃；
 *  案例：权重次之，案例多说明使用者多，坑应该都踩得差不多了，有坑也应该是明坑；案例少的话，就要自己上去踩，暗坑多少不清楚；从官网公开案例来看，taro、uni-app公开展示的案例是最多的（mpvue、wepy虽案例也很多，但已被权重最高的跨端能力给淘汰了）
 *  技术栈：权重再次之，我们团队对于react、vue技术栈都有涉及，只是使用深度问题上有差异

最后，我们决定把taro、uni-app两个框架作为候选，做进一步对比。  
uni-app其实内置了mpvue，感觉是个加强版，拓展到多端了。  
其实这2个框架的github star差的有点多，taro远超uni-app，但不能根据这个直接做决定，对比报告还是得做的，果然最后发现不能以star取人。

## Taro VS uni-app ##

看了几天文档对2个框架大概摸到门道，理了下对比思路，还是认真从如下几个维度比较下taro、uni-app两个框架：

*  跨端程度：真实运行项目到各平台，对比平台差异抹平程度
 *  运行性能：框架是否带来了额外的性能开销，降低用户体验
 *  开发体验：是否支持现代开发流程，是否对工程师提供高效友好的协助
 *  社区生态：社区是否繁荣，是否有大量可用轮子？

### 跨端 ###

**数量对比**

双方都宣传能支持微信、百度、支付宝、今日头条等小程序，H5，以及iOS和Android的App。看起来都不错。

**质量对比**

为验证最终跨端效果，我们分别下载 taro、uni-app的示例项目，体验编译到不同平台的运行效果。

首先选择 taro 官方账号下的知乎小程序示例（[github地址][github]），运行到各端后的效果：

![Image 1][]

taro-zhihu-01.png

从如上截图来看，taro成功实现了多端编译；我们接着更细致的对比了一下各端运行，发现taro在如下方面存在问题：

*  H5端：选项卡高亮状态错误，如上图，内容显示的是第二个选项卡，但底部高亮的依然是第一个选项卡
 *  H5端：下拉刷新不生效
 *  百度小程序端：下拉刷新触发后，回弹失败；若页面同时存在下拉刷新和上拉加载，则和页面滚动冲突

之后点击二级页、三级页，发现H5端的其它问题：

*  所有页面缺少导航栏，小程序端导航栏是原生控件，taro在H5端未对应生成
 *  跳转到二级页后，底部选项卡依然不消失，难道所有页面都要包含选项卡？如下图所示，不合理

![Image 1][]

taro-zhihu-02.png

针对这些问题，我们复查了一遍taro官网，官网倒是明确说明部分事件函数在H5端不生效，主要包括：

<table> 
 <thead> 
  <tr> 
   <th>方法</th> 
   <th>作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>onPullDownRefresh</td> 
   <td>页面相关事件处理函数--监听用户下拉动作</td> 
  </tr> 
  <tr> 
   <td>onReachBottom</td> 
   <td>页面上拉触底事件的处理函数</td> 
  </tr> 
  <tr> 
   <td>onShareAppMessage</td> 
   <td>用户点击右上角转发</td> 
  </tr> 
  <tr> 
   <td>onPageScroll</td> 
   <td>页面滚动触发事件的处理函数</td> 
  </tr> 
  <tr> 
   <td>onTabItemTap</td> 
   <td>当前是 tab 页时，点击 tab 时触发</td> 
  </tr> 
 </tbody> 
</table>

不过进一步仔细发现，taro文档里大量存在只有微信平台打勾的情况，H5和App侧大量的X。这说明跨其他平台很难平滑迁移。

接着运行uni-app示例项目，选择官方账号下的看图App模板（[github地址][github 1]）测试，运行到各端后效果：

![Image 1][]

uni-picture-01.png

从上图来看，uni-app 同样成功的实现了多端编译；我们接着更细致的对比了一下各端运行，发现如下问题：

*  支付宝平台：下拉刷新、上拉加载无效

之后点击二级页、三级页，没再发现明显问题。

![Image 1][]

uni-picture-02.png

从两个项目的实际运行来看，uni-app的跨端效果更好（其实不止对比了官方demo，我们自己也写了小demo），特别是在H5平台相比taro要完善不少。

另外，在进行两个框架的发行编译时，我们还发现了一个差异点：

*  taro 的 `dist` 目录下不区分编译平台，同一时间仅可编译到一个平台，不支持多个平台对比查看运行效果；
 *  uni-app 的 `dist` 目录区分编译平台，故支持同时编译到多个平台，可同时对比查看不同平台运行效果，这个体验是不错的，更有跨端开发的感觉  
    另外uni-app的条件编译比较完善，这个在处理平台差异时很有用。

**案例对比**

两个框架都在官网放上了众多案例，只是taro案例清一色是微信小程序，没看到其他端，难道大家使用taro，只是为了用react开发微信小程序，不需要跨端？

uni-app的案例什么平台都有，很多App做了多个平台。说起来我们领导还问过跨iOS、Android App的事情，不过目前另有原生团队，我们也只是做个备份调研。最终还是决定先把前端的技术统一了，稳定后再考虑App是否也迁移到这类框架下。

综合比较，uni-app跨端质量更好，真实跨端案例也更多。

### 运行性能 ###

我们在网上查阅了一些文章，有人认为taro的运行性能好于mpvue，而uni-app集成了mpvue，这个性能问题就得重点关注了。

不管是taro还是uni-app，`setData`的优化都是小程序性能优化中最为重要之事，且优化主要有两个方向：

*  尽可能减少`setData`调用的频次
 *  尽可能减少单次`setData`传输的数据

然后在调研中发现，uni-app其实还集成了另一个前述参选的框架`megalo`（怎么都被它揉进去了）

前面调研时知道`megalo`是做了差量数据更新的，那就应该问题不大。

我们自己动手写了一个长列表测试，分别写了taro版、uni-app版、原生小程序版，前几页数据滚动时差不多，7、8页过去发现uni-app加载新页面时有变慢的感觉。  
推测uni-app的长列表没有recycle机制，花了点时间把demo改进了下，滚动下面时把前面几页的数据干掉，然后再滚动就感受不到流畅度的差别了。

总结：taro在性能优化上做的更细致，使用uni-app需要自己注意代码优化。

### 开发体验 ###

taro 和 uni-app 的环境搭建及项目创建、运行编译都比较简单。

taro的安装及使用：

# 全局安装 @tarojs/cli $ npm install -g @tarojs/cli # 创建 taro 项目 $ taro init myApp # 进入项目目录 $ cd myApp # 运行到微信小程序，调试模式 $ npm run dev:weapp # 发行到微信小程序 $ npm run build:weapp

uni-app的安装及使用：

# 全局安装 vue-cli $ npm install -g @vue/cli # 创建uni-app项目 $ vue create -p dcloudio/uni-preset-vue my-project # 进入项目目录 $ cd my-project # 运行到微信小程序，调试模式 $ npm run dev:mp-weixin # 发行到微信小程序 $ npm run build:mp-weixin

开发流程方面，taro和uni-app均是以微信小程序为基础，也都针对小程序的开发弊端，提供了更优秀的体验，比如：

*  均支持使用 npm/yarn 安装管理第三方依赖
 *  均支持使用 ES6 甚至更新的ES规范
 *  均支持使用 less/scss/ts 等预编译器
 *  均支持进行应用状态管理，taro 支持 Redux/Mobx，uni-app 支持 vuex

开发工具方面，taro官方未特别推荐IDE，但提供了vscode支持的d.ts；  
uni-app推荐的开发工具是他自家的HBuilderX，用它可以不配环境，开箱即用；  
hbuilder以前接触过，当时没深研究，新版还挺让我意外，真没想到国人的开发工具可以做到这样，尤其是他家的markdown支持真心不错，于是本文就是在hbuilder里写的（已经有情感分了哈哈）。

总结：两个框架都支持现代前端开发流程。hbuilder对uni-app提供了优化定制，但对不熟悉的开发者有一定适应成本。另外hbuilder自带一个编译器，和cli装在项目下的编译器是2个，这个坑不少新人要注意别踩。

### 社区生态 ###

**学习交流**

Taro通过Github Issues+微信群方式交流，微信群活跃，贡献代码的人也多。

uni-app有专门的论坛，还有视频教程，QQ群微信群都活跃。

另外文档角度，uni-app的文档比taro要完善，数了数交流群的数量，也是uni-app多不少。

**生态**

taro官方发布了taro-ui库，awesome里三方组件不太多。

uni-app官方发布了uni-ui库，还有个插件市场，里面轮子很多，做业务应该可以很快拼轮子做出来。

## 基于公司业务及团队人员技能考虑 ##

橱窗里的衣服再漂亮，适合自己的才有用，开发框架亦是如此。

我们根据业务需求及团队成员现状，形成如下对比：

*  如何在有限前端团队人数下搞定更多平台，是我们的首要考虑，我们可不想踩太多坑导致任务完不成，跨端方面uni-app更成熟；
 *  团队里熟悉vue技术栈的同学多一点，全员培训react的风险还是略高，使用uni-app内部培训时间短、风险低。

因此，我们团队最后决定使用uni-app作为新项目的开发框架。

但挺诚心感谢其他开源框架的作者的，各位大牛的无私奉献，让我们可以节省这么多人力，拜谢！  
喜欢taro的朋友也莫喷我，大家各有所好，react和vue谁更好之类的骂战就不要继续延续到这里了。

接下来肯定会有很多uni-app的坑，等着我们去跳，但我等猿类的宿命就是不断跳坑、爬坑ㄟ( ▔, ▔ )ㄏ，待我们项目结束，再写一篇《uni-app爬坑血泪史》分享给大家。

转载：https://www.jianshu.com/p/03e08399587e

[math_formula_40_40_E2_80_8B]: https://math.jianshu.com/math?formula=%40%40%E2%80%8B
[github]: https://github.com/NervJS/taro-zhihu-sample
[Image 1]: 
[github 1]: https://github.com/dcloudio/uni-template-picture