1. 慎用deep watch：
第一次遇到性能問題是文件夾數(shù)據(jù)量稍大時(shí)揣钦，操作素材會(huì)感覺到明顯的延遲和卡頓谓罗，通過chrome的performance分析發(fā)現(xiàn)是使用watch時(shí)域那，配置了deep等于true活逆，由于這個(gè)文件系統(tǒng)是個(gè)大的tree狀對(duì)象，每個(gè)素材對(duì)象又相互引用剪决，導(dǎo)致任何一份數(shù)據(jù)更新都會(huì)通知到這個(gè)watcher灵汪。復(fù)盤分析對(duì)比圖如下：
deep:true, 明顯延遲卡頓
deep:false, 流暢
2. 使用更好的方式來解決問題:
第二次性能問題是在數(shù)據(jù)量超過1500左右時(shí)，加載元素耗時(shí)變久昼捍，操作開始慢慢變卡识虚，檢查發(fā)現(xiàn)此時(shí)頁面內(nèi)存暫用升高，dom元素?cái)?shù)量巨大妒茬，附上16000個(gè)素材的dom數(shù)，這個(gè)時(shí)候系統(tǒng)已經(jīng)完全不能用了蔚晨，卡出天際乍钻。
優(yōu)化方案，只渲染用戶能看到部分的素材铭腕，用戶滾動(dòng)滾動(dòng)條時(shí)才動(dòng)態(tài)的切換素材银择，產(chǎn)生一種所有素材都已經(jīng)渲染了的感覺。優(yōu)化后的dom數(shù)如下累舷，使用基本流程浩考，滑動(dòng)滾動(dòng)條還是有明顯的不流暢。
3. 盡可能的減少watcher的數(shù)量
在上面16000個(gè)素材的情況被盈，vue至少會(huì)創(chuàng)建16000個(gè)watcher析孽，實(shí)際情況下會(huì)多得多，這樣的后果就是操作時(shí)js執(zhí)行會(huì)特別耗時(shí)只怎，這里我優(yōu)化的辦法是把素材數(shù)據(jù)單獨(dú)保存到一個(gè)js變量中袜瞬，只把需要展示給用戶的那一屏數(shù)據(jù)拿出來給vue監(jiān)聽，這樣大大減少了wather的數(shù)據(jù)身堡，原理同2邓尤，現(xiàn)在16000個(gè)素材無論是操作還是滑動(dòng)滾動(dòng)條一點(diǎn)都沒有卡頓的感覺了。
結(jié)語：之前在哪看過一句話贴谎，大意是不要老想著從技術(shù)的角度去解決問題汞扎，要試著從設(shè)計(jì)上從方式上去規(guī)避問題，挺有感觸的擅这。
