摘要：懶加載方式常見的有淘寶一屏用元素占據(jù)一定的高度，然后再去拉圖片數(shù)據(jù)。但這種方式還是需要元素占位，淘寶一頁的數(shù)據(jù)量其實(shí)不算大，因?yàn)樗Y(jié)合了分頁。

大數(shù)據(jù)項(xiàng)目根據(jù)用戶輸入代碼查詢數(shù)據(jù)，用戶的代碼不可控（比如select from db limit 5000），有可能一頁需求要求展示100行5000列數(shù)據(jù)。由于是用戶代碼實(shí)時(shí)查詢的數(shù)據(jù)，后端不可能將所有查詢結(jié)果都存儲(chǔ)。因此，查詢的結(jié)果是實(shí)時(shí)的、全量的，分頁和排序都需要前端去實(shí)現(xiàn)。

剛開始的接手項(xiàng)目的時(shí)候完全不能展示十萬級(jí)的數(shù)量，chrome標(biāo)簽頁直接崩潰。這個(gè)在分析了需求，展示數(shù)據(jù)不需要響應(yīng)式后，用了Object.freeze()后就可以勉強(qiáng)展示十萬級(jí)數(shù)據(jù)。雖然還是卡頓，但是需求已經(jīng)實(shí)現(xiàn)。（值得注意的是Object.freeze()并不是深度凍結(jié)，實(shí)際應(yīng)用中對(duì)象要進(jìn)行遞歸操作。）

下面圖展示的是100行乘以一千列，在左右拖拽0-150列。目前也對(duì)超過兩百列的數(shù)據(jù)進(jìn)行橫向的懶加載操作，實(shí)現(xiàn)原理時(shí)監(jiān)聽scroll事件滾動(dòng)到末尾時(shí)截取對(duì)應(yīng)下一組數(shù)據(jù)，然后將滾動(dòng)條恢復(fù)到頭部。可以從gif中明顯感覺到這個(gè)過程是滾動(dòng)條恢復(fù)到原狀之間耗時(shí)比較長。而且當(dāng)用戶想要看前一組數(shù)據(jù)的最后一項(xiàng)和后一組數(shù)據(jù)的前一項(xiàng)時(shí)，js就要不停地做截取數(shù)據(jù)的操作重新渲染，開銷非常大。

利用chrome devtool performance進(jìn)行性能分析。（進(jìn)行性能分析時(shí)使用隱身模式避免chrome插件對(duì)結(jié)果分析造成偏差）

觀察FPS圖表，有幾段紅幀證明這過程中頁面超負(fù)荷，會(huì)出現(xiàn)卡頓響應(yīng)緩慢等。

選中紅幀區(qū)域，Main區(qū)域發(fā)生變化，變?yōu)楫?dāng)前選擇時(shí)段的函數(shù)調(diào)用棧詳情。點(diǎn)擊會(huì)在下面的Summary里發(fā)現(xiàn)對(duì)應(yīng)的信息以及警告提示回流可能為性能的瓶頸Forced reflow is a likely performance bottleneck.。對(duì)應(yīng)的問題出在監(jiān)聽scroll事件后出現(xiàn)的js代碼中，執(zhí)行的次數(shù)非常多。不僅需要去讀取scrollLeft值，還因?yàn)橹匦落秩緮?shù)據(jù)時(shí)使組件縱向高度發(fā)生了改變，進(jìn)而多次觸發(fā)了element-ui組件的updateScrollY方法。從Screenshots可以看到這時(shí)剛好是數(shù)據(jù)移動(dòng)到最后要對(duì)數(shù)據(jù)進(jìn)行截取重新渲染。

從上圖summary可以看到j(luò)s的運(yùn)行壓力很大，勾選memory項(xiàng)紀(jì)錄js heap占用情況，查看到占用高達(dá)161mb-325mb

table的數(shù)據(jù)并不會(huì)有修改的需要，僅僅是展示，并不需要響應(yīng)式。Object.freeze()可以阻止vue追蹤屬性的變化，減少性能的開銷

由于數(shù)據(jù)展示的table不僅大量而且經(jīng)常變換數(shù)據(jù)集。為了減少回流和重繪，table做絕對(duì)定位脫離文檔流，避免布局抖動(dòng)。

由于后端返回的數(shù)據(jù)一組表頭和內(nèi)容分開的數(shù)組，而開源element-ui的vue組件都是以key:value的形式，大量數(shù)據(jù)情況下僅僅是將數(shù)組轉(zhuǎn)化為key:value的形式就花費(fèi)掉幾百毫秒的時(shí)間。開源組件能解決的是通用情況，這種情況下為了盡量減少開銷重寫適用于業(yè)務(wù)的table組件還是很有必要的。

//后端返回的格式
data = [
    columnName: ["col1", "col2", ……],
    columns: [
        ["1", "2", ……],
        ["1", "2", ……],
        ……
    ]
]
// 開源組件需要的格式
data = [
    {
        col1: "1",
        col2: "2",
        ……
    },
    {
        col1: "1",
        col2: "2",
        ……
    }
]

后端返回的數(shù)據(jù)量有可能高達(dá)百萬級(jí)，盡管前端進(jìn)行分頁還是有可能要展示到數(shù)量達(dá)十萬。其中行最多每頁只展示100條，但是列由ide用戶執(zhí)行的代碼決定，這里主要影響性能的是列數(shù)。列數(shù)有可能為1000條，模擬橫向懶加載，將拿回來的數(shù)組截取部分展示，減少頁面上的dom節(jié)點(diǎn)。但是目前模擬懶加載的方式用戶體驗(yàn)不好。

為了解決橫向滾動(dòng)時(shí)相鄰列的數(shù)據(jù)能夠展示在同一屏上，而不需多次來回切換，首先做的工作是在截取數(shù)據(jù)時(shí)保留前一屏的數(shù)據(jù)，拖動(dòng)后滾動(dòng)條回到中間位置，在一定范圍內(nèi)不需要多次滾動(dòng)才能查看。（如下圖）

- 但這種方式也是非常不友好，每次滾動(dòng)到最后要去檢測用戶是否按著鼠標(biāo)有沒有抬起，防止觸發(fā)多次數(shù)據(jù)重新渲染。因?yàn)檫@種情況下，用戶拖一次只能加載一組新數(shù)據(jù)，滾動(dòng)條便回到了中間位置，如果用戶需要看到最后一組數(shù)據(jù)就要多次操作。正常的懶加載應(yīng)該是有一條適應(yīng)高度的滾動(dòng)條拖拽，無縫連接。

- 懶加載方式常見的有：
    1. 淘寶一屏用元素占據(jù)一定的高度，然后再去拉圖片數(shù)據(jù)。滾動(dòng)條便適應(yīng)高度的拖動(dòng)距離。但這種方式還是需要元素占位，淘寶一頁的數(shù)據(jù)量其實(shí)不算大，因?yàn)樗Y(jié)合了分頁。
    2. 掘金沸點(diǎn)的無限加載：掘金的方式是監(jiān)聽到底部時(shí)，再去拉響應(yīng)的數(shù)據(jù)追加，滾動(dòng)條會(huì)自適應(yīng)滾到相對(duì)應(yīng)的地方。但是掘金這種懶加載一直加載數(shù)據(jù)沒有截取掉舊數(shù)據(jù)，所以滾動(dòng)條距離也是一直適應(yīng)數(shù)據(jù)的。嘗試將掘金沸點(diǎn)一直拖動(dòng)到2000條，網(wǎng)頁已經(jīng)開始有點(diǎn)卡頓。而在ide項(xiàng)目中，兩千條數(shù)據(jù)算是少量數(shù)據(jù)。
- 啟發(fā)于[https://github.com/tangbc/vue-virtual-scroll-list](vue-virtual-scroll-list)，利用了padding值模擬了淘寶固定高度，不需要元素占位，模擬出全部數(shù)據(jù)量的滾動(dòng)條縱向滾動(dòng)距離，拖動(dòng)時(shí)完全無感知數(shù)據(jù)的重新渲染。目前vue-virtual-scroll-list只支持縱向，但稍微改造下就能用在ide項(xiàng)目的橫向懶加載。（改造后如下圖，gif軟件錄制時(shí)稍微有點(diǎn)卡頓感）

scroll長時(shí)間運(yùn)行的重新計(jì)算樣式事件，其時(shí)間如果超過 16.7 毫秒，并且恰好發(fā)生在滾動(dòng)期間，導(dǎo)致用戶體驗(yàn)到明顯的抖動(dòng)。為了在拖動(dòng)過程中數(shù)據(jù)變化以連貫、平滑進(jìn)行過渡，函數(shù)節(jié)流改setTimeout為requestAnimationFrame（rAF），由系統(tǒng)來決定回調(diào)函數(shù)的執(zhí)行時(shí)機(jī);它能保證回調(diào)函數(shù)在屏幕每一次的繪制間隔中只被執(zhí)行一次，這樣就不會(huì)引起丟幀現(xiàn)象，也不會(huì)導(dǎo)致渲染數(shù)據(jù)出現(xiàn)卡頓的問題，并且rAF能兼容到ie9以上了。

拖動(dòng)幾百條數(shù)據(jù)截取的performance在FPS圖表中已經(jīng)沒有最初的紅標(biāo)，沒有Forced reflow，每幀的rendering也由rAF控制在16.7ms以內(nèi)，js內(nèi)存占用也從161mb-325mb，降低到157mb-196mb。

復(fù)用性：配置參數(shù)的方式去差異化體現(xiàn)，參數(shù)的可配置性提高了組件的復(fù)用率和靈活性。
可維護(hù)性：組件化后，組件內(nèi)部的邏輯只對(duì)組件負(fù)責(zé)，外部的邏輯只通過配置參數(shù)適配，提高了代碼的邏輯清晰度，可以快速定位代碼出現(xiàn)問題的地方。

這個(gè)組件設(shè)計(jì)時(shí)對(duì)外提供toLeft，toRight，onScroll事件，分別是滑動(dòng)過程中到了頭、尾，及滑動(dòng)過程的回調(diào)。提供了offset，remain，bench參數(shù)表示剛渲染時(shí)的偏差，顯示的列數(shù)，及保留多少列在實(shí)際dom中。

以前沒有想過js也會(huì)承受那么大的壓力，一點(diǎn)點(diǎn)優(yōu)化都能顯著減輕內(nèi)存。在寫代碼時(shí)要特別關(guān)注高頻事件的觸發(fā)，一切的優(yōu)化方向就是在實(shí)現(xiàn)功能的前提下減少重新渲染的發(fā)生。