1. 問題現(xiàn)象與根源剖析最近在維護一個基于LayUi搭建的后臺管理系統(tǒng)時遇到了一個非常典型的性能瓶頸一個數(shù)據(jù)表格頁面里面嵌入了大量的動態(tài)下拉框。當表格數(shù)據(jù)量超過200行且每個下拉框的選項數(shù)據(jù)量也達到幾十條時整個頁面的操作就變得異?？D滾動、點擊、展開下拉框都像在看幻燈片。這幾乎是所有使用LayUi這類前端UI框架處理復雜表單表格時都會踩到的一個“坑”。這個問題的表象是“卡頓”但根源是多方面的遠不止是“數(shù)據(jù)太多”這么簡單。它本質上是瀏覽器渲染性能、JavaScript執(zhí)行效率與框架自身渲染機制共同作用的結果。首先LayUi的表格table.render在渲染時如果開啟了page: false即關閉分頁一次性渲染所有數(shù)據(jù)它會將你傳入的所有數(shù)據(jù)逐行、逐列地生成對應的DOM節(jié)點。想象一下200行數(shù)據(jù)每行有5個帶下拉框的單元格那就是1000個td每個td里又包含一個div class“l(fā)ayui-input-block”、一個select元素以及LayUi為了美化下拉框而生成的一整套復雜DOM結構包括隱藏的dl、dd等。這瞬間就會在頁面上創(chuàng)建出上萬個DOM節(jié)點對瀏覽器的布局計算和渲染造成了巨大壓力。其次更關鍵的是下拉框的初始化。LayUi的下拉框form.render(‘select’)在渲染時不僅僅是將一個簡單的select標簽畫出來。它會遍歷頁面中所有未被渲染的select元素為每一個都創(chuàng)建一套獨立的DOM結構來模擬下拉效果并綁定一系列的事件監(jiān)聽器如點擊、鼠標移入移出、鍵盤事件等。當有幾百個下拉框同時需要初始化時這個遍歷、創(chuàng)建、綁定的過程會阻塞瀏覽器的主線程導致明顯的“腳本執(zhí)行時間過長”用戶就會感覺到頁面“凍住”了。最后交互事件也會成為性能殺手。即使頁面勉強渲染出來了當你點擊某個下拉框時LayUi需要計算這個下拉框的彈出位置position: absolute并顯示對應的下拉列表。如果頁面DOM樹非常龐大且復雜計算元素位置和顯示/隱藏樣式的重排與重繪過程也會變得緩慢從而造成點擊響應延遲感覺“卡卡的”。所以解決這個問題不能頭痛醫(yī)頭腳痛醫(yī)腳必須從數(shù)據(jù)加載、渲染策略、事件管理三個層面進行系統(tǒng)性的優(yōu)化。2. 核心優(yōu)化策略從源頭減少與延遲計算面對這種因“量”引起的性能問題最根本的思路就是“做減法”和“延遲加載”。不要試圖在瀏覽器里硬扛成千上萬個動態(tài)節(jié)點的實時計算。2.1 策略一啟用服務端分頁與條件篩選這是最有效、最應該優(yōu)先考慮的方案。如果業(yè)務允許絕對不要一次性將所有數(shù)據(jù)都加載到前端。具體做法將LayUi表格的page參數(shù)設置為true并配置limits和limit。同時在cols中為需要篩選的列配置篩選控件并確保where參數(shù)能正確傳遞到后端。table.render({ elem: #test, url: /api/data/list, // 服務端接口 page: true, // 開啟分頁 limits: [10, 20, 50], limit: 20, // 默認每頁20條 cols: [[ {field: id, title: ID}, {field: status, title: 狀態(tài), templet: #statusTpl, filter: statusFilter} ]], where: { // 初始查詢條件 } });為什么有效減少數(shù)據(jù)傳輸量每次只請求和渲染一頁數(shù)據(jù)如20條網(wǎng)絡傳輸和JSON解析的壓力驟降。減少DOM節(jié)點數(shù)前端只需要維護當前頁的DOM元素從幾千上萬個減少到幾百個瀏覽器渲染和內存占用立刻得到緩解。簡化下拉框初始化每頁只有20行數(shù)據(jù)對應的下拉框數(shù)量也有限form.render的執(zhí)行時間幾乎可以忽略不計。實操心得很多開發(fā)者為了方便喜歡一次性拉取所有數(shù)據(jù)在前端做篩選和排序這在數(shù)據(jù)量小時沒問題但數(shù)據(jù)量一大就是災難。務必養(yǎng)成習慣將分頁、排序、篩選的邏輯放到服務端。這不僅優(yōu)化了前端性能也減輕了服務端一次性查詢大結果集的壓力。2.2 策略二下拉框數(shù)據(jù)動態(tài)加載與緩存對于某些列其下拉框的選項可能是固定的如“狀態(tài)”字典進行中、已完成也可能是依賴其他條件的動態(tài)數(shù)據(jù)如選擇“省份”后“城市”下拉框數(shù)據(jù)變化。對于固定數(shù)據(jù)我們應該避免在每一行都重復定義。具體做法全局定義選項數(shù)據(jù)在頁面加載時通過一次Ajax請求將所有下拉框所需的靜態(tài)字典數(shù)據(jù)獲取到存儲在一個全局變量或Vue/React的狀態(tài)中。模板中引用在表格的templet自定義列模板中使用這些全局數(shù)據(jù)來生成select的option。// 假設這是從接口獲取的全局狀態(tài)字典 var statusDict [ {value: 1, name: 待處理}, {value: 2, name: 處理中}, {value: 3, name: 已完成} ]; table.render({ elem: #test, cols: [[ {field: id, title: ID}, {field: status, title: 狀態(tài), templet: function(d){ // 使用全局字典數(shù)據(jù)構建select var options option value請選擇/option; for(var i0; istatusDict.length; i){ var selected d.status statusDict[i].value ? selected : ; options option value statusDict[i].value selected statusDict[i].name /option; } return select lay-filterstatusSelect lay-verifyrequired options /select; }} ]], done: function(res, curr, count){ // 表格渲染完成后再統(tǒng)一渲染一次表單元素包括下拉框 form.render(select); } });為什么有效避免了在每一行數(shù)據(jù)中都內嵌一段長長的optionHTML字符串減少了模板的復雜度和最終生成的HTML體積。同時數(shù)據(jù)集中管理也便于維護和更新。對于動態(tài)數(shù)據(jù)如級聯(lián)選擇則需要在事件觸發(fā)時如lay-filter再去異步加載數(shù)據(jù)并只更新當前激活的那個下拉框而不是全部重新渲染。2.3 策略三使用虛擬滾動或懶渲染技術如果業(yè)務上確實無法進行分頁例如需要對比所有行的數(shù)據(jù)那么可以考慮更高級的前端渲染方案——虛擬滾動。虛擬滾動的原理是只渲染可視區(qū)域內的DOM元素隨著滾動動態(tài)替換可視區(qū)域外的元素內容。這能保證無論數(shù)據(jù)有多少條頁面上的DOM節(jié)點數(shù)都維持在一個很低的恒定值。LayUi本身不直接支持表格的虛擬滾動但我們可以結合其他庫或手動實現(xiàn)思路。一個折中的“懶渲染”思路是在done回調中只初始化當前可視區(qū)域內的下拉框監(jiān)聽滾動事件當某行進入可視區(qū)域時再動態(tài)渲染該行的下拉框。table.render({ elem: #test, // ... 其他配置 done: function(res, curr, count){ // 初始只渲染前30行的下拉框假設一屏大概顯示20行 lazyRenderSelect(0, 30); // 監(jiān)聽表格容器的滾動事件 $(#tableContainer).scroll(function(){ var scrollTop $(this).scrollTop(); var viewportHeight $(this).height(); // 計算當前可視區(qū)域的起始行和結束行索引 var startIdx calculateStartIndex(scrollTop); var endIdx calculateEndIndex(scrollTop, viewportHeight); // 渲染這個區(qū)域內的下拉框 lazyRenderSelect(startIdx, endIdx); }); } }); function lazyRenderSelect(start, end) { // 找到表格中第start到第end行的所有select元素 // 遍歷它們如果尚未渲染例如沒有特定的class標記則調用 form.render(select, elem) 進行單元素渲染 }為什么有效它極大地減少了同時需要初始化和維護的DOM節(jié)點數(shù)量將性能開銷從一次性支付改為“按需分期付款”顯著提升了超大表格的滾動流暢度和初始加載速度。注意事項虛擬滾動或懶渲染的實現(xiàn)復雜度較高需要精確計算行高和滾動位置并且要處理好狀態(tài)保持比如某行下拉框選中的值在滾動出視野再滾回來時需要正確顯示。如果團隊前端實力不強優(yōu)先推薦方案一服務端分頁。3. 代碼級優(yōu)化與細節(jié)調優(yōu)在確定了宏觀策略后代碼層面的細節(jié)處理同樣重要一些不好的編程習慣會默默加劇性能問題。3.1 避免在循環(huán)或模板中進行密集計算和DOM查詢在列模板templet函數(shù)或done回調中要極力避免進行復雜的計算或頻繁的DOM查詢。反面例子templet: function(d){ // 每次渲染一行都要執(zhí)行一次$.ajax這是災難 var cityName; $.ajax({ url: /api/city, data: {id: d.cityId}, async: false, // 甚至用了同步頁面直接卡死 success: function(res){ cityName res.name; } }); return cityName; }正確做法所有數(shù)據(jù)應該在渲染前就準備好。如果有關聯(lián)數(shù)據(jù)應該在服務端查詢表格數(shù)據(jù)時通過JOIN或額外接口批量獲取然后以鍵值對的形式傳給前端前端在模板中直接通過id從Map中取值。// 假設后端返回的數(shù)據(jù)中已經(jīng)包含了cityName字段 // 或者前端預先加載了所有城市數(shù)據(jù)到 cityMap 中 var cityMap {1: ‘北京‘ 2: ‘上海‘ ...}; templet: function(d){ return cityMap[d.cityId] || ‘未知‘; }3.2 精細化控制表單渲染的范圍form.render()是一個非常消耗性能的函數(shù)。不要動輒就執(zhí)行form.render()或form.render(‘select’)來渲染整個頁面。優(yōu)化技巧指定容器如果下拉框只在表格的某個特定容器內使用form.render(‘select’, ‘#tableContainer’)來限定渲染范圍。渲染單個元素當動態(tài)新增一行或修改某一個下拉框后使用form.render(‘select’, elem)其中elem是具體的select元素的DOM對象或jQuery對象只重新渲染這一個元素。防抖處理如果在done回調或某些頻繁觸發(fā)的事件中需要調用form.render務必使用防抖函數(shù)。// 使用LayUi的util.debounce var renderFormDebounced util.debounce(function(){ form.render(‘select‘, ‘#myTable‘); }, 300); table.reload(‘tableId‘, { // ... done: renderFormDebounced });3.3 優(yōu)化表格配置選項LayUi表格的一些配置選項也會影響性能。skin: ‘line‘使用line模式行邊框通常比row模式列邊框或nob模式性能稍好因為生成的DOM結構更簡單。even: false關閉隔行換色背景。這個功能會為偶數(shù)行添加一個CSS類雖然影響不大但在極限優(yōu)化時可以關閉。謹慎使用fixed固定列固定列會創(chuàng)建額外的表格副本非常消耗性能。非必要不使用尤其不要在左右都固定多列。簡化col配置不必要的toolbar、edit單元格編輯、event自定義事件都會增加渲染開銷。按需啟用。4. 實戰(zhàn)排查與性能監(jiān)測當頁面已經(jīng)卡頓如何定位瓶頸不能光靠“感覺”需要用數(shù)據(jù)說話。4.1 使用瀏覽器開發(fā)者工具Performance面板性能面板錄制頁面從加載到操作卡頓的整個過程。重點觀察Main線程上的活動。你會看到長長的黃色塊JavaScript執(zhí)行和紫色塊渲染、布局、繪制。找到耗時最長的函數(shù)調用點擊查看其來源很可能就是form.render或某個復雜的templet函數(shù)。Memory面板內存面板拍攝堆快照查看DOM節(jié)點HTMLDivElement HTMLSelectElement的數(shù)量。一個健康的復雜單頁應用DOM節(jié)點數(shù)通常不應超過5000個。如果你的表格頁面節(jié)點數(shù)輕松破萬那卡頓是必然的。檢查是否存在內存泄漏即隨著操作如翻頁DOM節(jié)點數(shù)只增不減。Rendering面板渲染面板Chrome打開Paint flashing它會用綠色高亮顯示頁面重繪的區(qū)域。如果你滾動表格或點擊下拉框時大面積甚至整個屏幕都在閃爍綠色說明發(fā)生了不必要的全局重繪需要優(yōu)化。4.2 常見問題速查與解決方案下表列出了一些典型癥狀和對應的排查思路癥狀描述可能原因排查與解決方案頁面初始加載極慢長時間白屏1. 一次性加載數(shù)據(jù)量過大。2. 在templet中執(zhí)行同步Ajax或復雜計算。1. 打開Network面板查看接口響應時間和數(shù)據(jù)大小。啟用分頁。2. 打開Performance面板錄制加載過程找到長任務。將數(shù)據(jù)預處理移至后端或提前批量加載。表格渲染出來后滾動卡頓1. DOM節(jié)點過多。2. 綁定了復雜的滾動事件監(jiān)聽。1. 使用Memory面板查看DOM節(jié)點數(shù)。實施虛擬滾動或懶渲染。2. 檢查滾動事件處理函數(shù)是否過于頻繁如使用了scroll事件但未防抖。點擊下拉框彈出緩慢1.form.render(‘select’)一次性渲染所有下拉框耗時。2. 下拉框彈出位置計算慢頁面布局復雜。1. 在Performance面板中確認點擊事件后是否有長腳本。改為懶渲染或單元素渲染。2. 簡化下拉框所在容器的CSS減少復雜布局。檢查是否有position: fixed的父元素影響計算。勾選復選框、排序等操作響應慢1. 表格綁定了全局事件事件委托處理函數(shù)效率低。2. 操作觸發(fā)了表格重繪。1. 檢查事件處理函數(shù)中是否有全表遍歷如$(‘.layui-table .checkbox‘)。優(yōu)化選擇器緩存DOM引用。2. 非必要操作避免使用table.reload嘗試只更新數(shù)據(jù)。4.3 一個綜合優(yōu)化案例記錄我曾接手一個項目一個設備管理表格約500行每行有4個動態(tài)下拉框下拉選項來自不同字典表。頁面加載超過15秒點擊下拉框延遲2-3秒。我的優(yōu)化步驟性能分析用Performance錄制發(fā)現(xiàn)長達12秒的腳本執(zhí)行阻塞。堆棧顯示是form.render和大量的templet函數(shù)執(zhí)行。第一步服務端分頁。與產(chǎn)品經(jīng)理溝通同意增加分頁功能。改為每頁50條。加載時間從15秒降至2秒。第二步下拉框數(shù)據(jù)全局化。發(fā)現(xiàn)每個templet都在拼接相同的option字符串。我將四個字典數(shù)據(jù)在頁面初始化時通過一個接口批量獲取并生成一個渲染函數(shù)。templet內只需調用這個函數(shù)并傳入當前行數(shù)據(jù)即可。done里的form.render時間從數(shù)秒降至幾百毫秒。第三步事件優(yōu)化。發(fā)現(xiàn)表格的toolbar和checkbox也綁定了事件且事件處理函數(shù)內有$(‘.layui-table-body‘).find(‘…‘)這樣的全局查找。我將其改為事件委托到表格容器并緩存了表格body的jQuery對象。最終效果頁面加載含數(shù)據(jù)請求在3秒內完成下拉框點擊響應在200毫秒以內滾動流暢。這個經(jīng)歷讓我深刻體會到前端性能優(yōu)化是一個系統(tǒng)工程需要從數(shù)據(jù)流、渲染策略、代碼細節(jié)多個層面協(xié)同推進。對于LayUi數(shù)據(jù)表格這類傳統(tǒng)jQuery插件式的組件其設計初衷并非應對海量數(shù)據(jù)的實時交互因此我們在使用它構建復雜應用時更要主動將“性能”二字納入架構設計的第一考量。