眾所周知，Vue項目采用了數據雙向綁定和虛擬DOM基礎，在數據驅動代替DOM頻繁渲染已經算是非常高效了，對開發者而言已經非常優化了，那為什么還會有Vue性能優化這一說呢？
因為目前Vue 2.x使用了webpack等第三方打包構建工具，并且支持其他第三方的插件，我們在項目中使用這些工具時可能不同的操作在運行或打包效率上會有不同的效果，下面就來詳細說明優化的方向。
1 v-if 和 v-show 的使用
- v-if 為false的時候不會渲染DOM到視圖，為true的時候才會渲染到視圖；
- v-show 不管初始條件是什么，元素總是會渲染到視圖，只是簡單地基于 CSS 的 display 屬性進行切換。
最佳實踐：頻繁切換顯示隱藏的元素采用v-show，很少改變使用v-if
2 computed 和 watch 區分使用
- computed： 是計算屬性，依賴其它屬性值，并且 computed 的值有緩存，只有它依賴的屬性值發生改變，下一次獲取 computed 的值時才會重新計算 computed的值；
- watch： 更多的是「觀察」的作用，類似于某些數據的監聽回調 ，每當監聽的數據變化時都會執行回調進行后續操作；
最佳實踐：當我們需要進行數值計算，并且依賴于其它數據時，應該使用 computed，因為可以利用 computed 的緩存特性，避免每次獲取值時，都要重新計算；當我們需要在數據變化時執行異步或開銷較大的操作時，應該使用 watch，使用 watch 選項允許我們執行異步操作 ( 訪問一個 API )，限制我們執行該操作的頻率，并在我們得到最終結果前，設置中間狀態。這些都是計算屬性無法做到的。
3 v-for 遍歷必須為 item 添加 key，且避免同時使用 v-if
現在不加key一般會報錯的，添加key可以方便 Vue內部機制精準找到該條列表數據。當更新時，新的狀態值和舊的狀態值對比，較快地定位到 diff
v-for比 v-if 優先級高，如果每一次都需要遍歷整個數組，將會影響速度，尤其是當之需要渲染很小一部分的時候，必要情況下應該替換成 computed屬性。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
<ul> <li v-for="user in adminUsers" :key="user.id"> {{ user.name }} </li></ul><script>export default { data () { return { users: [] } }, computed: { adminUsers: function(){ return this.users.filter(()=>user.isAdmin) } }}</script> |
4 純顯示長列表性能優化
對于只用來展示用的數據，不需要做vue做數據劫持，只需要凍結這個對象即可：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
export default { data () { return { users: [] } }, created () { axios.get('/api/users').then((res)=>{ this.users = Object.freeze(res.data.users) }) }} |
5 事件的銷毀
Vue 組件銷毀時，會自動清理它與其它實例的連接，解綁它的全部指令及事件監聽器，但是僅限于組件本身的事件。 如果在 js 內使用 addEventListene 等方式是不會自動銷毀的，我們需要在組件銷毀時手動移除這些事件的監聽，以免造成內存泄露，如：
|
1
2
3
4
5
6
7
|
created() { addEventListener('click', this.click, false)},beforeDestroy() { removeEventListener('click', this.click, false)} |
6 圖片資源懶加載
使用vue-lazyload插件：
安裝
|
1
|
npm install vue-lazyload --save-dev |
man.js 引用
|
1
2
3
4
5
6
7
8
9
|
import VueLazyload from 'vue-lazyload'Vue.use(VueLazyload)// 或自定義Vue.use(VueLazyload, { preLoad: 1.3, error: 'dist/error.png', loading: 'dist/loading.gif', attempt: 1}) |
修改img標簽
|
1
|
<img v-lazy="/static/img/1.png"> |
7 路由懶加載
Vue 是單頁面應用，可能會有很多的路由引入 ，這樣使用 webpcak 打包后的文件很大，當進入首頁時，加載的資源過多，頁面會出現白屏的情況，不利于用戶體驗。如果我們能把不同路由對應的組件分割成不同的代碼塊，然后當路由被訪問的時候才加載對應的組件，這樣就更加高效了。這樣會大大提高首屏顯示的速度，但是可能其他的頁面的速度就會降下來。
|
1
2
3
4
5
6
|
const Foo = () => import('./Foo.vue')const router = new VueRouter({ routes: [ { path: '/foo', component: Foo } ]}) |
8 第三方插件按需引入
我們在使用第三方庫的時候，最好是按需引入而不是全局引入，因為第三方庫的插件比較多全部引入會打包比較慢，如Element UI、Ant Design of Vue等UI庫：
按需引入
|
1
2
3
4
|
import Vue from 'vue';import { DatePicker } from 'ant-design-vue';Vue.use(DatePicker); |
全局引入
|
1
2
|
import Antd from 'ant-design-vue';Vue.use(Antd); |
9 優化無限列表性能
如果你是在渲染帶無限滾動加載的列表時，那么需要采用 窗口化 的技術來優化性能，只需要渲染少部分區域的內容，減少重新渲染組件和創建 dom 節點的時間。 你可以參考以下開源項目 vue-virtual-scroll-list 和 vue-virtual-scroller來優化這種無限列表的場景的。
大家自己去Github看使用說明吧。
10 服務端渲染 SSR or 預渲染
一般單頁應用是在瀏覽器端完成頁面渲染的，數據是發請求從后臺拿過來的；而服務器端渲染SSR是頁面元素的結構(HTML)是在服務器端就已經構建好的，直接把整個頁面返回到客戶端的。
那SSR有什么優缺點呢：
- 更好的SEO：網絡爬蟲可以直接爬取頁面信息利于被搜索引擎收錄，而ajax異步請求的內容不會被收錄，所以通過SSR渲染的完整的頁面信息更利于SEO；
- 支持的鉤子函數只支持 beforCreate 和 created，服務器需要處于Node Server環境；
- 需要更高的服務器配置：因為它包含了數據處理和頁面渲染，所以服務器開支變大
如果對首屏加載速度要求比較高或對SEO有要求的可以采用SSR渲染。
PS：優化只是建議，需要考慮是否適合自己的項目，包括優化難度、影響范圍、適用場景、是否影響別的模塊、優化效果是否明顯等等。適合自己的才是最好的！
到此這篇關于Vue2.x 項目性能優化之代碼優化的實現的文章就介紹到這了,更多相關Vue2.x 代碼優化內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！
原文鏈接：https://blog.csdn.net/zy1281539626/article/details/114952458
