uni-app和微信原生开发的详细比较

使用uniapp开发小程序,比直接原生开发小程序好在哪里? 小程序原生开发有不少槽点: 1.原生wxml开发对Node,预编译器, webpack支持不好,影响开发效率和工程构建流程 2.微信定义的这套语法,wxml,wxs 以及wx:if等语法,私有化太强,不如正经学vue,学会了全端通用,而不只是为了微信小程序 3.vue生态里有太多周边工具,可以提高开发效率,比如ide,校验器,三方库,而微信的开发者工具和专业编辑器相对不太好用,个性化设置比较少 作为前端工程师,除了微信小程序,还要开发web, 其他小程序设置app, uniapp可以解决这些问题。但开发者又会有顾虑: 1.怕使用uniapp后,微信小程序里的功能无法实现,受制于uniapp更新 2.性能不如原生wxml 3.框架不成熟,掉坑里 4.社区不完善

1.功能实现

uniapp不限制底层API调用,在小程序端,uniapp支持直接编写微信原生代码,类比传统web开发,如果vue、react等框架的使用,造成开发者无法操作浏览器提供的所有api,那这样的框架肯定是不成熟的。小程序开发也一样,uni-app框架中,同样可调用微信提供的所有原生API,如果存在某项API,uniapp未封装,开发者可直接在uniapp中编写微信原生API,即wx.开头的各种API.

<view>  
 <view>微信公众号关注组件</view>  
 <view>  
     <!-- uni-app未封装,但可直接使用微信原生的official-account组件-->  
     <official-account></official-account>  
 </view>  
</view>

包括微信小程序自定义组件、WXS、云开发这些复杂用法,在uni-app里一样全面支持。尤其是wxs,目前在各种小程序开发框架里,也只有uni-app支持 所以,结论是:使用uni-app框架开发,在功能上和原生小程序开发没有区别,不会有任何限制。

2. 性能体验

uniapp不会导致性能下载,甚至对很多环节做了自动优化,很多场景下性能体验比微信原生开发更好。类似vue.js开发web, 不但不会造成性能比原生js差,反而由于虚拟dom和差量更新技术的运用,在大多数场景下,比开发者手动写代码操作dom的性能更好。 小程序中频繁的用setData更新数据,这里很重要的就是差量数据更新。如果不做差量,代码性能不好,如果每处逻辑都判断差量数据更新,那代码写起来太麻烦了。 使用uni-app,底层自动差量数据更新,简单而高性能。 我们从优化理论、实测数据两个维度来仔细说明。

2.1 理论:框架优化方案

为提高性能体验,小程序从架构设计层面做了很多工作:
1.逻辑层,视图层分离,避免js运算阻塞视图渲染
2.单独定义组件标签wxml,减少dom复杂度
3.精简样式wxss,提升渲染性能
4.复杂组件原生化(video/map等),解决web组件的功能、体验缺失

通过这些规范约束,大幅提升了小程序的整体性能体验,但依然存在不少性能坑点,其中以setData最为频繁普遍 这里引用微信官方的描述,简单介绍一下setData背后的工作原理: 小程序的视图层目前使用 WebView 作为渲染载体,而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上,WebView 和 JavascriptCore 都是独立的模块,并不具备数据直接共享的通道。当前,视图层和逻辑层的数据传输,实际上通过两边提供的 evaluateJavascript 所实现。 为简化开发,微信将evaluateJavascript调用封装成了setData JS方法,实现视图层和逻辑层的数据传输

小程序的运行时性能直接决定了用户在使用小程序功能时的体验。如果运行时性能出现问题,很容易出现页面滚动卡顿、响应延迟等问题,影响用户使用。如果内存占用过高,还会出现黑屏、闪退等问题。
开发者可以从以下几个方面着手进行启动性能的优化
1.合理使用setData https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips/runtime_setData.html
2.渲染性能优化  https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips/runtime_render.html
3.页面切换优化
4.资源加载优化
5.内存优化

2.1.1 减少 setData 传递数据量

假设当前页面有一个列表(初始值为a,b,c,d),现在要向列表后追加4个新列表项(e,f,g,h),我们分别以微信原生、uni-app 两种模式编写代码。 小程序原生代码

page({  
    data:{  
        list:['a','b','c','d']  
    },  
    change:function(){  
        let newData = ['e','f','g','h'];  
        this.data.list.push(...newData);  
        this.setData({  
            list:this.data.list  
        })  
    }  
})

如上微信原生代码,change方法执行时,会将list中的a,b,c,d,e,f,g,h8个列表项通过setData全部传输过去。 uni-app 代码:

export default{  
    data(){  
        return {  
            list:['a','b','c','d']  
        }  
    },  
    methods:{  
        change:function(){  
            let newData = ['e','f','g','h'];  
            this.list.push(...newData)  
        }  
    }  
}

如上uni-app代码,change方法执行时,仅会将list中的e,f,g,h4个新增列表项传输过去,实现了setData传输量的极简化。

uni-app借鉴了 westore JSON Diff库,在调用setData之前,会先比对历史数据,精确、高效计算出有变化的差量数据,然后再调用setData,仅传输变化的数据,这样就实现 setData 传递数据量的最小化,大幅提高通讯性能。 Tips:也许有些同学对传递数据从a,b,c,d,e,f,g,h8个列表项优化为e,f,g,h4个列表项,不以为然,但我们提醒,不要小看这个机制,上述只是demo示例。

  • 在实际列表场景中,每个列表项可能包含缩略图、标题、摘要、时间等各种信息,每个列表项数据都会更大(假设为1k);
  • 假设当前页面有20个列表项,连续上拉4次后,页面变成100条记录;如果再次上拉,页面变成120条记录时,情况会有不同
  • 上述微信原生的方式,将120条记录数据(120k)全部传输过去
  • 上述 uni-app 模式,仅会将新增的20条(101 ~ 120)记录数据(20k)传输过去,数据量是原生方式的1/6!
  • 当页面列表项数据越多,这个差别就越大,页面有200条记录时,uni-app传递数据量会变成微信原生数据传递量的1/10!

2.1.2 减少 setData 调用频次

假设我们有更改多个变量值的需求,我们分别以微信原生、uni-app 两种模式编写代码 小程序原生代码:

change:function(){  
    this.setData({a:1});  
    this.setData({b:2});  
    this.setData({c:3});  
    this.setData({d:4});  
}

如上四次调用setData,就会引发4次逻辑层、视图层数据通讯 uni-app 代码:

change:function(){  
    this.a = 1;  
    this.b = 2;  
    this.c = 3;  
    this.d = 4;  
}

如上uni-app的代码,最后会被合并成{"a":1,"b":2,"c":3,"d":4}一条数据,然后仅调用一次setData完成所有数据传递,大幅降低了setData的调用频次。

uni-app之所以有这样的优势,是因为 uni-app 基于 Vue Runtime 深度定制实现,并借助了 Vue 的 nextTick 机制。

2.2 实测:性能对比数据

以400条微博列表为例,从页面空列表开始,每隔1秒触发一次上拉加载(新增20条微博),记录单次耗时,触发20次后停止(页面达到400条微博),计算这20次的平均耗时,结果微信原生在这20次 触发上拉 -> 渲染完成 的平均耗时为876毫秒,uni-app是741毫秒。 这个数据,可能违反了很多人的直觉,uni-app 的性能竟然比微信原生还好! 当然,使用微信原生开发,也可以自己单独写代码优化setData。但每处业务都编写太多判断是不现实的,自然是用框架更舒心。 这个结果,和web开发类似,web开发也有原生js开发、vue、react框架等情况。如果不做特殊优化,原生js写的网页,性能经常还不如vue、react框架的性能。 也恰恰是因为Vuereact框架的优秀,性能好,开发体验好,所以原生js开发已经逐渐减少使用了。

3.社区生态

小程序是脱离web自造生态,很多web生态中轮子无法使用。

微信小程序还是有周边生态的,而其他几家小程序平台的生态基本没建起来。 uni-app的周边生态非常丰富,在插件市场有近数千个插件,详见 ext.dcloud.net.cn

首先uni-app兼容小程序的生态,各种自定义组件均可直接引入使用。在此基础上,uni-app的插件市场,有更多vue组件,同时可跨多端使用,并且性能优秀。

这使得uni-app的生态成为最丰富的小程序开发生态。

比如富文本解析、图表、自定义下拉刷新等组件,uni-app的插件性能均超过了wxparse、wx-echart等微信小程序组件。包括 uni ui等ui库的性能也超过了vant、iview等ui库的小程序版。

如果开发者需要丰富和高性能的组件,更应该使用uni-app,而不是原生小程序开发

4.学习门槛、开发体验

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

uni-app则对开发者更为友好,简单来说是 vue的语法 + 小程序的js api。

它遵循Vue.js语法规范,组件和API遵循微信小程序命名,这些都属于通用技术栈,学习它们是前端必备技能,uni-app没有太多额外学习成本。

有一定 Vue.js 和微信小程序开发经验的开发者可快速上手 uni-app 。

没学过vue的同学,也不用掌握vue的全部,只需了解vue基础语法、数据绑定、列表渲染、组件等,其他如路由、loader、cli、node.js、webpack并不需要学。

因为HBuilderX工具搭配uni-app可以免终端开发,可视化创建项目、可视化安装组件和扩展编译器,也就是uni-app的学习门槛,比web开发的vue.js还低。

开发体验层面,微信原生开发相比uni-app有较大差距,主要体现在:

  • 更为强大的组件化开发能力:vue的组件开发比小程序自定义组件开发的体验要好很多
  • 应用状态管理:uni-app支持vuex
  • 使用 Sass 等 CSS 预处理器
  • 完整的 ES Next 语法支持
  • 自定义构建策略

开发工具维度,差距更大:

  • 微信开发者工具被吐槽无数
  • uni-app的出品公司,同时也是HBuilder的出品公司,DCloud.io。HBuilder/HBuilderX系列是四大主流前端开发工具(可对比百度指数),其为uni-app做了很多优化,故uni-app的开发效率、易用性非微信原生开发可及。

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

5.未来扩展性

然当前产品仅要求发布到微信小程序,但阿里、百度、字节跳动、QQ、快应用等众多平台的流量越来越多,覆盖这些平台是迟早要考虑的事情。

此时,uni-ap的跨端功能将成为程序员的自救神器,基于uni-app开发的小程序,无需修改,即可同时发布到多家小程序,甚至App、H5平台。这不是梦想,而是现实。大家可依次扫描如下8个二维码,亲自体验最全面的跨平台效果!

6.结语

uni-app微信
功能相同相同
性能常规场景更优需要自己编写复杂代码才能提高性能
社区生态丰富,更多高性能组件丰富
开发体验纯vue体验,高效、统一;工程化能力强语法私有化;工程化能力弱
多端能力同时支持H5、多家小程序、跨平台App只能用于微信小程序

7.结语

只开发小程序,需要uni-app的好处

  1. uniapp无需追随微信升级,可不受限在条件编译里使用wx的现在或未来的所有api
  2. uniapp的性能比一般人手写的微信原生代码性能更高,就像vue操作比一般人手写js操作dom性能更高一样,底层自动diff差量更新数据,比手动setData性能更高
  3. uniapp是纯vue语法,不必另学一种dsl, 开发不同项目时,思维不用切换
  4. uniapp 的组件,模板非常丰富,插件市场千款插件,如富文本解析,图表,自定义下拉刷新等组件,uniapp版插件性能均超过wxparse,wx-echart等微信小程序组件
  5. HBuilderX比微信工具更强大,开发效率更高。哪怕使用vscode等工具,由于这些工具对vue的支持强于对wxml的支持,所以开发效果也会更高
  6. 微信原生开发对webpack、预编译语言、工程流程管理很多功能都不支持,大公司很少用微信原生开发,都是在用框架来提升开发效率
  7. uni-app支持双向数据绑定、vuex状态管理,比小程序原生开发方便的多
  8. 多端需求
  9. uni-app并非仅用于做跨端的,只用uni-app做小程序、只做web、只做App的,案例是一样多的