K60至尊版狂暴引擎2.0加持：超177萬跑分斬獲性能第一
Redmi的后性能時代戰略發布會今天下午如期舉辦，在本次發布會上，Redmi公布了多項關于和聯發科的深度合作，以及新機K60 Ultra在軟件和硬件方面的特性，例如：“K60 至尊版，雙芯旗艦
hi, 大家好, 我是徐小夕, 今天和大家分享一下前端項目重構的一些思考和復盤, 同時也是對自己多年項目研發經驗的一個總結.
項目重構是每一家穩定發展的互聯企業的必經之路, 就像一個產品的誕生, 會經歷產品試錯和產品迭代 一樣, 隨著業務或新技術的不斷發展, 已有架構已無法滿足更多業務擴展的需求, 所以只有通過重構來讓產品“進化”, 才能跟上飛速發展的時代浪潮.
圖片
這里我結合自己的實際經驗總結一下項目重構的幾個原因:
技術因素主要有如下幾個方面:
早期技術團隊在技術選型上的誤判(常發生于MVP類型的產品快速上線導致的技術調研不夠充分)
新老技術框架的更替(比如從 jquery 遷移到 vue/react)
技術團隊交接出現的斷層(老技術團隊的架構設計更不上新技術團隊的發展, 出現架構上的“平替”)
技術架構升級(比如隨著業務發展, 由傳統的MPA應用轉為基于微前端模式的SPA應用)
安全,性能,代碼質量等原因導致的技術重構
上面是我列出來的比較典型的重構場景, 也是我們未來在設計產品技術架構之前需要考慮的方面. 為了提高自己設計的架構穩定性, 我們需要提前和產品溝通明確, 以降低后期重構和維護成本.
最后總結幾條架構設計的經驗:
當然做項目重構也是有技術門檻的,不是所有程序員都能做好重構工作, 建議大家具備如下幾種技術能力:
接下來我們一起看看常見的幾種項目重構場景及其重構方向.
圖片
業務系統自身的重構一般可以包含如下幾個方面:
業務代碼優化主要是針對一些核心業務代碼, 進行流程上, 邏輯上的重構, 讓它更具可讀性和維護性, 同時保證業務操作的兼容性, 具體方案如下:
早期可能由某名研發單獨負責的項目, 對代碼規范和格式要求不是很高, 但是需要考慮后期團隊擴容帶來的協作開發問題, 這個時候如果沒有統一的規范, 不同研發小伙伴可能寫出的代碼千奇百怪, 導致后期維護成本巨大, 尤其是涉及到需要維護他人代碼時. 所以我們重構的另一個目標就是降低代碼理解成本, 保證項目代碼在閱讀時就像同一個寫出來的, 這樣對后期邏輯復用, 組件解耦, 問題定位以及業務代碼維護將非常有幫助.
常用的措施有:
當然, 這些都是需要結合自身團隊和項目來定的, 這里只做參考.
工程化優化主要有以下幾個場景:
接下來我會針對以上場景, 進行一些解決方案的分享.
針對這種情況, 我們可以借助 speed-measure-webpack-plugin 插件，它可以分析 webpack 的總打包耗時以及每個 plugin 和 loader 的打包耗時，從而讓我們對打包時間較長的部分進行針對性優化。
同時默認情況react, react-dom, react-router 等公共模塊在每次構建都會參與打包, 這些實際上是沒有必要的, 我們可以將其傳到 cdn上, 從而減少webpack 的打包”工作量“.
我們可以安裝 html-webpack-externals-plugin 來實現將指定模塊從打包列表中排除, 具體用法如下:
const HtmlWebpackExternalsPlugin = require('html-webpack-externals-plugin');module.exports = { // ...其他配置代碼 plugins: [ new HtmlWebpackExternalsPlugin({ externals: [ { module: 'react', entry: 'https://cdn.dooring.cn/umd/react.production.min.js', global: 'React', }, { module: 'react-dom', entry: 'https://cdn.dooring.cn/umd/react-dom.production.min.js', global: 'ReactDOM', }, ], }), ],};為了追求更驚一步的打包效率, 我們可以使用并行的方式構建, 同樣 webpack 生態也提供了對應的模塊 parallel-webpack. 具體用法大家可以看文檔, 非常簡單方便.
其他還有很多優化的方案, 這里我列一下, 大家可以根據實際情況使用:
當然除了對已有構建工具的優化, 我們可以評估一下重構成本, 將構建內核替換vite等更高效的構建工具.
針對項目代碼量的增加導致頁面臃腫, 我們可以從項目本身的角度, 對項目進行拆解, 將公共模塊抽離為公用業務類庫或者組件庫:
圖片
除了對項目進行可復用性拆分之外, 我們還需要根據系統復雜量級, 近一步拆分項目, 比如將一個巨石工程拆分為多個子工程, 單獨運行維護, 或者采用之前熱點討論的微前端的模式, 比如使用 qainkun, single-spa, Micro App, EMP, Garfish, Bit 這些優秀的微前端框架.
綜上, 我們可以根據項目復雜度, 做如下優化:
當然我們始終需要保持一個理念: 局部最優, 誤增繁復.
這種情況主要是在項目發展穩定之后, 需要思考的重構方向, 比如早期由于業務場景單一, 很多公共配置都寫在業務代碼里的, 隨著業務復雜之后, 很多模塊都需要使用改配置或者變量, 比如:
// a.jsconst publicDomain = 'https://dooring.vip';const serverUrl = 'https://xxx.cn';// b.jsconst publicDomain = 'https://dooring.vip';// c.jsconst appid = 'xxxxxxxx';const website_Logo = 'http://h5.dooring.cn/logo.png';對于這種零散且固定的變量, 未來可能會被多個頁面或者模塊復用, 所以為了降低成本, 我們可以把這些通用配置提取到外層, 作為公共配置文件, 這樣后期新項目也能享受開箱即用的配置體驗.
拿我的親身經驗, 比如幾年前我開發的低代碼項目H5-Dooring, 有一些零散的配置信息分散在項目的各個角落, 后面經過幾次重構優化之后, 整個項目只需要在配置文件中輕松配置內容, 即可一鍵控制頁面的走向, 這里分享一下優化過后的配置文件:
// h5-dooring全局配置文件define: { START_ENV, lang, // 配置h5端訪問的域名 h5Domain: 'h5.dooring.cn', // 設置當前版本號 curVersion: dooringVersion, // 備案信息 copyright: 'xxxxx-3', // 是否顯示更新彈窗 showUpdateModal: true, // 更新日志 updateList: [ "1. 新增表格組件", "2. 國際化優化", "3. 表單詳情頁支持內部滾動", "4. 個人圖片庫性能優化", "5. 下載代碼功能優化" ], // 網站logo地址 logo: 'http://cdn.dooring.cn/dr/logo.ff7fc6bb.png', // 入口頁面是否展示贊助品牌和版權提示 showAdsAndTip: true, // 登錄時獲取登錄碼的二維碼 qrcode: 'http://cdn.dooring.cn/dr%2Fcode1.png', // 友情鏈接展示 friendLinks: [ { name: 'V6', link: 'http://v6.dooring.cn/beta', title: '可視化大屏編輯器' }, { name: 'Power', link: '/powernice', title: '文檔編輯器' } ], // 默認語言 defaultLocale: 'zh-CN', langMap: langMap },這樣, 我們的工程化結果就可以讓不同的技術小伙伴輕松的享受, 讓項目創建的成本和自由度得到極大的提升.
圖片
對于這種場景, 我們就需要對腳手架自身有更多的研究和了解, 比如熟悉webpack設計思想, 熟悉babel的工作流程, 熟悉 nodejs 開發工具鏈的一些模式等, 這里分享幾個比較成熟的先進腳手架, 大家如果覺得老項目工程比較老舊, 可以往這幾個方向重構:
如果大家對以上三種之一比較熟悉, 也可以基于他們二次封裝成符合自身業務場景的DIY項目工具.
渲染層優化主要表現在產品的體驗上, 比如:
以上是我之前遇到的一些渲染優化的維度, 接下來和大家一一介紹解決思路.
1. 提高首屏加載速度
有很多方法可以幫助我們提高首屏加載速度, 比如:
當然還存在很多客觀因素, 比如用戶所在區域為弱網環境, 我們可以根據網速提供一個最小化弱網可替代頁面, 來保證我們網站的可用性和可訪問性.
對于白屏優化, 也有很多成熟的例子, 比如采用骨架屏:
圖片
如果我們的項目是基于 vue-cli 構建的，那么可以使用比較成熟的的 page-skeleton-webpack-plugin 方案，否則我們仍然可以選擇 vue-router 提供的 vue-server-renderer.
當然你的項目是使用react的, 也可以輕松使用如 react-content-loader 這樣的svg方案來定制自己的骨架屏.
除了骨架屏之外, 我們還可以提供一個模版頁面或者加載動畫, 以便在頁面加載完成之前給用戶一個優雅的過渡提示. 比如:
圖片
對于一些中后臺復雜的系統模塊, 可能會涉及到一次渲染大量列表項或者多級組織樹的情況:
圖片
尤其是在大公司或者大集團中出現的頻率非常高, 這種情況我們就需要用到虛擬列表或者節點懶加載的方式了. 虛擬列表應用非常廣泛, 目前也有幾個成熟的方案大家可以直接使用:
如果你的項目目前還好沒有使用這種方案, 不妨評估一下, 是否可以用這些方案為自己項目保駕護航.
圖片
api 請求優化主要正對這種場景: 頁面的渲染依賴于某個或者某些請求的完成, 或者由于某個頁面請求量過大導致每次重新進入頁面都需要造成一定的性能開銷.
對于這兩種情況, 其實不僅僅是對瀏覽器渲染有影響, 還會極大的增加服務器的壓力, 所以我們需要對請求或者頁面進行一定范圍的緩存.
比如說我們可以把不長變動的請求數據存在 indexedDB 中, 當第二次訪問直接可以從 indexedDB 中拿到請求數據, 這樣既降低了服務器壓力, 也提高了二次渲染的效率.
其次我們可以對部分頁面做路由緩存, 避免每次切換都重新渲染, 當然這只針對于不需要實時更新數據的頁面而言. 我之前也分享了一篇瀏覽器緩存接口實戰的文章, 大家感興趣的可以學習參考, 對于 indexedDB, 我封裝了一個開箱即用的庫, 大家可以直接使用:
github地址: https://github.com/MrXujiang/xdb
這也是個老生常談的問題, 這里直接分享幾個方案:
由于dom動畫有上限很低, 所以對于一些更復雜的動畫渲染, 我們可以采用 svg 或者 canvas 來代替, 以降低 dom 對瀏覽器內存的占用.
一個頁面如果dom數量過多, 會產生很多問題, 一方面會使得瀏覽器內存占用過高, 導致其他不相關的js邏輯操作進行阻塞或者失效, 表現就是頁面卡頓或者無響應.
為了解決這個問題我們仍然可以使用虛擬滾動的方案或者懶加載的方案, 保證用戶當前屏幕下的dom在一個合理的范圍內, 如果是無法避免必須要展示大段dom元素, 我們可以用一個單獨的頁面來承載或者嵌入, 避免頁面其他部分宕機. 也可以對復雜dom 進行局部“冷凍”(在非激活狀態將其轉化為圖片, 激活時在逐漸渲染)
產品需求層面導致的重構主要場景比如:
當然還有很到場景這里不一一介紹了. 以上列的場景都是比較常見的, 而且也有很多解決方案, 后期我會一一復盤. 我們在項目重構之前或者立項之前, 這幾種情況也是需要重點考慮的, 畢竟都是大工作量的任務.
技術升級帶來的重構主要有前端框架的升級, 前端設計模式的升級, 腳手架的升級. 后面兩個主要是圍繞前端技術的不斷演進, 我們采取的程序性升級, 比如從傳統的 gulp 升級到 webpack, 或者從 webpack 升級到vite 等. 前者比較常見的場景是企業中有很多老的系統, 采用的是比較傳統的技術方案如 CMD 模式 + jquery, 但是新項目采用的是 webpack + vue 或者 react, 此時我們需要更新項目情況來有選擇的做重構:
這種情況我們就不需要大刀闊斧的重新用新框架再寫一套了, 我們只需要在重構時, 對老項目代碼做好足夠的注釋, 類庫的封裝即可:
圖片
其次我們需要做好js變量隔離, 因為傳統模式我們會在 window 頂層定義大量 var 全局變量, 作為優化的一部分, 我們可以采用閉包自執行和變量約定來規范我的js變量定義, 以防止全局的變量污染.
這種情況我們需要做評估和拆分, 如果是小模塊, 我們可以用 jquery插件 的方式快速爹迭代, 如果是頁面級別的迭代, 并且交互比較復雜, 我們可以將老系統的新頁面拆離一個子工程, 采用最新的框架(如vue)來開發迭代, 再通過 MPA 的方式和老系統做集成:
圖片
這種場景下最好的方式就是用iframe + postmessage, 或者我們可以參考類似微前端的方式來管理組織不同子系統.
圖片
對于一個包含很多子系統的復雜的項目系統來說，要想設計一個好的架構，第一步就是合理劃分組件，組件的粒度拆成的足夠細，這樣才能最大限度的復用組件。
對于任何一個復雜系統來說，最重要的就是實現錯綜復雜的業務功能，但是不同模塊或者子系統之間很多業務往往是相通的或者相似的，如果這個時候我們每個頁面對于實現類似的業務場景都去重復去寫一遍業務代碼，那完全是沒必要的，對于可維護性來說也是一種打擊，所以基于這種場景我們的 業務組件 就很有必要出場了。我們可以把功能或者需求類似的有機體封裝成一個業務組件，并對外暴露接口來實現靈活的可定制性，這樣的話我們就可以再不同頁面不同子系統中復用同樣的邏輯和功能了。
同理，不同頁面中往往有可能出現視覺或者交互完全相同或者類似的區塊，為了提高可復用性和提高開發效率，我們往往會基于基礎組件和業務組件再進行一次封裝，讓其成為一個獨立的區塊以便直接復用。
通過這樣一層層封裝，我們就逐漸搭建了一套完整的組件化系統，基于這種模式的開發往往也是一個好的前端架構的開始。但要注意一點就是高層次的組件一定會依賴低層次的組件，但是低層次的組件不可以包含高層次的組件。（聽起來有點像rudex的單向數據流法則），他們的關系就好像下圖：
圖片
所以對組件庫的重構需要對我們的項目有一個本質的認知, 并對頁面進行有效的拆分, 從而達到局部的最優, 降低后續的維護成本, 并能提高整個系統甚至跨系統的復用.
圖片
有關如何從0到1教你搭建前端團隊的組件系統 我之前也寫過詳細的文章, 大家可以參考學習一下.
系統重構是一個持續的過程, 我們不僅要有持續學習的態度, 還需要不斷的實踐和積累優秀的最佳實踐, 這樣才能在不斷重構中讓我們的系統不斷適應復雜多變的“社會環境”.
本文鏈接：http://www.tebozhan.com/showinfo-26-14322-0.html前端項目重構的深度思考和復盤
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 快速掌握Spring異步請求接口，輕松解決并發問題
下一篇： 圖形編輯器開發：實現自定義規則輸入框組件
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號