小型Web頁打包最佳化(下)

來源:互聯網
上載者:User

標籤:cdn   自己的   出錯   run   打包工具   哪些   搬運工   檔案   接受   

之前我們推送了一篇小型Web項目打包最佳化文章,(連結),我們使用了一段時間, 在這過程中我們也一直在思考, 怎麼能把結構做的更好。於是我們改造了一版, 把可以改進的地方和可能會出現的問題, 在這一版中進行了最佳化。小夥伴們, 有沒有迫不及待? 那好, 我們廢話少說, 進入正題^_^

一、背景

之前, 轉轉App端內有些Hybrid頁面和一些端外的落地頁, 一般是單個的一兩個小頁面, 不是所謂的大型的前端應用, 比較零散, 互動也比較簡單。如果用vue或react, 有點殺雞焉用宰牛刀的意思, 沒有必要, 而且業務代碼比架構代碼還少, 對頁面載入的效能來說, 效率也不高。

於是我們為了把這些頁面統一管理, 我們在自己的gitlab上建立一個項目, 作為這些小頁面的集合, 裡面有許多目錄, 每個目錄代表一個小項目。一切看似都很正常, 都很有序...

兩個月前, 我們組內發現, 這些頁面經曆了一年多的時間, 已經迭代了好多小項目, 由於規範不是很完善, 裡面的頁面也寫的五花八門, 尤其是打包構建工具, 有fis、有glup、還有webpack等。這無疑給後面接手的同學, 帶來了麻煩, 於是我們產生了第一版的統一。我們統一了打包工具的使用, 然後精簡了代碼, 最佳化了層級結構, 使每個目錄結構得到了統一, 形成了規範。

 

 

可是最近, 我們在思考, 雖然目錄結構統一了, 但是如果遇到了組件升級, 比如我們轉轉的JsBridge升級, 那麼要把每個項目的依賴都升級一遍, 這豈不是很頭疼的事。如果項目目錄超過20個, 那就要手動升級20個頁面, 帶來了麻煩不說, 而且還很容易出錯。所以, 操練起來吧, 讓我們一起來最佳化。

二、簡單介紹

1.原理圖

說到原理, 不得不先說下webpack, 這次的改造都是基於webpack來打包編譯的, webpack主要幫我們做了這些事, 也是webpack最最基本的功能, 如:

 

 

 眾所周知, webpack是全英文的文檔, 這裡給英文不好的小夥伴貼一個中文版的。是整個項目的拆解圖

 

 

2.項目結構

廢話少說, 大家都是程式猿, 先上代碼。本人在自己的github裡放了項目結構代碼, 後面以此為例, ZZDownload為眾多小項目的一個(例子)。為了方便大家查看, 把項目目錄結構如下, 具體請移步這裡!

 

 

三、使用方法和情境

1.如何使用

- 安裝

npm install

 

nodejs環境是前提, 我想大家應該沒有什麼疑問, 這個不做過多解釋, 你懂得~

- 配置

module.exports = {       "name": "ZZDownload",         "vendor": [‘es6-promise/auto‘, ‘axios‘, ‘mustache‘],       "pages": [{           "name": "Download",           "template": "/Download/Download.html",           "entry": "/Download/Download.js",           "output": "index.html"       }]};

  

每個src中的目錄, 可以稱之為一個獨立小項目。 每個小項目中, 需要有個此項目的配置, 即config.js。還是以ZZDownload為例, 見上面的配置, 可以是單個落地頁、也可以是多個頁面。配置在此不做過多闡述, 後面會有詳細解釋。

調試頁面可以使用

npm run dev 項目名

待頁面發開完成, 需要打包上線, 執行

npm run build 項目名
以我們git的例子來說, 我們就執行 **npm run build ZZDownload**。然後編譯產出的代碼就在根目錄的 **dist/ZZDownload** 裡。

**至於頁面內部的業務實現, 隨便你! **
**至於頁面內部的依賴架構, 隨便你! **
**至於頁面內部的目錄結構, 隨便你! **

我們就是這麼人性化, 業務代碼隨你DIY! 不干擾個人習慣, 我們只是代碼的編譯打包的搬運工!

2.哪些情況來使用

  • 減小了產出代碼的大小

用事實說話, 以上面的項目為例, 我做了一個轉轉的下載落地頁面ZZDownload。看了下dist產出的頁面, 一共75k。是不是顯而易見了, 整個頁面不到80k, 我想就算是2G的環境, 載入起來也不算很慢吧。

  • 不建議搭建複雜的單頁應用

說到這, 好多同學會問, 如果我們利用像React/Vue這樣的架構, 搭建整個項目, 每個小頁面是一個路由, 那不也能達到同樣的效果麼? 那麼升級jdk或者解決一些公用組件的問題, 不是也很方便麼?

其實是這樣, 短期看這樣貌似沒什麼問題, 但是考慮到一段時間以後, 有可能小頁面數量會很多, 那麼每當新增一個小頁面的時候, 需要編譯整個項目, 那個時候項目產出的代碼可不是幾十K的大小能解決的。而且只是新增了一個小頁面, 卻需要整包編譯和上線, 這對於項目內其他小頁面, 還是比較有風險的。

雖然我們對複雜單頁面也支援, 但是為了精簡產出代碼, 就沒有引入babel, 像React/Vue這種構建複雜應用的項目, 不用es6, 開發起來也並不順手, 對於強迫症的我, 還是挺不能接受的。並且複雜的頁面應用, 本身就會依賴很多庫或者外掛程式, 這也和我們為了精簡的出發點是相違背的。如果大家有複雜單頁應用的項目, 建議還是vue-cli比較來的方便, 也更快捷。

四、原理

1.代碼執行步驟

 

 

 

  • 我們對npm的命令, 進行了傳參, 項目名就是參數。
  • 將參數透傳到webpack裡, 並根據參數尋找src中對應目錄。
  • 讀取目錄內的config.js檔案, 根屬性包括name、vendor、pages, 分別對應項目名(後續可能會最佳化掉此參數, 只用目錄名和參數匹配)、公用依賴、頁面集合(多個頁面, 數組配多項)。
  • 通過遍曆config的各個屬性, config可以理解為一個大的參數集合, 遍曆的結果傳入webpack的entry和plugins屬性裡, 產生完整的webpack的配置。
  • 一切就緒之後, 就是webpack自己的編譯打包了。等待若干秒之後, 你就可以在dist裡看到產出的代碼啦!

2.參數說明

module.exports = {"name": "ZZDownload","vendor": [‘es6-promise/auto‘, ‘axios‘, ‘mustache‘],"pages": [{"name": "Download","template": "/Download/Download.html","entry": "/Download/Download.js","output": "index.html"   }]};

  

 

還是以上面的配置為例。

  • name: 為頁面名, 可以理解起到一個id的作用, 同一個項目中的多個頁面, name不能相同。
  • template: 頁面入口的模板, 就是產出頁面的html路徑
  • entry: 頁面入口的js檔案路徑
  • output: 產出頁面的檔案名稱
  • name: 為此項目的項目名, 需要與src裡的目錄相同, 用作webpack編譯的目錄, 後續考慮是否可以把此參數最佳化掉, 因為執行npm run的參數, 可以找到目錄。
  • vendor: 為此項目的公用依賴, 比如我們依賴的模板(如mustache)、發送請求(如axios)等, 都可以放在此處配置。
  • pages: 屬於頁面的集合, 如果多個頁面, 就配置數組多項。

PS: 上面配置為單個頁面, 多個頁面只要在pages數組裡配置多個項即可。每個入口需要分別有html和js的entry, 每個頁面也要產出的頁面名(即output)。整個項目的模組名為name, 總體的第三方功能依賴為vender。注意, 這裡的依賴, 是指每個小項目的依賴, 不是整個大項目的依賴。

五、總結

1.優勢

  • 依賴問題

目前所有項目的依賴得到了統一, 都依賴最外部的package.json的配置。即使有依賴升級, 只要修改package.json中的版本, 然後編譯一下就OK啦。

  • 產出代碼

每個項目的產出代碼, 都統一到根目錄的dist裡, dist中會根據src中的項目目錄進行分割, 並且一一對應。進入自己的產出項目目錄, 裡面有html檔案和static目錄, 然後分別部署到測試的伺服器和cdn就可以了。

  • 個人化頁面入口

此配置同時適用於單頁面和多頁面, 根據設定檔的入口而定。外部的webpack都是統一的, 只是每個項目需要自己的設定檔, 來個人化DIY。所以, 不管是你基於什麼技術站, vue/react或是早起的require/jquery, 統統一網打盡。

2.作用

此最佳化主要是針對零散的小頁面, 方便對小頁面的集合進行管理。如果每個小頁面作為一個項目, 既造成了項目數量的泛濫、不方便管理, 又會。如果在缺失文檔, 那後果可想而知, 估計每個接手的同學都會有怨言。

個人感覺, 這種形式試用與那種互動不複雜、迭代需求快的頁面, 類似一些運營頁面之類的, 我覺得是一種不錯的方式。

 

說到這裡, 我們要暫時告一段落了, 感謝大家能看到這裡。對於這種方案, 我們還會持續最佳化, 有了新的提升我會再給大家進行分享。也請看到本文的大神們多提寶貴意見, 我們會繼續加油努力......

小型Web頁打包最佳化(下)

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.