信息谷 - ICITU

标题: 跨端开发框架深度横评之2020版 [打印本页]
作者: sxadmin    时间: 2024-8-6 15:10
标题: 跨端开发框架深度横评之2020版
评测目标筛选跨端框架是一个重投入工作，在各框架的1年多的比拼中，很多框架因为投入不足而逐渐被开发者放弃，uni-app和taro依靠持续的大力度投入，成为了市场主流。
taro 在稳定版的基础之上，最近也推出了 taro next，这2个版本差异较大，本次会分别评测。
kbone 框架虽面世不久，但毕竟是微信官方发布，关注的人不少，故本次将 kbone 加入评测目标。
所以，本次评测的对象（按发布时间排序）：
本次评测除了运行性能等实测数据外，尽可能得通过框架官网及github、掘金、腾讯课堂等三方社区公开采集数据，希望给大家一个综合全面的评估依据。
功能实现taro 和 uni-app 是比较典型的多端框架，发布到各个端均可。而 kbone 只支持微信小程序和H5。
taro 和  uni-app 均将常用接口及组件封装了成了跨端API和跨端组件，组件规范沿用微信小程序的规范，部分平台特有API，这两个框架亦有应对方案：
taro 和 uni-app 可以不受限的调用各家小程序平台所有的API及组件。
kbone 沿用web的开发习惯，使用html标签及js api；涉及微信特有api时，可通过process.env.isMiniprogram判断环境，然后编写微信原生代码。对于html中没有标签可替代的微信内置组件（如swiper），需要使用 wx-component 标签或者使用 wx- 前缀，这样的内置组件会被包裹一层自定义组件，带来相应的性能开销。
除了接口、组件之外，我们以微信小程序为例，找几个典型能力对比框架支持度：
[td]
框架tarouni-appkbone
微信自定义组件⭕️⭕️⭕️
三方插件⭕️⭕️❌
分包加载⭕️⭕️⭕️
sitemap⭕️⭕️⭕️
wxs❌⭕️❌
云开发⭕️⭕️⭕️
补充说明：
wxs是提升性能体验的重要利器，除了微信小程序的wxs外，还有支付宝的SJS、百度的Filter，这些高级技术 uni-app 均完善支持。参考：谜之wxs，uni-app如何用它大幅提升性能
从如上功能对比来看：微信原生 ~ uni-app > taro > kbone
运行性能(微信小程序)我们继续沿用去年的测试模型，看看一年来，各家开发框架的性能是否有提升。详细如下：
我们以上述仿微博小程序为例，测试2个容易出性能问题的点：长列表加载、大量点赞组件的响应。
长列表加载仿微博的列表是一个包含很多组件的列表，这种复杂列表对性能的压力更大，很适合做性能测试。
从触发上拉加载到数据更新、页面渲染完成，需要准确计时。人眼视觉计时肯定不行，我们采用程序埋点的方式，制定了如下计时时机：
Tips：setData回调函数开头可认为是页面渲染完成的时间，是因为微信setData定义如下(微信规范)：

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

(, 下载次数: 38)
说明：以400条微博列表为例，从页面空列表开始，每隔1秒触发一次上拉加载（新增20条微博），记录单次耗时，触发20次后停止（页面达到400条微博），计算这20次的平均耗时，结果微信原生在这20次 触发上拉 -> 渲染完成 的平均耗时为538毫秒，最快的uni-app是446毫秒，最慢的kbone是4057毫秒
大家初看这个数据，可能比较疑惑，别急，下方有详细说明
说明1：为何 taro next/kbone 测试数据不完整?
因为 taro next 和kbone 采用的是动态渲染方案，这类方案在页面复杂、组件较多时，会大量增加页面 dom 节点数量，甚至超出微信的 dom 节点数限制（如下告警信息）。我们在 红米手机（Redmi 6 Pro）上实测，页面组件超过600个时，taro next、kbone  实现的仿微博App就会报出运行异常，并停止渲染（页面白屏），故这两个测试框架在组件较多时，测试数据不完整。这也就意味着，当页面组件太多时，无法使用这2个框架。
dom limit exceeded please check if there's any mistake you've made
另外，kbone官网有如下介绍：
kbone 是使用一定的性能损耗来换取更为全面的 Web 端特性支持。
故taro next、kbone的测试数据，明显和taro 2.0、uni-app不是一个量级的。
如果你的应用是长列表场景，那taro next、kbone就明显不太合适。
说明2：为什么测试数据显示uni-app 会比微信原生框架的性能略好呢？
这个问题在去年的测评中，已解释过。为了避免新同学迷惑，这里再次说明一下。
微信原生框架耗时主要在setData调用上，开发者若不单独优化，则每次都会传递大量数据；而 uni-app、taro 都在调用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) //增量数据，发送数据到视图层}经过如上优化修改后，再次测试，微信原生框架性能数据如下：

(, 下载次数: 35)
从测试结果可看出：
这个结果，和web开发类似，web开发也有原生js开发、vue、react框架等情况。如果不做特殊优化，原生js写的网页，性能经常还不如vue、react框架的性能。
也恰恰是因为Vue、react框架的优秀，性能好，开发体验好，所以原生js开发已经逐渐减少使用了。
说明3：为何今年的性能测试数据和去年的不同？
细心的同学会发现，同样的测试手机，同样的测试代码，为何今年的性能数据会比去年的数据有大幅提升？
其实，通过微信原生工程的数据对比，就能得出结论：2019年，微信针对小程序运行时做了大幅性能优化。
这对开发者来说应该是个好消息，小程序性能体验更佳，可承载更好的用户业务。
复杂长列表加载下一页评测结论：微信原生开发(手动优化) ~ uni-app > 微信原生开发(未手动优化) ~ taro 2.0 > taro next > kbone
点赞组件响应速度长列表中的某个组件，比如点赞组件，点击时是否能及时的修改未赞和已赞状态？是这项测试的评测点。
测试方式：
在红米手机（Redmi 6 Pro）上进行多次测试，求其平均值，结果如下：

(, 下载次数: 44)
说明：也就是在列表数量为400时，微信原生开发的应用，点赞按钮从点击到状态变化需要26毫秒。
测试结果数据说明：
组件数据更新性能测评：uni-app ~ taro 2.0 > taro next > kbone
综上，本性能测试做了2个测试，长列表加载和组件状态更新，综合2个实验，结论如下：
微信原生开发(手动优化) ~ uni-app > 微信原生开发(未手动优化) ~ taro 2.0 > taro next > kbone
运行性能（支付宝小程序）今年新增基于支付宝小程序的性能测试，我们同样按照如上描述，对长列表加载、点赞组件响应两个场景进行测试。
场景1：长列表加载
[td]
列表条数taro 2.0uni-app
2001954850
40031551012
60042841119
80052781258
100065551452
场景2：点赞组件响应
[td]
组件数量taro 2.0uni-app
2003833
4003445
6003737
8004039
10005148
Tips：
通过如上测试数据，在支付宝小程序的运行性能，uni-app > taro 2.0
跨端支持这三个框架都是为了解决平台同构问题，跨端的比较是必需的。
taro 和 uni-app 相对比较成熟，支持主流的所有平台。kbone 只支持微信小程序和 Web 端。我们重点比较一下 taro 和 uni-app。
小程序平台taro 和 uni-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动画：
(, 下载次数: 74)
taro的开发者需自行搭建iOS/Android开发环境，比较繁琐，（官方原文如下）：
如果你之前没有接触过 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个发行到快应用的方案（当前两个版本都处于社区维护状态）：
跨端灵活性跨端开发，离不开条件编译。因为不能用统一来抹杀各个平台的特色。
优良的条件编译能力对各端开发的灵活度至关重要，可以让开发者在共享和个性化之间游刃有余。
taro 、uni-app和 kbone 均支持在js代码通过process.env判断平台，然后编写平台特有代码。
taro额外支持统一接口的多端文件编码方式，以及在样式文件中使用ifdef条件编译。
uni-app是全面可条件编译的，目录、文件、配置、组件、js、css，所有一切均可通过ifdef条件编译。
跨端支持小结结论：uni-app > taro > kbone
开发体验taro、uni-app、kbone均支持cli模式，可以在主流前端工具中开发，且基本都带有d.ts的语法提示库。三个框架均支持vue或react流行框架语法，配套的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 方案才是开发者的最优解。
目前主流框架对云开发的支持情况：
serverless 维度上，uni-app大幅领先其它框架。
插件市场一个开发框架能否成功，除了框架自身的高度产品化外，开发者生态的构建也至关重要。
uni-app 于2018年底率先推出插件市场，支持前端组件、js sdk、页面模板、项目模板、原生插件等多种类型，且提供了赞赏、付费购买等手段，刺激轮子作者的创作激情。目前市场上已发布插件接近1500个，众多插件下载量都在万次以上。
Taro 于 2019年5月上线物料市场，目前市场上已发布物料90个；从热门榜单来看，下载量并不大，下载最多的也就数百。
kbone目前还没有插件市场。

(, 下载次数: 41)
Tips:
插件市场维度，uni-app独领风骚。
学习资源除了各大框架官网外，开发者通常还会通过视频教程、社区博客等方式系统学习。
相关学习资源的丰富程度，也能侧面反映一个框架的受欢迎程度，故我们采集了几个三方站点的数据。
视频教程
[td]
框架腾讯课堂网易云课堂慕课网
taro412
uni-app16161
Tips：
开发交流除了入门的学习资源，开发期的交流也很重要，这个我们主要看官方组织的社区和交流群。
社区论坛uni-app 的问答社区，帖子丰富，沉淀较多；目前已沉淀2万多相关帖子，每日更新帖子数百篇，月uv百万。
对于习惯使用 github issue反馈问题的用户，uni-app同样支持，目前累计有1391个issues。
Taro 早期基于github issue进行产品Bug管理，目前累计已有近4898个issue；后于2019年5月上线开发者社区，和物料市场上线时间相同，目前沉淀1300+帖子，每日更新帖子在10个左右，相关数据计算方法如下：

(, 下载次数: 67)
kbone 在微信开放社区中新增了一个Kbone官方框架的专区，因产品发布较晚，目前只有一百多个帖子。
总结一下社区帖子及issue数据，情况如下（采集时间为 2020.04.03 23：00）：

(, 下载次数: 46)
交流群[td]
框架微信群QQ群交流群开发者（预估）
taro16-8k
uni-app2040+90k
kbone-10.5k
Tips:
除了交流群外，DCloud对外公布的uni-app的开发者数量达到百万人，暂未看到taro和kbone公布此类数据。
总体而言，开发交流维度比较结果如下：uni-app > taro > kbone
其它指标github[td]
框架star贡献者
taro24.6k122
uni-app19.7k72
kbone2.7k7
在开源社区方面，Taro做的还是非常成功的，它吸引了更多开发者为其贡献代码、文档。
百度指数通过index.baidu.com，可查看主流框架的搜索指数，它代表了网友的搜索量和相关文章的收录量。目前kbone尚未收录到百度指数中，如下是近期 uni-app 和 taro的百度指数对比图：

(, 下载次数: 44)
结语所有的评测都只是提供决策依据，最后的结果还是要依赖开发者的团队技术栈、业务诉求、未来规划等。
不过作为一篇评测文章的结语，我们还是要给出自己的建议：


作者：CHB
链接：https://juejin.cn/post/6844904118901817351
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。






欢迎光临 信息谷 - ICITU (https://icitu.com/) Powered by Discuz! X3.4