小程序开发框架选型总结
从2016年微信小程序内测到现在,各大公司对小程序的业务开发需求越来越大,但是微信的原生工具在实际使用时很不便捷,尤其是业务比较复杂的项目很难通过其进行管理和迭代。
使用原生开发的问题:
小程序本身不支持常用的css预编译器
不支持ES7以上的高级语法,如async await等特性;
不支持工程化,如环境、变量等管理
缺少统一的request拦截请求
缺少统一的本地缓存读取管理
目前市面上开源的框架可以帮助我们解决上述问题,有些框架还有比较便捷的脚手架工具、以及支持多端的能力。本文将从业务功能的满足度、接入成本、项目性能、可维护性等多方面对现有框架进行介绍和对比,为大家在项目中选择开源框架时提供一个参考。
1.框架介绍
1.1 Wepy
WePY (发音: /'wepi/)是一款让小程序支持组件化开发的框架,通过预编译的手段让开发者可以选择自己喜欢的开发风格去开发小程序。框架的细节优化、Promise、Async Functions的引入等都是为了能让开发小程序项目变得更加简单,高效。
其特点如下图所示:
1.2 Mpvue
Mpvue是一个使用Vue.js开发小程序的前端框架。框架基于 Vue.js 核心,Mpvue 修改了 Vue.js 的 runtime 和 compiler 实现,使其可以运行在小程序环境中,从而为小程序开发引入了整套 Vue.js 开发体验。
主要特性:
彻底的组件化开发能力:提高代码复用性
完整的 Vue.js 开发体验
方便的 Vuex 数据管理方案:方便构建复杂应用
快捷的 webpack 构建机制:自定义构建策略、开发阶段 hotReload
支持使用 npm 外部依赖
使用 Vue.js 命令行工具 vue-cli 快速初始化项目
H5 代码转换编译成小程序目标代码的能力
1.3 Taro
Taro是一套遵循React语法规范的多端开发解决方案。
1.4 Uni-app
Uni-app 是一个使用 Vue.js 开发跨平台应用的前端框架。
1.5 Chamelon
Chameleon/kəˈmiːlɪən/,简写CML,中文名卡梅龙;中文意思变色龙,意味着就像变色龙一样能适应不同环境的跨端整体解决方案。
主要特性:
目录结构:提供规范化的项目结构,适合于企业级大型应用的开发。
视图层:视图层由CML与CMSS编写,核心是一个标准响应式数据驱动视图更新。
逻辑层:逻辑层由javascript编写,逻辑层将处理数据后自动更新视图,提供视图层的事件响应方法。
多态协议:提供了跨端时各端底层组件与接口统一的解决方案。
规范校验:为了提高开发的效率与代码的可维护性,提供了全面的代码规范与校验。
2.框架选型
2.1 业务功能的满足度
一般公司开发团队对业务功能的需求,有两种:
小程序原生基本业务功能的开发,包括用户登录、内容展示、页面交互、图片文档查看等等
页面开发一版支持微信小程序、百度小程序、H5或快应用等多端兼容需求
2.1.1 基本业务功能
Wepy、Mpvue、Taro、Uni-app、Chamelon几种框架已经支持小程序原生的大部分组件、API,在一般业务功能的开发上没有太大的差异性,在新功能的支持力度上略有差异。
从各框架最新版本的更新内容和时间来看,Taro、Uni-app和Chameleon对新功能的支持力度比较好,尤其Taro框架支持了小程序原生的写法,这样即使框架不支持的小程序API也可以在不修改项目框架的前提下使用。
2.1.2 多端兼容需求
_ | Wepy | Mpvue | Taro | Uni-app | Chameleon |
微信小程序 | 支持 | 支持 | 支持 | 支持 | 支持 |
支付宝小程序 | 不支持 | 支持 | 支持 | 支持 | 不支持 |
百度小程序 | 不支持 | 支持 | 支持 | 支持 | 不支持 |
头条小程序 | 不支持 | 支持 | 支持 | 支持 | 不支持 |
H5 | 不支持 | 不支持 | 支持 | 支持 | 支持 |
React Native | 不支持 | 不支持 | 支持 | 不支持 | 不支持 |
快应用 | 不支持 | 不支持 | 支持 | 不支持 | 不支持 |
QQ小程序 | 不支持 | 不支持 | 支持 | 支持 | 不支持 |
Android原生 | 不支持 | 不支持 | 不支持 | 支持 | 不支持 |
iOS原生 | 不支持 | 不支持 | 不支持 | 支持 | 不支持 |
Chameleon Playground App | 不支持 | 不支持 | 不支持 | 不支持 | 支持 |
Weex playground App | 不支持 | 不支持 | 不支持 | 不支持 | 支持 |
从框架对各端的兼容性来看,Taro和Uni-app对各端的兼容能力较强。
2.2 接入成本
选择框架并接入到团队内,需要两种成本:
代码成本:新项目建立项目模板成本、老项目代码迁移成本
学习成本:团队内的开发人员从0到1熟练使用框架的成本
2.2.1 Wepy
接入成本
给新起项目提供了cli能力:
$ npm install @wepy/cli -g # 全局安装 WePY CLI 工具 $ wepy init standard myproj # 使用 standard 模板初始化项目 $ cd myproj # 进入到项目目录 $ npm install # 安装项目依赖包 $ npm run dev # 监听并且编译项目
未给老项目迁移提供能力,只能手动迁移代码。
学习成本
Wepy有一个比较简单的开源文档,Wepy的语法糖是类Vue,基本项目结构和原生小程序类似,对熟悉Vue和小程序的同学来说学习成本很低。
一个简单的Wepy代码示例:
<style lang="less"> .container { height: 100%; } </style> <script> import wepy from 'wepy' export default class extends wepy.app { config = { pages: [ 'pages/index' ], window: { navigationBarTitleText: '日历' } } } </script>
2.2.2 Mpvue
接入成本
给新起项目提供了cli能力:
# 1. 全局安装 vue-cli $ npm install --global vue-cli@2.9 # 2. 创建一个基于 mpvue-quickstart 模板的新项目 $ vue init mpvue/mpvue-quickstart my-project # 3. 安装依赖,走你 $ cd my-project $ npm install $ npm run dev
未给老项目迁移提供能力,只能手动迁移代码。
学习成本
Mpvue的文档在2018.8.10后再也没有更新过,文档的内容较老也比较简单,其语法糖是Vue,为开发者提供了整体的Vue的开发体验,对熟悉Vue的同学接入成本较低。
一个简单的Mpvue代码示例:
<template> <div @click="clickHandle"> <div class="userinfo" @click="bindViewTap"> <div class="userinfo-nickname"> <card :text="userInfo.nickName"></card> </div> </div> </div> </template> <script> import card from '@/components/card' export default { data () { return { motto: 'Hello miniprograme', userInfo: { nickName: 'mpvue', avatarUrl: 'http://mpvue.com/assets/logo.png' } } } } </script> <style scoped> .userinfo { display: flex; } </style>
2.2.3 Taro
接入成本
给新起项目提供了cli能力:
# 使用 npm 安装 CLI $ npm install -g @tarojs/cli # 使用命令创建模板项目 $ taro init myApp
给老的原生小程序项目提供了代码一键转换的指令:
$ taro convert
学习成本
Taro有一个完善的开源文档,详细的描述了Taro的组件、API支持情况和使用、进阶指南,Taro的语法糖是React,对熟悉React同学来说学习成本很低。
一个简单的Taro代码示例:
import Taro, { Component } from "@tarojs/taro"; import { View, Button } from "@tarojs/components"; export default class Index extends Component { constructor() { super(...arguments); this.state = { title: "首页", list: [1, 2, 3] }; } componentDidMount() {} add = e => { // dosth } render() { return ( <View className="index"> <View className="title">{this.state.title}</View> </View> ); } }
2.2.4 Uni-app
接入成本
给新起项目提供了两种生产项目模板方式:
通过 HBuilderX 可视化界面,在点击工具栏里的文件 -> 新建 -> 项目
通过vue-cli命令行:
# 全局安装vue-cli $ npm install -g @vue/cli # 创建uni-app $ vue create -p dcloudio/uni-preset-vue my-project
给小程序原生、Wepy、Mpvue提供了详细的迁移步骤文档。
学习成本
Uni-app有一个完善的开源文档,其语法糖是Vue,对熟悉Vue的同学来说学习成本很低,在开发工具上官方对HBuilderX更友好,对熟悉HBuilderX使用的入手成本较低。
一个简单的Uni-app代码示例:
<template> <view class="content"> <view> <text class="title">{{title}}</text> </view> </view> </template> <script> export default { data() { return { title: 'Hello' } } } </script> <style> .content { text-align: center; height: 400upx; } </style>
2.2.5 Chameleon
接入成本
给新起项目提供了cli能力:
# 全局安装cli $ npm i -g chameleon-tool # 初始化项目 $ cml init project
给小程序原生、Vue、Weex提供了CML的迁移指南。
学习成本
Chameleon有一个相对完善的开源文档,其语法糖是类Vue,对熟悉Vue的同学来说学习成本很低。
一个简单的Chameleon代码示例:
<template> <view> <!-- 数据绑定与计算属性 --> <text>{{ message }}</text> <text class="class1">{{ message2 }}</text> </view> </template> <script> class Index { data = { message: 'HelloCML', } } export default new Index() </script> <style scoped> .class1 { color: #f00; } </style> </script>
2.3 项目性能
本文主要研讨的应用方向是微信小程序,所以选型的框架需要对微信小程序的兼容性很高、且产出的项目有较高的性能。多端框架很多都是基于微信小程序的API开发的,所以对微信小程序的兼容性都很高,下面我们来看一下一个简单的日历组件应用到各框架产出的微信小程序性能数据对比。
2.3.1 微信原生
小程序包大小:22.868 字节
微信基础库版本:2.6.2 (以下框架相同)
测试数据记录:
内存 | 页面切换耗时 | 启动耗时 | 初次渲染耗时 | 再次渲染耗时 | 数据缓存 |
252m | 146ms | 1163ms | 26ms | 94ms | 0B |
244m | 606ms | 1293ms | 38ms | 60ms | 0B |
256m | 159ms | 1293ms | 26ms | 131ms | 0B |
235m | 708ms | 1403ms | 49ms | 58ms | 0B |
245m | 571ms | 1163ms | 32ms | 56ms | 0B |
2.3.2 Wepy
小程序包大小:131,957 字节
Wepy版本:1.6.0
测试数据记录:
内存 | 页面切换耗时 | 启动耗时 | 初次渲染耗时 | 再次渲染耗时 | 数据缓存 |
253m | 436ms | 1049ms | 29ms | 35ms | 0B |
259m | 542ms | 1340ms | 33ms | 61ms | 0B |
267m | 466ms | 1113ms | 22ms | 37ms | 0B |
260m | 447ms | 1160ms | 22ms | 50ms | 0B |
254m | 459ms | 1036ms | 30ms | 40ms | 0B |
2.3.3 Mpvue
小程序包大小:197,601 字节
Mpvue版本:2.0.6
测试数据记录:
内存 | 页面切换耗时 | 启动耗时 | 初次渲染耗时 | 再次渲染耗时 | 数据缓存 |
225m | 247ms | 896ms | 24ms | 62ms | 0B |
239m | 253ms | 910ms | 22ms | 58ms | 0B |
235m | 446ms | 1591ms | 27ms | 62ms | 0B |
237m | 269ms | 979ms | 21ms | 60ms | 0B |
243m | 270ms | 908ms | 23ms | 57ms | 0B |
2.3.4 Taro
小程序包大小:167,080 字节
Taro版本:1.3.2
测试数据记录:
内存 | 页面切换耗时 | 启动耗时 | 初次渲染耗时 | 再次渲染耗时 | 数据缓存 |
246m | 231ms | 718ms | 16ms | 224ms | 0B |
241m | 297ms | 1007ms | 19ms | 246ms | 0B |
246m | 256ms | 868ms | 16ms | 288ms | 0B |
242m | 227ms | 829ms | 17ms | 224ms | 0B |
237m | 231ms | 869ms | 17ms | 229ms | 0B |
2.3.5 Uni-app
小程序包大小:292,831 字节
Uni-app版本:2.0.0
测试数据记录:
内存 | 页面切换耗时 | 启动耗时 | 初次渲染耗时 | 再次渲染耗时 | 数据缓存 |
239m | 440ms | 987ms | 34ms | 178ms | 34B |
237m | 529ms | 1365ms | 34ms | 182ms | 34B |
232m | 531ms | 1133ms | 39ms | 183ms | 34B |
236m | 487ms | 1154ms | 32ms | 178ms | 34B |
239m | 486ms | 1051ms | 33ms | 190ms | 34B |
2.3.6 Chameleon
小程序包大小:671,702 字节
Chameleon版本:1.0.3
测试数据记录:
内存 | 页面切换耗时 | 启动耗时 | 初次渲染耗时 | 再次渲染耗时 | 数据缓存 |
223m | 550ms | 1043ms | 46ms | 60ms | 0B |
231m | 597ms | 1326ms | 36ms | 60ms | 0B |
225m | 631ms | 1338ms | 37ms | 58ms | 0B |
237m | 658ms | 1289ms | 47ms | 68ms | 0B |
245m | 611ms | 1241ms | 35ms | 66ms | 0B |
2.3.7 框架性能PK (平均值)
包大小:
原生 < Wepy < Taro < Mpvue < Uni-app < Chameleon
微信小程序的性能:
Taro > Mpvue > Uni-app > Wepy > Chamelon > 未优化过的原生代码
框架使用后比原生的性能更好,这简直逆天了,后来研究发现:
微信原生框架耗时主要在setData调用上,开发者若不单独优化,则每次都会传递大量数据;而 Uni-app、Taro等都在调用setData之前自动做diff计算,每次仅传递变动的数据。
2.4 可维护性
团队选型框架后,最担心的事情就是后期的维护性。在需求开发的过程中,发现框架本身有问题,怎么解决?框架深度使用过程中,突然发现该框架无人维护了,issue上提交的问题迟迟没人跟进了,怎么办?所以在选型框架中,框架的可维护性是大部分团队所关注的事情。
_ | Wepy | Mpvue | Taro | Uni-app | Chameleon |
Star数 | 18854 | 18605 | 21740 | 12484 | 6521 |
社群 | 无论坛、无交流群;只能网搜或者提issues | 无论坛、无交流群;只能网搜或者提issues | 有论坛、社区、交流群等,论坛活跃 | 有论坛、社区、交流群等,论坛活跃,交流群多且回复及时 | 官方文档提供了微信、QQ交流群、顺风公鹿等 |
语言 | 类Vue的语法糖 | 类Vue的语法糖 | React的语法糖 | 类Vue的语法糖 | 类Vue的语法糖 |
开源程度 | 完全开源 | 完全开源 | 完全开源 | 半开源 | 完全开源 |
从框架现有star数可以看出:Wepy、Mpvue和Taro的开源关注度比较高,这说明这几个框架的论坛活跃度更高,相关问题的解决方法更多。
从社群活跃度可以看出:Wepy和Mpvue已经很久没人维护了,所以后续的可维护性较差,建议使用其他的框架。
从框架停更的后期维护成本来看:
Wepy、Mpvue、Uni-app、Chameleon都是类Vue的语法糖,其迁移成本略低;而Taro是React的语法糖,其迁移成本较高;
Wepy、Mpvue、Taro、Chameleon都是完全开源的,团队可以根据自己需求把代码拷贝出来自己维护;而Uni-app是半开源的,团队无法把源代码拷贝出来。
3.总结
通过以上业务功能的满足度、接入成本、项目性能、可维护性等多方面对比,可以看出各个框架在各个方面有不同的优缺点。由于wepy和mpvue已长期不再维护,不建议团队选择。团队可以根据自己的实际业务需求和内部的技术栈选择,React系的可以选择Taro框架,Vue系的可以选择Uni-app或者Chameleon。
本文转载自公众号贝壳产品技术(ID:beikeTC)。
原文链接:
- 小程序技术选型-开发+UI框架汇总
- 小程序开发总结之框架分析
- TinkPHP框架开发的CRMEB小程序商城v4.0二次开发集成支付宝支付
- 小程序快速开发框架,大厂给我们造轮子咯
- Yii框架开发问题总结
- 【程序源代码】商城微服务开发框架
- 安卓开发知识框架_1_知识点总结
- 微信小程序框架主体快速开发教程
- 微信小程序开发过程中总结的注意事项
- Flask框架开发的毕业设计知识点总结
- 《转载》2015前端开发框架选型清单
- .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
- 微信小程序开发框架_类MINA文件结构
- 最近又开发串口通信程序总结1
- 基于MVC4+EasyUI的Web开发框架经验总结
- 微信小程序开发总结(一)
- 基于Metronic的Bootstrap开发框架经验总结(9)--实现Web页面内容的打印预览和保存操作
- Winform混合式开发框架的特点总结
- 微信小程序之小程序UI组件、开发框架、实用库学习资源汇总-建议收藏
- DSP程序开发与优化经验之二:程序运行时间测量方法总结