最近一直在折騰mpvue寫(xiě)的微信小程序的性能優(yōu)化,分享下實(shí)戰(zhàn)的過(guò)程。
先上個(gè)優(yōu)化前后的圖:

可以看到打包后的代碼量從813KB減少到387KB,Audits體驗(yàn)評(píng)分從B到A,效果還是比較明顯的。其實(shí)這個(gè)指標(biāo)說(shuō)明不了什么,而且輕易就可以做到,更重要的是優(yōu)化小程序運(yùn)行過(guò)程中的卡頓感,請(qǐng)耐心往下看。
常規(guī)優(yōu)化
常規(guī)的Web端優(yōu)化方法在小程序中也是適用的,而且不可忽視。
一、壓縮圖片
這一步最簡(jiǎn)單,但是容易被忽視。在tiny上在線壓縮,然后下載替換即可。

我這項(xiàng)目的壓縮率高達(dá)72%,可以說(shuō)打包后的代碼從813KB降到387KB大部分都是歸功于壓縮圖片了。
二、移除無(wú)用的庫(kù)
我之前在項(xiàng)目中使用了Vant Weapp,在static目錄下引入了整個(gè)庫(kù),但實(shí)際上我只使用了button,field,dialog等幾個(gè)組件,實(shí)在是沒(méi)必要。
所以干脆移除掉了,微信小程序自身提供的button,wx.showModal等一些組件基本可以滿足需求,自己手寫(xiě)一下樣式也不用花什么時(shí)間。
在這里建議大家,在微信小程序中,盡量避免使用過(guò)多的依賴庫(kù)。
不要貪圖方便而引入一些比較大的庫(kù),小程序不同于Web,限制比較多,能自己寫(xiě)一下就盡量自己寫(xiě)一下吧。
小程序的優(yōu)化
咱們首先得看一下官方優(yōu)化建議,大多是圍繞這個(gè)建議去做。
一、開(kāi)啟Vue.config._mpTrace = true
這個(gè)是mpvue性能優(yōu)化的一個(gè)黑科技啊,可能大多數(shù)同學(xué)都不知道這個(gè),我在官方文檔都沒(méi)有搜到到這個(gè)配置,我真的是服了。我能找到這個(gè)配置也是Google機(jī)緣巧合下看到的,出處:mpvue重要更新,頁(yè)面更新機(jī)制進(jìn)行全面升級(jí)
具體做法是在/src/main.js添加Vue.config._mpTrace = true,如:
Vue.config._mpTrace = trueVue.config.productionTip = falseApp.mpType = 'app'
添加了Vue.config._mpTrace屬性,這樣就可以看到console里會(huì)打印每500ms更新的數(shù)據(jù)量。如圖:

如果數(shù)據(jù)更新量很大,會(huì)明顯感覺(jué)小程序運(yùn)行卡頓,反之就流暢。因此我們可以根據(jù)這個(gè)指標(biāo),逐步找出性能瓶頸并解決掉。
二、精簡(jiǎn)data
1. 過(guò)濾api返回的冗余數(shù)據(jù)
后端的api可能是需要同時(shí)為iOS,Android,H5等提供服務(wù)的,往往會(huì)有些冗余的數(shù)據(jù)小程序是用不到的。比如api返回的一個(gè)文章列表數(shù)據(jù)有很多字段:
this.articleList = [ { articleId: 1, desc: 'xxxxxx', author: 'fengxianqi', time: 'xxx', comments: [ { userId: 2, conent: 'xxx' } ] }, { articleId: 2 // ... }, // ...]假設(shè)我們?cè)谛〕绦蛑兄恍枰玫搅斜碇械牟糠肿侄危绻粚?duì)數(shù)據(jù)做處理,將整個(gè)articleList都setData進(jìn)去,是不明智的。
小程序官方文檔:單次設(shè)置的數(shù)據(jù)不能超過(guò)1024kB,請(qǐng)盡量避免一次設(shè)置過(guò)多的數(shù)據(jù)。
可以看出,內(nèi)存是很寶貴的,當(dāng)articleList數(shù)據(jù)量非常大超過(guò)1M時(shí),某些機(jī)型就會(huì)爆掉(我在iOS中遇到過(guò)很多次)。
因此,需要將接口返回的數(shù)據(jù)剔除掉不需要的,再setData,回到我們上面的articleList例子,假設(shè)我們只需要用articleId和author這兩個(gè)字段,可以這樣:
import { getArticleList } from '@/api/article'export default { data () { return { articleList: [] } } methods: { getList () { getArticleList().then(res => { let rawList = res.list this.articleList = this.simplifyArticleList(rawList) }) }, simplifyArticleList (list) { return list.map(item => { return { articleId: item.articleId, author: item.author // 需要哪些字段就加上哪些字段 } }) } }}這里我們將返回的數(shù)據(jù)通過(guò)simplifyArticleList 來(lái)精簡(jiǎn)數(shù)據(jù),此時(shí)過(guò)濾后的articleList中的數(shù)據(jù)類似:
[ {articleId: 1, author: 'fengxianqi'}, {articleId: 2, author: 'others'} // ...]當(dāng)然,如果你的需求中是所有數(shù)據(jù)都要用到(或者大部分?jǐn)?shù)據(jù)),就沒(méi)必要做一層精簡(jiǎn)了,收益不大。畢竟精簡(jiǎn)數(shù)據(jù)的函數(shù)中具體的字段,是會(huì)增加維護(hù)成本的。
PS: 在我個(gè)人的實(shí)際操作中,做數(shù)據(jù)過(guò)濾雖然增加了維護(hù)的成本,但一般收益都很大,因次這個(gè)方法比較推薦。
2. data()中只放需要的數(shù)據(jù)
import xx from 'xx.js'export default { data () { return { xx, otherXX: '2' } }}有些同學(xué)可能會(huì)習(xí)慣將import的東西都先放進(jìn)data中,再在methods中使用,在小程序中可能是個(gè)不好的習(xí)慣。
因?yàn)橥ㄟ^(guò)Vue.config._mpTrace = true在更新某個(gè)數(shù)據(jù)時(shí),我對(duì)比放進(jìn)data和不放進(jìn)data中的兩種情況會(huì)有差別。
所以我猜測(cè)可能是data是會(huì)一起更新的,比如只是想更新otherXX時(shí),會(huì)同時(shí)將xx也一起合起來(lái)setData了。
3. 靜態(tài)圖片放進(jìn)static
這個(gè)問(wèn)題和上面的問(wèn)題其實(shí)是一樣的,有時(shí)候我們會(huì)通過(guò)import的方式引入,比如這樣:
<template> <img :src="UserIcon"></template><script>import UserIcon from '@/assets/images/user_icon.png'export default { data () { return { UserIcon } }}</script>這樣會(huì)導(dǎo)致打包后的代碼,圖片是base64形式(很長(zhǎng)的一段字符串)存放在data中,不利于精簡(jiǎn)data。同時(shí)當(dāng)該組件多個(gè)地方使用時(shí),每個(gè)組件實(shí)例都會(huì)攜帶這一段很長(zhǎng)的base64代碼,進(jìn)一步導(dǎo)致數(shù)據(jù)的冗余。
因此,建議將靜態(tài)圖片放到static目錄下,這樣引用:
<template> <img src="/static/images/user_icon.png"></template>
代碼也更簡(jiǎn)潔清爽。
看一下做了上面操作的前后對(duì)比圖,使用體驗(yàn)上也流暢了很多。

三、swiper優(yōu)化
小程序自身提供的swiper組件性能上不是很好,使用時(shí)要注意。參考著兩個(gè)思路:
【優(yōu)化】解決swiper渲染很多圖片時(shí)的卡頓
想請(qǐng)教一下小程序swiper組件的問(wèn)題
在我使用時(shí),由于需求原因,動(dòng)態(tài)刪掉swiper-item的思路不可行(手滑時(shí)會(huì)造成抖動(dòng))。因此只能作罷。但仍然可以優(yōu)化一下:
將未顯示的swiper-item中的圖片用v-if隱藏到,當(dāng)判斷到current時(shí)才顯示,防止大量圖片的渲染導(dǎo)致的性能問(wèn)題。
四、vuex使用注意事項(xiàng)
我之前寫(xiě)過(guò)的一篇mpvue開(kāi)發(fā)音頻類小程序踩坑和建議里面有講如何在小程序中使用vuex。但遇到了個(gè)比較嚴(yán)重的性能問(wèn)題。
1. 問(wèn)題描述
我開(kāi)發(fā)的是一個(gè)音頻類的小程序,所以需要將播放列表playList,當(dāng)前索引currentIndex和當(dāng)前時(shí)長(zhǎng)currentTime放進(jìn)state.js中:
const state = { currentIndex: 0, // playList當(dāng)前索引 currentTime: 0, // 當(dāng)前播放的進(jìn)度 playList: [], // {title: '', url: '', singer: ''}}每次用戶點(diǎn)擊播放音頻時(shí),都會(huì)先加載音頻的播放列表playList,然后播放時(shí)更新當(dāng)前時(shí)長(zhǎng)currentTime,發(fā)現(xiàn)有時(shí)候播音頻時(shí)整個(gè)小程序非常卡頓。
注意到,音頻需每秒就得更新一次currentTime,即每秒就做一次setData操作,稍微有些卡頓是可以理解的。但我發(fā)現(xiàn)是播放列表數(shù)據(jù)比較多時(shí)會(huì)特別卡,比如playList的長(zhǎng)度是100條以上時(shí)。
2. 問(wèn)題原因
我開(kāi)啟Vue.config._mpTrace = true后發(fā)現(xiàn)一個(gè)規(guī)律:
當(dāng)palyList數(shù)據(jù)量小時(shí),console顯示造成的數(shù)據(jù)量更新數(shù)值比較小;當(dāng)playList比較大時(shí),console顯示造成的數(shù)據(jù)量更新數(shù)值比較大。
PS: 我曾嘗試將playList數(shù)據(jù)量增加到200條,每500ms的數(shù)據(jù)量更新達(dá)到800KB左右。
到這里基本可以確定一個(gè)事實(shí)就是:更新state中的任何一個(gè)字段,將導(dǎo)致整個(gè)state全量一起setData。在我這里的例子,雖然我每次只是更新currentTime這個(gè)字段的值,但依然導(dǎo)致將state中的其他字段如playList,currentIndex都一起做了一次setData操作。
3. 解決問(wèn)題
有兩個(gè)思路:
精簡(jiǎn)state中保存的數(shù)據(jù),即限制playList的數(shù)據(jù)不能太多,可將一些數(shù)據(jù)暫存在storage中
vuex采用Module的寫(xiě)法能改善這個(gè)問(wèn)題,雖然使用時(shí)命名空間造成一定的麻煩。vuex傳送門(mén)
一般情況下,推薦使用后者。我在項(xiàng)目中嘗試使用了前者,同樣能達(dá)到很好的效果,請(qǐng)繼續(xù)看下面的分享。
五、善用storage
1.為什么說(shuō)要善用storage
由于小程序的內(nèi)存非常寶貴,占用內(nèi)存過(guò)大會(huì)非常卡頓,因此最好盡可能少的將數(shù)據(jù)放到內(nèi)存中,即vuex存的數(shù)據(jù)要盡可能少。而小程序的storage支持單個(gè) key允許存儲(chǔ)的最大數(shù)據(jù)長(zhǎng)度為 1MB,所有數(shù)據(jù)存儲(chǔ)上限為 10MB。
所以可以將一些相對(duì)取用不頻繁的數(shù)據(jù)放進(jìn)storage中,需要時(shí)再將這些數(shù)據(jù)放進(jìn)內(nèi)存,從而緩解內(nèi)存的緊張,有點(diǎn)類似Windows中虛擬內(nèi)存的概念。
2.storage換內(nèi)存的實(shí)例
這個(gè)例子講的會(huì)有點(diǎn) 主站蜘蛛池模板: 茶陵县| 印江| 肥城市| 溆浦县| 图们市| 宣恩县| 洱源县| 乐都县| 彭阳县| 当雄县| 徐州市| 阜南县| 普兰县| 独山县| 雷山县| 彭泽县| 枣阳市| 阜南县| 连平县| 岳阳市| 南开区| 南岸区| 宝坻区| 宁武县| 荥阳市| 万州区| 德庆县| 信阳市| 林周县| 红原县| 百色市| 大姚县| 林周县| 临湘市| 玛纳斯县| 泸定县| 成安县| 湘潭市| 和平县| 梧州市| 桑日县|