一直以來，性能都是技術(shù)層面不可避開的話題，尤其在中大型復(fù)雜項(xiàng)目中。猶如汽車整車性能，追求極速的同時(shí)，還要保障舒適性和實(shí)用性，而在汽車制造的每個環(huán)節(jié)、零件整合情況、發(fā)動機(jī)調(diào)校等等，都會最終影響用戶體感以及商業(yè)達(dá)成，如下圖性能對收益的影響。

性能優(yōu)化是一個體系化、整體性的事情，印刻在項(xiàng)目開發(fā)環(huán)節(jié)的各個細(xì)節(jié)中，也是體現(xiàn)技術(shù)深度的大的戰(zhàn)場。下面我將以Quick BI的復(fù)雜系統(tǒng)為背景，深扒整個性能優(yōu)化的思路和手段，以及體系化的思考。

如何定位性能問題？

通常來講，我們對動畫的幀率是比較敏感的（16ms內(nèi)），但如果出現(xiàn)性能問題，我們的實(shí)際體感可能就一個字：“慢”，但這并不能為我們解決問題提供任何幫助，由此我們需要剖析這個字背后的整條鏈路。

上圖是瀏覽器通用的處理流程，結(jié)合我們的場景，我這里抽象成以下幾個步驟：

可以看出，主要的耗時(shí)階段分為兩個：

階段一：資源包下載（Download Code）

階段二：執(zhí)行 & 取數(shù)（Script Execution & Fetch Data）

如何深入這兩個階段，我們一般會用以下幾個主要的工具來分析：

Network

首先我們要使用的一個工具是Chrome的Network，它能幫助我們初步定位瓶頸所在的環(huán)節(jié)：

如圖示例，在Network中可以一目了然看到整個頁面的：加載時(shí)間（Finish）、加載資源大小、請求數(shù)量、每個請求耗時(shí)及耗時(shí)點(diǎn)、資源優(yōu)先級等等。上面示例可以很明顯看出：整個頁面加載的資源很大，接近了30MB。

Coverage（代碼覆蓋率）

對于復(fù)雜的前端工程，其工程構(gòu)建的產(chǎn)物一般會存在冗余甚至未被使用的情況，這些無效加載的代碼可以通過Coverage工具來實(shí)時(shí)分析：

如上圖示例可以看到：整個頁面28.3MB，其中19.5MB都未被使用（執(zhí)行），其中engine-style.css文件的使用率只有不到0.7%

資源大圖

剛才我們已經(jīng)知道前端資源的利用率非常低，那么具體是哪些無效代碼被引入進(jìn)來了？這時(shí)候我們要借助webpack-bundle-analyzer來分析整個的構(gòu)建產(chǎn)物（產(chǎn)物stats可以通過webpack --profile --json=stats.json輸出）：

如上例，結(jié)合我們當(dāng)前業(yè)務(wù)可以看到構(gòu)建產(chǎn)物的問題：

第一，初始包過大（common.js）

第二，存在多個重復(fù)包（momentjs等）

第三，依賴的第三方包體積過大

模塊依賴關(guān)系

有了資源構(gòu)建大圖，我們也大概知道了可優(yōu)化的點(diǎn)，但在一個系統(tǒng)中，成百上千的模塊一般都是通過互相引用的方式組織在一起，打包工具再通過依賴關(guān)系將其構(gòu)建在一起（比如打成common.js單個文件），想要直接移除掉某個模塊代碼或依賴可能并非易事，由此我們可能需要一定程度抽絲剝繭，借助工具理清系統(tǒng)中模塊的依賴關(guān)系，再通過調(diào)整依賴或加載方式來作優(yōu)化：

上圖我們使用到的是webpack官方的analyse工具（其他工具還有：webpack-xray，Madge），只需要將資源大圖stats.json上傳即可得到整個依賴關(guān)系大圖

Performance

前面講到的都是和資源加載相關(guān)的工具，那么在分析 “執(zhí)行 & 取數(shù)” 環(huán)節(jié)我們使用什么，Chrome提供了非常強(qiáng)大的工具：Performance：

如上圖示例，我們可以至少發(fā)現(xiàn)幾個點(diǎn)：主流程串化、長任務(wù)、高頻任務(wù)。

如何優(yōu)化性能？

結(jié)合剛才提到的分析工具，剛才提到的 “資源包下載”、“執(zhí)行 & 取數(shù)” 兩個大的階段我們基本上已經(jīng)覆蓋到，其根本問題和解法也在不斷的分析中逐步有了思路，這里我將結(jié)合我們這里的場景，給出一些不錯的優(yōu)化思路和效果

大包按需加載

要知道，前端工程構(gòu)建打包（如webpack）一般是從entry出發(fā)，去尋找整棵依賴樹（直接依賴），從而根據(jù)這棵樹產(chǎn)出多個js和css文件bundle或trunk，而一個模塊一旦出現(xiàn)在依賴樹中，那么當(dāng)頁面加載entry的時(shí)候，同時(shí)也會加載該模塊。

所以我們的思路是打破這種直接依賴，針對末端的模塊改用異步依賴方式，如下：

將同步的import { Marker } from '@antv/l7'改為異步，這樣在構(gòu)建時(shí)，被依賴的Marker會形成一個chunk，僅在此段代碼執(zhí)行時(shí)（按需），該thunk才被加載，從而減少了首屏包的體積。

然而上面方案會存在一個問題，構(gòu)建會將整個@antv/l7作為一個chunk，而非Marker部分代碼，導(dǎo)致該chunk的TreeShaking失效，體積很大。我們可以使用構(gòu)建分片方式解決：

如上，先創(chuàng)建Marker的分片文件，使之具備TreeShaking的能力，再在此基礎(chǔ)上作異步引入。

下方是我們優(yōu)化后的流程對比結(jié)果：

這一步，我們通過按需拆包，異步加載，節(jié)省了資源下載時(shí)間和部分執(zhí)行時(shí)間

資源預(yù)加載

其實(shí)我們在分析階段已經(jīng)發(fā)現(xiàn)一個“主流程串化”的問題，js的執(zhí)行是單線程，但瀏覽器實(shí)際上是多線程運(yùn)行的，這里面就包括異步請求（fetch等），所以我們進(jìn)一步的思路是把取數(shù)（Fetch Data）與資源下載通過多線程并行。

按照當(dāng)前現(xiàn)狀，接口取數(shù)的邏輯一般是耦合在業(yè)務(wù)邏輯或數(shù)據(jù)處理邏輯中的，所以解耦（與UI、業(yè)務(wù)模塊等解耦）的步驟必不可少，將純粹的fetch請求（及少量處理邏輯）剝離出來，放到優(yōu)先級更高的階段來發(fā)起請求。那么放到什么地方呢？我們知道，瀏覽器對資源的處理是有優(yōu)先級的，正常按如下順序：

HTML/CSS/FONT

Preload/SCRIPT/XHR

Image/Audio/Video

Prefetch

要做到資源拉取 和 發(fā)起取數(shù)并行，就有必要把取數(shù)提前到第1優(yōu)先級（HTML解析完畢后立即執(zhí)行，而非等待SCRIPT標(biāo)簽資源加載執(zhí)行過程中發(fā)起請求），我們的流程會變成如下：

需要特別注意一點(diǎn)：由于JS的執(zhí)行是串行，發(fā)起取數(shù)的那段邏輯必須要先于主流程邏輯執(zhí)行，并且不能放到nextTick（如使用setTimeout(() => doFetch())），否則主流程會一直占用CPU時(shí)間使得請求無法發(fā)出

主動任務(wù)調(diào)度

瀏覽器對資源也有優(yōu)先級策略，但它并不知道業(yè)務(wù)層面的我們，到底想要哪些資源先加載/執(zhí)行，哪些資源后加載/執(zhí)行，所以我們跳出來看，若把整個業(yè)務(wù)層面的資源加載+執(zhí)行/取數(shù)流程拆成一個一個小的任務(wù)，這些任務(wù)全權(quán)由我們自己來控制其：打包粒度、加載時(shí)機(jī)、執(zhí)行時(shí)機(jī)，是不是意味著能最大化利用CPU時(shí)間和網(wǎng)絡(luò)資源了？

答案是肯定的，不過一般對于簡單的項(xiàng)目，瀏覽器本身的調(diào)度優(yōu)先級策略已經(jīng)足夠滿足需要，但如果針對大型復(fù)雜項(xiàng)目，要做的相對極致的優(yōu)化，就有必要引入“自定義任務(wù)調(diào)度”方案了。

以Quick BI為例，我們的前期目標(biāo)是：讓首屏主要內(nèi)容展現(xiàn)更加快速。那么從資源加載、代碼執(zhí)行、取數(shù)層面是應(yīng)該根據(jù)我們業(yè)務(wù)優(yōu)先級作CPU/網(wǎng)絡(luò)分配的，比如：我希望“卡片的下拉菜單”，在首屏主要內(nèi)容展示完畢后或CPU空閑時(shí)，才開始加載（即降低優(yōu)先級，更甚至在用戶鼠標(biāo)移入卡片中時(shí)，又希望它提高優(yōu)先級立即開始加載并展示）。如下：

這里我們封裝了一個任務(wù)調(diào)度器，其目的是可以聲明一段邏輯，在其某個依賴（Promise）完成后開始執(zhí)行。我們的流程圖變化如下：

黃色區(qū)塊代表 作優(yōu)先級降級處理的部分模塊，其幫助減少了整個首屏?xí)r間

TreeShaking

上面講方法大多從優(yōu)先級出發(fā)，其實(shí)在前端工程化日益復(fù)雜的時(shí)代（中大型項(xiàng)目已超幾十萬行代碼），誕生了一個較為智能的優(yōu)化方案用于減少包大小，其思想很簡單：工具化分析依賴關(guān)系，將沒有被引用到的代碼從最終產(chǎn)物中剔除掉。

聽起來很酷，實(shí)際用起來也非常不錯，但這里想講一些很多其官網(wǎng)也不會提到的點(diǎn) --- TreeShaking經(jīng)常失效的情況：

副作用

副作用（Side Effects）通常表達(dá)的是對全局（如window對象等）或環(huán)境會產(chǎn)生影響的代碼。

如圖示例，b代碼看似未被使用，但其文件中存在console.log(b(1))這樣的代碼，webpack等打包工具不敢輕易移除它，所以它會被照常打入。

解決方法

在package.json 或 webpack配置中明確指定哪些代碼具備副作用（例如sideEffects: [“**/*.css”]），無副作用的代碼將被移除

IIFE類代碼

IIFE即會被立即執(zhí)行的函數(shù)表達(dá)式（Immediately invoked function expression）

如圖，這類型的代碼，會導(dǎo)致TreeShaking失效

解決方法

三個原則：

[避免]立即執(zhí)行的函數(shù)調(diào)用
[避免]立即執(zhí)行的new操作
[避免]立即影響全局的代碼

懶加載

我們在“按需加載”處提到過異步import來做拆包會導(dǎo)致TreeShaking失效，這里再進(jìn)一步說明一下另外一個case：

如圖，由于index.ts同步import了bar.ts中的sharedStr，然后在某個地方，又同時(shí)異步import('./bar')，這種情況下，會同時(shí)導(dǎo)致兩個問題：

TreeShaking失效（unusedStr會被打入）
異步懶加載失效（bar.ts會和index.ts打入到一起）
當(dāng)代碼量達(dá)到一定量級，N個人協(xié)同開發(fā)就很容易出現(xiàn)這個問題

解決方法

[避免]同步和異步import同個文件
按需策略（Lazy）

其實(shí)前面有講到一些按需加載的方案，這里我們適當(dāng)延伸一下：既然資源包的加載可以做到按需，是否某個組件的渲染可以按需？某個對象實(shí)例的使用可以按需？某個數(shù)據(jù)緩存的生成也可以按需？

懶組件（LazyComponent）

如圖，PieArc.private.ts對應(yīng)一個復(fù)雜的React組件，PieArc通過makeLazyComponent封裝成默認(rèn)懶加載的組件，只有在代碼執(zhí)行到此處時(shí)，組件才會加載并執(zhí)行。甚至，還可以通過第二個參數(shù)（deps）申明依賴，待依賴（promise）完畢時(shí)，才加載和執(zhí)行。

懶緩存（LazyCache）

懶緩存用于這種場景：需要在任何地方使用到數(shù)據(jù)流（或其他可訂閱數(shù)據(jù)）中的某個數(shù)據(jù)經(jīng)過轉(zhuǎn)換后的結(jié)果，且僅在使用的那一刻才進(jìn)行轉(zhuǎn)換

懶對象（LazyObject）

懶對象意即該對象只有在被使用的時(shí)候（屬性/方法被訪問、修改、刪除等等），才會被實(shí)例化

如圖，globalRecorder被引入時(shí)，其并未實(shí)例化，僅當(dāng)調(diào)用globalRecorder.record()時(shí)進(jìn)行實(shí)例化

數(shù)據(jù)流：節(jié)流渲染

中大型項(xiàng)目中為了方便狀態(tài)管理，通常會使用到數(shù)據(jù)流的方案，如下流程：

store中存儲的數(shù)據(jù)通常偏原子化，粒度非常小，比如state中有：a、b、c ...等N個原子屬性，某個組件依賴這N個屬性來作UI渲染，假設(shè)N個屬性會在不同的ACTION下被改變，且這些改變均在16ms內(nèi)發(fā)生，那么若N=20，則16ms內(nèi)（1幀）會有20次View更新：

這顯然會引發(fā)非常大的性能問題，由此，我們需要對短時(shí)間的ACTION量作一個緩沖節(jié)流，待20次ACTION狀態(tài)改變完畢后，僅進(jìn)行1次View更新，如下：

此方案在Quick BI以redux中間件的形式發(fā)揮作用，在復(fù)雜+頻繁數(shù)據(jù)更新場景起到了不錯的效果

思考

“君子以思患而豫防之”，當(dāng)我們回過頭去看看，出現(xiàn)的這些性能問題，在架構(gòu)設(shè)計(jì)、編碼階段是可以避免掉80%以上的，20%的則可以“空間<=>時(shí)間置換策略”等方式去平衡。所以，最佳的性能優(yōu)化方案，是在于我們對每一段代碼質(zhì)量的執(zhí)著：是否考慮到了這樣的模塊依賴關(guān)系，可能帶來的構(gòu)建產(chǎn)物體積問題？是否考慮到了這段邏輯可能的執(zhí)行頻次？是否考慮到了隨著數(shù)據(jù)增長，空間或CPU占用的可控性？等等。性能優(yōu)化沒有銀彈，作為技術(shù)人，需要內(nèi)修于心（熟知底層原理），把對性能的執(zhí)念植入本能思考當(dāng)中，方為銀彈。

原文鏈接：http://click.aliyun.com/m/1000283335/