如何優(yōu)化前端性能？
隨著前端的范疇逐漸擴(kuò)大，深度逐漸下沉，富前端必然帶來(lái)的一個(gè)問(wèn)題就是性能。特別是在大型復(fù)雜項(xiàng)目中，重前端業(yè)務(wù)可能因?yàn)橐粋€(gè)小小的數(shù)據(jù)依賴(lài)，導(dǎo)致整個(gè)頁(yè)面卡頓甚至崩潰。本文基于Quick BI(數(shù)據(jù)可視化分析平臺(tái))歷年架構(gòu)變遷中性能的排查、解決和總結(jié)出的“個(gè)性”問(wèn)題，嘗試總結(jié)整個(gè)前端層面相對(duì)“共性”的問(wèn)題，提供一些前端性能解決思路。
一 引發(fā)性能問(wèn)題原因?
引發(fā)性能問(wèn)題的原因通常不是單方面緣由，特別是大型系統(tǒng)迭代多年后，長(zhǎng)期積勞成疾造成，所以我們要必要分析找到癥結(jié)所在，并按瓶頸優(yōu)先級(jí)逐個(gè)擊破，拿我們項(xiàng)目為例，大概分幾個(gè)方面：
1 資源包過(guò)大
通過(guò)Chrome DevTools的Network標(biāo)簽，我們可以拿到頁(yè)面實(shí)際拉取的資源大小(如下圖)：
經(jīng)過(guò)前端高速發(fā)展，近幾年項(xiàng)目更新迭代，前端構(gòu)建產(chǎn)物也在急劇增大，因?yàn)橐獦I(yè)務(wù)先行，很多同學(xué)引入庫(kù)和編碼過(guò)程并沒(méi)有考慮性能問(wèn)題，導(dǎo)致構(gòu)建的包增至幾十MB，這樣帶來(lái)兩個(gè)顯著的問(wèn)題：
- 弱(普通)網(wǎng)絡(luò)下，首屏資源下載耗時(shí)長(zhǎng)
- 資源解壓解析執(zhí)行慢
對(duì)于第一個(gè)問(wèn)題，基本上會(huì)影響所有移動(dòng)端用戶(hù)，并且會(huì)耗費(fèi)大量不必要的用戶(hù)帶寬，對(duì)客戶(hù)是一個(gè)經(jīng)濟(jì)上的隱式損失和體驗(yàn)損失。
對(duì)于第二個(gè)問(wèn)題，會(huì)影響所有用戶(hù)，用戶(hù)可能因?yàn)榈却龝r(shí)間過(guò)長(zhǎng)而放棄使用。
下圖展示了延遲與用戶(hù)反應(yīng)：
2 代碼耗時(shí)長(zhǎng)
在代碼執(zhí)行層面，項(xiàng)目迭代中引發(fā)的性能問(wèn)題普遍是因?yàn)殚_(kāi)發(fā)人員編碼質(zhì)量導(dǎo)致，大概以下幾個(gè)緣由：
不必要的數(shù)據(jù)流監(jiān)聽(tīng)
此場(chǎng)景在hooks+redux的場(chǎng)景下會(huì)更容易出現(xiàn)，如下代碼：
- const FooComponent = () => {
- const data = useSelector(state => state.fullData);
- return <Bar baz={data.bar.baz} />;
- };
假設(shè)fullData是頻繁變更的大對(duì)象，雖然FooComponent僅依賴(lài)其.bar.baz屬性，fullData每次變更也會(huì)導(dǎo)致Foo重新渲染。
雙刃劍cloneDeep
相信很多同學(xué)在項(xiàng)目中都有cloneDeep的經(jīng)歷，或多或少，特別是迭代多年的項(xiàng)目，其中難免有mutable型數(shù)據(jù)處理邏輯或業(yè)務(wù)層面依賴(lài)，需要用到cloneDeep，但此方法本身存在很大性能陷阱，如下：
- // a.tsx
- export const a = {
- name: 'a',
- };
- // b.tsx
- import { a } = b;
- saveData(_.cloneDeep(a)); // 假設(shè)需要克隆后落庫(kù)到后端數(shù)據(jù)庫(kù)
上方代碼正常迭代中是沒(méi)有問(wèn)題的，但假設(shè)哪天 a 需要擴(kuò)展一個(gè)屬性，保存一個(gè)ReactNode的引用，那么執(zhí)行到b.tsx時(shí)，瀏覽器可能直接崩潰!
Hooks之Memo
hooks的發(fā)布，給react開(kāi)發(fā)帶來(lái)了更高的自由度，同時(shí)也帶來(lái)了容易忽略的質(zhì)量問(wèn)題，由于不再有類(lèi)中明碼標(biāo)價(jià)的生命周期概念，組件狀態(tài)需要開(kāi)發(fā)人員自由控制，所以開(kāi)發(fā)過(guò)程中務(wù)必懂得react對(duì)hooks組件的渲染機(jī)制，如下代碼可優(yōu)化的地方：
- const Foo = () => { // 1. Foo可用React.memo，避免無(wú)props變更時(shí)渲染
- const result = calc(); // 2. 組件內(nèi)不可使用直接執(zhí)行的邏輯，需要用useEffect等封裝
- return <Bar result={result} />; // 3.render處可用React.useMemo，僅對(duì)必要的數(shù)據(jù)依賴(lài)作渲染
- };
Immutable Deep Set
在使用數(shù)據(jù)流的過(guò)程中，很大程度我們會(huì)依賴(lài)lodash/fp的函數(shù)來(lái)實(shí)現(xiàn)immutable變更，但fp.defaultsDeep系列函數(shù)有個(gè)弊端，其實(shí)現(xiàn)邏輯相當(dāng)于對(duì)原對(duì)象作深度克隆后執(zhí)行fp.set，可能帶來(lái)一些性能問(wèn)題，并且導(dǎo)致原對(duì)象所有層級(jí)屬性都被變更，如下：
- const a = { b: { c: { d: 123 }, c2: { d2: 321 } } };
- const merged = fp.defaultsDeep({ b: { c3: 3 } }, a);
- console.log(merged.b.c === a.b.c); // 打印 false
3 排查路徑
對(duì)于這些問(wèn)題來(lái)源，通過(guò)Chrome DevTools的Performance火焰圖，我們可以很清晰地了解整個(gè)頁(yè)面加載和渲染流程各個(gè)環(huán)節(jié)的耗時(shí)和卡頓點(diǎn)(如下圖)：
當(dāng)我們鎖定一個(gè)耗時(shí)較長(zhǎng)的環(huán)節(jié)，就可以再通過(guò)矩陣樹(shù)圖往下深入(下圖)，找到具體耗時(shí)較長(zhǎng)的函數(shù)。
誠(chéng)然，通常我們不會(huì)直接找到某個(gè)單點(diǎn)函數(shù)占用耗時(shí)非常長(zhǎng)，而基本是每個(gè)N毫秒函數(shù)疊加執(zhí)行成百上千次導(dǎo)致卡頓。所以這塊結(jié)合react調(diào)試插件的Profile可以很好地幫助定位渲染問(wèn)題所在：
如圖react組件被渲染的次數(shù)以及其渲染時(shí)長(zhǎng)一目了然。
二 如何解決性能問(wèn)題?
1 資源包分析
作為一名有性能sense的開(kāi)發(fā)者，有必要對(duì)自己構(gòu)建的產(chǎn)物內(nèi)容保持敏感，這里我們使用到webpack提供的stats來(lái)作產(chǎn)物分析。
首先執(zhí)行 webpack --profile --json > ./build/stats.json 得到 webpack的包依賴(lài)分析數(shù)據(jù)，接著使用 webpack-bundle-analyzer ./build/stats.json 即可在瀏覽器看到一張構(gòu)建大圖(不同項(xiàng)目產(chǎn)物不同，下圖僅作舉例)：
當(dāng)然，還有一種直觀的方式，可以采用Chrome的Coverage功能來(lái)輔助判定哪些代碼被使用(如下圖)：
紅色表示未執(zhí)行過(guò)的代碼
最佳構(gòu)建方式
通常來(lái)講，我們組織構(gòu)建包的基本思路是：
- 按entry入口構(gòu)建。
- 一個(gè)或多個(gè)共享包供多entry使用。
而基于復(fù)雜業(yè)務(wù)場(chǎng)景的思路是：
- entry入口輕量化。
- 共享代碼以chunk方式自動(dòng)生成，并建立依賴(lài)關(guān)系。
- 大資源包動(dòng)態(tài)導(dǎo)入(異步import)。
webpack 4中提供了新的插件 splitChunks 來(lái)解決代碼分離優(yōu)化的問(wèn)題，它的默認(rèn)配置如下：
- module.exports = {
- //...
- optimization: {
- splitChunks: {
- chunks: 'async',
- minSize: 20000,
- minRemainingSize: 0,
- maxSize: 0,
- minChunks: 1,
- maxAsyncRequests: 30,
- maxInitialRequests: 30,
- automaticNameDelimiter: '~',
- enforceSizeThreshold: 50000,
- cacheGroups: {
- defaultVendors: {
- test: /[\\/]node_modules[\\/]/,
- priority: -10
- },
- default: {
- minChunks: 2,
- priority: -20,
- reuseExistingChunk: true
- }
- }
- }
- }
- };
根據(jù)上述配置，其分離chunk的依據(jù)有以下幾點(diǎn)：
- 模塊被共享或模塊來(lái)自于node_modules。
- chunk必須大于20kb。
- 同一時(shí)間并行加載的chunk或初始包不得超過(guò)30。
理論上webpack默認(rèn)的代碼分離配置已經(jīng)是最佳方式，但如果項(xiàng)目復(fù)雜或耦合程度較深，仍然需要我們根據(jù)實(shí)際構(gòu)建產(chǎn)物大圖情況，調(diào)整我們的chunk split配置。
解決TreeShaking失效
“你項(xiàng)目中有60%以上的代碼并沒(méi)有被使用到!”
treeshaking的初衷便是解決上面一句話(huà)中的問(wèn)題，將未使用的代碼移除。
webpack默認(rèn)生產(chǎn)模式下會(huì)開(kāi)啟treeshaking，通過(guò)上述的構(gòu)建配置，理論上應(yīng)該達(dá)到一種效果“沒(méi)有被使用到的代碼不應(yīng)該被打入包中”，而現(xiàn)實(shí)是“你認(rèn)為沒(méi)有被使用的代碼，全部被打入Initial包中”，這個(gè)問(wèn)題通常會(huì)在復(fù)雜項(xiàng)目中出現(xiàn)，其緣由就是代碼副作用(code effects)。由于webpack無(wú)法判定某些代碼是否“需要產(chǎn)生副作用”，所以會(huì)將此類(lèi)代碼打入包中(如下圖)：
所以，你需要明確知道你的代碼是否有副作用，通過(guò)這句話(huà)判定：“關(guān)于‘副作用’的定義是，在導(dǎo)入時(shí)會(huì)執(zhí)行特殊行為的代碼(修改全局對(duì)象、立即執(zhí)行的代碼等)，而不是僅僅暴露一個(gè) export 或多個(gè) export。舉例說(shuō)明，例如 polyfill，它影響全局作用域，并且通常不提供 export。”
對(duì)此，解決方法就是告訴webpack我的代碼沒(méi)有副作用，沒(méi)有被引入的情況下可以直接移除，告知的方式即：
- 在package.json中標(biāo)記sideEffects為false。
- 或 在webpack配置中 module.rules 添加sideEffects過(guò)濾。
模塊規(guī)范
由此，要使得構(gòu)建產(chǎn)物達(dá)到最佳效果，我們?cè)诰幋a過(guò)程中約定了以下幾點(diǎn)模塊規(guī)范：
- [必須] 模塊務(wù)必es6 module化(即export 和 import)。
- [必須] 三方包或數(shù)據(jù)文件(如地圖數(shù)據(jù)、demo數(shù)據(jù))超過(guò) 400KB 必須動(dòng)態(tài)按需加載(異步import)。
- [禁止] 禁止使用export * as方式輸出(可能導(dǎo)致tree-shaking失效并且難以追溯)。
- [推薦] 盡可能引入包中具體文件，避免直接引入整個(gè)包(如：import { Toolbar } from '@alife/foo/bar')。
- [必須] 依賴(lài)的三方包必須在package.json中標(biāo)記為sideEffects: false(或在webpack配置中標(biāo)記)。
2 Mutable數(shù)據(jù)
基本上通過(guò)Performance和React插件提供的調(diào)試能力，我們基本可以定位問(wèn)題所在。但對(duì)于mutable型的數(shù)據(jù)變更，我這里也結(jié)合實(shí)踐給出一些非標(biāo)準(zhǔn)調(diào)試方式：
凍結(jié)定位法
眾所周知，數(shù)據(jù)流思想的產(chǎn)生緣由之一就是避免mutable數(shù)據(jù)無(wú)法追溯的問(wèn)題(因?yàn)槟銦o(wú)法知道是哪段代碼改了數(shù)據(jù))，而很多項(xiàng)目中避免不了mutable數(shù)據(jù)更改，此方法就是為了解決一個(gè)棘手的mutable數(shù)據(jù)變更問(wèn)題而想出的方法，這里我暫時(shí)命名為“凍結(jié)定位法”，因?yàn)樵砭褪鞘褂脙鼋Y(jié)方式定位mutable變更問(wèn)題，使用相當(dāng)tricky：
- constob j= {
- prop: 42
- };
- Object.freeze(obj);
- obj.prop=33; // Throws an error in strict mode
Mutable追溯
此方法也是為了解決mutable變更引發(fā)數(shù)據(jù)不確定性變更問(wèn)題，用于實(shí)現(xiàn)排查的幾個(gè)目的：
- 屬性在什么地方被讀取。
- 屬性在什么地方被變更。
- 屬性對(duì)應(yīng)的訪(fǎng)問(wèn)鏈路是什么。
如下示例，對(duì)于一個(gè)對(duì)象的深度變更或訪(fǎng)問(wèn)，使用 watchObject 之后，不管在哪里設(shè)置其屬性的任何層級(jí)，都可以輸出變更相關(guān)的信息(stack內(nèi)容、變更內(nèi)容等)：
- const a = { b: { c: { d: 123 } } };
- watchObject(a);
- const c =a.b.c;
- c.d =0; // Print: Modify: "a.b.c.d"
watchObject 的原理即對(duì)一個(gè)對(duì)象進(jìn)行深度 Proxy 封裝，從而攔截get/set權(quán)限，詳細(xì)可參考: https://gist.github.com/wilsoncook/68d0b540a0fea24495d83fc284da9f4b
避免Mutable
通常像react這種技術(shù)棧，都會(huì)配套使用相應(yīng)的數(shù)據(jù)流方案，其與mutable是天然對(duì)立的，所以在編碼過(guò)程中應(yīng)該盡可能避免mutable數(shù)據(jù)，或者將兩者從設(shè)計(jì)上分離(不同store)，否則出現(xiàn)不可預(yù)料問(wèn)題且難以調(diào)試
3 計(jì)算&渲染
最小化數(shù)據(jù)依賴(lài)
在項(xiàng)目組件爆炸式增長(zhǎng)的情況下，數(shù)據(jù)流store內(nèi)容層級(jí)也逐漸變深，很多組件依賴(lài)某個(gè)屬性觸發(fā)渲染，這個(gè)依賴(lài)項(xiàng)需要盡可能在設(shè)計(jì)時(shí)遵循最小化原則，避免像上方所述，依賴(lài)一個(gè)大的屬性導(dǎo)致頻繁渲染。
合理利用緩存
(1)計(jì)算結(jié)果
在一些必要的cpu密集型計(jì)算邏輯中，務(wù)必采用 WeakMap 等緩存機(jī)制，存儲(chǔ)當(dāng)前計(jì)算終態(tài)結(jié)果或中間狀態(tài)。
(2)組件狀態(tài)
對(duì)于像hooks型組件，有必要遵循以下兩個(gè)原則：
- 盡可能memo耗時(shí)邏輯。
- 無(wú)多余memo依賴(lài)項(xiàng)。
避免cpu密集型函數(shù)
某些工具類(lèi)函數(shù)，其復(fù)雜度跟隨入?yún)⒌牧考?jí)上升，而另外一些本身就會(huì)耗費(fèi)大量cpu時(shí)間。針對(duì)這類(lèi)型的工具，要盡量避免使用，若無(wú)法避免，也可通過(guò) “控制入?yún)?nèi)容(白名單)” 及 “異步線(xiàn)程(webworker等)”方式做到嚴(yán)控。
比如針對(duì) _.cloneDeep ，若無(wú)法避免，則要控制其入?yún)傩灾胁坏糜幸弥?lèi)的大型數(shù)據(jù)。
另外像最上面描述的immutable數(shù)據(jù)深度merge的問(wèn)題，也應(yīng)該盡可能控制入?yún)ⅲ蛘咭部蓞⒖际褂米匝械膇mmutable實(shí)現(xiàn)：https://gist.github.com/wilsoncook/fcc830e5fa87afbf876696bf7a7f6bb1
- const a = { b: { c: { d: 123 }, c2: { d2: 321 } } };
- const merged = immutableDefaultsDeep(a, { b: { c3: 3 } });
- console.log(merged === a); // 打印 false
- console.log(merged.b.c === a.b.c); // 打印 true
三 寫(xiě)在最后
以上，總結(jié)了Quick BI性能優(yōu)化過(guò)程中的部分心得和經(jīng)驗(yàn)，性能是每個(gè)開(kāi)發(fā)者不可繞過(guò)的話(huà)題，我們的每段代碼，都對(duì)標(biāo)著產(chǎn)品的健康度。
