最近客戶反應在操作頁面的過程中出現了卡頓甚至交互多一點瀏覽器直接崩潰了。項目的技術是vue + svg 所以我一直在想是不是svg交互導致的,但是svg涉及的交互也不是很多,不至於產生崩潰狀態呀!后來又懷疑是代碼問題,於是對大家都知道的一些內存泄露的情況進行了排查:
- 沒有全局變量
- 沒有定時器
- 沒有使用未銷毀的全局事件和第三方庫
- v-if和v-show合理使用了,v-if和v-for合理使用了
- 沒有使用watch
- ...
確保代碼層面是沒有問題的,但是打開任務管理器,內存的確在隨着點擊選擇交互而飆升。為了排查哪里出了問題,這里使用了vue-devtools
選擇Performance
然后點擊 Start
進行卡頓的操作后再點擊 Stop
,原因一目了然:
Σ(っ °Д °;)っ 找到交互中的下拉框,原來是頁面中的下拉框的數據太多了導致的頁面卡頓~
解決方案
試將下拉框的數據減少,再進行同樣的操作,耗時小了90倍(笑哭~~)
我的業務場景是下拉數據是通過接口一把獲取的,之前沒有那么多的數據,問題沒有暴露,隨着業務迭代數據達到幾百至幾千條。問題暴露了~
一般情況下,在網上可以搜到一堆對下拉數據進行遠程搜索和分頁處理,而本案例根據實際業務情況進行了下巧妙處理:
第一步:在data中設置一個變量moreNum:20
,表示每次最多顯示20條;
第二步:在組件中進行如下操作,當數量多於20條的時候,不再顯示
<el-option-group v-for="group in oOtherArr" :key="group.label" :label="group.label">
<template v-for="(item,num) in group.options">
<el-option
:key="item.text"
:label="item.text"
:value="item.text"
v-if="item.text && (group.label === '從庫中選擇' ? num < moreNum : true)"
></el-option>
</template>
<div
v-if="group.label === '從庫中選擇' && group.options.length > moreNum"
class="search-keyword-more"
>
只顯示前{{moreNum}}條庫中結果,請完善搜索關鍵字
</div>
</el-option-group>
顯示結果:
第三步:支持篩選,篩選后返回適配的20條數據
第四步:用戶不明覺厲的反饋,哈哈哈~
第五步:總結,小細節引發的大問題,需要記錄下,以后再遇到類似操作要學會問題規避和風險預測!