有一位同事跟大家說他在網(wǎng)上看到一道面試題：“如果后臺傳給前端幾萬條數(shù)據(jù)，前端怎么渲染到頁面上？”，如何回答？ 于是辦公室沸騰了， 同事們討論開了， 你一言我一語說出自己的方案。 有的說直接循環(huán)遍歷生成html插到頁面上；有的說應(yīng)該用分頁來處理；還有的說這個面試官是個白癡， 哪有后臺傳幾萬條數(shù)據(jù)給前端這種情況的；我仔細(xì)思考了一下，先不論后端到底會不會白癡到傳幾萬條數(shù)據(jù)給前端，假如真碰到這種情況，那么如果前端獲取到數(shù)據(jù)以后， 直接將數(shù)據(jù)轉(zhuǎn)換成html字符串，通過DOM操作插入到頁面，勢必導(dǎo)致頁面運行出現(xiàn)卡頓， 為此我還特意寫了一個 demo測試了一下， 代碼如下

data.json中大概有13萬條數(shù)據(jù)左右， 通過ajax獲取數(shù)據(jù)后以最簡單粗暴的方法展示數(shù)據(jù)，在chrome瀏覽器下， 刷新頁面到數(shù)據(jù)顯示，我心中默數(shù)， 整個過程大概花掉5秒鐘左右的時間， 卡頓非常明顯。 我大致觀察了一下代碼的運行時間，發(fā)現(xiàn)循環(huán)生成字符串這過程其實并不算太耗時， 性能瓶頸是在將html字符串插入到文檔中這個過程上， 也就是 $("#content").html(html); 這句代碼的執(zhí)行， 畢竟有13萬個li元素要被挺入到文檔里面， 頁面渲染速度緩慢也在情理之中。

既然一次渲染13萬條數(shù)據(jù)會造成頁面加載速度緩慢，那么我們可以不要一次性渲染這么多數(shù)據(jù)，而是分批次渲染， 比如一次10000條，分13次來完成， 這樣或許會對頁面的渲染速度有提升。 然而，如果這13次操作在同一個代碼執(zhí)行流程中運行，那似乎不但無法解決糟糕的頁面卡頓問題，反而會將代碼復(fù)雜化。 類似的問題在其它語言最佳的解決方案是使用多線程，Javascript雖然沒有多線程，但是setTimeout和setInterval兩個函數(shù)卻能起到和多線程差不多的效果。 因此，要解決這個問題， 其中的setTimeout便可以大顯身手。 setTimeout函數(shù)的功能可以看作是在指定時間之后啟動一個新的線程來完成任務(wù)。

以上代碼大致的執(zhí)行流程是

1. 用ajax獲取到需要處理的數(shù)據(jù)， 共13萬條

2. 將數(shù)組分組，每組500條，一共260組

3. 循環(huán)這260組數(shù)據(jù)，分別處理每一組數(shù)據(jù)， 利用setTimeout函數(shù)開啟一個新的執(zhí)行線程（異步），防止主線程因渲染大量數(shù)據(jù)導(dǎo)致阻塞。

loadPart函數(shù)中有這段代碼

是為了保證不同的線程中最終插入html到文檔中時順序的一致性， 不至于同時執(zhí)行的代碼在插入html時互相篡位。

通過這種方式執(zhí)行， 頁面瞬間就刷出來了，不用絲毫等待時間。 從同步改為異步，雖然代碼的整體資源消耗增加了， 但是頁面卻能瞬間響應(yīng)， 而且， 前端的運行環(huán)境是用戶的電腦，因此些許的性能損失帶來的用戶體驗提升相對來說還是值得的。

雖然示例中提到的情況在現(xiàn)實環(huán)境中幾乎不可能出現(xiàn)， 但是在我們平時的工作中總會有一些似是而非的場景出現(xiàn)， 利用里面的處理思路， 或許對我們解決問題會有一定的幫助。

ps：setTimeout并不算真正的多線程， 但是為了方便表達(dá)，便借用了線程一詞

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com