-
國家級
全民數字素養與技能培訓基地 -
河南省
第一批產教融合型企業建設培育單位 -
鄭州市
數字技能人才（碼農）培養評價聯盟
補充：JS中其實是沒有線程概念的，所謂的單線程也只是相對于多線程而言。JS的設計初衷就沒有考慮這些，針對JS這種不具備并行任務處理的特性，我們稱之為“單線程”。
JS單線程是指一個瀏覽器進程中只有一個JS的執行線程，同一時刻內只會有一段代碼在執行。
舉個通俗例子，假設JS支持多線程操作的話，JS可以操作DOM，那么一個線程在刪除DOM，另外一個線程就在獲取DOM數據，這樣子明顯不合理，這算是證明之一。
來看段代碼??
function foo() { ? ?console.log("first");
setTimeout(( function(){ ? ? ? ?console.log( 'second' );
}),5);
}
for (var i = 0; i < 1000000; i++) {
foo();
}復制代碼
打印結果就是首先是很多個first,然后再是second。
異步機制是瀏覽器的兩個或以上常駐線程共同完成的，舉個例子，比如異步請求由兩個常駐線程，JS執行線程和事件觸發線程共同完成的。
先給出結論
CSS不會阻塞DOM解析，但會阻塞DOM渲染。CSS會阻塞JS執行，并不會阻塞JS文件下載CSS控制的屬性，瀏覽器是需要計算的，也就是依賴于CSS。瀏覽器也無法感知腳本內容到底是什么，為避免樣式獲取，因而只好等前面所有的樣式下載完后，再執行JS。先給出結論??
由于 JavaScript 是可操縱 DOM 的,如果在修改這些元素屬性同時渲染界面（即 JavaScript 線程和 UI 線程同時運行）,那么渲染線程前后獲得的元素數據就可能不一致了。 因此為了防止渲染出現不可預期的結果,瀏覽器設置?「GUI 渲染線程與 JavaScript 引擎為互斥」的關系。 當 JavaScript 引擎執行時 GUI 線程會被掛起,GUI 更新會被保存在一個隊列中等到引擎線程空閑時立即被執行。 當瀏覽器在執行 JavaScript 程序的時候,GUI 渲染線程會被保存在一個隊列中,直到 JS 程序執行完成,才會接著執行。 因此如果 JS 執行的時間過長,這樣就會造成頁面的渲染不連貫,導致頁面渲染加載阻塞的感覺。
DOMContentLoaded?事件前執行，如果缺少?src?屬性（即內嵌腳本），該屬性不應被使用，因為這種情況下它不起作用帶async的腳本一定會在load事件之前執行，可能會在DOMContentLoaded之前或之后執行。
如果 script 標簽中包含 defer，那么這一塊腳本將不會影響 HTML 文檔的解析，而是等到HTML 解析完成后才會執行。而 DOMContentLoaded 只有在 defer 腳本執行結束后才會被觸發。
我覺得這個題目說法上可能就是行不通，不能這么說，如果了解的話，都知道will-change只是一個優化的手段，使用JS改變transform也可以享受這個屬性帶來的變化，所以這個說法上有點不妥。
所以圍繞這個問題展開話，更應該說建議推薦使用CSS動畫，至于為什么呢，涉及的知識點大概就是重排重繪，合成，這方面的點，我在瀏覽器渲染流程中也提及了。
盡可能的避免重排和重繪，具體是哪些操作呢，如果非要去操作JS實現動畫的話，有哪些優化的手段呢？
比如??
createDocumentFragment進行批量的 DOM 操作節流的意思是讓函數有節制地執行，而不是毫無節制的觸發一次就執行一次。什么叫有節制呢？就是在一段時間內，只執行一次。
規定在一個單位時間內，只能觸發一次函數。如果這個單位時間內觸發多次函數，只有一次生效。
抓取一個關鍵的點：就是執行的時機。要做到控制執行的時機，我們可以通過「一個開關」，與定時器setTimeout結合完成。
?function throttle(fn, delay) { ? ? ? ? ? ?let flag = true,
timer = null; ? ? ? ? ? ?return function (...args) { ? ? ? ? ? ? ? ?let context = this; ? ? ? ? ? ? ? ?if (!flag) return;
flag = false;
clearTimeout(timer)
timer = setTimeout(() => {
fn.apply(context, args);
flag = true;
}, delay);
};
};復制代碼在事件被觸發n秒后再執行回調，如果在這n秒內又被觸發，則重新計時。
核心思想：每次事件觸發都會刪除原有定時器，建立新的定時器。通俗意思就是反復觸發函數，只認最后一次，從最后一次開始計時。
代碼：
?function debounce(fn, delay) { ? ? ? ? ? ?let timer = null
return function (...args) { ? ? ? ? ? ? ? ?let context = this
if(timer) ? clearTimeout(timer)
timer = setTimeout(function() {
fn.apply(context, args)
},delay)
}
}復制代碼_.debounce?和?_.throttle?方法，可以使用 Lodash 的自定義構建工具，生成一個 2KB 的壓縮庫。使用以下的簡單命令即可：npm i -g lodash-cli
npm i -g lodash-clilodash-cli include=debounce,throttle復制代碼_.debounce?方法：// 錯誤$(window).on('scroll', function() {
_.debounce(doSomething, 300);
});// 正確$(window).on('scroll', _.debounce(doSomething, 200));復制代碼debounced_version.cancel()，lodash 和 underscore.js 都有效。let debounced_version = _.debounce(doSomething, 200);防抖
節流
動畫幀率可以作為衡量標準，一般來說畫面在 60fps 的幀率下效果比較好。
換算一下就是，每一幀要在 16.7ms (16.7 = 1000/60) 內完成渲染。
我們來看看MDN對它的解釋吧??
window.requestAnimationFrame() 方法告訴瀏覽器您希望執行動畫并請求瀏覽器在下一次重繪之前調用指定的函數來更新動畫。該方法使用一個回調函數作為參數，這個回調函數會在瀏覽器重繪之前調用。— MDN
當我們調用這個函數的時候，我們告訴它需要做兩件事：
rAF(requestAnimationFrame) 最大的優勢是「由系統來決定回調函數的執行時機」。
具體一點講就是，系統每次繪制之前會主動調用 rAF 中的回調函數，如果系統繪制率是 60Hz，那么回調函數就每16.7ms 被執行一次，如果繪制頻率是75Hz，那么這個間隔時間就變成了 1000/75=13.3ms。
換句話說就是，rAF 的執行步伐跟著系統的繪制頻率走。它能保證回調函數在屏幕每一次的繪制間隔中只被執行一次(上一個知識點剛剛梳理完「函數節流」)，這樣就不會引起丟幀現象，也不會導致動畫出現卡頓的問題。
另外它可以自動調節頻率。如果callback工作太多無法在一幀內完成會自動降低為30fps。雖然降低了，但總比掉幀好。
與setTimeout動畫對比的話，有以下幾點優勢
規范中似乎是這么去定義的：
這樣子分析的話，似乎很合理嘛，為什么要在重新渲染前去調用呢？因為rAF作為官方推薦的一種做流暢動畫所應該使用的API，做動畫不可避免的去操作DOM，而如果是在渲染后去修改DOM的話，那就只能等到下一輪渲染機會的時候才能去繪制出來了，這樣子似乎不合理。
rAF在瀏覽器決定渲染之前給你最后一個機會去改變 DOM 屬性，然后很快在接下來的繪制中幫你呈現出來，所以這是做流暢動畫的不二選擇。
至于宏任務，微任務，這可以說起來就要展開篇幅了，暫時不在這里梳理了。
跟?_.throttle(dosomething, 16)?等價。它是高保真的，如果追求更好的精確度的話，可以用瀏覽器原生的 API 。
可以使用 rAF API 替換 throttle 方法，考慮一下優缺點：
優點
缺點
根據經驗，如果 JavaScript 方法需要繪制或者直接改變屬性，我會選擇?requestAnimationFrame，只要涉及到重新計算元素位置，就可以使用它。
涉及到 AJAX 請求，添加/移除 class （可以觸發 CSS 動畫），我會選擇?_.debounce?或者?_.throttle?，可以設置更低的執行頻率（例子中的200ms 換成16ms）。
