我是如何讓公司後臺管理系統面目一新的(上) -性能優化

時間  2019-11-05
標籤 如何 公司 後臺 管理 系統 面目一新 性能 優化 欄目 系統性能 简体版
原文   原文鏈接

寫在前面

立刻到了金三銀四的時間，不少公司開啓了今年第一輪招聘的熱潮，雖然說今年是互聯網的寒冬，可是隻要對技術始終抱有熱情以及有過硬的實力，即便是寒冬也不會阻撓你前進的步伐。在面試的時候，每每在二面，三面的時面試官會結合你的簡歷問一些關於你簡歷上項目的問題，而如下這個問題在不少時候都會被問到javascript

在這個項目中你有遇到什麼技術難點，你是怎麼解決的？css

其實這個問題旨在瞭解你在遇到問題的時候的解決方法，畢竟如今前端技術領域廣，各類框架和組件庫層出不窮，而業務需求上有時紛繁複雜，觀察一個程序員在面對未知問題時是如何處理的，這個過程相對於只出一些面試題來考面試者更能瞭解面試者實際解決問題的能力html

而不少人會說個人項目不大，並無什麼難點，或者說並不算難點，只能說是一些坑，只要google一下就能解決，實在不行請教我同事，這些問題並無困擾我好久。其實我也遇到過相同的狀況，和麪試官說如何經過搜索引擎解決這些坑的吧不太好，讓面試官認爲你只是一個API Caller，可是又沒有什麼值得一談的項目難點前端

個人建議是，若是沒有什麼能夠深聊的技術難點，不妨在平常開發過程當中，試着封裝幾個經常使用的組件，同時嘗試分析項目的性能瓶頸，尋找一些優化的方案，一樣也能讓面試官對你有一個總體的瞭解vue

在這篇文章中，我會分享在我目前公司的項目裏，是如何在知足業務需求的基礎上，讓整個系統面目一新的過程java

技術棧是Vue + Element的單頁面應用node

起源

在我剛入職的那會，編碼能力不怎麼好，加上以前離職的前端技術棧是React，接手這個Vue項目的時候，代碼高度的耦合，而那個時候由於能力有限，也只是在他的基礎上繼續開發，好在接手的時候開發進度也只是剛剛開始，所以在幾個月後的某一天，我作了一個決定：準備把整個項目重寫webpack

得益於整個後臺管理系統都是我獨立開發的，項目的不足點我都深有體會，而且修改的時候可以更加的自由，剛好在那段時間看了花褲衩的vue-element-admin，我決定新開一個工程把以前的代碼所有重寫ios

項目結構

以前我有打算基於Webpack4本身寫個腳手架用來打包文件，可是那段時間恰好Vue-cli3剛剛發佈正式版而且也是基於Webpack4封裝的，因而想了一下還決定使用新的Vue-cli3腳手架搭建，最後我將項目分爲如下層級nginx

├─api                                 //api接口
├─assets                              //項目運行時使用到的圖片和靜態資源
├─components                          //組件
│  ├─BaseEllipsis                     //業務組件 (Base開頭都是全局組件)
│  ├─BasePagination                   //分頁器組件   
│  ├─BaseIcon                         //svg圖標組件
│  ├─BaseToggle                       //業務組件
│  ├─BaseTable                        //表格組件
│  ├─FormPanel                        //業務組件(Form開頭是圍繞表單相關的小組件)
│  ├─TableOptions                     //業務組件(Table開頭是圍繞表格相關的小組件)
│  ├─TheBreadcrumb                    //麪包屑組件(The開頭是每一個頁面組件只會引入一次的無狀態組件)
|  ├─TheSidebar                       //側邊欄組件
│  ├─TransitionSildeDown              //業務組件(Transition開頭是動畫組件)
│  └─index.js                         //全局組件自動註冊的腳本
│  
├─directives                          //自定義指令
├─element                             //elementui
├─errorLog                            //錯誤捕獲
├─filters                             //全局過濾器
├─icons                               //svg圖標存放文件夾
├─interface                           //TypeScript接口
├─mixins                              //局部混入
├─router                              //vue-router
│  ├─modules                      
│  └─index.js           
├─store                                //vuex
│  ├─modules                      
│  └─index.js                      
├─style                                //全局樣式/局部頁面可複用的樣式
├─util                                //公共的模塊(axios,cookie封裝,工具函數)
├─vendor                              //類庫文件
└─views                               //頁面組件(全部給用戶顯示的頁面)
複製代碼

一個良好的項目分層在業務迭代的時候可以快速找到對應的模塊進行修改，而不是在茫茫的代碼海中找到其中的某一行代碼

性能優化

在我重寫整個系統以前，每次打包都會花費好幾分鐘的時間，而且打包後的項目超過了17M

然而在我優化系統以後，打包後的體積只有2M，縮小了8倍

這裏我從如下4個方面分享一下我在項目中是如何改善系統的性能，讓系統"步履如飛"的

  • 網絡請求相關
  • 構建相關
  • 靜態資源優化
  • 編碼相關

網絡請求相關

這部分旨在實現需求的前提下儘可能減小http請求的開銷，或者減小響應時間

CDN

將第三方的類庫放到CDN上，可以大幅度減小生產環境中的項目體積，另外CDN可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上

另外由於CDN和服務器的域名通常不是同一個，能夠緩解同一域名併發http請求的數量限制,有效分流以及減小多餘的cookie的發送（CDN上面的靜態資源請求時不須要攜帶任何cookie）

通俗的來講就是使用CDN會必定程度上提高項目中的靜態文件的傳輸速度，在vue-cli3中能夠經過externals配置項，將第三方的類庫的引用地址從本地指向你提供的CDN地址

externals只適用於ES Module的默認導入

這裏經過環境變量來判斷生產環境才啓用CDN，除了須要開啓CDN外，你還須要在index.html注入CDN的域名，因此我這裏經過html-webpack-plugin根據cdn域名動態的注入script標籤，同時須要在index.html中經過模版的語法聲明循環的數組和注入的元素

打包前的index.html:

打包後的index.html:

能夠看到經過這個插件能夠將cdn域名動態的注入到打包後的index.html中

還有一點要注意的是，externals對象的屬性爲你引入包的名字，而屬性值是對應的全局變量名稱（CDN引入的類庫文件會自動掛載到window對象下面，而掛載時的屬性名須要去對應的CDN在源碼中尋找，通常在開頭行都會有聲明,除此以外導入還有困難的還能夠看下這篇博客webpack externals 深刻理解）

這裏仍是建議儘可能放到公司專用的CDN上，不推薦使用公共的CDN，由於容易掛，生產環境仍是以穩定爲主吧

合理的緩存策略

將長時間不會改變的第三方類庫或者靜態資源設置爲強緩存,將max-age設置爲一個很是長的時間,再將訪問路徑加上哈希達到哈希值變了之後保證獲取到最新資源(vue-cli3會自動構建,本身搭建的webpack腳手架須要自行配置contentHash,chunkHash)

CDN上的緩存策略,能夠看到max-age的值很是大,這樣下次訪問就只會讀取本地磁盤/內存中緩存的資源:

對於index.html和一些圖片等多媒體資源,能夠選擇協商緩存（max-age<=0,Last-Modified,ETag）,保證返回服務器最新的資源

一個好的緩存策略,有助於減輕服務器的壓力,而且顯著的提高用戶的體驗

gzip

爲你的文件開啓gzip壓縮是一個不錯的選擇，一般開啓gzip壓縮可以有效的縮小傳輸資源的大小，若是你的項目是用nginx做爲web服務器的話，只需在nginx的配置文件中配置相應的gzip選項就可讓你的靜態資源服務器開啓gzip壓縮

#開啓和關閉gzip模式
    gzip on;
    #gizp壓縮起點，文件大於1k才進行壓縮
    gzip_min_length 1k;
    # gzip 壓縮級別，1-9，數字越大壓縮的越好，也越佔用CPU時間
    gzip_comp_level 6;
    # 進行壓縮的文件類型。
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript ;
    #nginx對於靜態文件的處理模塊，開啓後會尋找以.gz結尾的文件，直接返回，不會佔用cpu進行壓縮，若是找不到則不進行壓縮
    gzip_static on
    # 是否在http header中添加Vary: Accept-Encoding，建議開啓
    gzip_vary on;
    # 設置gzip壓縮針對的HTTP協議版本
    gzip_http_version 1.1;
複製代碼

可是咱們這裏要說的是前端輸出gzip文件，利用compression-webpack-plugin讓webpack在打包的時候輸出.gz後綴的壓縮文件

這樣不須要服務器主動壓縮咱們就已經能夠獲得gzip文件，在上面的nginx配置項中能夠發現這一行

#nginx對於靜態文件的處理模塊，開啓後會尋找以.gz結尾的文件，直接返回，不會佔用cpu進行壓縮，若是找不到則不進行壓縮
    gzip_static on
複製代碼

只要把.gz的文件放到服務器上，開始gzip_static就可讓服務器優先返回.gz文件，在面對高流量時，也能必定程度減輕對服務器的壓力，屬於用空間來換時間（.gz文件會額外佔有服務器的空間）

資源嗅探

對於現代瀏覽器來講，能夠給link標籤添加preload,prefetch,dns-prefetch屬性

preload

對於SPA應用來講,當瀏覽器解析完script腳本纔會生成DOM節點,若是你的項目中沒有使用服務端渲染的話且須要加載一個比較耗時的首屏圖片時,能夠考慮將這個首屏圖片放在preload標籤中讓瀏覽器預先請求並加載執行,這樣當script腳本執行完畢後就會瞬間加載圖片(不然須要等腳本執行完畢後再向後臺請求圖片)

另外使用preload預加載首屏須要的css樣式也是一個不錯的選擇,相似的庫有critical

沒有使用preload

使用preload

經過Waterfall能夠看到這個webp圖片須要等到腳本加載完以後纔回去請求,若是這個圖片比較大就會浪費沒必要要的時間

在工程中，利用一些preload的webpack插件能夠很方便的給打包後的index.html注入預加載的資源標籤，有興趣的朋友能夠試着搜索一下相關的插件

prefetch

prefetch可讓瀏覽器提早加載下個頁面可能會須要的資源,vue-cli3默認會給全部懶加載的路由添加prefetch屬性，這樣能夠在你訪問使用到懶加載的路由頁面時可以得到更快的加載速度

preload和prefetch的區別在於，preload的資源會和頁面須要的靜態資源並行加載，而prefetch則會等到瀏覽器加載完必要的資源後，在空閒時間加載被標記爲prefetch的資源

dns-prefetch

dns-prefetch可讓瀏覽器提早對域名進行解析，減小DNS查找的開銷,若是你的靜態資源和後端接口不是同一個服務器的話，能夠將考慮你後端的域名放入link標籤加入dns-prefetch屬性

京東首頁也使用到了dns-prefetch技術

http2

http2從2015年問世以來已經走過了4個年頭，現在在國內也有超過50%的覆蓋率，得益於http2的分幀傳輸，它可以極大的減小http(s)請求開銷

http2和http1.1的性能差別對比

若是系統首屏同一時間須要加載的靜態資源很是多，可是瀏覽器對同一域名的tcp鏈接數量是有限制的（chrome爲6個）超過規定數量的tcp鏈接，則必需要等到以前的請求收到響應後才能繼續發送，而http2則能夠在一個tcp鏈接中併發多個請求沒有限制，在一些網絡較差的環境開啓http2性能提高尤其明顯

這裏極力推薦在支持https協議的服務器中使用http2協議,能夠經過web服務器Nginx配置，或是直接讓服務器支持http2

nginx開啓http2很是簡單,在nginx.conf中只需在原來監聽的端口後面加上http2就能夠了,前提是你的nginx版本不能低於1.95，而且已經開啓了https

listen 443 ssl http2;
複製代碼

在network中經過protocol能夠查看到當前的資源是經過哪一個版本的http協議傳輸的

h2表明http2

構建相關

構建方面經過合理的配置構建工具，達到減小生產環境的代碼的體積，減小打包時間，縮短頁面加載時間

路由懶加載

傳統的路由組件是經過import靜態的打包到項目中，這樣作的缺點是由於全部的頁面組件都打包在同一個腳本文件中，致使生產環境下首屏由於加載的代碼量太多會有明顯的卡頓（白屏）

經過import()使得ES6的模塊有了動態加載的能力，讓url匹配到相應的路徑時，會動態加載頁面組件，這樣首屏的代碼量會大幅減小，webpack會把動態加載的頁面組件分離成單獨的一個chunk.js文件

固然懶加載也有缺點，就是會額外的增長一個http請求，若是項目很是小的話能夠考慮不使用路由懶加載

預渲染

因爲瀏覽器在渲染出頁面以前，須要先加載和解析相應的html,css和js文件，爲此會有一段白屏的時間，如何儘量的減小白屏對用戶的影響，目前我選擇的是在html模版中，注入一個loading動畫，這裏我拿D2-Admin中的loading動畫舉例

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <link rel="icon" href="<%= BASE_URL %>icon.ico">
    <title><%= VUE_APP_TITLE %></title>
    <style>
      html, body, #app { height: 100%; margin: 0px; padding: 0px; }
      .d2-home { background-color: #303133; height: 100%; display: flex; flex-direction: column; }
      .d2-home__main { user-select: none; width: 100%; flex-grow: 1; display: flex; justify-content: center; align-items: center; flex-direction: column; }
      .d2-home__footer { width: 100%; flex-grow: 0; text-align: center; padding: 1em 0; }
      .d2-home__footer > a { font-size: 12px; color: #ABABAB; text-decoration: none; }
      .d2-home__loading { height: 32px; width: 32px; margin-bottom: 20px; }
      .d2-home__title { color: #FFF; font-size: 14px; margin-bottom: 10px; }
      .d2-home__sub-title { color: #ABABAB; font-size: 12px; }
    </style>
  </head>
  <body>
    <noscript>
      <strong>
        很抱歉，若是沒有 JavaScript 支持，D2Admin 將不能正常工做。請啓用瀏覽器的 JavaScript 而後繼續。
      </strong>
    </noscript>
    <div id="app">
      <div class="d2-home">
        <div class="d2-home__main">
          <img
            class="d2-home__loading"
            src="./image/loading/loading-spin.svg"
            alt="loading">
          <div class="d2-home__title">
            正在加載資源
          </div>
          <div class="d2-home__sub-title">
            初次加載資源可能須要較多時間 請耐心等待
          </div>
        </div>
        <div class="d2-home__footer">
          <a
            href="https://github.com/d2-projects/d2-admin"
            target="_blank">
            https://github.com/d2-projects/d2-admin
          </a>
        </div>
      </div>
    </div>
  </body>
</html>

複製代碼

在打包完成後，在這個index.html下方還會注入頁面的腳本，當用戶訪問你的項目時，腳本尚未執行，可是能夠顯示loading動畫，由於它是直接注入在html中的，等到腳本執行完畢後，Vue會新生成一個app的節點而後將舊的同名節點刪除，這樣能夠有效的過渡白屏的時間

loading動畫只是一個讓用戶感知到你程序正在啓動的效果，只是一個靜態頁面沒有任何的功能

另外預渲染還可使用服務端渲染（SSR），經過後端輸出一個首頁的模版，或者使用骨架屏的方案，這裏本人沒有深刻的瞭解過，有興趣的朋友能夠去實踐一下

升級到最新的webpack版本

webpack4相對於webpack3來講在打包優化方面性能提高仍是比較明顯的，若是以爲本身配置腳手架比較複雜的話，可使用vue-cli3來構建你的項目，一樣是基於webpack4搭建的

DllPlugin

當沒有一個穩定的CDN時，使用DllPlugin這個webpack插件一樣能夠將類庫從業務代碼中分離出去，其原理是預先將類庫文件打包，隨後建立一個關聯表，在業務代碼依賴第三方類庫時，會直接去關聯表中獲取已經打包好的類庫文件。這樣作的好處在於由於業務代碼會經常須要打包上線，而第三方類庫基本不會改變，因此每次打包能夠跳過這些類庫文件，減小沒必要要的重複打包

DllPlugin是一個webpack內置的插件，無需安裝，可是要讓打包後的index.html注入這些打包後第三方類庫，須要額外安裝add-asset-html-webpack-plugin插件

當你須要在index.html中注入多個類庫時，須要實例化屢次add-asset-html-webpack-plugin，這裏咱們能夠利用nodejs的fs模塊，遍歷DllPlugin打包後的目錄，根據類庫的數量決定須要生成多少個實例，很是的靈活，具體的配置項能夠查看我底部的連接

合理使用第三方庫

若是項目中有一些日期操做的需求，不妨將目光從moment轉移到day，相對於笨重的moment，它只有2kb，day和moment的api徹底同樣，而且中文文檔也比較友好

另外對於lodash這類的庫若是隻須要部分功能，則只要引入其中一部分，這樣webpack在treeshaking後在生產環境也只會引入這一部分的代碼

對於UI庫（element-ui）打包後的體積也會很是大，儘可能使用按需加載，官方文檔上也有詳細教程

element-ui的壓縮後的體積居然是Vue的十倍

經常使用的路徑建立文件別名

給經常使用的模塊路徑建立一個別名是一個不錯的選擇，能夠減小模塊查找時耗費的時間，項目越大收益也就越明顯

vue-cli3中的配置和使用方法(webpack鏈式調用文檔)

使用可視化工具分析打包後的模塊體積

我經過webpack-bundle-analyzer這個插件在每次打包後可以更加直觀的分析打包後模塊的體積，再對其中比較大的模塊進行優化

這是我在優化前的各模塊體積:

由於業務需求,要求前端導出pdf和excel文件,我這裏引入了xlsx和pdf.js這2個包,可是打包後經過可視化工具發現光着2個文件就佔了一半的項目體積,另外elementui和moment也很是的大

這是優化後經過可視化工具觀察到的各模塊體積,經過將這些類庫放到CDN上或者使用dllPlugin將類庫和業務文件分離,能夠看到沒有明顯特別大的模塊了

靜態資源優化

這部分旨在減小請求一些圖片資源所形成的影響

圖片懶加載

若是你的系統是一個偏展現的項目須要給用戶展現大量圖片，是否啓用圖片懶加載多是你須要考慮的一個點，不在用戶視野中的圖片是沒有必要加載的，圖片懶加載經過讓圖片先加載成一張統一的圖片，再給進入用戶視野的圖片替換真正的圖片地址，能夠同一時間減小http請求開銷，避免顯示圖片致使的畫面抖動，提升用戶體驗

下面我提供2種圖片懶加載的思路，這2個方案最終都是用將佔位的圖片替換成真正的圖片，而後給img標籤設置一個自定義屬性data-src存放真正的圖片地址，src存放佔位圖片的地址

getBoundingClientRect

DOM元素包含一個getBoundingClientRect方法，執行該方法返回當前DOM節點相關的CSS邊框集合

其中有一個top屬性表明當前DOM節點距離瀏覽器窗口頂部的高度，只需判斷top值是否小於當前瀏覽器窗口的高度（window.innerHeight），若小於說明已經進入用戶視野，而後替換爲真正的圖片便可

另外使用getBoundingClientRect做圖片懶加載須要注意3點

  1. 由於須要監聽scroll事件，不停的判斷top的值和瀏覽器高度的關係，請對監聽事件進行函數節流
  2. 當屏幕首次渲染時，不會觸發scroll事件，請主動調用一次事件處理程序，不然若用戶不滾動則首屏的圖片會一直使用懶加載的默認圖片
  3. 當全部須要懶加載的圖片都被加載完，須要移除事件監聽，避免沒必要要的內存佔用

IntersectionObserver

IntersectionObserver做爲一個構造函數，傳入一個回調函數做爲參數，生成一個實例observer，這個實例有一個observe方法用來觀察指定元素是否進入了用戶的可視範圍，隨即觸發傳入構造函數中的回調函數

同時給回調函數傳入一個entries的參數，記錄着這個實例觀察的全部元素的一些閾值信息（對象），其中intersectionRatio屬性表示圖片進入可視範圍的百分比，大於0表示已經有部分進入了用戶視野

此時替換爲真實的圖片，而且調用實例的unobserve將這個img元素從這個實例的觀察列表的去除

實例代碼

對懶加載還有迷惑的同窗我這裏寫了一個DEMO能夠參考一下實現的方式源代碼

結論

這2種的區別在於監聽的方式，我我的更推薦使用Intersection Observer，由於經過監聽scroll事件開銷比較大，而讓將這個工做交給另外一個線程異步的去監聽開銷會小不少，可是它的缺點是一些老版本的瀏覽器可能支持率不高，好在社區有polyfill的方案

或者能夠直接使用第三方的組件庫vue-lazyload

使用svg圖標

相對於用一張圖片來表示圖標，svg擁有更好的圖片質量，體積更小，而且不須要開啓額外的http請求，svg是一個將來的趨勢，阿里的圖標庫iconfont支持導出svg格式的圖標，可是在項目中須要封裝一個支持svg的組件，具體封裝的教程能夠參考花褲衩的文章這裏就很少贅述了手摸手，帶你優雅的使用 icon,或者能夠參考個人github

使用webp圖片

webp圖片最初在2010年發佈，目標是減小文件大小，但達到和JPEG格式相同的圖片質量，但願可以減小圖片檔在網絡上的發送時間。webp圖片無損比png圖片無損的平均體積要小 20%~40%，而且圖片質量用肉眼看幾乎沒什麼差異

webp圖片的缺點是兼容性並非那麼的好，在can l use 上查到webp圖片的支持率並非那麼的理想。可是咱們仍能夠在支持webp圖片的瀏覽器中使用它，而在不支持的瀏覽器提供png圖片

這裏須要使用到響應式圖片,HTML提供了picture標籤讓咱們能夠在不一樣設備中使用不一樣的圖片格式

MDN:

HTML 元素經過包含零或多個 元素和一個 元素來爲不一樣的顯示/設備場景提供圖像版本。瀏覽器會選擇最匹配的子 元素，若是沒有匹配的，就選擇 元素的 src 屬性中的URL。而後，所選圖像呈如今元素佔據的空間中。

在工程中咱們能夠這樣使用

picture標籤包裹2個source標籤,一個提供webp圖片,經過srcset屬性讓瀏覽器從上到下選擇能夠支持的圖片格式,若是瀏覽器不支持webp圖片會只使用第二個source,會回退到png圖片,若是瀏覽器不支持picture標籤,會使用底部的img標籤,一樣也會生成一個png圖片

picture標籤的瀏覽器支持率,相對於webp要好不少（注意底部的img標籤不管如何都要有，不然就算支持webp圖片也沒法渲染出圖片）

壓縮圖片

對於一些png圖片可能質量會很是的高，可是對於Web平臺來講，用戶可能並不care圖片的畫質問題，可是若是加載圖片致使頁面出現卡頓那就顯得得不償失了，咱們能夠考慮將一些畫質較高的圖片作壓縮處理，我這裏使用tinypng幫我壓縮圖片，一樣可以保證在肉眼幾乎分辨不出區別的狀況下，提供一個體積較小的圖片，若是有其餘好的壓縮軟件也能夠推薦給我

另外有一個圖片壓縮的 loader image-webpack-loader，在用戶肉眼分辨不清的狀況下必定程度上壓縮圖片

編碼相關

編碼這方面主要是減小對DOM的訪問，減小瀏覽器的重排/重繪，訪問DOM是很是昂貴的操做，由於會涉及到2個不一樣的線程交互（JS線程和UI渲染線程）而且DOM自己又是一個很是笨重的對象，這裏給出幾個建議

  • 若是有須要動態建立DOM的需求，能夠建立一個文檔碎片(DocumentFragment)，在文檔碎片中操做由於不是在當前文檔流不會引發重排/重繪，最後再一次性插入DOM節點

  • 避免頻繁獲取視圖信息(getBoundingClientRect,clientWidth,offsetWidth),當發生重排/重繪操做時瀏覽器會維護一個隊列，等到超過了最大值或過了指定時間（1000ms/60 = 16.6ms）纔會去清空隊列一次性執行操做，這樣能夠節省性能，而獲取視圖信息會馬上清空隊列執行重排/重繪

  • 高頻的監聽事件使用函數防抖/節流（可使用lodash庫的throttle函數，可是推薦先搞懂原理）

  • 特效能夠考慮單獨觸發渲染層（CSS3的transform會觸發渲染層），動畫可使用絕對定位脫離文檔流

開發過程當中小技巧

使用require.context這個webpack的api能夠避免每次引入一個文件都須要顯式的用import導入，它能夠掃描你指定的文件，而後所有導入到指定文件，能夠用在

  • vue-router的路由自動導入
  • vuex的模塊自動導入
  • svg圖標的自動導入
  • 全局組件的自動導入

vuex：

這樣在建立一個新的模塊時,不須要在index.js中用import引入,在modules中再聲明一遍了

全局組件和svg圖標：

避免了每建立一個全局組件都須要引入,在調用一次Vue.component的過程,而當加載到Svg組件會自動掃描icons文件夾,將全部svg圖標導入進來

有興趣的朋友能夠看看我另外一篇介紹這個api的博客

源代碼

部分優化的方案放在個人github上,有興趣能夠看看

源碼地址

下篇在這裏:

我是如何讓公司後臺管理系統面目一新的（下）-封裝組件

參考資料

vue-element-admin

D2 Admin

嗨，送你一張Web性能優化地圖

vue-cli3 項目從搭建優化到docker部署

前端性能優化不徹底指北

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程