日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
如何優(yōu)化前端性能？

 隨著前端的范疇逐漸擴大，深度逐漸下沉，富前端必然帶來的一個問題就是性能。特別是在大型復(fù)雜項目中，重前端業(yè)務(wù)可能因為一個小小的數(shù)據(jù)依賴，導(dǎo)致整個頁面卡頓甚至崩潰。本文基于Quick BI(數(shù)據(jù)可視化分析平臺)歷年架構(gòu)變遷中性能的排查、解決和總結(jié)出的“個性”問題，嘗試總結(jié)整個前端層面相對“共性”的問題，提供一些前端性能解決思路。

10年的汪清網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整汪清建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“汪清網(wǎng)站設(shè)計”,“汪清網(wǎng)站推廣”以來，每個客戶項目都認(rèn)真落實執(zhí)行。

一 引發(fā)性能問題原因?

引發(fā)性能問題的原因通常不是單方面緣由，特別是大型系統(tǒng)迭代多年后，長期積勞成疾造成，所以我們要必要分析找到癥結(jié)所在，并按瓶頸優(yōu)先級逐個擊破，拿我們項目為例，大概分幾個方面：

1 資源包過大

通過Chrome DevTools的Network標(biāo)簽，我們可以拿到頁面實際拉取的資源大小(如下圖)：

經(jīng)過前端高速發(fā)展，近幾年項目更新迭代，前端構(gòu)建產(chǎn)物也在急劇增大，因為要業(yè)務(wù)先行，很多同學(xué)引入庫和編碼過程并沒有考慮性能問題，導(dǎo)致構(gòu)建的包增至幾十MB，這樣帶來兩個顯著的問題：

  • 弱(普通)網(wǎng)絡(luò)下，首屏資源下載耗時長
  • 資源解壓解析執(zhí)行慢

對于第一個問題，基本上會影響所有移動端用戶，并且會耗費大量不必要的用戶帶寬，對客戶是一個經(jīng)濟上的隱式損失和體驗損失。

對于第二個問題，會影響所有用戶，用戶可能因為等待時間過長而放棄使用。

下圖展示了延遲與用戶反應(yīng)：

2 代碼耗時長

在代碼執(zhí)行層面，項目迭代中引發(fā)的性能問題普遍是因為開發(fā)人員編碼質(zhì)量導(dǎo)致，大概以下幾個緣由：

不必要的數(shù)據(jù)流監(jiān)聽

此場景在hooks+redux的場景下會更容易出現(xiàn)，如下代碼：

 
 
 
 
    
  
  
  
  
  1. const FooComponent = () => {
    2. 
  
  
  
  
  2.   const data = useSelector(state => state.fullData);
    3. 
  
  
  
  
  3.   return ;
    4. 
  
  
  
  
  4. };
    5.

假設(shè)fullData是頻繁變更的大對象，雖然FooComponent僅依賴其.bar.baz屬性，fullData每次變更也會導(dǎo)致Foo重新渲染。

雙刃劍cloneDeep

相信很多同學(xué)在項目中都有cloneDeep的經(jīng)歷，或多或少，特別是迭代多年的項目，其中難免有mutable型數(shù)據(jù)處理邏輯或業(yè)務(wù)層面依賴，需要用到cloneDeep，但此方法本身存在很大性能陷阱，如下：

 
 
 
 
    
  
  
  
  
  1. // a.tsx
    2. 
  
  
  
  
  2. export const a = {
    3. 
  
  
  
  
  3.     name: 'a',
    4. 
  
  
  
  
  4. };
    5. 
  
  
  
  
  5. // b.tsx
    6. 
  
  
  
  
  6. import { a } = b;
    7. 
  
  
  
  
  7. saveData(_.cloneDeep(a)); // 假設(shè)需要克隆后落庫到后端數(shù)據(jù)庫
    8.

上方代碼正常迭代中是沒有問題的，但假設(shè)哪天 a 需要擴展一個屬性，保存一個ReactNode的引用，那么執(zhí)行到b.tsx時，瀏覽器可能直接崩潰!

Hooks之Memo

hooks的發(fā)布，給react開發(fā)帶來了更高的自由度，同時也帶來了容易忽略的質(zhì)量問題，由于不再有類中明碼標(biāo)價的生命周期概念，組件狀態(tài)需要開發(fā)人員自由控制，所以開發(fā)過程中務(wù)必懂得react對hooks組件的渲染機制，如下代碼可優(yōu)化的地方：

 
 
 
 
    
  
  
  
  
  1. const Foo = () => { // 1. Foo可用React.memo，避免無props變更時渲染
    2. 
  
  
  
  
  2.     const result = calc(); // 2. 組件內(nèi)不可使用直接執(zhí)行的邏輯，需要用useEffect等封裝
    3. 
  
  
  
  
  3.     return ; // 3.render處可用React.useMemo，僅對必要的數(shù)據(jù)依賴作渲染
    4. 
  
  
  
  
  4. };
    5.

Immutable Deep Set

在使用數(shù)據(jù)流的過程中，很大程度我們會依賴lodash/fp的函數(shù)來實現(xiàn)immutable變更，但fp.defaultsDeep系列函數(shù)有個弊端，其實現(xiàn)邏輯相當(dāng)于對原對象作深度克隆后執(zhí)行fp.set，可能帶來一些性能問題，并且導(dǎo)致原對象所有層級屬性都被變更，如下：

 
 
 
 
    
  
  
  
  
  1. const a = { b: { c: { d: 123 }, c2: { d2: 321 } } };
    2. 
  
  
  
  
  2. const merged = fp.defaultsDeep({ b: { c3: 3 } }, a);
    3. 
  
  
  
  
  3. console.log(merged.b.c === a.b.c); // 打印 false
    4.

3 排查路徑

對于這些問題來源，通過Chrome DevTools的Performance火焰圖，我們可以很清晰地了解整個頁面加載和渲染流程各個環(huán)節(jié)的耗時和卡頓點(如下圖)：

當(dāng)我們鎖定一個耗時較長的環(huán)節(jié)，就可以再通過矩陣樹圖往下深入(下圖)，找到具體耗時較長的函數(shù)。

誠然，通常我們不會直接找到某個單點函數(shù)占用耗時非常長，而基本是每個N毫秒函數(shù)疊加執(zhí)行成百上千次導(dǎo)致卡頓。所以這塊結(jié)合react調(diào)試插件的Profile可以很好地幫助定位渲染問題所在：

如圖react組件被渲染的次數(shù)以及其渲染時長一目了然。

二 如何解決性能問題?

1 資源包分析

作為一名有性能sense的開發(fā)者，有必要對自己構(gòu)建的產(chǎn)物內(nèi)容保持敏感，這里我們使用到webpack提供的stats來作產(chǎn)物分析。

首先執(zhí)行 webpack --profile --json > ./build/stats.json 得到 webpack的包依賴分析數(shù)據(jù)，接著使用 webpack-bundle-analyzer ./build/stats.json 即可在瀏覽器看到一張構(gòu)建大圖(不同項目產(chǎn)物不同，下圖僅作舉例)：

當(dāng)然，還有一種直觀的方式，可以采用Chrome的Coverage功能來輔助判定哪些代碼被使用(如下圖)：

紅色表示未執(zhí)行過的代碼

最佳構(gòu)建方式

通常來講，我們組織構(gòu)建包的基本思路是：

  • 按entry入口構(gòu)建。
  • 一個或多個共享包供多entry使用。

而基于復(fù)雜業(yè)務(wù)場景的思路是：

  • entry入口輕量化。
  • 共享代碼以chunk方式自動生成，并建立依賴關(guān)系。
  • 大資源包動態(tài)導(dǎo)入(異步import)。

webpack 4中提供了新的插件 splitChunks 來解決代碼分離優(yōu)化的問題，它的默認(rèn)配置如下：

 
 
 
 
    
  
  
  
  
  1. module.exports = {
    2. 
  
  
  
  
  2.     //...
    3. 
  
  
  
  
  3.     optimization: {
    4. 
  
  
  
  
  4.         splitChunks: {
    5. 
  
  
  
  
  5.             chunks: 'async',
    6. 
  
  
  
  
  6.             minSize: 20000,
    7. 
  
  
  
  
  7.             minRemainingSize: 0,
    8. 
  
  
  
  
  8.             maxSize: 0,
    9. 
  
  
  
  
  9.             minChunks: 1,
    10. 
  
  
  
  
  10.             maxAsyncRequests: 30,
    11. 
  
  
  
  
  11.             maxInitialRequests: 30,
    12. 
  
  
  
  
  12.             automaticNameDelimiter: '~',
    13. 
  
  
  
  
  13.             enforceSizeThreshold: 50000,
    14. 
  
  
  
  
  14.             cacheGroups: {
    15. 
  
  
  
  
  15.                 defaultVendors: {
    16. 
  
  
  
  
  16.                     test: /[\\/]node_modules[\\/]/,
    17. 
  
  
  
  
  17.                     priority: -10
    18. 
  
  
  
  
  18.                 },
    19. 
  
  
  
  
  19.                 default: {
    20. 
  
  
  
  
  20.                     minChunks: 2,
    21. 
  
  
  
  
  21.                     priority: -20,
    22. 
  
  
  
  
  22.                     reuseExistingChunk: true
    23. 
  
  
  
  
  23.                 }
    24. 
  
  
  
  
  24.             }
    25. 
  
  
  
  
  25.         }
    26. 
  
  
  
  
  26.     }
    27. 
  
  
  
  
  27. };
    28.

根據(jù)上述配置，其分離chunk的依據(jù)有以下幾點：

  • 模塊被共享或模塊來自于node_modules。
  • chunk必須大于20kb。
  • 同一時間并行加載的chunk或初始包不得超過30。

理論上webpack默認(rèn)的代碼分離配置已經(jīng)是最佳方式，但如果項目復(fù)雜或耦合程度較深，仍然需要我們根據(jù)實際構(gòu)建產(chǎn)物大圖情況，調(diào)整我們的chunk split配置。

解決TreeShaking失效

“你項目中有60%以上的代碼并沒有被使用到!”

treeshaking的初衷便是解決上面一句話中的問題，將未使用的代碼移除。

webpack默認(rèn)生產(chǎn)模式下會開啟treeshaking，通過上述的構(gòu)建配置，理論上應(yīng)該達(dá)到一種效果“沒有被使用到的代碼不應(yīng)該被打入包中”，而現(xiàn)實是“你認(rèn)為沒有被使用的代碼，全部被打入Initial包中”，這個問題通常會在復(fù)雜項目中出現(xiàn)，其緣由就是代碼副作用(code effects)。由于webpack無法判定某些代碼是否“需要產(chǎn)生副作用”，所以會將此類代碼打入包中(如下圖)：

所以，你需要明確知道你的代碼是否有副作用，通過這句話判定：“關(guān)于‘副作用’的定義是，在導(dǎo)入時會執(zhí)行特殊行為的代碼(修改全局對象、立即執(zhí)行的代碼等)，而不是僅僅暴露一個 export 或多個 export。舉例說明，例如 polyfill，它影響全局作用域，并且通常不提供 export。”

對此，解決方法就是告訴webpack我的代碼沒有副作用，沒有被引入的情況下可以直接移除，告知的方式即：

  • 在package.json中標(biāo)記sideEffects為false。
  • 或 在webpack配置中 module.rules 添加sideEffects過濾。

模塊規(guī)范

由此，要使得構(gòu)建產(chǎn)物達(dá)到最佳效果，我們在編碼過程中約定了以下幾點模塊規(guī)范：

  • [必須] 模塊務(wù)必es6 module化(即export 和 import)。
  • [必須] 三方包或數(shù)據(jù)文件(如地圖數(shù)據(jù)、demo數(shù)據(jù))超過 400KB 必須動態(tài)按需加載(異步import)。
  • [禁止] 禁止使用export * as方式輸出(可能導(dǎo)致tree-shaking失效并且難以追溯)。
  • [推薦] 盡可能引入包中具體文件，避免直接引入整個包(如：import { Toolbar } from '@alife/foo/bar')。
  • [必須] 依賴的三方包必須在package.json中標(biāo)記為sideEffects: false(或在webpack配置中標(biāo)記)。

2 Mutable數(shù)據(jù)

基本上通過Performance和React插件提供的調(diào)試能力，我們基本可以定位問題所在。但對于mutable型的數(shù)據(jù)變更，我這里也結(jié)合實踐給出一些非標(biāo)準(zhǔn)調(diào)試方式：

凍結(jié)定位法

眾所周知，數(shù)據(jù)流思想的產(chǎn)生緣由之一就是避免mutable數(shù)據(jù)無法追溯的問題(因為你無法知道是哪段代碼改了數(shù)據(jù))，而很多項目中避免不了mutable數(shù)據(jù)更改，此方法就是為了解決一個棘手的mutable數(shù)據(jù)變更問題而想出的方法，這里我暫時命名為“凍結(jié)定位法”，因為原理就是使用凍結(jié)方式定位mutable變更問題，使用相當(dāng)tricky：

 
 
 
 
    
  
  
  
  
  1. constob j= {
    2. 
  
  
  
  
  2.     prop: 42
    3. 
  
  
  
  
  3. };
    4. 
  
  
  
  
  4. 
  
  
  
  
  5. Object.freeze(obj);
    6. 
  
  
  
  
  6. 
  
  
  
  
  7. obj.prop=33; // Throws an error in strict mode
    8.

Mutable追溯

此方法也是為了解決mutable變更引發(fā)數(shù)據(jù)不確定性變更問題，用于實現(xiàn)排查的幾個目的：

  • 屬性在什么地方被讀取。
  • 屬性在什么地方被變更。
  • 屬性對應(yīng)的訪問鏈路是什么。

如下示例，對于一個對象的深度變更或訪問，使用 watchObject 之后，不管在哪里設(shè)置其屬性的任何層級，都可以輸出變更相關(guān)的信息(stack內(nèi)容、變更內(nèi)容等)：

 
 
 
 
    
  
  
  
  
  1. const a = { b: { c: { d: 123 } } };
    2. 
  
  
  
  
  2. watchObject(a);
    3. 
  
  
  
  
  3. const c =a.b.c;
    4. 
  
  
  
  
  4. c.d =0; // Print: Modify: "a.b.c.d"
    5.

watchObject 的原理即對一個對象進行深度 Proxy 封裝，從而攔截get/set權(quán)限，詳細(xì)可參考: https://gist.github.com/wilsoncook/68d0b540a0fea24495d83fc284da9f4b

避免Mutable

通常像react這種技術(shù)棧，都會配套使用相應(yīng)的數(shù)據(jù)流方案，其與mutable是天然對立的，所以在編碼過程中應(yīng)該盡可能避免mutable數(shù)據(jù)，或者將兩者從設(shè)計上分離(不同store)，否則出現(xiàn)不可預(yù)料問題且難以調(diào)試

3 計算&渲染

最小化數(shù)據(jù)依賴

在項目組件爆炸式增長的情況下，數(shù)據(jù)流store內(nèi)容層級也逐漸變深，很多組件依賴某個屬性觸發(fā)渲染，這個依賴項需要盡可能在設(shè)計時遵循最小化原則，避免像上方所述，依賴一個大的屬性導(dǎo)致頻繁渲染。

合理利用緩存

(1)計算結(jié)果

在一些必要的cpu密集型計算邏輯中，務(wù)必采用 WeakMap 等緩存機制，存儲當(dāng)前計算終態(tài)結(jié)果或中間狀態(tài)。

(2)組件狀態(tài)

對于像hooks型組件，有必要遵循以下兩個原則：

  • 盡可能memo耗時邏輯。
  • 無多余memo依賴項。

避免cpu密集型函數(shù)

某些工具類函數(shù)，其復(fù)雜度跟隨入?yún)⒌牧考壣仙?，而另外一些本身就會耗費大量cpu時間。針對這類型的工具，要盡量避免使用，若無法避免，也可通過 “控制入?yún)?nèi)容(白名單)” 及 “異步線程(webworker等)”方式做到嚴(yán)控。

比如針對 _.cloneDeep ，若無法避免，則要控制其入?yún)傩灾胁坏糜幸弥惖拇笮蛿?shù)據(jù)。

另外像最上面描述的immutable數(shù)據(jù)深度merge的問題，也應(yīng)該盡可能控制入?yún)ⅲ蛘咭部蓞⒖际褂米匝械膇mmutable實現(xiàn)：https://gist.github.com/wilsoncook/fcc830e5fa87afbf876696bf7a7f6bb1

 
 
 
 
    
  
  
  
  
  1. const a = { b: { c: { d: 123 }, c2: { d2: 321 } } };
    2. 
  
  
  
  
  2. const merged = immutableDefaultsDeep(a, { b: { c3: 3 } });
    3. 
  
  
  
  
  3. console.log(merged === a); // 打印 false
    4. 
  
  
  
  
  4. console.log(merged.b.c === a.b.c); // 打印 true
    5.

三 寫在最后

以上，總結(jié)了Quick BI性能優(yōu)化過程中的部分心得和經(jīng)驗，性能是每個開發(fā)者不可繞過的話題，我們的每段代碼，都對標(biāo)著產(chǎn)品的健康度。


網(wǎng)站題目：如何優(yōu)化前端性能？
當(dāng)前網(wǎng)址：http://www.5511xx.com/article/dppjpji.html