好久不寫博文了，本文作為我使用半年 vue 框架的經(jīng)驗(yàn)小結(jié)，隨便談?wù)劊冶疚闹贿m用于 vue-cli 初始化的項(xiàng)目或依賴于 webpack 打包的項(xiàng)目。

前幾天看到大家說(shuō) vue 項(xiàng)目越大越難優(yōu)化，帶來(lái)很多痛苦，這是避免不了的，問(wèn)題終究要解決，框架的性能是沒有問(wèn)題的，各大測(cè)試網(wǎng)站都有相關(guān)數(shù)據(jù)。下面進(jìn)入正題

基礎(chǔ)優(yōu)化

所謂的基礎(chǔ)優(yōu)化是任何 web 項(xiàng)目都要做的，并且是問(wèn)題的根源。HTML，CSS，JS 是第一步要優(yōu)化的點(diǎn)

分別對(duì)應(yīng)到 .vue 文件內(nèi)的，<template>,<style>,<script>，下面逐個(gè)談下 vue 項(xiàng)目里都有哪些值得優(yōu)化的點(diǎn)

template

語(yǔ)義化標(biāo)簽，避免亂嵌套，合理命名屬性等等標(biāo)準(zhǔn)推薦的東西就不談了。

模板部分幫助我們展示結(jié)構(gòu)化數(shù)據(jù)，vue 通過(guò)數(shù)據(jù)驅(qū)動(dòng)視圖，主要注意一下幾點(diǎn)

1. v-show，v-if 用哪個(gè)？在我來(lái)看要分兩個(gè)維度去思考問(wèn)題，第一個(gè)維度是權(quán)限問(wèn)題，只要涉及到權(quán)限相關(guān)的展示無(wú)疑要用 v-if，第二個(gè)維度在沒有權(quán)限限制下根據(jù)用戶點(diǎn)擊的頻次選擇，頻繁切換的使用 v-show，不頻繁切換的使用 v-if，這里要說(shuō)的優(yōu)化點(diǎn)在于減少頁(yè)面中 dom 總數(shù)，我比較傾向于使用 v-if，因?yàn)闇p少了 dom 數(shù)量，加快首屏渲染，至于性能方面我感覺肉眼看不出來(lái)切換的渲染過(guò)程，也不會(huì)影響用戶的體驗(yàn)。
2. 不要在模板里面寫過(guò)多的表達(dá)式與判斷 v-if="isShow && isAdmin && (a || b)"，這種表達(dá)式雖說(shuō)可以識(shí)別，但是不是長(zhǎng)久之計(jì)，當(dāng)看著不舒服時(shí)，適當(dāng)?shù)膶懙?methods 和 computed 里面封裝成一個(gè)方法，這樣的好處是方便我們?cè)诙嗵幣袛嘞嗤谋磉_(dá)式，其他權(quán)限相同的元素再判斷展示的時(shí)候調(diào)用同一個(gè)方法即可。
3. 循環(huán)調(diào)用子組件時(shí)添加 key，key 可以唯一標(biāo)識(shí)一個(gè)循環(huán)個(gè)體，可以使用例如 item.id 作為 key，假如數(shù)組數(shù)據(jù)是這樣的 ['a' , 'b', 'c', 'a'],使用 :key="item" 顯然沒有意義，更好的辦法就是在循環(huán)的時(shí)候 (item, index) in arr，然后 :key="index"來(lái)確保 key 的唯一性。

style

1. 將樣式文件放在 vue 文件內(nèi)還是外？討論起來(lái)沒有意義，重點(diǎn)是按模塊劃分，我的習(xí)慣是放在 vue 文件內(nèi)部，方便寫代碼是在同一個(gè)文件里跳轉(zhuǎn)上下對(duì)照，無(wú)論內(nèi)外建議加上 <style scopeed> 將樣式文件鎖住，目的很簡(jiǎn)單，再好用的標(biāo)準(zhǔn)也避免不了多人開發(fā)的麻煩，約定命名規(guī)則也可能會(huì)沖突，鎖定區(qū)域后盡量采用簡(jiǎn)短的命名規(guī)則，不需要 .header-title__text 之類的 class，直接 .title 搞定。
2. 為了和上一條作區(qū)分，說(shuō)下全局的樣式文件，全局的樣式文件，盡量抽象化，既然不在每一個(gè)組件里重復(fù)寫，就盡量通用，這部分抽象做的越好說(shuō)明你的樣式文件體積越小，復(fù)用率越高。建議將復(fù)寫組件庫(kù)如 Element 樣式的代碼也放到全局中去。
3. 不使用 float 布局，之前看到很多人封裝了 .fl -- float: left 到全局文件里去，然后又要 .clear，現(xiàn)在的瀏覽器還不至于弱到非要用 float 去兼容，完全可以 flex，grid 兼容性一般，功能其實(shí) flex 布局都可以實(shí)現(xiàn)，float 會(huì)帶來(lái)布局上的麻煩，用過(guò)的都知道不相信解釋坑了。

至于其他通用的規(guī)范這里不贅述，相關(guān)文章很多。

script

這部分也是最難優(yōu)化的點(diǎn)，說(shuō)下個(gè)人意見吧。

1. 多人開發(fā)時(shí)盡量保持每個(gè)組件 export default {} 內(nèi)的方法順序一致，方便查找對(duì)應(yīng)的方法。我個(gè)人習(xí)慣 data、props、鉤子、watch、computed、components。
2. data 里要說(shuō)的就是初始化數(shù)據(jù)的結(jié)構(gòu)盡量詳細(xì)，命名清晰，簡(jiǎn)單易懂，避免無(wú)用的變量，isEditing 實(shí)際可以代表兩個(gè)狀態(tài)，true 或 false，不要再去定義 notEditing 來(lái)控制展示，完全可以在模板里 {{ isEditing ? 編輯中 : 保存 }}
3. props 父子組件傳值時(shí)盡量 :width="" :heigth="" 不要 :option={}，細(xì)化的好處是只傳需要修改的參數(shù)，在子組件 props 里加數(shù)據(jù)類型，是否必傳，以及默認(rèn)值，便于排查錯(cuò)誤，讓傳值更嚴(yán)謹(jǐn)。
4. 鉤子理解好生命周期的含義就好，什么時(shí)間應(yīng)該請(qǐng)求，什么時(shí)間注銷方法，哪些方法需要注銷。簡(jiǎn)單易懂，官網(wǎng)都有寫。
5. metheds 中每一個(gè)方法一定要簡(jiǎn)單，只做一件事，盡量封裝可復(fù)用的簡(jiǎn)短的方法，參數(shù)不易過(guò)多。如果十分依賴 lodash 開發(fā)，methed 看著會(huì)簡(jiǎn)潔許多，代價(jià)就是整體的 bundle 體積會(huì)大，假如項(xiàng)目?jī)H僅用到小部分方法可以局部引入 loadsh，不想用 lodash 的話可以自己封裝一個(gè) util.js 文件
6. watch 和 computed 用哪個(gè)的問(wèn)題看官網(wǎng)的例子，計(jì)算屬性主要是做一層 filter 轉(zhuǎn)換，切忌加一些調(diào)用方法進(jìn)去，watch 的作用就是監(jiān)聽數(shù)據(jù)變化去改變數(shù)據(jù)或觸發(fā)事件如 this.$store.dispatch('update', { ... })

組件優(yōu)化

vue 的組件化深受大家喜愛，到底組件拆到什么程度算是合理，還要因項(xiàng)目大小而異，小型項(xiàng)目可以簡(jiǎn)單幾個(gè)組件搞定，甚至不用 vuex，axios 等等，如果規(guī)模較大就要細(xì)分組件，越細(xì)越好，包括布局的封裝，按鈕，表單，提示框，輪播等，推薦看下 Element 組件庫(kù)的代碼，沒時(shí)間寫這么詳細(xì)可以直接用 Element 庫(kù)，分幾點(diǎn)進(jìn)行優(yōu)化

1. 組件有明確含義，只處理類似的業(yè)務(wù)。復(fù)用性越高越好，配置性越強(qiáng)越好。
2. 自己封裝組件還是遵循配置 props 細(xì)化的規(guī)則。
3. 組件分類，我習(xí)慣性的按照三類劃分，page、page-item 和 layout，page 是路由控制的部分，page-item 屬于 page 里各個(gè)布局塊如 banner、side 等等，layout 里放置多個(gè)頁(yè)面至少出現(xiàn)兩次的組件，如 icon, scrollTop 等

vue-router 和 vuex 優(yōu)化

vue-router 除了切換路由，用的最多的是處理權(quán)限的邏輯，關(guān)于權(quán)限的控制這里不贅述，相關(guān) demo 和文章有許多，那么說(shuō)到優(yōu)化，值得一提的就是組件懶加載

中午官網(wǎng)鏈接如上，例子如下

const Foo = r => require.ensure([], () => r(require('./Foo.vue')), 'group-foo') 
const Bar = r => require.ensure([], () => r(require('./Bar.vue')), 'group-foo') 
const Baz = r => require.ensure([], () => r(require('./Baz.vue')), 'group-foo') 

 

這段代碼將 Foo, Bar, Baz 三個(gè)組件打包進(jìn)了名為 group-foo 的 chunk 文件，當(dāng)然啦是 js 文件

其余部分正常寫就可以，在網(wǎng)站加載時(shí)會(huì)自動(dòng)解析需要加載哪個(gè) chunk，雖然分別打包的總體積會(huì)變大，但是單看請(qǐng)求首屏速度的話，快了好多。

vuex 面臨的問(wèn)題和解決方案有幾點(diǎn)

當(dāng)網(wǎng)站足夠大時(shí)，一個(gè)狀態(tài)樹下，根的部分字段繁多，解決這個(gè)問(wèn)題就要模塊化 vuex，官網(wǎng)提供了模塊化方案，允許我們?cè)诔跏蓟?vuex 的時(shí)候配置 modules。每一個(gè) module 里面又分別包含 state 、action 等，看似是多個(gè)狀態(tài)樹，其實(shí)還是基于 rootState 的子樹。細(xì)分后整個(gè) state 結(jié)構(gòu)就清晰了，管理起來(lái)也方便許多。

由于 vuex 的靈活性，帶來(lái)了編碼不統(tǒng)一的情況，完整的閉環(huán)是 store.dispatch('action') -> action -> commit -> mutation -> getter -> computed，實(shí)際上中間的環(huán)節(jié)有的可以省略，因?yàn)?API 文檔提供了以下幾個(gè)方法 mapState、mapGetters、mapActions、mapMutations，然后在組件里可以直接調(diào)取任何一步，還是項(xiàng)目小想怎么調(diào)用都可以，項(xiàng)目大的時(shí)候，就要考慮 vuex 使用的統(tǒng)一性，我的建議是不論多簡(jiǎn)單的流程都跑完整個(gè)閉環(huán)，形成代碼的統(tǒng)一，方便后期管理，在我的組件里只允許出現(xiàn) dispatch 和 mapGetters，其余的流程都在名為 store 的 vuex 文件夾里進(jìn)行。

基于上面一條，說(shuō)下每個(gè)過(guò)程里面要做什么，前后端數(shù)據(jù)一定會(huì)有不一致的地方，或是數(shù)據(jù)結(jié)構(gòu)，或是字段命名，那么究竟應(yīng)該在哪一步處理數(shù)據(jù)轉(zhuǎn)換的邏輯呢？有人會(huì)說(shuō)其實(shí)哪一步都可以實(shí)現(xiàn)，其實(shí)不然，我的建議如下

1. 在發(fā) dispatch 之前就處理好組件內(nèi)需要傳的參數(shù)的數(shù)據(jù)結(jié)構(gòu)和字段名
2. 到了 action 允許我們做的事情很多，因?yàn)檫@部支持異步，支持 state, rootState, commit, dispatch, getters，由此可見責(zé)任重大，首先如果后端需要部分其他 module 里面的數(shù)據(jù)，要通過(guò) rootState 取值再整合到原有數(shù)據(jù)上，下一步發(fā)出請(qǐng)求,建議（async await + axios），拿到數(shù)據(jù)后進(jìn)行篩選轉(zhuǎn)換，再發(fā)送 commit 到 mutation
3. 這一步是將轉(zhuǎn)換后的數(shù)據(jù)更新到 state 里，可能會(huì)有數(shù)據(jù)分發(fā)的過(guò)程（傳進(jìn)一個(gè) object 改變多個(gè) state 中 key 的 value），可以轉(zhuǎn)換數(shù)據(jù)結(jié)構(gòu)，但是盡量不做字段轉(zhuǎn)換，在上一步做
4. 此時(shí)的 store 已經(jīng)更新，使用 getter 方法來(lái)取值，token: state => state.token，單單的取值，盡量不要做數(shù)據(jù)轉(zhuǎn)換，需要轉(zhuǎn)換的點(diǎn)在于多個(gè)地方用相同的字段，但是結(jié)構(gòu)不同的情況（很少出現(xiàn)）。
5. 在組件里用 mapGetters 拿到對(duì)應(yīng)的 getter 值。

打包優(yōu)化

上面說(shuō)了代碼方面的規(guī)范和優(yōu)化，下面說(shuō)下重點(diǎn)的打包優(yōu)化，前段時(shí)間打包的 vender bundle 足足 1.4M，app bundle 也有 270K，app bundle 可以通過(guò)組件懶加載解決，vender 包該怎么解決？

有人會(huì)質(zhì)疑是不是沒壓縮或依賴包沒去重，其實(shí)都做了就是看到的 1.4M。

解決方法很簡(jiǎn)單，打包 vender 時(shí)不打包 vue、vuex、vue-router、axios 等，換用國(guó)內(nèi)的 bootcdn 直接引入到根目錄的 index.html 中。

例如：

<script src="http://cdn.bootcss.com/vue/2.2.5/vue.min.js"></script> 
<script src="http://cdn.bootcss.com/vue-router/2.3.0/vue-router.min.js"></script> 
<script src="http://cdn.bootcss.com/vuex/2.2.1/vuex.min.js"></script> 
<script src="http://cdn.bootcss.com/axios/0.15.3/axios.min.js"></script> 

在 webpack 里有個(gè) externals，可以忽略不需要打包的庫(kù)

externals: { 
 'vue': 'Vue', 
 'vue-router': 'VueRouter', 
 'vuex': 'Vuex', 
 'axios': 'axios' 
} 

此時(shí)的 vender 包會(huì)非常小，如果不夠小還可以拆分其他的庫(kù)，此時(shí)增加了請(qǐng)求的數(shù)量，但是遠(yuǎn)比加載一個(gè) 1.4M 的 bundle 快的多。

總結(jié)

本文談的優(yōu)化可以解決部分性能問(wèn)題，實(shí)際開發(fā)細(xì)節(jié)很多，總之按著規(guī)范寫代碼，團(tuán)隊(duì)的編碼風(fēng)格盡量統(tǒng)一，處理細(xì)節(jié)上多加思考，大部分性能問(wèn)題都能迎刃而解。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論