微信开发和原生开发_现在微信小程序用原生开发还是用wepy开发的多 - CSDN
精华内容
参与话题
  • WePY2 是基于小程序原生组件实现组件化开发。因此WePY2支持的最低版本小程序基础库为 1.6.3。WePY的特点有: 类Vue开发风格 支持自定义组件开发 支持引入NPM包 支持Promise 支持ES2015+特性,如Async Functions 支持...

    WePY框架

    WePY是一个由腾讯团队推出的最早的一款类Vue语法的小程序组件化开发框架。WePY2 是基于小程序原生组件实现组件化开发。因此WePY2支持的最低版本小程序基础库为 1.6.3。WePY官网https://wepyjs.github.io/wepy-docs/,WePY的特点有:

    1. 类Vue开发风格
    2. 支持自定义组件开发
    3. 支持引入NPM包
    4. 支持Promise 支持ES2015+特性,如Async Functions
    5. 支持多种编译器,Less/Sass/Styus、Babel/Typescript、Pug
    6. 支持多种插件处理,文件压缩,图片压缩,内容替换等
    7. 支持 Sourcemap,ESLint等
    8. 小程序细节优化,如请求列队,事件优化等

    因为WePY是在代码开发风格上借鉴了Vue,本身和Vue没有什么关系,所以说它是一个类vue框架。WePY搭建项目的方法也是先要安装node,然后在终端输入命令,如下:
    在这里插入图片描述

    mpvue框架

    mpvue 是美团点评开源的一个使用 Vue.js 开发小程序的前端框架,框架基于Vue.js 核心,mpvue修改了 Vue.js 的runtime和 compiler 实现,使其可以运行在小程序环境中,从而为小程序开发引入了整套 Vue.js 开发体验,这给使用过Vue开发Web应用的前端开发者提供了极低的切换门槛来开发小程序。mpvue是从整个Vue的核心代码上经过二次开发而形成的一个框架,相当于是给Vue本身赋能,增加了开发微信小程序的能力。

    用mpvue搭建一个小程序项目:
    1.安装node.js,命令node --version检测是否安装成功。
    2.执行以下命令,将npm的下载源切换到国内淘宝的镜像,以提高下载时的速度和成功率:

    npm set registry https://registry.npm.taobao.org/
    

    3.全局安装vue-cli

    npm install vue-cli -g
    

    4.创建一个基于mpvue的小程序项目

    vue init  mpvue/mpvue-quickstart  my-project
    

    命令行将一步步的引导我们选择或填写项目的配置信息,如果你还不太明白这些内容的含义,可以先直接全部按回车,随着运行成功的回显之后,可以看到本地多了个 dist 目录,这个目录里就是生成的小程序相关代码。

    5.打开微信开发者工具,填好相关信息:
    项目目录选择指向my-project目录:
    在这里插入图片描述
    6.如果你使用的编辑器是vscode,推荐安装Vetur插件。
    在vscode的插件管理器中,查找Vetur并安装它。Vetur是一款可以提供Vue语法高亮、语法检查和代码快捷输入等功能的插件,可以为我们的开发过程提供很多便利。所以十分推荐安装使用它。我们用vscode打开项目my-project,直接在这里编写代码,记得勾选微信开发者工具里编辑设置中的"保存时自动编译小程序",这样代码保存后模拟器就会自动刷新界面。

    这里附上官方给的五分钟快速搭建mpvue项目链接:http://mpvue.com/mpvue/quickstart.html

    编写模板代码的时候通常也主要是以HTML为主,比如我们编写一个.vue组件时写了如下代码:
    在这里插入图片描述
    而mpvue会通过编译,将这个HTML模板转换成小程序的WXML代码:
    在这里插入图片描述
    这样,我们就可以完全用开发Web应用的方式去开发小程序了,这为我们减少了一些思维切换方面的成本。

    百花齐放的开发方式

    下面对原生微信小程序、mpvue、WePY这三种开发小程序方式的比较:
    在这里插入图片描述
    除此之外,我们知道uniapp也是可以开发微信小程序的,而且它的上手速度也很快。听说WePY开发的坑有点多,目前用的人数也不是很多,目前也有人用原生开发微信小程序,个人还是喜欢uniapp和mpvue来开发小程序。你是用什么方法开发微信小程序呢,欢迎评论留言交流。最后,欢迎关注微信公众号一起来学习前端技术
    在这里插入图片描述

    展开全文
  • 2. 微信小程序已经支持了绝大部分的 ES6 API 3. 可以自动补全css的兼容语法 文档:https://developers.weixin.qq.com/miniprogram/dev/framework/details.html 一. 设计 总结: 设计图750px, 1px ...

     

    简介:

    总结:

    1. 逻辑层使用js引擎,视图层使用webview渲染

    2. 微信小程序已经支持了绝大部分的 ES6 API

    3. 可以自动补全css的兼容语法

    文档:https://developers.weixin.qq.com/miniprogram/dev/framework/details.html

    一. 设计

    总结:

    设计图750px, 1px =  1rpx,方便计算

     

    二. 小程序页面结构

     wxml:

    功能类似html,描述节点,但小程序的 WXML 用的标签是 viewbuttontext 等等,这些标签就是小程序给开发者包装好的基本能力,我们还提供了地图、视频、音频等等组件能力

    wxss:

    类似css,有css大部分属性:

    1. 单位rpx

    2. 样式导入和less等css预处理器一致,用@import

    3. 不能用嵌套选择器

     js: 

    微信小程序的 JavaScript 运行环境即不是 Browser 也不是 Node.js。它运行在微信 App 的上下文中,不能操作DOM,没有window, document, 也不能通过 Node.js 相关接口访问操作系统 API

    JS 脚本文件通过改变数据来处理用户的操作

    Page({
       data: {
            msg: ''
        }, 
       clickMe: function() {
            this.setData({ msg: "Hello World" })
      }
    })

     json:

    页面配置文件,可选

    比如配置组件,配置下拉刷新功能等

    {
        "usingComponents": {
            "login-page": "/components/login-page/login-page"
        },
        "enablePullDownRefresh": true
    }

     

    Q&A

     

    三. 工作原理

     

    微信小程序View层用来渲染页面结构,AppService层用来逻辑处理、数据请求、接口调用,它们在两个进程(两个Webview)里运行。

    视图层和逻辑层通过系统层的JSBridage进行通信,

    逻辑层把数据变化通知到视图层,触发视图层页面更新,

    视图层把触发的事件通知到逻辑层进行业务处理。

     

     

     

    视图层和逻辑层的数据传输,实际上通过两边提供的 evaluateJavascript 所实现。

    即用户传输的数据,需要将其转换为字符串形式传递,同时把转换后的数据内容拼接成一份 JS 脚本,再通过执行 JS 脚本的形式传递到两边独立环境。

    而 evaluateJavascript 的执行会受很多方面的影响,数据到达视图层并不是实时的。

     

    为什么小程序最多允许打开5个层级的页面?

    小程序的UI视图和逻辑处理是用多个webview实现的,逻辑处理的JS代码全部加载到一个Webview里面,称之为AppService,整个小程序只有一个,并且整个生命周期常驻内存,
    而所有的视图(wxml和wxss)都是单独的Webview来承载,称之为AppView。
    所以一个小程序打开至少就会有2个webview进程,正式因为每个视图都是一个独立的webview进程,考虑到性能消耗,小程序不允许打开超过5个层级的页面,当然同是也是为了体验更好。

    类MVVM开发模式

    1. 都是渲染和逻辑分离,不再JS 直接操控 DOMJS 只需要管理状态,再通过一种模板语法({{ }})来描述状态和界面结构的关系
    2. 小程序逻辑和UI执行在2个独立的Webview里面,这个是跟当前流行的react,agular,vue本质的差别
     

    Q&A

    原理详解:https://www.jianshu.com/p/b50ed8fc49d6

    JsCore详解:http://www.cnblogs.com/meituantech/p/9528285.html

    四. 开发工具

     

     项目设置:

    Q&A:

    为什么要代码保护?

     第一次打开小程序,微信会把整个小程序包下载到本地,命名为:  _1992529666_112.wxapkg  形式,在本地进行解压编译操作。

    所以我们可以在文件系统找到此包,进行反编译,如下为反编译后的小程序源码:

    但源码的js部分会被混淆或者丢失

     

    详解:https://developers.weixin.qq.com/miniprogram/dev/devtools/devtools.htm

     

    五. 小程序能力--分包加载

    目的: 用户在使用时按需进行加载,减少启动时间

    主包:放置默认启动页面/TabBar 页面,以及一些所有分包都需用到公共资源/JS 脚本

    分包:可以有多个分包。每个分包小程序必定含有一个主包

     

    在小程序启动时,默认会下载主包并启动主包内页面,当用户进入分包内某个页面时,客户端会把对应分包下载下来,下载完成后再进行展示。

    目前小程序分包大小有以下限制:

    • 整个小程序所有分包大小不超过 8M
    • 单个分包/主包大小不能超过 2M

     

    独立分包:是小程序中一种特殊类型的分包,可以独立于主包和其他分包运行。从独立分包中页面进入小程序时,不需要下载主包。当用户进入普通分包或主包内页面时,主包才会被下载。

     

    所有的分包,独立分包,都是在同一套源码内,通过app.json配置进行划分

    {
      "pages": [
        "pages/index",
        "pages/logs"
      ],
      "subpackages": [
        {
          "root": "moduleA",
          "pages": [
            "pages/rabbit",
            "pages/squirrel"
          ]
        }, {
          "root": "moduleA",
          "pages": [
            "pages/pear",
            "pages/pineapple"
          ],
          "independent": true
        }
      ]
    }

     

    分包预下载:

    在主包内预下载分包,在独立分包内预下载主包

    {
      "pages": ["pages/index"],
      "subpackages": [
        {
          "root": "important",
          "pages": ["index"],
        },
        {
          "root": "sub1",
          "pages": ["index"],
        },
        {
          "name": "hello",
          "root": "path/to",
          "pages": ["index"]
        },
        {
          "root": "sub3",
          "pages": ["index"]
        },
        {
          "root": "indep",
          "pages": ["index"],
          "independent": true
        }
      ],
      "preloadRule": {
        "pages/index": {
          "network": "all",
          "packages": ["important"]
        },
        "sub1/index": {
          "packages": ["hello", "sub3"]
        },
        "sub3/index": {
          "packages": ["path/to"]
        },
        "indep/index": {
          "packages": ["__APP__"]
        }
      }
    }

     

    6. 小程序支付

     

    wx.requestPayment(
    {
    'timeStamp': '',
    'nonceStr': '',
    'package': '',
    'signType': 'MD5',
    'paySign': '',
    'success':function(res){},
    'fail':function(res){},
    'complete':function(res){}
    })

     

    文档:https://pay.weixin.qq.com/wiki/doc/api/wxa/wxa_api.php?chapter=7_3&index=1

     

    7. 小程序登录

    实际项目登录时序图:

     

    授权弹框两种形式:

    1. 判断skey不存在,直接显示登录按钮

    <button class="btn" open-type="getUserInfo" bindgetuserinfo="login">登录</button>

    点击按钮直接弹出微信授权框,授权成功后调用wx.login()等上述流程

    微信授权弹框:

     

    2. 接口返回未登录状态,弹起自定义登录框

    自定义登录弹框内的登录按钮依然为:

    <button class="btn" open-type="getUserInfo" bindgetuserinfo="login">登录</button>

     

    自定义登录弹框:

     

    Unionid机制

     注意:

    这里要注意下UnionID的获取,如果这个用户没有关注你的公众号,那你直接从code2session中是拿不到unionId的,所以就看上面的第一点,从getUserInfo中获取加密数据传到后台解密后再获取unionId才行。

     

    了解更多小程序,建议再看下小程序避坑指南

    转载于:https://www.cnblogs.com/saysmy/p/9846714.html

    展开全文
  • 与之相随,小程序的开发生态也在蓬勃发展,从最初的微信原生开发,到wepy、mpvue、taro、uni-app等框架依次出现,从刀耕火种演进为现代化开发,生态越来越丰富。 选择多了,问题也就来了,开发小程序,该用原生还是...

    2017-1-9微信小程序诞生以来,历经2年多的迭代升级,已有数百万小程序上线,成为继Web、iOS、Android之后,第四大主流开发技术。

    与之相随,小程序的开发生态也在蓬勃发展,从最初的微信原生开发,到wepympvuetarouni-app等框架依次出现,从刀耕火种演进为现代化开发,生态越来越丰富。

    选择多了,问题也就来了,开发小程序,该用原生还是选择三方框架?

    首先,微信原生开发的槽点大多集中如下:

    1. 原生开发对Node、预编译器、webpack支持不好,影响开发效率和工程构建流程
    2. 微信定义了一个不伦不类的语法,不如正经学vue、react,学会了全端通用,而不是只为微信小程序
    3. vue/react生态里有太多周边工具,可以提高开发效率,比如ide、校验器、三方库。。。
    4. 微信那个ide和专业编辑器相比实在不好用

    同时,开发者对三方框架,又总是有各种顾虑:

    1. 怕性能不如原生
    2. 怕有些功能框架实现不了,只能用原生
    3. 怕框架不稳定,跳到坑里
    4. 以及诸多三方框架,到底该用哪个

    面对如此纠结的场景,不少热心开发者发布评测文章分享经验,但感觉众说纷纭,过期信息太多。缺少一份非常专业的、深度的,或者按如今流行的话来讲,“硬核的”评测报告。

    做评测报告这件事,不同于泛泛经验分享,其实非常花费时间。它需要:

    • 你必须成为每一个框架的专业使用人员,而不是浅浅的了解一下这些框架
    • 真实的动手写多个平台的测试例,比较各个平台的功能、性能,了解他们的社区情况、技术服务情况
    • 你要有长期跟踪和更新报告的能力,避免半年后沦为过期信息

    换言之:评测要想真,功夫得做深!

    uni-app团队花费2个周时间完成本报告,并坚持每个季度更新一次本评测报告。目前更新时间为2019年5月。

    本文从面向用户、面向开发者两大维度七大细项,对微信原生及主流的wepympvuetarouni-app开发框架进行横向对比,希望给开发者在小程序框架选型时提供一种参考思路。本文基于各框架官网可采集到的公开数据及真实测试数据,希望客观公正地评价各个框架的现状和优劣。但宥于利益相关,本文的观点很可能是带有偏向性的,大家可以带着批判的眼光来看待,如发现本文中有任何评测失真,欢迎在这里报 issuse

    面向用户、面向开发者维度,具体包括:

    1. 用户:提供完整的业务实现,并保证高性能体验
    2. 开发者:平缓的学习曲线、现代开发体验(工程化)、高效的社区支持、活跃的开发迭代、多端复用

    2. 用户

    1.1 功能实现

    软件开发,首要目标是向用户提供完整、闭环的业务功能。

    在web开发中,如果vue、react等框架的使用,造成开发者无法操作浏览器提供的所有api,那这样的框架肯定是不成熟的。小程序开发也一样,任何开发框架,都不能限制底层的api调用。

    而各种业务功能底层依赖微信暴漏的组件和接口(微信官网介绍的组件和 API 规范,也即微信原生API),三方框架是基于微信原生进行的二次封装,开发者此时常会有个疑问:小程序在不断的迭代升级,如果某项业务依赖于最新的小程序API,但三方框架尚未封装,该怎么办?

    实际上就像web开发的vue、react一样,浏览器出了一个新API,并不会涉及vue、react的升级。本评测里的所有框架,都不会限制开发者调用底层能力。这里详细解释下原因:

    • wepy:未对小程序API作二次封装,API依然使用微信原生的,框架与微信小程序是否新增API无关
    • mpvue:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似mpvue.request()
    • taro:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似Taro.request(),支持Taro 代码与小程序代码混写,可通过混写的方式调用框架尚未封装的小程序新增API
    • uni-app:支持微信的所有原生组件和api,无限制。在跨端方面,即便仍然使用微信原生的组件和API,也可以直接跨端编译到App、H5、以及支付宝百度头条等小程序。但为了管理清晰,推荐使用uni封装的API,类似uni.request()。同时支持条件编译,可在条件编译代码块中,随意调用各个平台新增的API及组件

    注:以上顺序,按各个框架的诞生顺序排序,下同。

    故,三方框架均可调用所有小程序API,完成用户的业务需求,这个维度各框架是无差别的。

    然而有差别的,是性能体验。

    1.2 性能体验

    三方框架,内部大多做了层层封装,这些封装是否会增加运行负载,导致性能下降?尤其是与原生微信小程序开发相比性能怎么样,这是大家普遍关心的问题。

    为客观的进行对比,我们特意搭建了一个测试模型,详细如下:

    • 开发内容:开发一个仿微博小程序首页的复杂长列表,支持下拉刷新、上拉翻页、点赞。

    • 界面如下:

    • 开发版本:一共开发了5个版本,包括微信原生版、wepy版、mpvue版、taro版、uni-app版,按照官网指引通过cli方式默认安装。

    • 测试代码开源(Github仓库地址:https://github.com/dcloudio/test-framework), Tips:若有同学觉得测试代码写法欠妥,欢迎提交 PR 或 Issus

    • 测试机型:红米 Redmi 6 Pro、MIUI 10.2.2.0 稳定版(最新版)、微信版本 7.0.3(最新版)

    • 测试环境:每个框架开始测试前,杀掉各App进程、清空内存,保证测试机环境基本一致;每次从本地读取静态数据,屏蔽网络差异。

    我们以上述仿微博小程序为例,测试2个容易出性能问题的点:长列表加载、大量点赞组件的响应。

    1.2.1 长列表加载

    仿微博的列表是一个包含很多组件的列表,这种复杂列表对性能的压力更大,很适合做性能测试。

    从触发上拉加载到数据更新、页面渲染完成,需要准确计时。人眼视觉计时肯定不行,我们采用程序埋点的方式,制定了如下计时时机:

    • 计时开始时机:交互事件触发,框架赋值之前,如:上拉加载(onReachBottom)函数开头
    • 计时结束时机:页面渲染完毕(微信setData回调函数开头)

    Tips:setData回调函数开头可认为是页面渲染完成的时间,是因为微信setData定义如下(微信规范):

    测试方式:从页面空列表开始,通过程序自动触发上拉加载,每次新增20条列表,记录单次耗时;固定间隔连续触发 N 次上拉加载,使得页面达到 20*N 条列表,计算这 N 次触发上拉到渲染完成的平均耗时。

    测试结果如下:

    说明:以400条微博列表为例,从页面空列表开始,每隔1秒触发一次上拉加载(新增20条微博),记录单次耗时,触发20次后停止(页面达到400条微博),计算这20次的平均耗时,结果微信原生在这20次 触发上拉 -> 渲染完成 的平均耗时为876毫秒,最快的uni-app是741毫秒,最慢的mpvue是4493毫秒

    大家初看这个数据,可能比较疑惑,别急,下方有详细说明

    说明1:为何 mpvue/wepy 测试数据不完整?

    mpvuewepy 诞生之初,微信小程序尚不支持自定义组件,无法进行组件化开发;mpvuewepy 为解决这个问题,将用户编写的Vue组件,编译为WXML中的模板(template),变相实现了组件化开发能力,提高代码复用性,这在当时的技术条件下是很棒的技术方案。

    但如此方案,在页面复杂、组件较多的时,会大量增加页面 dom 节点数量,甚至超出微信的 dom 节点数限制。我们在 红米手机(Redmi 6 Pro)上实测,页面组件超过500个时,mpvuewepy 实现的仿微博App就会报出如下异常,并停止渲染,故这两个测试框架在组件较多时,测试数据不完整。这也就意味着,当页面组件太多时,无法使用这2个框架。

    dom limit exceeded please check if there's any mistake you've made

    Tips1:wepy官网的CHANGELOG,提到 v1.7.2 测试版本添加了对小程序原生组件的支持,实测坑很多,因为是测试版,官方在 issue 中也表示不推荐使用;按照官网文档,默认安装的 v1.7.3 正式版本并不支持原生组件

    Tips2:wepy在400条列表以内,为何性能高于微信原生框架,这个跟自定义组件管理开销及业务场景有关(wepy编译为模板,不涉及组件创建及管理开销),后续对微博点赞,涉及组件数据传递时,微信原生框架的性能优势就提现出来了,详见下方测试数据。

    说明2:为什么测试数据显示uni-app 会比微信原生框架的性能略好呢?

    其实,在页面上有200条记录(200个组件)时,taro 性能数据也比微信原生框架更好。

    微信原生框架耗时主要在setData调用上,开发者若不单独优化,则每次都会传递大量数据;而 uni-apptaro 都在调用setData之前自动做diff计算,每次仅传递变动的数据。

    例如当前页面有20条数据,触发上拉加载时,会新加载20条数据,此时原生框架通过如下代码测试时,setData会传输40条数据

    data: {
        listData: []
    },
    onReachBottom() { //上拉加载
        let listData = this.data.listData;
        listData.push(...Api.getNews());//新增数据
        this.setData({
            listData
        }) //全量数据,发送数据到视图层
    }
    复制代码

    开发者使用微信原生框架,完全可以自己优化,精简传递数据,比如修改如下:

    data: {
        listData: []
    },
    onReachBottom() { //上拉加载
        // 通过长度获取下一次渲染的索引
        let index = this.data.listData.length;
        let newData = {}; //新变更数据
        Api.getNews().forEach((item) => {
            newData['listData[' + (index++) + ']'] = item //赋值,索引递增
        }) 
        this.setData(newData) //增量数据,发送数据到视图层
    }
    复制代码

    经过如上优化修改后,再次测试,微信原生框架性能数据如下:

    从测试结果可看出,经过开发者手动优化,微信原生框架可达到更好的性能,但 uni-apptaro 相比微信原生,性能差距并不大。

    这个结果,和web开发类似,web开发也有原生js开发、vue、react框架等情况。如果不做特殊优化,原生js写的网页,性能经常还不如vue、react框架的性能。

    也恰恰是因为Vuereact框架的优秀,性能好,开发体验好,所以原生js开发已经逐渐减少使用了。

    复杂长列表加载下一页评测结论:微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > wepy > mpvue

    Tips:有人以为uni-app和mpvue是一样的,早期uni-app确实使用过mpvue,但后来因为性能和vue语法支持度问题已经重新开发了。

    1.2.2 点赞组件响应速度

    长列表中的某个组件,比如点赞组件,点击时是否能及时的修改未赞和已赞状态?是这项测试的评测点。

    测试方式:

    • 选中某微博,点击“点赞”按钮,实现点赞状态状态切换(已赞高亮、未赞灰色),
    • 点赞按钮 onclick函数开头开始计时,setData回调函数开头结束计时;

    在红米手机(Redmi 6 Pro)上进行多次测试,求其平均值,结果如下:

    说明:也就是在列表数量为400时,微信原生开发的应用,点赞按钮从点击到状态变化需要111毫秒。

    测试结果数据说明:

    • wepy/mpvue 测试数据不完整的原因同上,在组件较多时,页面已经不再渲染了
    • 基于微信自定义组件实现组件开发的框架(uni-app/taro),组件数据通讯性能接近于微信原生框架,远高于基于template实现组件开发的框架(wepy/mpvue)性能

    组件数据更新性能测评:微信原生开发,uni-app,taro > wepy > mpvue

    综上,本性能测试做了2个测试,长列表加载和组件状态更新,综合2个实验,结论如下:

    微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > wepy > mpvue

    2.开发者

    在满足用户业务需求的前提下,我们谈谈开发者的需求,从如下几个维度比较:

    • 平缓的学习曲线:简单易学,最好能复用现有技术栈,丰富的学习资料
    • 高效的开发体验:现代前端开发流程、工程化支持
    • 高效的社区支持:遇到问题,可很快的寻求到帮助
    • 活跃的开发迭代:框架处于积极更新升级状态,无需担心停更

    2.1 平缓的学习曲线

    2.1.1 DSL语法支持

    选择开发团队熟悉的、能快速上手的DSL,是团队框架选型的基本点。

    首先微信原生的开发语法,既像React ,又像Vue,有点不伦不类,对于开发者来说,等于又要学习一套新的语法,大幅提升了学习成本,这一直被大家所诟病。

    其它开发框架基本都遵循React、Vue(类Vue)语法,其主要目的:复用工程师的现有技术栈,降低学习成本。此时,框架对于原框架(React/Vue)语法的支持度就是一个重要的衡量标准,如果支持度较低、和原框架语法差异较大,则开发者无异于要学习一门新的框架,成本太高。

    实际开发中发现,各个开发框架,都没有完全实现VueReact在web上的所有语法:

    wepy开发风格接近于 Vue.js,属于类Vue实现,相对微信原生开发算前进了一大步,但相比完整Vue语法还有较大差距,开发时需要单独学习它的规则;

    mpvueuni-app 框架基于 Vue.js 核心,通过修改 Vue.jsruntimecompiler,实现了在小程序端的运行。mpvue支持的Vue语法略少,uni-app 则基本支持绝大多数vue语法,如filter、复杂 JavaScript 表达式等;

    taro 对于 JSX 的语法支持度,也达到了绝大多数都支持的完善程度。

    DSL语法支持评测:taro,uni-app > mpvue > wepy > 微信原生

    2.1.2 学习资料完善度

    官方文档、问题搜索、示例demo的完备度方面:

    • 微信原生:文档丰富,API搜索准确,官方有示例demo,支持官网上调起微信开发者工具,预览运行效果 详见
    • wepy:文档只有2页,没有搜索,组件API等文档都直接看微信的文档。没有提供示例demo,很多配置需要靠猜。详见
    • mpvue:文档较少,但其概念不复杂,组件API等文档都直接看微信的文档,学习难度低。问题搜索效果一般。没有提供示例demo。详见
    • taro:基础文档完整,具体使用问题资源较少,问题搜索效果一般,示例demo只包含基础功能,仅发布了微信一端。详见
    • uni-app:基础文档和各种使用专题内容丰富,问题搜索效果较好,示例demo功能完备,并发布为7端上线。详见

    教学课程方面:

    学习资料完善度评测:微信原生 > uni-app > mpvue , taro > wepy

    2.2 现代前端开发体验

    开发体验层面,处于明显劣势的是微信原生开发,主要差距在于:

    • 框架开发提供了精简的代码组织(微信原生开发,一个Page由4个文件构成,写个代码要开的标签卡太多)
    • 框架开发提供了更强大的组件化能力
    • 框架开发提供了应用状态管理(类Vuex/Redux/Mobx等)
    • 框架开发能灵活支持各种 Sass 等 预处理器
    • 框架开发可提供完整的 ES Next 语法支持
    • 框架开发方便自定义构建策略

    其它小程序开发框架均支持cli模式,可以在主流前端工具中开发,且基本都带有d.ts的语法提示库。

    由于mpvueuni-apptaro直接支持vuereact语法,配套的ide工具链较丰富,着色、校验、格式化完善;wepy要弱一些,有部分三方维护的vscode插件。

    好的开发工具,绝对可以大幅提升开发体验,这个维度上,明显高出一截的框架是uni-app,其出品公司同时也是HBuilder的出品公司,DCloud.io。HBuilder是四大主流前端开发工具(可对比百度指数),其为uni-app做了很多优化,故uni-app的开发效率、易用性非其他框架可及。

    开发体验维度,对比结果:uni-app > taro,mpvue > wepy > 微信原生

    这里可以输出一个结论:如果你需要工程化能力,那就直接忘了微信原生开发吧。

    2.3 高效的社区支持

    学习、开发难免遇到问题,官方技术支持和社区活跃度很重要。

    本次评测demo开发期间,我们的同学(同时掌握vue和react),在学习研究各个多端框架时,切实感受到由于语法、学习资料、社区的差异带来的学习门槛,吐出了很多槽。

    综合评估,本项评测结论:微信原生 , uni-app > taro > mpvue > wepy

    2.4 活跃的开发迭代

    开发者必须关心一个问题:该项目是否有人长期维护?

    这个问题可以通过github commits 频次、产品更新日志(changelog)、百度搜索指数等指标来衡量和对比。

    github commits 频次

    我们采集2019年4月份(时间为4.1 ~ 4.30),每个项目在github上的master分支有commit的天数,结果如下:

    Tips:

    • 微信原生是闭源的,看不到 commits 数量,但保持每月至少一次的更新节奏,详见
    • wepy的master分支无commit,最新的2.0.x分支在4月份也仅1天有commit记录

    从 commit 的记录来看,tarouni-app处于更新比较活跃的状态,wepympvue则相对疲软,呈现无人维护之态。

    产品更新日志

    通过浏览产品更新日志,可确认产品是否在积极迭代、增加新功能、修复用户bug。

    我们分别查看各框架官方链接的更新日志(CHANGELOG),下方是链接地址:

    通过产品更新日志对比,微信原生、tarouni-app 三者更新频繁,bug修复、新功能补充都处于比较紧凑的状态;而mpvuewepy则已有长时间没有版本发布,wepy甚至有将近1年时间未发布正式版本,开发者选型需谨慎。

    2.5 多端复用

    随着微信小程序的火爆,支付宝、百度、字节跳动等公司也先后进入小程序领域,这些公司个个日活过亿,坐拥海量用户,企业主希望将自己的业务触达每个用户,不管这个用户在哪个小程序中。

    需求转接到程序员这里,程序员怎么办?难道真的每个平台到处搬砖吗?此时,一套代码、多端发布就成为很多程序员的梦想,小程序跨端框架应运而生。

    现实真能如此理想吗?每个跨端框架能否真的像官网宣传的那样,实现开发一次,发布到所有小程序平台?甚至和H5平台复用代码?

    我们用事实说话,依然使用上述仿微博App,依次发布到各平台,验证每个框架在各端的兼容性,结果如下:

    测试结果说明:

    • ⭕ 表示支持且功能正常,❌ 表示不支持,其它则表示支持但存在部分bug或兼容问题

    通过这个简单的例子可以看出,跨端支持度测评结论: uni-app,taro > mpvue> 原生微信小程序wepy

    但是仅有上面的测试还不全面,实际业务要比这个测试例复杂很多。但我们没法开发很多复杂业务做评测,所以还需要再对照各家文档补充一些信息。 由于每个框架的文档中都描述了各种组件和API的跨端支持程度。我们过了几家的文档,发现各家基本是以微信小程序为基线,然后把各种组件和API在其他端实现了一遍:

    • taro:H5端实现了大部分微信的API
    • uni-app:组件、API、配置,大部分在各个端均已实现,个别API有说明在某些端不支持。可以看出uni-app是完整在H5端实现了一套微信模拟器

    跨端框架,一方面要考虑框架提供的通用api跨端支持,同时还要考虑不同端的特色差异如何兼容。毕竟每个端都会有自己的特色,不可能完全一致。

    • taro:提供了js环境变量判断和统一接口的多端文件,可以在组件、js、文件方面扩展多端,不支持其他环节的分平台处理。
    • uni-app:提供了条件编译模型,所有代码包括组件、js、css、配置json、文件、目录,均支持条件编译,可不受限的编写各端差异代码。

    跨端框架,还涉及一个ui框架的跨端问题,评测结果如下:

    • taro:官方提供了taro ui,只支持微信小程序和H5两端,不支持App,详见
    • uni-app:官方提供了uni ui,可全端运行;uni-app还有一个插件市场,里面有很多三方ui组件,详见

    最后补充跨端案例:

    • mpvue:微信端案例丰富,未见其它端案例
    • taro:微信端案例丰富,百度、支付宝、H5端亦有少量案例
    • uni-app:多端案例丰富,官方示例已发布到7端(包括App端)

    综合以上信息,本项的最终评测结论:uni-app > taro > mpvue > 原生微信小程序wepy

    这里可以输出一个结论,如果有多端发布需求,微信原生开发、wepy这两种方式可以直接排除了。

    结语

    真实客观的永远是实验和数据,而不是结论。不同需求的开发者,可以根据上述实验数据,自行得出自己的选型结论。

    但作为一篇完整的评测,我们也必须提供一份总结,虽然它可能加入了我们的主观感受:

    如果你只开发微信小程序,不做多端,那么使用uni-apptaro是更优的选择,他们相当于web世界的vue和react,有了这些工具,不再需要使用原生wxml开发。

    • 如果坚持微信原生开发,需要注意手动写优化代码来控制setdata,并且注意其工程化能力非常弱
    • 如果你是react系,那就用taro
    • 如果是vue系,那就用uni-appuni-app在性能、周边生态和开发效率上更有优势

    如果你开发多端,uni-apptaro都可以,可根据自己熟悉的技术栈选择,相对而言uni-app的多端成熟度更高一些。

    如有读者认为本文中任何评测失真,欢迎在这里报 issuse

    展开全文
  • 自2017-1-9微信小程序诞生以来,历经2年多的迭代升级,已有数百万小程序上线,成为继Web、iOS、Android之后,第四大主流开发技术。... 原生开发对Node、预编译器、webpack支持不好,影响开发效率工程...

    自 2017-1-9微信小程序诞生以来,历经2年多的迭代升级,已有数百万小程序上线,成为继Web、iOS、Android之后,第四大主流开发技术。

    与之相随,小程序的开发生态也在蓬勃发展,从最初的微信原生开发,到wepympvuetarouni-app等框架依次出现,从刀耕火种演进为现代化开发,生态越来越丰富。

    选择多了,问题也就来了,开发小程序,该用原生还是选择三方框架?

    首先,微信原生开发的槽点大多集中如下:

    • 原生开发对Node、预编译器、webpack支持不好,影响开发效率和工程构建流程

    • 微信定义了一个不伦不类的语法,不如正经学vue、react,学会了全端通用,而不是只为微信小程序

    • vue/react生态里有太多周边工具,可以提高开发效率,比如ide、校验器、三方库。。。

    • 微信那个ide和专业编辑器相比实在不好用

    同时,开发者对三方框架,又总是有各种顾虑:

    1. 怕性能不如原生

    2. 怕有些功能框架实现不了,只能用原生

    3. 怕框架不稳定,跳到坑里

    4. 以及诸多三方框架,到底该用哪个

    面对如此纠结的场景,不少热心开发者发布评测文章分享经验,但感觉众说纷纭,过期信息太多。缺少一份非常专业的、深度的,或者按如今流行的话来讲,“硬核的”评测报告。

    做评测报告这件事,不同于泛泛经验分享,其实非常花费时间。它需要:

    • 你必须成为每一个框架的专业使用人员,而不是浅浅的了解一下这些框架

    • 真实的动手写多个平台的测试例,比较各个平台的功能、性能,了解他们的社区情况、技术服务情况

    • 你要有长期跟踪和更新报告的能力,避免半年后沦为过期信息

    换言之:评测要想真,功夫得做深!

    本文从面向用户、面向开发者两大维度七大细项,对微信原生及主流的wepympvuetarouni-app开发框架进行横向对比,希望给开发者在小程序框架选型时提供一种参考思路。

    本文基于各框架官网可采集到的公开数据及真实测试数据,希望客观公正地评价各个框架的现状和优劣。但宥于利益相关,本文的观点很可能是带有偏向性的,大家可以带着批判的眼光来看待,如发现本文中有任何评测失真,欢迎在这里报 issuse。

    面向用户、面向开发者维度,具体包括:

    1. 用户:提供完整的业务实现,并保证高性能体验

    2. 开发者:平缓的学习曲线、现代开发体验(工程化)、高效的社区支持、活跃的开发迭代、多端复用。

     

    一、用户

     

    1.1 功能实现

    软件开发,首要目标是向用户提供完整、闭环的业务功能。

    在web开发中,如果vue、react等框架的使用,造成开发者无法操作浏览器提供的所有api,那这样的框架肯定是不成熟的。小程序开发也一样,任何开发框架,都不能限制底层的api调用。

    而各种业务功能底层依赖微信暴漏的组件和接口(微信官网介绍的组件和 API 规范,也即微信原生API),三方框架是基于微信原生进行的二次封装,开发者此时常会有个疑问:小程序在不断的迭代升级,如果某项业务依赖于最新的小程序API,但三方框架尚未封装,该怎么办?

    实际上就像web开发的vue、react一样,浏览器出了一个新API,并不会涉及vue、react的升级。本评测里的所有框架,都不会限制开发者调用底层能力。这里详细解释下原因:

    • wepy:未对小程序API作二次封装,API依然使用微信原生的,框架与微信小程序是否新增API无关

    • mpvue:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似mpvue.request()

    • taro:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似Taro.request(),支持Taro 代码与小程序代码混写,可通过混写的方式调用框架尚未封装的小程序新增API

    • uni-app:支持微信的所有原生组件和api,无限制。在跨端方面,即便仍然使用微信原生的组件和API,也可以直接跨端编译到App、H5、以及支付宝百度头条等小程序。但为了管理清晰,推荐使用uni封装的API,类似uni.request()。同时支持条件编译,可在条件编译代码块中,随意调用各个平台新增的API及组件

    注:以上顺序,按各个框架的诞生顺序排序,下同。

    故,三方框架均可调用所有小程序API,完成用户的业务需求,这个维度各框架是无差别的。

    然而有差别的,是性能体验。

     

    1.2 性能体验

    三方框架,内部大多做了层层封装,这些封装是否会增加运行负载,导致性能下降?尤其是与原生微信小程序开发相比性能怎么样,这是大家普遍关心的问题。

    为客观的进行对比,我们特意搭建了一个测试模型,详细如下:

    • 开发内容:开发一个仿微博小程序首页的复杂长列表,支持下拉刷新、上拉翻页、点赞。

    • 界面如下:

       

    • 开发版本:一共开发了5个版本,包括微信原生版、wepy版、mpvue版、taro版、uni-app版,按照官网指引通过cli方式默认安装。

    • 测试代码开源, Tips:若有同学觉得测试代码写法欠妥,欢迎提交 PR 或 Issus

    • 测试机型:红米 Redmi 6 Pro、MIUI 10.2.2.0 稳定版(最新版)、微信版本 7.0.3(最新版)

    • 测试环境:每个框架开始测试前,杀掉各App进程、清空内存,保证测试机环境基本一致;每次从本地读取静态数据,屏蔽网络差异。

    我们以上述仿微博小程序为例,测试2个容易出性能问题的点:长列表加载、大量点赞组件的响应。

     

    1.2.1 长列表加载

    仿微博的列表是一个包含很多组件的列表,这种复杂列表对性能的压力更大,很适合做性能测试。

    从触发上拉加载到数据更新、页面渲染完成,需要准确计时。人眼视觉计时肯定不行,我们采用程序埋点的方式,制定了如下计时时机:

    • 计时开始时机:交互事件触发,框架赋值之前,如:上拉加载(onReachBottom)函数开头

    • 计时结束时机:页面渲染完毕(微信setData回调函数开头)

    Tips:setData回调函数开头可认为是页面渲染完成的时间,是因为微信setData定义如下(微信规范):

    测试方式:从页面空列表开始,通过程序自动触发上拉加载,每次新增20条列表,记录单次耗时;固定间隔连续触发 N 次上拉加载,使得页面达到 20*N 条列表,计算这 N 次触发上拉到渲染完成的平均耗时。

    测试结果如下:

     

    说明:以400条微博列表为例,从页面空列表开始,每隔1秒触发一次上拉加载(新增20条微博),记录单次耗时,触发20次后停止(页面达到400条微博),计算这20次的平均耗时,结果微信原生在这20次 触发上拉 -> 渲染完成 的平均耗时为876毫秒,最快的uni-app是741毫秒,最慢的mpvue是4493毫秒

    大家初看这个数据,可能比较疑惑,别急,下方有详细说明

    说明1:为何 mpvue/wepy 测试数据不完整?

    mpvuewepy 诞生之初,微信小程序尚不支持自定义组件,无法进行组件化开发;mpvuewepy 为解决这个问题,将用户编写的Vue组件,编译为WXML中的模板(template),变相实现了组件化开发能力,提高代码复用性,这在当时的技术条件下是很棒的技术方案。

    但如此方案,在页面复杂、组件较多的时,会大量增加页面 dom 节点数量,甚至超出微信的 dom 节点数限制。我们在 红米手机(Redmi 6 Pro)上实测,页面组件超过500个时,mpvuewepy  实现的仿微博App就会报出如下异常,并停止渲染,故这两个测试框架在组件较多时,测试数据不完整。这也就意味着,当页面组件太多时,无法使用这2个框架。

    dom limit exceeded please check if there's any mistake you've made

    Tips1:wepy官网的CHANGELOG,提到 v1.7.2 测试版本添加了对小程序原生组件的支持,实测坑很多,因为是测试版,官方在 issue 中也表示不推荐使用;按照官网文档,默认安装的 v1.7.3 正式版本并不支持原生组件

    Tips2:wepy在400条列表以内,为何性能高于微信原生框架,这个跟自定义组件管理开销及业务场景有关(wepy编译为模板,不涉及组件创建及管理开销),后续对微博点赞,涉及组件数据传递时,微信原生框架的性能优势就提现出来了,详见下方测试数据。

    说明2:为什么测试数据显示uni-app 会比微信原生框架的性能略好呢?

    其实,在页面上有200条记录(200个组件)时,taro 性能数据也比微信原生框架更好。

    微信原生框架耗时主要在setData调用上,开发者若不单独优化,则每次都会传递大量数据;而 uni-apptaro 都在调用setData之前自动做diff计算,每次仅传递变动的数据。

    例如当前页面有20条数据,触发上拉加载时,会新加载20条数据,此时原生框架通过如下代码测试时,setData会传输40条数据

    
     

    开发者使用微信原生框架,完全可以自己优化,精简传递数据,比如修改如下:

    经过如上优化修改后,再次测试,微信原生框架性能数据如下:

     

    从测试结果可看出,经过开发者手动优化,微信原生框架可达到更好的性能,但 uni-apptaro 相比微信原生,性能差距并不大。

    这个结果,和web开发类似,web开发也有原生js开发、vue、react框架等情况。如果不做特殊优化,原生js写的网页,性能经常还不如vue、react框架的性能。

    也恰恰是因为Vuereact框架的优秀,性能好,开发体验好,所以原生js开发已经逐渐减少使用了。

    复杂长列表加载下一页评测结论:微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > wepy > mpvue

    Tips:有人以为uni-app和mpvue是一样的,早期uni-app确实使用过mpvue,但后来因为性能和vue语法支持度问题已经重新开发了。

     

    1.2.2 点赞组件响应速度

    长列表中的某个组件,比如点赞组件,点击时是否能及时的修改未赞和已赞状态?是这项测试的评测点。

    测试方式:

    • 选中某微博,点击“点赞”按钮,实现点赞状态状态切换(已赞高亮、未赞灰色),

    • 点赞按钮 onclick函数开头开始计时,setData回调函数开头结束计时;

    在红米手机(Redmi 6 Pro)上进行多次测试,求其平均值,结果如下:

     

     

    说明:也就是在列表数量为400时,微信原生开发的应用,点赞按钮从点击到状态变化需要111毫秒。

    测试结果数据说明:

    • wepy/mpvue 测试数据不完整的原因同上,在组件较多时,页面已经不再渲染了

    • 基于微信自定义组件实现组件开发的框架(uni-app/taro),组件数据通讯性能接近于微信原生框架,远高于基于template实现组件开发的框架(wepy/mpvue)性能

    组件数据更新性能测评:微信原生开发,uni-app,taro > wepy > mpvue

    综上,本性能测试做了2个测试,长列表加载和组件状态更新,综合2个实验,结论如下:

    微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > wepy > mpvue

     

    二、开发者

    在满足用户业务需求的前提下,我们谈谈开发者的需求,从如下几个维度比较:

    • 平缓的学习曲线:简单易学,最好能复用现有技术栈,丰富的学习资料

    • 高效的开发体验:现代前端开发流程、工程化支持

    • 高效的社区支持:遇到问题,可很快的寻求到帮助

    • 活跃的开发迭代:框架处于积极更新升级状态,无需担心停更

     

    2.1 平缓的学习曲线

    2.1.1 DSL语法支持

    选择开发团队熟悉的、能快速上手的DSL,是团队框架选型的基本点。

    首先微信原生的开发语法,既像React ,又像Vue,有点不伦不类,对于开发者来说,等于又要学习一套新的语法,大幅提升了学习成本,这一直被大家所诟病。

    其它开发框架基本都遵循React、Vue(类Vue)语法,其主要目的:复用工程师的现有技术栈,降低学习成本。此时,框架对于原框架(React/Vue)语法的支持度就是一个重要的衡量标准,如果支持度较低、和原框架语法差异较大,则开发者无异于要学习一门新的框架,成本太高。

    实际开发中发现,各个开发框架,都没有完全实现VueReact在web上的所有语法:

    • wepy开发风格接近于 Vue.js,属于类Vue实现,相对微信原生开发算前进了一大步,但相比完整Vue语法还有较大差距,开发时需要单独学习它的规则;

    • mpvueuni-app 框架基于 Vue.js 核心,通过修改 Vue.js 的 runtime 和 compiler,实现了在小程序端的运行。mpvue支持的Vue语法略少,uni-app 则基本支持绝大多数vue语法,如filter、复杂 JavaScript 表达式等;

    • taro 对于 JSX 的语法支持度,也达到了绝大多数都支持的完善程度。

    DSL语法支持评测:taro,uni-app > mpvue > wepy > 微信原生

     

    2.1.2 学习资料完善度

    官方文档、问题搜索、示例demo的完备度方面:

    • 微信原生:文档丰富,API搜索准确,官方有示例demo,支持官网上调起微信开发者工具。

    • wepy:文档只有2页,没有搜索,组件API等文档都直接看微信的文档。没有提供示例demo,很多配置需要靠猜。

    • mpvue:文档较少,但其概念不复杂,组件API等文档都直接看微信的文档,学习难度低。问题搜索效果一般。没有提供示例demo。

    • taro:基础文档完整,具体使用问题资源较少,问题搜索效果一般,示例demo只包含基础功能,仅发布了微信一端。

    • uni-app:基础文档和各种使用专题内容丰富,问题搜索效果较好,示例demo功能完备,并发布为7端上线。

    教学课程方面:

     

    学习资料完善度评测:微信原生 > uni-app > mpvue , taro > wepy

    2.2 现代前端开发体验

    开发体验层面,处于明显劣势的是微信原生开发,主要差距在于:

    • 框架开发提供了精简的代码组织(微信原生开发,一个Page由4个文件构成,写个代码要开的标签卡太多)

    • 框架开发提供了更强大的组件化能力

    • 框架开发提供了应用状态管理(类Vuex/Redux/Mobx等)

    • 框架开发能灵活支持各种 Sass 等 预处理器

    • 框架开发可提供完整的 ES Next 语法支持

    • 框架开发方便自定义构建策略

    其它小程序开发框架均支持cli模式,可以在主流前端工具中开发,且基本都带有d.ts的语法提示库。

    由于mpvueuni-apptaro直接支持vuereact语法,配套的ide工具链较丰富,着色、校验、格式化完善;wepy要弱一些,有部分三方维护的vscode插件。

    好的开发工具,绝对可以大幅提升开发体验,这个维度上,明显高出一截的框架是uni-app,其出品公司同时也是HBuilder的出品公司,DCloud.io。HBuilder是四大主流前端开发工具(可对比百度指数),其为uni-app做了很多优化,故uni-app的开发效率、易用性非其他框架可及。

    开发体验维度,对比结果:uni-app > taro,mpvue > wepy > 微信原生

    这里可以输出一个结论:如果你需要工程化能力,那就直接忘了微信原生开发吧。

     

    2.3 高效的社区支持

    学习、开发难免遇到问题,官方技术支持和社区活跃度很重要。

     

    本次评测demo开发期间,我们的同学(同时掌握vue和react),在学习研究各个多端框架时,切实感受到由于语法、学习资料、社区的差异带来的学习门槛,吐出了很多槽。

    综合评估,本项评测结论:微信原生 , uni-app > taro > mpvue > wepy

     

    2.4 活跃的开发迭代

    开发者必须关心一个问题:该项目是否有人长期维护?

    这个问题可以通过github commits 频次、产品更新日志(changelog)、百度搜索指数等指标来衡量和对比。

    github commits 频次

    我们采集2019年4月份(时间为4.1 ~ 4.30),每个项目在github上的master分支有commit的天数,结果如下:

    Tips:

    • 微信原生是闭源的,看不到 commits 数量,但保持每月至少一次的更新节奏。

    • wepy的master分支无commit,最新的2.0.x分支在4月份也仅1天有commit记录

    从 commit 的记录来看,tarouni-app处于更新比较活跃的状态,wepympvue则相对疲软,呈现无人维护之态。

    产品更新日志

    通过浏览产品更新日志,可确认产品是否在积极迭代、增加新功能、修复用户bug。

    我们分别查看各框架官方链接的更新日志(CHANGELOG),下方是链接地址:

    • 微信基础库更新日志

    • wepy官网 CHAGELOG

    • mpvue官网 Chang log

    • taro github 更新日志

    • uni-app官网更新日志

    通过产品更新日志对比,微信原生、tarouni-app 三者更新频繁,bug修复、新功能补充都处于比较紧凑的状态;而mpvuewepy则已有长时间没有版本发布,wepy甚至有将近1年时间未发布正式版本,开发者选型需谨慎。

     

    2.5 多端复用

    随着微信小程序的火爆,支付宝、百度、字节跳动等公司也先后进入小程序领域,这些公司个个日活过亿,坐拥海量用户,企业主希望将自己的业务触达每个用户,不管这个用户在哪个小程序中。

    需求转接到程序员这里,程序员怎么办?难道真的每个平台到处搬砖吗?此时,一套代码、多端发布就成为很多程序员的梦想,小程序跨端框架应运而生。

    现实真能如此理想吗?每个跨端框架能否真的像官网宣传的那样,实现开发一次,发布到所有小程序平台?甚至和H5平台复用代码?

    我们用事实说话,依然使用上述仿微博App,依次发布到各平台,验证每个框架在各端的兼容性,结果如下:

     

    测试结果说明:

    • ⭕ 表示支持且功能正常,❌ 表示不支持,其它则表示支持但存在部分bug或兼容问题

    通过这个简单的例子可以看出,跨端支持度测评结论:uni-app,taro > mpvue原生微信小程序wepy

    但是仅有上面的测试还不全面,实际业务要比这个测试例复杂很多。但我们没法开发很多复杂业务做评测,所以还需要再对照各家文档补充一些信息。由于每个框架的文档中都描述了各种组件和API的跨端支持程度。我们过了几家的文档,发现各家基本是以微信小程序为基线,然后把各种组件和API在其他端实现了一遍:

    • taro:H5端实现了大部分微信的API

    • uni-app:组件、API、配置,大部分在各个端均已实现,个别API有说明在某些端不支持。可以看出uni-app是完整在H5端实现了一套微信模拟器

    跨端框架,一方面要考虑框架提供的通用api跨端支持,同时还要考虑不同端的特色差异如何兼容。毕竟每个端都会有自己的特色,不可能完全一致。

    • taro:提供了js环境变量判断和统一接口的多端文件,可以在组件、js、文件方面扩展多端,不支持其他环节的分平台处理。

    • uni-app:提供了条件编译模型,所有代码包括组件、js、css、配置json、文件、目录,均支持条件编译,可不受限的编写各端差异代码。

    跨端框架,还涉及一个ui框架的跨端问题,评测结果如下:

    • taro:官方提供了taro ui,只支持微信小程序和H5两端,不支持App。

    • uni-app:官方提供了uni ui,可全端运行;uni-app还有一个插件市场,里面有很多三方ui组件。

    最后补充跨端案例:

    • mpvue:微信端案例丰富,未见其它端案例

    • taro:微信端案例丰富,百度、支付宝、H5端亦有少量案例

    • uni-app:多端案例丰富,官方示例已发布到7端(包括App端)

    综合以上信息,本项的最终评测结论:uni-app > taro > mpvue > 原生微信小程序wepy

    这里可以输出一个结论,如果有多端发布需求,微信原生开发、wepy这两种方式可以直接排除了。

     

    三、结语

    真实客观的永远是实验和数据,而不是结论。不同需求的开发者,可以根据上述实验数据,自行得出自己的选型结论。

    但作为一篇完整的评测,我们也必须提供一份总结,虽然它可能加入了我们的主观感受:

    1、如果你只开发微信小程序,不做多端,那么使用uni-apptaro是更优的选择,他们相当于web世界的vue和react,有了这些工具,不再需要使用原生wxml开发。

    • 如果坚持微信原生开发,需要注意手动写优化代码来控制setdata,并且注意其工程化能力非常弱

    • 如果你是react系,那就用taro

    • 如果是vue系,那就用uni-appuni-app在性能、周边生态和开发效率上更有优势

    2、如果你开发多端,uni-apptaro都可以,可根据自己熟悉的技术栈选择,相对而言uni-app的多端成熟度更高一些。

    展开全文
  • 微信小程序开发作为备受关注的移动社交应用,微信的一举一动都牵动着众多开发者、内容生产者网民的神经。从去年11月正式公测到现在,微信小程序的上线时间一直备受外界关注。 今天1月9日微信负责人张小龙在微信...
  • 微信小程序 VS 原生App

    万次阅读 2017-06-14 11:13:37
    1.什么是小程序 先来看看微信之父张小龙先生的说法:小程序是一种不需要下载安装即可使用的应用,它实现了应用“触手可及”的梦想,用户扫一扫或者搜一下即可打开应用。...2.小程序与原生App哪个好?
  • 微信小程序原生开发 wepy 、 mpvue 对比 参考资料1 参考资料2 三者的开发文档以及介绍 原生开发小程序文档:点此进入 wepy开发文档:点此进入 github地址 mpvue开发文档:点此进入 github地址 三者简单的...
  • 小程序框架的目标是通过尽可能简单、高效的方式让开发者可以在微信开发具有原生APP体验的服务。 小程序框架提供了自己的视图层描述语言 wxnLwxss,以及javascript,并在视图层与逻辑层间提供了数据传输事件...
  • 以往都是用友盟或者mobShareSDK框架来实现的,这两者在微信官方的sdk基础上封装的很好,并且加入了一些很实用性的功能,不过这次因为只有微信平台的分享,而且微信登录也是基于微信官方的原生SDK的,所以我们就不用...
  • 原生开发小程序文档:点此进入 wepy 开发文档:点此进入 mpVue 开发文档:点此进入 三者的简单对比 小程序缺点 个人认为小程序开发中,最大的缺点,也是很蛋疼的问题 不支持vue的过滤器filters(因此数据都得...
  • 1.pages文件同级的文件components文件夹下创建一个想要的组件popup,popup组件有popup.html, popup.css, popup.json, popup.js 四个文件 2.组件中写入传入的参数,在properies中声明传入参数类型 3.父组件给子组件...
  • 微信分享的原生集成

    2016-11-27 09:47:27
    现在的APP大都会包含分享部分,分享的集成平台也很多,如SharedSDK,友盟等等,但是这些分享都是统一实现差异化分享,进行多方的差异化配置进而实现相关的分享,但是我们开发时候有时候只需要进行最常用的微信分享就...
  • 微信开发五之微信红包开发

    千次阅读 2018-01-18 10:20:24
    本次文章将详细介绍微信支付中微信原生红包的开发思路,并提供源代码。以供各位同好交流。开发效果如图1所示,微信公众号9五后不害羞(love_thyc)发放红包效果。微信红包分为:普通红包、裂变红包。本次介绍普通...
  • 如果直接使用微信小程序的原生标签去写样式的话,会对全局的标签样式进行修改,如下: 就是不管你在哪修改了一个标签的样式,全局的都变了。 来看一下目前支持的选择器: 微信小程序官方文档:...
  • 目前小程序开发主要有三种形式:原生、wepy、mpvue,其中wepy是腾讯的开源项目;mpvue是美团开源的一个开发小程序的框架,全称mini program vue(基于vue.js的小程序),vue开发者使用了这个框架后,开发小程序的效率...
  • 微信支付,扫码后提示[原生支付URL参数错误],我的格式为weixin://wxpay/bizpayurl?appid=****&mch_id=****&nonce_str=766EBCD59621E305170616BA3D3DAC32&product_id=201503241009011261&time_stamp=1427162942&sign...
  • 微信开发之ngrok环境搭建

    千次阅读 2016-12-08 16:47:43
     各位肯定都知道,做微信开发,我们的开发服务器需要微信服务器做交互,我们需要准备一台放置在公网的服务器,能够使得我们的服务器可以正常访问微信服务器,并且微信服务器也需要可以正常访问我们的开发服务器。...
  • 微信小程序(原生) 雷达图
  • Lin UI 是基于 微信小程序原生语法 实现的组件库。遵循简洁,易用的设计规范。
  • 微信开发UI,一套原生,一套商城源码!可以实现微信及相关H5移动应用快速开发构建!微信开发UI,一套原生,一套商城源码!可以实现微信及相关H5移动应用快速开发构建!
1 2 3 4 5 ... 20
收藏数 34,155
精华内容 13,662
关键字:

微信开发和原生开发