【前端性能優化】02--vue性能優化

1、template

語義化標籤，避免亂嵌套，合理命名屬性等等標準推薦的東西就不談了。

模板部分幫助咱們展現結構化數據，vue 經過數據驅動視圖，主要注意一下幾點

1. v-show，v-if 用哪一個？在我來看要分兩個維度去思考問題，第一個維度是權限問題，只要涉及到權限相關的展現無疑要用 v-if ，第二個維度在沒有權限限制下根據用戶點擊的頻次選擇，頻繁切換的使用 v-show ，不頻繁切換的使用 v-if ，這裏要說的優化點在於減小頁面中 dom 總數，我比較傾向於使用 v-if ，由於減小了 dom 數量，加快首屏渲染，至於性能方面我感受肉眼看不出來切換的渲染過程，也不會影響用戶的體驗。
2. 不要在模板裏面寫過多的表達式與判斷 v-if="isShow && isAdmin && (a || b)" ，這種表達式雖然說能夠識別，可是不是長久之計，當看着不舒服時，適當的寫到 methods 和 computed 裏面封裝成一個方法，這樣的好處是方便咱們在多處判斷相同的表達式，其餘權限相同的元素再判斷展現的時候調用同一個方法便可。

3. 循環調用子組件時添加 key。

4. • key 能夠惟一標識一個循環個體，可使用例如 item.id 做爲 key，假如數組數據是這樣的 ['a' , 'b', 'c', 'a'],使用 :key="item" 顯然沒有意義，更好的辦法就是在循環的時候 (item, index) in arr ，而後 :key="index" 來確保 key 的惟一性。

• 在列表數據進行遍歷渲染時，給每一項item設置惟一key值，會方便vuejs內部機制精準找到該條列表數據。當state更新時，新的狀態值和舊的狀態值對比，較快地定位到diff。

2、style

1. 將樣式文件放在 vue 文件內仍是外？討論起來沒有意義，重點是按模塊劃分，個人習慣是放在 vue 文件內部，方便寫代碼是在同一個文件裏跳轉上下對照，不管內外建議加上 <style scoped> 將樣式文件鎖住，目的很簡單，再好用的標準也避免不了多人開發的麻煩，約定命名規則也可能會衝突，鎖定區域後儘可能採用簡短的命名規則，不須要 .header-title__text 之類的 class，直接 .title 搞定。
2. 爲了和上一條做區分，說下全局的樣式文件，全局的樣式文件，儘可能抽象化，既然不在每個組件裏重複寫，就儘可能通用，這部分抽象作的越好說明你的樣式文件體積越小，複用率越高。建議將複寫組件庫如 Element 樣式的代碼也放到全局中去。
3. 不使用 float 佈局，以前看到不少人封裝了 .fl -- float: left 到全局文件裏去，而後又要 .clear，如今的瀏覽器還不至於弱到非要用 float 去兼容，徹底能夠 flex，grid 兼容性通常，功能其實 flex 佈局均可以實現，float 會帶來佈局上的麻煩，用過的都知道。
4. 至於其餘通用的規範這裏不贅述。

3、script

這部分也是最難優化的點，說下我的意見吧。

1. 多人開發時儘可能保持每一個組件 export default {} 內的方法順序一致，方便查找對應的方法。我的習慣 data、props、鉤子、watch、computed、components。
2. data 裏要說的就是初始化數據的結構儘可能詳細，命名清晰，簡單易懂，避免無用的變量，isEditing 實際能夠表明兩個狀態，true 或 false，不要再去定義 notEditing 來控制展現，徹底能夠在模板裏 {{ isEditing ? 編輯中 : 保存 }}
3. props 父子組件傳值時儘可能 :width="" :heigth="" 不要 :option={} ，細化的好處是隻傳須要修改的參數，在子組件 props 里加數據類型，是否必傳，以及默認值，便於排查錯誤，讓傳值更嚴謹。
4. 鉤子理解好生命週期的含義就好，什麼時間應該請求，什麼時間註銷方法，哪些方法須要註銷。簡單易懂，官網都有寫。
5. methods 中每個方法必定要簡單，只作一件事，儘可能封裝可複用的簡短的方法，參數不易過多。若是十分依賴 lodash 開發，method 看着會簡潔許多，代價就是總體的 bundle 體積會大，假如項目僅僅用到小部分方法能夠局部引入 loadsh，不想用 lodash 的話能夠本身封裝一個 util.js 文件
6. watch 和 computed 用哪一個的問題看官網的例子，計算屬性主要是作一層 filter 轉換，切忌加一些調用方法進去，watch 的做用就是監聽數據變化去改變數據或觸發事件如 this.$store.dispatch('update', { ... })
7. 減小watch的數據。當組件某個數據變動後須要對應的state進行變動，就須要對另外的組件進行state進行變動。可使用watch監聽相應的數據變動並綁定事件。當watch的數據比較小，性能消耗不明顯。當數據變大，系統會出現卡頓，因此減小watch的數據。其它不一樣的組件的state雙向綁定，能夠採用事件中央總線或者vuex進行數據的變動操做。

​

4、組件優化

在項目開發過程之中，若是把全部的組件的佈局寫在一個組件中，當數據變動時，因爲組件代碼比較龐大，vue 的數據驅動視圖更新會比較慢，形成渲染過慢，也會形成比較差的體驗效果。因此要把組件細分，好比一個組件，能夠把整個組件細分紅輪播組件、列表組件、分頁組件等。

組件細化是有必要的，那組件細化到什麼程度算是合理，還要因項目大小而異，小型項目能夠簡單幾個組件搞定，甚至不用 vuex，axios 等等，若是規模較大就要細分組件，越細越好，包括佈局的封裝，按鈕，表單，提示框，輪播等，推薦看下 Element 組件庫的代碼，沒時間寫這麼詳細能夠直接用 Element 庫，分幾點進行優化：

1. 組件有明確含義，只處理相似的業務。複用性越高越好，配置性越強越好。
2. 本身封裝組件仍是遵循配置 props 細化的規則。
3. 組件分類，我習慣性的按照三類劃分，page、page-item 和 layout，page 是路由控制的部分，page-item 屬於 page 裏各個佈局塊如 banner、side 等等，layout 裏放置多個頁面至少出現兩次的組件，如 icon, scrollTop 等

​

5、組件的異步加載（按需加載組件）

在平時的demo中，可能不會碰見這個需求。當頁面不少，組件不少的時候，SPA頁面在首次加載的時候，就會變的很慢。這是由於vue首次加載的時候把可能一開始看不見的組件也一次加載了，這個時候就須要對頁面進行優化，就須要異步組件了。

在路由index.js裏（路徑： src/router/index.js ），經過require方式或者import()方式動態加載組件。像下面這樣：

{
    path: '/home',
    name: 'home',
    component:require('@views/home').default
}

或者

{
    path: '/home',
    name: 'home',
    component:() => import('@views/home')
}

6、vue-router 和 vuex 優化

vue-router 除了切換路由，用的最多的是處理權限的邏輯，關於權限的控制這裏不贅述，相關 demo 和文章有許多，那麼說到優化，值得一提的就是 組件懶加載

中文官網連接如上，例子以下

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 三個組件打包進了名爲 group-foo 的 chunk 文件，固然啦是 js 文件

其他部分正常寫就能夠，在網站加載時會自動解析須要加載哪一個 chunk，雖然分別打包的整體積會變大，可是單看請求首屏速度的話，快了好多。
​
vuex 面臨的問題和解決方案有幾點

1. 當網站足夠大時，一個狀態樹下，根的部分字段繁多，解決這個問題就要模塊化 vuex，官網提供了模塊化方案，容許咱們在初始化 vuex 的時候配置 modules。每個 module 裏面又分別包含 state 、action 等，看似是多個狀態樹，其實仍是基於 rootState 的子樹。細分後整個 state 結構就清晰了，管理起來也方便許多。
2. 因爲 vuex 的靈活性，帶來了編碼不統一的狀況，完整的閉環是 store.dispatch('action') -> action -> commit -> mutation -> getter -> computed，實際上中間的環節有的能夠省略，由於 API 文檔提供瞭如下幾個方法 mapState、mapGetters、mapActions、mapMutations，而後在組件裏能夠直接調取任何一步，仍是項目小想怎麼調用均可以，項目大的時候，就要考慮 vuex 使用的統一性，個人建議是不論多簡單的流程都跑完整個閉環，造成代碼的統一，方便後期管理，在個人組件裏只容許出現 dispatch 和 mapGetters，其他的流程都在名爲 store 的 vuex 文件夾裏進行。

3. 基於上面一條，說下每一個過程裏面要作什麼，先後端數據必定會有不一致的地方，或是數據結構，或是字段命名，那麼究竟應該在哪一步處理數據轉換的邏輯呢？有人會說其實哪一步均可以實現，其實否則，個人建議以下

   • 在發 dispatch 以前就處理好組件內須要傳的參數的數據結構和字段名
   • 到了 action 容許咱們作的事情不少，由於這部支持異步，支持 state, rootState, commit, dispatch, getters，因而可知責任重大，首先若是後端須要部分其餘 module 裏面的數據，要經過 rootState 取值再整合到原有數據上，下一步發出請求,建議（async await + axios），拿到數據後進行篩選轉換，再發送 commit 到 mutation
   • 這一步是將轉換後的數據更新到 state 裏，可能會有數據分發的過程（傳進一個 object 改變多個 state 中 key 的 value），能夠轉換數據結構，可是儘可能不作字段轉換，在上一步作
   • 此時的 store 已經更新，使用 getter 方法來取值，token: state => state.token，單單的取值，儘可能不要作數據轉換，須要轉換的點在於多個地方用相同的字段，可是結構不一樣的狀況（不多出現）。
   • 在組件裏用 mapGetters 拿到對應的 getter 值。

​

7、打包優化

上面說了代碼方面的規範和優化，下面說下重點的打包優化，前段時間打包的 vender bundle 足足 1.4M，app bundle 也有 270K，app bundle 能夠經過組件懶加載解決，vender 包該怎麼解決？

有人會質疑是否是沒壓縮或依賴包沒去重，其實都作了就是看到的 1.4M。

解決方法很簡單，打包 vender 時不打包 vue、vuex、vue-router、axios 等，換用國內的 bootcdn 直接引入到根目錄的 index.html 中。

例如：

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

在 webpack 裏有個 externals，能夠忽略不須要打包的庫

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

此時的 vender 包會很是小，若是不夠小還能夠拆分其餘的庫，此時增長了請求的數量，可是遠比加載一個 1.4M 的 bundle 快的多。