跨端开发框架深度横评之2020版

又是一年四月天,距离上次发布跨端开发框架深度横评已过去整整一年。

这一年,小程序在用户规模及商业化方面都取得了极大的成功。微信小程序日活超过3亿,支付宝、百度、字节跳动小程序的月活也纷纷超过3亿。

对应小程序开发领域,这一年也发生了巨大变化。开发框架从单纯的微信小程序开发,过渡到多端框架成为标配,进一步提升开发效率成为开发者的强烈需求。

这一年 mpvue 停止更新,Taro开始探索 taro nextuni-app 产品和生态持续完善,微信新推出了支持H5和微信小程序的 kbone 框架…

去年的深度横评中很多老将已经退出江湖,一些新秀吸引眼球,因此,是时候来一波2020版的新横评了。

评测目标筛选

跨端框架是一个重投入工作,在各框架的1年多的比拼中,很多框架因为投入不足而逐渐被开发者放弃,uni-apptaro依靠持续的大力度投入,成为了市场主流。

taro 在稳定版的基础之上,最近也推出了 taro next,这2个版本差异较大,本次会分别评测。

kbone 框架虽面世不久,但毕竟是微信官方发布,关注的人不少,故本次将 kbone 加入评测目标。

所以,本次评测的对象(按发布时间排序):

本次评测除了运行性能等实测数据外,尽可能得通过框架官网及github、掘金、腾讯课堂等三方社区公开采集数据,希望给大家一个综合全面的评估依据。

功能实现

tarouni-app 是比较典型的多端框架,发布到各个端均可。而 kbone 只支持微信小程序和H5。

tarouni-app 均将常用接口及组件封装了成了跨端API和跨端组件,组件规范沿用微信小程序的规范,部分平台特有API,这两个框架亦有应对方案:

  • taro:支持与小程序代码混写,可通过混写的方式调用框架尚未封装的小程序新增API
  • uni-app:支持条件编译,可在条件编译代码块中,随意调用各个平台新增的API及组件

tarouni-app 可以不受限的调用各家小程序平台所有的API及组件。

kbone 沿用web的开发习惯,使用html标签及js api;涉及微信特有api时,可通过process.env.isMiniprogram判断环境,然后编写微信原生代码。对于html中没有标签可替代的微信内置组件(如swiper),需要使用 wx-component 标签或者使用 wx- 前缀,这样的内置组件会被包裹一层自定义组件,带来相应的性能开销。

除了接口、组件之外,我们以微信小程序为例,找几个典型能力对比框架支持度:

框架 taro uni-app kbone
微信自定义组件 ⭕️ ⭕️ ⭕️
三方插件 ⭕️ ⭕️
分包加载 ⭕️ ⭕️ ⭕️
sitemap ⭕️ ⭕️ ⭕️
wxs ⭕️
云开发 ⭕️ ⭕️ ⭕️

补充说明:

  • 如果在 Taro 项目引用了小程序原生的第三方组件,那么该项目将不再具备多端转换的能力,例如,如果使用了微信小程序的第三方组件,那么项目只能转换成微信小程序,转义成其他平台会失效,详见taro官网
  • uni-app 中使用微信自定义组件的话,支持编译发行到App/H5/微信小程序/QQ小程序4个平台,详见uni-app官网
  • taro 不支持 wxs 的依据:#2959
  • kbone 不支持微信三方插件的依据:#58;不支持wxs的依据:#129
  • 云开发在微信平台,三个框架都支持,但 taro/kbone仅支持微信小程序平台,uni-app支持App/H5/小程序所有平台使用云开发,详见下方 serverless/云开发 章节。

wxs是提升性能体验的重要利器,除了微信小程序的wxs外,还有支付宝的SJS、百度的Filter,这些高级技术 uni-app 均完善支持。参考:谜之wxs,uni-app如何用它大幅提升性能

从如上功能对比来看:微信原生 ~ uni-app > taro > kbone

运行性能(微信小程序)

我们继续沿用去年的测试模型,看看一年来,各家小程序开发框架的性能是否有提升。详细如下:

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

  • 界面如下:

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

  • taro 目前稳定版本是2.0版,但近期在宣传跨框架的taro next,故我们基于同样的 react代码,同时测试了taro 2.0 和 taro next 两个版本的数据。

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

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

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

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

长列表加载

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

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

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

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

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

测试结果如下:

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

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

说明1:为何 taro next/kbone 测试数据不完整?

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

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

另外,kbone官网有如下介绍:

kbone 是使用一定的性能损耗来换取更为全面的 Web 端特性支持。

taro nextkbone的测试数据,明显和taro 2.0uni-app不是一个量级的。

如果你的应用是长列表场景,那taro nextkbone就明显不太合适。

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

这个问题在去年的测评中,已解释过。为了避免新同学迷惑,这里再次说明一下。

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

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

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

开发者使用微信原生框架,完全可以自己优化,精简传递数据(每次仅传递变化的20条数据),比如修改如下:

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

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

从测试结果可看出:

  • 经过开发者手动优化,微信原生框架可达到更好的性能;
  • uni-app相比微信原生,性能接近,算是一个数量级;并且随着数据量增加,性能消耗增加不明显,从438到454,只有16毫秒的变化
  • taro 2.0随着数据量越大,性能损耗随着增大,从595到790,有将近200毫秒的变化;
  • taro nextkbone相比之下,差距就比较大了。

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

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

说明3:为何今年的性能测试数据和去年的不同?

细心的同学会发现,同样的测试手机,同样的测试代码,为何今年的性能数据会比去年的数据有大幅提升?

  • taro、uni-app及微信原生,三个框架的数据都有大幅提升,400条记录时,至少都有300毫秒的优化
  • uni-app及优化后的微信原生,随着数据量的增加,耗时数据变化并不明显,但去年是很明显的线性增长

其实,通过微信原生工程的数据对比,就能得出结论:2019年,微信针对小程序运行时做了大幅性能优化。

这对开发者来说应该是个好消息,小程序性能体验更佳,可承载更好的用户业务。

复杂长列表加载下一页评测结论:微信原生开发(手动优化) ~ uni-app > 微信原生开发(未手动优化) ~ taro 2.0 > taro next > kbone

点赞组件响应速度

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

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

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

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

测试结果数据说明:
– taro next/kbone 测试数据不完整的原因同上,在组件较多时,页面已经不再渲染了
– taro 2.0版本、uni-app和微信原生在点赞组件上的性能体验接近,但taro next和kbone有较大的性能差距,这个也是因为动态运行时框架导致的。

组件数据更新性能测评:uni-app ~ taro 2.0 > taro next > kbone

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

微信原生开发(手动优化) ~ uni-app > 微信原生开发(未手动优化) ~ taro 2.0 > taro next > kbone

运行性能(支付宝小程序)

今年新增基于支付宝小程序的性能测试,我们同样按照如上描述,对长列表加载、点赞组件响应两个场景进行测试。

因 kbone 不支持其他家小程序,故本次仅测试了 taro 2.0 和 uni-app 的性能数据。

场景1:长列表加载

列表条数 taro 2.0 uni-app
200 1954 850
400 3155 1012
600 4284 1119
800 5278 1258
1000 6555 1452

场景2:点赞组件响应

组件数量 taro 2.0 uni-app
200 38 33
400 34 45
600 37 37
800 40 39
1000 51 48

Tips:

  • 基于 taro next 的实现原理,taro next 性能会比 taro 2.0 差不少,这里仅提供 taro 2.0 的数据(上一章节微信小程序的实测数据也已验证了这一推论)
  • 支付宝小程序进行自动化性能测试时,请在项目配置中启用 component2 编译 选项

通过如上测试数据,在支付宝小程序的运行性能,uni-app > taro 2.0

跨端支持

这三个框架都是为了解决平台同构问题,跨端的比较是必需的。

tarouni-app 相对比较成熟,支持主流的所有平台。kbone 只支持微信小程序和 Web 端。我们重点比较一下 tarouni-app

小程序平台

tarouni-app 均支持微信、支付宝、百度、字节跳动小程序,功能基本可以拉齐。

双方都有不少大厂案例,taro有京东、货拉拉、淘票票等公司小程序案例,uni-app有腾讯、华为、vivo、联想、中华英才网等公司小程序案例。

App平台

  • 能力方面

taro与微信小程序引擎拉齐度较低,很多功能需要开发者分别在iOS和Android上做原生开发才能实现。比如App端很常见的三方登录、支付、分享等能力,taro并未封装。

uni-app则在基础引擎层面提供了丰富的能力,还提供了丰富的插件市场,可切实提升开发者的效率。

  • 性能方面

taro在App端使用了react native的渲染引擎,虽然渲染层ui是原生的,但在实时交互和高响应要求的UI操作方面表现一直不佳,js层和视图层的通信损耗让很多开发者深感无力。

uni-app的App引擎同时给开发者提供了原生渲染引擎和小程序引擎的双选方案,并且由于发明了renderjs技术,以及支持wxs、bindingx等技术,解决了js层和视图层的通信损耗问题,在高响应要求的UI操作方面有更好的性能表现。比如这类canvas动画:

  • 开发体验方面

taro的开发者需自行搭建iOS/Android开发环境,比较繁琐,(官方原文地址):

uni-app可以做到让前端开发者不依赖原生工程师独立完成App。其开发的小程序,可以更平滑的变成可商用的App。

使用跨平台开发的核心诉求在于提升效率,如果一个App的开发由前端、iOS、Android等3拨工程师协作完成,其实效率反而非常低。

另外,uni-app还提供了uni小程序sdk,这个工具可以帮助原生App快速搭建自己的小程序平台。这是其他框架所未提供的。

H5平台

taro的H5平台在一年来的进步较多,可用性大幅提升。但相比于uni-app,目前仍然缺失对wxs和小程序组件的支持。

快应用

taro支持快应用的时间比uni-app早。

但快应用发展到2020年有了一些变化,uni-app针对新的形势,提供了2个发行到快应用的方案(当前两个版本都处于社区维护状态):

  • quickapp-vue版:使用 Vue开发快应用。此方案由小米主导,但华为快应用暂不支持。
  • quickapp-light版:基于小程序架构的快应用(Light版),详见https://www.hellohub.cn。此方案由华为主导,但小米快应用暂不支持。

跨端灵活性

跨端开发,离不开条件编译。因为不能用统一来抹杀各个平台的特色。

优良的条件编译能力对各端开发的灵活度至关重要,可以让开发者在共享和个性化之间游刃有余。

tarouni-appkbone 均支持在js代码通过process.env判断平台,然后编写平台特有代码。

taro额外支持统一接口的多端文件编码方式,以及在样式文件中使用ifdef条件编译。

uni-app是全面可条件编译的,目录、文件、配置、组件、js、css,所有一切均可通过ifdef条件编译。

跨端支持小结结论:uni-app > taro > kbone

开发体验

tarouni-appkbone均支持cli模式,可以在主流前端工具中开发,且基本都带有d.ts的语法提示库。三个框架均支持主流的vuereact语法,配套的ide工具链较丰富,着色、校验、格式化完善。

相比微信原生,这三个开发框架的开发体验都更为优秀。

但在开发工具维度上,明显高出一截的框架是uni-app,其出品公司同时也是HBuilderX的出品公司DCloud.io,HBuilderX为uni-app做了很多优化,代码提示、转到定义、easycom、运行调试…故uni-app的开发效率、易用性非其他框架可及。

开发体验维度,对比结果:uni-app > taro,kbone

serverless/云开发

serverless是目前炙手可热的一个概念,被称为下一代的云技术,是真正的”云“。

微信率先将 serverless 技术引入小程序开发领域,即云开发,帮助开发者云端一体的完成业务。随后,支付宝、百度都上线了自己的云开发。根据微信公开的数据,已经有50万开发者在使用微信云开发了。

不过小程序厂家主导的云开发存在一个天然限制,就是和平台绑定过紧,无法和其它平台共享数据。

我们以微信云开发为例,如果你仅开发微信小程序,数据独家存在微信平台,那没问题;但如果你同时还有App或其他家小程序,此时微信小程序的数据存储在微信平台,其它平台的数据存储在开发者自己的服务器上,此时就出现了数据割裂。假设一个用户先使用小程序,个人数据存储在微信平台;有了粘性后升级到App,此时App端无法读取微信平台的数据,则用户就无法查看之前在小程序上的历史数据,甚至在App平台需要重新注册。这种情况对开发者是不利的。

因此,跨端的 serverless 方案才是开发者的最优解。

目前主流框架对云开发的支持情况:

  • Taro:仅支持微信小程序,详见小程序云开发模板
  • uni-app:DCloud 联合阿里云、腾讯云,提供基于 serverless 模式和 js 编程的云开发平台,支持App/H5/小程序所有平台,详见uniCloud
  • kbone:仅支持微信小程序,详见云开发

serverless 维度上,uni-app大幅领先其它框架。

插件市场

一个开发框架能否成功,除了框架自身的高度产品化外,开发者生态的构建也至关重要。

uni-app 于2018年底率先推出插件市场,支持前端组件、js sdk、页面模板、项目模板、原生插件等多种类型,且提供了赞赏、付费购买等手段,刺激轮子作者的创作激情。目前市场上已发布插件接近1500个,众多插件下载量都在万次以上。

Taro 于 2019年5月上线物料市场,目前市场上已发布物料90个;从热门榜单来看,下载量并不大,下载最多的也就数百。

kbone目前还没有插件市场。

框架 插件市场上线时间 插件数量 top 1 插件下载量
taro 2019年5月 90 237
uni-app 2018年12月 1485 50764

Tips:
– 插件数量及下载量数据采集时间为 2020.04.03 16:00

插件市场维度,uni-app独领风骚。

学习资源

除了各大框架官网外,开发者通常还会通过视频教程、社区博客等方式系统学习。

相关学习资源的丰富程度,也能侧面反映一个框架的受欢迎程度,故我们采集了几个三方站点的数据。

视频教程

框架 腾讯课堂 网易云课堂 慕课网
taro 4 1 2
uni-app 24 14 2

Tips:

  • 视频教程数据采集时间为2020.04.26 16:30

开发交流

除了入门的学习资源,开发期的交流也很重要,这个我们主要看官方组织的社区和交流群。

社区论坛

uni-app问答社区,帖子丰富,沉淀较多;目前已沉淀2万多相关帖子,每日更新帖子数百篇,月uv百万。

对于习惯使用 github issue反馈问题的用户,uni-app同样支持,目前累计有1391个issues。

Taro 早期基于github issue进行产品Bug管理,目前累计已有近4898个issue;后于2019年5月上线开发者社区,和物料市场上线时间相同,目前沉淀1300+帖子,每日更新帖子在10个左右,相关数据计算方法如下:

  • 帖子总数:Taro 社区顶部选择板块,计算每个板块下所有主题总数,如下图。
  • 每日更新帖子数:根据帖子列表中的最后回复时间,计算24小时内有回复或评论的主题总数

kbone 在微信开放社区中新增了一个Kbone官方框架的专区,因产品发布较晚,目前只有一百多个帖子。

总结一下社区帖子及issue数据,情况如下(采集时间为 2020.04.03 23:00):

交流群

框架 微信群 QQ群 交流群开发者(预估)
taro 16 8k
uni-app 20 40+ 90k
kbone 1 0.5k

Tips:
– Taro 有16个微信群是根据 Taro 官网上显示Taro 开发交流 15 群 已满推论而出,每个微信群500人,交流群人数: 50016 = 8000人
– uni-app 官网 QQ群有35个,微信群20个,还有十几个专项QQ群,其中有30个QQ群达到2000人,交流群人数: 30 * 2000 + 5
1000 + 20*500 + 5000 = 90000人
– kbone 在 github 的 readme中有一个qq交流群,申请加入时显示500人已满

除了交流群外,DCloud对外公布的uni-app的开发者数量达到百万人,暂未看到tarokbone公布此类数据。

总体而言,开发交流维度比较结果如下:uni-app > taro > kbone

其它指标

github

框架 star 贡献者
taro 24.6k 122
uni-app 19.7k 72
kbone 2.7k 7

在开源社区方面,Taro做的还是非常成功的,它吸引了更多开发者为其贡献代码、文档。

百度指数

通过index.baidu.com,可查看主流框架的搜索指数,它代表了网友的搜索量和相关文章的收录量。目前kbone尚未收录到百度指数中,如下是近期 uni-apptaro的百度指数对比图:

结语

所有的评测都只是提供决策依据,最后的结果还是要依赖开发者的团队技术栈、业务诉求、未来规划等。

不过作为一篇评测文章的结语,我们还是要给出自己的建议:

  • 如果你熟悉React,不懂Vue.js,推荐Taro;
  • 如果你熟悉Vue.js,则推荐 uni-app;
  • 如果你已经有H5代码,只想增加微信小程序平台,并且对性能要求不高,可以考虑kbone;
  • 如果你的业务涉及多端,更推荐 uni-app;
  • 如果你希望通过 serverless 方案快速上线业务,推荐 uni-app。

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

2020了,各家小程序发展的怎么样?

2017年,微信发布小程序,掀起小程序大战。

2018年,阿里、百度、字节跳动、手机厂商等各大巨头纷纷发布自己的小程序。

2019年,QQ也加入战局,各家全面开花。

时至2020年,各家小程序发展的到底怎么样?我们根据数据和访谈,形成了这份报告,希望能给开发者带来指引帮助。

作为开发者,我们关心的问题,说白了就2个:

各家有多大量?
各家流量质量怎么样?
想了解这些情况,需要一个相对权威的数据。DCloud有4百多万开发者,这些开发者把应用发布到微信、阿里、百度、头条、QQ等各种小程序,以及App、H5等平台,多应用去重后,目前有8.4亿月活设备。

这可能是当前体量最大的多平台数据了,基于这些数据,以及开发者调研,DCloud发布了本报告,作为开发者了解各小程序平台发展情况的参考。

一、各家小程序流量到底有多大

小程序还有流量红利吗?微信的红利是不是已经过去了?不少人存有这种疑问。

如果以2018年微信小程序的火爆对比,那么2019年的微信确实没有那么大的红利了。随着用户对群里的小程序由新鲜转向反感,以及微信的严格封杀策略,很多开发者开始抱怨在微信平台裂变不起来了。

当然微信小程序平台自身的流量仍在增长,只是增长主要来自于品牌主,比如自带流量的政府、商户,而不是独立开发商了。

压下葫芦起了瓢,其他小程序平台给开发者提供了更大的爆发机会。

我们来看看各家的流量天花板,也就是小程序宿主应用的月活,微信月活10亿、字节跳动(抖音+今日头条+西瓜+火山)月活10亿、QQ和支付宝月活都是6亿、百度App月活也有4亿。但各家的小程序月活并不是这个顺序,因为: 小程序的月活 = 宿主月使用时长 * 小程序使用频次

各家小程序的宿主和小程序流量数据平台宿主月活小程序月活微信10亿日活3亿,未公布月活支付宝6亿+5亿百度4亿+3亿字节跳动10亿+3亿QQ6亿+未公布

平台宿主月活里,百度最低,只有4亿。这让人一度担心百度小程序能不能起来。从最终结果来看,百度小程序的月活并不低。因为它的“小程序使用频次”高。用户使用百度App的主需求,就是为了查信息。而百度的百科、贴吧、知道等业务已经全部转为了小程序。

其他平台,都有自己的核心功能,小程序属于外延生态。宿主月活虽高,但其中使用小程序的人未必很多。当然支付宝有个例外,很多人打开支付宝,就是为了用蚂蚁森林小程序,而不是为了用支付宝支付,出现了神奇的反客为主效应。。。

在近期,有3个平台的小程序表现尤为抢眼,分别是字节跳动、微信、支付宝。

字节跳动的App群,从春节开始,流量暴增,然后一直维持在高位。这是一个令人佩服的成绩,在这段时间,字节跳动给小游戏分发了大量流量,宅家的人们一边消费着可观的短视频流量,一边玩小游戏消遣时间。

在春节后,各地防疫战打响,每个城市都开始上线抗疫相关的项目,健康登记、出入管理、口罩预约、实名乘车……引发了一大波新应用热潮。这些小程序仅承载在微信和支付宝的平台上。其他小程序平台没有抓到这拨红利。倒不是因为微信或支付宝的给量能力强,流量来自于政府和商户。而他们之所以选择微信和支付宝平台,完全是因为民众对于扫码的使用习惯依赖。人们看到一个码,不是用微信扫,就是用支付宝扫。其他小程序平台还没有给民众培养出扫码的使用习惯。

支付宝小程序,从1月起原本是大幅下滑的状态,线下商户陆续放假,严重依赖线下渠道的支付宝小程序受到很大影响。直到现在,随着线下商户复工才有了起色。所幸健康码挽救了支付宝小程序的日活。不过老实讲,健康码对于微信和阿里的商业价值都不大,也只能当做培养用户使用习惯和拉近政府关系了。支付宝小程序不擅长线上分发应用流量,线下商户连接价值才是支付宝小程序的核心,赋能商户、提升交易,是它的真正使命。

值得支付宝警惕的是,一些餐饮行业的开发者,使用uni-app多端框架开发应用后,明明可以发布为支付宝小程序,却仅仅发布了H5端,让顾客在线下使用支付宝扫码后打开H5页面。根据DCloud的访谈,这些开发者认为支付宝里扫码打开小程序,并不会比打开H5页强多少,而且小程序审核麻烦,导致很多支付宝小程序的流量跑到了支付宝内置浏览器里了。这需要支付宝改进策略,为小程序开发者提供更多的吸引力,同时减少开发者的麻烦。

百度小程序,恰恰是支付宝小程序的对立面,它是纯纯的线上流量。对于很多中小开发者,从百度获取流量,比任何其他平台都容易。做好seo、甚至付费买点流量,总会让你有用户的。不少中小开发者反馈,提交到多个平台小程序,发现百度的流量是大于其他家的。尤其是内容类小程序。在春节和疫情期间,百度小程序的流量有所下滑,近期随着复工复产,又开始快速增长。

各家巨头,除了利用自己的主App的体量,也在通过搞联盟来扩大流量池。百度和阿里,都计划通过联合多个头部App组成流量联盟,来帮助开发者获取更大流量。但从目前运行的情况看,这类计划的效果不太明显。阿里小程序和百度小程序的流量,基本都集中在支付宝和百度App上。不管是开发者还是用户,都还没有对流量联盟的其他小程序形成大范围认知和使用习惯。

阿里系小程序里,值得期待的新兵是淘宝小程序。近期淘宝小程序已经开始崭露头角,相信随着产品和运营的完善,淘宝小程序会开辟一片新蓝海,因为赋能卖家,确实是一个大市场。

QQ小程序发布较晚,它没有采取同为后来者的字节跳动小程序那般中心化疯狂配量模型,目前处于稳定增长中,但整体体量暂时和其他几家还不在一个量级。

再分享一个数据:各个平台的应用数量。除了月活流量外,我们还应该关注一个指标,是应用数量。uni-app的开发者发布到各个平台的“应用数量”,看下图:

虽然使用uni-app框架可以发布到所有小程序平台,但大多数开发者不会全平台提交应用。上面的饼图有2种解读:

微信小程序的应用数量远远超过其他平台,是绝对数量级的差距。说明它已经成为一种生活方式而不只是一个流量平台。
微信小程序非常拥挤,大量开发者聚集在微信平台,但得不到足够的流量
百度和字节跳动,应用数量少,但小程序月活体量却非常大,有更多红利机会。

如果你是一个自带流量的品牌主,比如政府单位,那微信小程序是很好的选择。如果你是一个独立开发者,现在在微信里获取流量其实已经很难了,不妨试试其他平台。与微信、支付宝的给量逻辑不同,百度和字节跳动是卖流量的。在微信里获客,一般是给用户利益,比如拼团砍价;在百度、字节跳动里获客,是给平台利益,花钱投放立即带来用户。从难度来讲,在微信里已经变得很难,而在百度和字节跳动则很简单。

百度里小程序的权重高于H5,投资到百度小程序上比投放H5页面更有性价比。至于字节跳动,不得不佩服它家的流量实在太大了,大到什么地步呢?这么说吧,只要肯投钱,快速获取上千万用户很easy。

当然,不花钱投放,一样可以得到流量,那对应的要求就是你的内容过硬。

以DCloud的开发者社区App为例,每天在百度小程序上得到的流量是最大的。很多用户在百度上搜索技术问题,被导流到DCloud社区的百度小程序中,拉新效果远优于其他小程序、App和H5。

在2020年,手机厂商的快应用也出现了更积极的变化。过去快应用的数量很少,不过几千款,与微信的百万级应用数差距很大。最近快应用在原生渲染引擎之外,推出了兼容小程序架构的新应用引擎。对快应用平台而言,新策略有助于增加快应用的开发者数量。

对开发者而言,这或许是拿到一个巨大流量的新机会。

uni-app在第一时间也跟踪了快应用的新引擎适配,欢迎开发者关注。

二、各家小程序平台的流量质量怎么样?

有量,还不够。开发者还关心流量质量。流量质量怎么看?我们来看这两个指标:1、单用户页面访问数量;2、次日留存

大家都知道,小程序的流量质量,比App要差。但具体差多少呢?我们把App的数据请出来,一起比一下。

不同平台用户访问应用的页面数量
可以看到,App的一个日活用户,平均访问49个页面,远超小程序。虽然小程序的拉新能力甩开App几条街,但深度用户,还是更喜欢用App。

在各家小程序里,微信小程序的表现最接近App,领先其他小程序不少。

从这个数据可以明显看出,用户对在支付宝、百度、字节跳动的App中重度使用小程序的习惯没有养成。基于这个现状,开发者若在百度、字节跳动平台推广小程序,需要注意缩短流程,在尽可能短的页面完成自己的业务。比如获取注册表单、获取商机线索、直购低价商品等。而另一方面,也需要微信以外的其他小程序运营平台,努力学习微信,改进运营策略。尤其是百度、字节跳动和QQ小程序,还比较重视应用内广告的收益,如果页面访问次数上不去,广告位的曝光量就上不去,导致美梦落空。

我们再来看第二个指标:次日留存。

各平台次日留存表
首先,所有小程序的留存,都比App差不少。然后看各家小程序。微信小程序,在众多小程序里,留存遥遥领先,平均次日留存超过了10%。其他小程序的平均次日留存,都在5%以下。

为什么会有这么大差距。从留存入口来看,微信的下拉二楼、发现选项卡的小程序栏目,已经成功的培养起了用户的使用习惯。用户第一次不管从哪里得到一个小程序,第二次还可以比较顺畅的找到它,从而形成留存。但其他平台在这方面做得不好。百度App的二楼,经常和信息流刷新冲突。支付宝的二次使用入口,打开很慢,远不及微信的体验。字节跳动、QQ的二次使用入口则非常深。

当然,这里还有另一个关键问题,对于非微信的其他小程序平台,它们还有一个尴尬,二次使用的入口,到底做的多方便为好?字节跳动和百度,都是卖流量为生的公司。开发商投放了搜索关键字或信息流广告,如果后续用户可以方便的在二次使用入口获取这个应用,那对于字节跳动和百度来说,第一次卖流量的钱就会越来越少。这和微信不同,微信不卖初次获取的流量,它的变现是后向的,来自于持续使用的微信支付、应用内广告。后向支付和广告收益如何平衡?初次流量销售收益和小程序留存如何平衡?这是2个需要它们妥善取舍的问题。

三、结语

本文给开发者提供了数据参考,也给小程序平台提出了一些问题。

衷心希望各家小程序平台能解决好问题,取得更大的发展;

更祝愿开发者把握住新红利,在大潮中实现自己的梦想。

uni-app将始终在开发者通往成功的道路上助力!