摘要：還是老規(guī)矩，從易到難吧傳統(tǒng)的定時(shí)器，異步編程等。分配對(duì)象時(shí)，先是在空間中進(jìn)行分配。內(nèi)存泄漏內(nèi)存泄漏是指程序中己動(dòng)態(tài)分配的堆內(nèi)存由于某種原因程序未釋放或無(wú)法釋放，造成系統(tǒng)內(nèi)存的浪費(fèi)，導(dǎo)致程序運(yùn)行速度減慢甚至系統(tǒng)崩潰等嚴(yán)重后果。

網(wǎng)上參差不棄的面試題，本文由淺入深，讓你在做面試官的時(shí)候，能夠辨別出面試者是不是真的有點(diǎn)東西，也能讓你去面試中級(jí)前端工程師更有底氣。但是切記把背誦面試題當(dāng)成了你的唯一求職方向

另外歡迎大家加入我們的前端交流二群～，里面很多小姐姐哦，下篇將是非常硬核的源碼，原理，自己編寫(xiě)框架和庫(kù)等，如果感覺(jué)寫(xiě)得不錯(cuò)，可以關(guān)注給個(gè)star～

越是開(kāi)放性的題目，更能體現(xiàn)回答者的水平，一場(chǎng)好的面試，不僅能發(fā)現(xiàn)面試者的不足，也能找到他的閃光點(diǎn)，還能提升面試官自身的技術(shù)

標(biāo)準(zhǔn)答案：百度上當(dāng)然很多，這里不做闡述，好的回答思路是：

元素消失的方案先列出來(lái)， display:none和visibility: hidden;的區(qū)別，拓展到vue框架的v-if和v-show的區(qū)別，可以搭配回流和重繪來(lái)講解

當(dāng)Render Tree中部分或全部元素的尺寸、結(jié)構(gòu)、或某些屬性發(fā)生改變時(shí)，瀏覽器重新渲染部分或全部文檔的過(guò)程稱(chēng)為回流

下面內(nèi)容會(huì)導(dǎo)致回流:

頁(yè)面首次渲染

瀏覽器窗口大小發(fā)生改變

元素尺寸或位置發(fā)生改變

元素內(nèi)容變化（文字?jǐn)?shù)量或圖片大小等等）

元素字體大小變化

添加或者刪除可見(jiàn)的DOM元素

激活CSS偽類(lèi)（例如：:hover）

查詢(xún)某些屬性或調(diào)用某些方法

一些常用且會(huì)導(dǎo)致回流的屬性和方法：

clientWidth、clientHeight、clientTop、clientLeft

offsetWidth、offsetHeight、offsetTop、offsetLeft

scrollWidth、scrollHeight、scrollTop、scrollLeft

scrollIntoView()、scrollIntoViewIfNeeded()

getComputedStyle()

getBoundingClientRect()

scrollTo()

當(dāng)頁(yè)面中元素樣式的改變并不影響它在文檔流中的位置時(shí)（例如：color、background-color、visibility等），瀏覽器會(huì)將新樣式賦予給元素并重新繪制它，這個(gè)過(guò)程稱(chēng)為重繪。

原文出處，感謝作者

列出元素垂直居中的方案，以及各種方案的缺陷

16種居中方案，感謝作者

講出flex常用的場(chǎng)景，以及flex 1做了什么

阮一峰老師的Flex布局

上面的問(wèn)題如果答得非常好，在重繪和回流這塊要下大功夫。這點(diǎn)是前端性能優(yōu)化的基礎(chǔ)，而性能優(yōu)化是前端最重要的核心基礎(chǔ)技能點(diǎn)，也是面試官最看中的基礎(chǔ)之一

50行javaScript代碼實(shí)現(xiàn)call,apply,bind

這是一個(gè)很基礎(chǔ)的技能點(diǎn)，考察你對(duì)閉包，函數(shù)調(diào)用的理解程度，我感覺(jué)我寫(xiě)得比較簡(jiǎn)單容易懂

這個(gè)題目如果回答非常完美，那么可以判斷這個(gè)人已經(jīng)脫離了初級(jí)前端工程師，前端的核心就是異步編程，這個(gè)題目也是體現(xiàn)前端工程師基礎(chǔ)是否扎實(shí)的最重要依據(jù)。

還是老規(guī)矩，從易到難吧

setTimeout(),setInterval()等。

缺點(diǎn)：當(dāng)同步的代碼比較多的時(shí)候，不確定異步定時(shí)器的任務(wù)時(shí)候能在指定的時(shí)間執(zhí)行。

例如：

在第100行執(zhí)行代碼 setTimeout(()=>{console.log(1)},1000)//1s后執(zhí)行里面函數(shù)

但是后面可能有10000行代碼+很多計(jì)算的任務(wù)，例如循環(huán)遍歷，那么1s后就無(wú)法輸出console.log(1)

可能要到2s甚至更久

setInterval跟上面同理 當(dāng)同步代碼比較多時(shí)，不確保每次能在一樣的間隔執(zhí)行代碼，

如果是動(dòng)畫(huà)，那么可能會(huì)掉幀

promise generator async

 new promise((resolve,reject)=>{ resolve() }).then()....
 缺點(diǎn)： 仍然沒(méi)有擺脫回掉函數(shù)，雖然改善了回掉地獄
 
 generator函數(shù) 調(diào)用next()執(zhí)行到下一個(gè)yeild的代碼內(nèi)容，如果傳入?yún)?shù)則作為上一個(gè)

`yield`的
返回值
 缺點(diǎn)：不夠自動(dòng)化

 async await 
 只有async函數(shù)內(nèi)部可以用await,將異步代碼變成同步書(shū)寫(xiě)，但是由于async函數(shù)本身返回一個(gè)
promise,也很容易產(chǎn)生async嵌套地獄

傳統(tǒng)的javascript 動(dòng)畫(huà)是通過(guò)定時(shí)器 setTimeout 或者 setInterval 實(shí)現(xiàn)的。但是定時(shí)器動(dòng)畫(huà)一直存在兩個(gè)問(wèn)題

第一個(gè)就是動(dòng)畫(huà)的循時(shí)間環(huán)間隔不好確定，設(shè)置長(zhǎng)了動(dòng)畫(huà)顯得不夠平滑流暢，設(shè)置短了瀏覽器的重繪頻率會(huì)達(dá)到瓶頸，推薦的最佳循環(huán)間隔是17ms（大多數(shù)電腦的顯示器刷新頻率是60Hz，1000ms/60）；

第二個(gè)問(wèn)題是定時(shí)器第二個(gè)時(shí)間參數(shù)只是指定了多久后將動(dòng)畫(huà)任務(wù)添加到瀏覽器的UI線程隊(duì)列中，如果UI線程處于忙碌狀態(tài)，那么動(dòng)畫(huà)不會(huì)立刻執(zhí)行。為了解決這些問(wèn)題，H5 中加入了 requestAnimationFrame以及requestIdleCallback

requestAnimationFrame 會(huì)把每一幀中的所有 DOM 操作集中起來(lái)，在一次重繪或回流中就完成，并且重繪或回流的時(shí)間間隔緊緊跟隨瀏覽器的刷新頻率

在隱藏或不可見(jiàn)的元素中，requestAnimationFrame 將不會(huì)進(jìn)行重繪或回流，這當(dāng)然就意味著更少的 CPU、GPU 和內(nèi)存使用量

requestAnimationFrame 是由瀏覽器專(zhuān)門(mén)為動(dòng)畫(huà)提供的 API，在運(yùn)行時(shí)瀏覽器會(huì)自動(dòng)優(yōu)化方法的調(diào)用，并且如果頁(yè)面不是激活狀態(tài)下的話，動(dòng)畫(huà)會(huì)自動(dòng)暫停，有效節(jié)省了 CPU 開(kāi)銷(xiāo)

requestAnimationFrame的回調(diào)會(huì)在每一幀確定執(zhí)行，屬于高優(yōu)先級(jí)任務(wù)，而requestIdleCallback的回調(diào)則不一定，屬于低優(yōu)先級(jí)任務(wù)。

我們所看到的網(wǎng)頁(yè)，都是瀏覽器一幀一幀繪制出來(lái)的，通常認(rèn)為FPS為60的時(shí)候是比較流暢的，而FPS為個(gè)位數(shù)的時(shí)候就屬于用戶(hù)可以感知到的卡頓了，那么在一幀里面瀏覽器都要做哪些事情呢，如下所示：

圖中一幀包含了用戶(hù)的交互、js的執(zhí)行、以及requestAnimationFrame的調(diào)用，布局計(jì)算以及頁(yè)面的重繪等工作。

假如某一幀里面要執(zhí)行的任務(wù)不多，在不到16ms（1000/60)的時(shí)間內(nèi)就完成了上述任務(wù)的話，那么這一幀就會(huì)有一定的空閑時(shí)間，這段時(shí)間就恰好可以用來(lái)執(zhí)行requestIdleCallback的回調(diào)，如下圖所示：

不想解釋太多，看圖

JS 的垃圾回收機(jī)制的基本原理是：

找出那些不再繼續(xù)使用的變量，然后釋放其占用的內(nèi)存，垃圾收集器會(huì)按照固定的時(shí)間間隔周期性地執(zhí)行這一操作。

V8 的垃圾回收策略主要基于分代式垃圾回收機(jī)制，在 V8 中，將內(nèi)存分為新生代和老生代，新生代的對(duì)象為存活時(shí)間較短的對(duì)象，老生代的對(duì)象為存活事件較長(zhǎng)或常駐內(nèi)存的對(duì)象。

V8 堆的整體大小等于新生代所用內(nèi)存空間加上老生代的內(nèi)存空間，而只能在啟動(dòng)時(shí)指定，意味著運(yùn)行時(shí)無(wú)法自動(dòng)擴(kuò)充，如果超過(guò)了極限值，就會(huì)引起進(jìn)程出錯(cuò)。

在分代的基礎(chǔ)上，新生代的對(duì)象主要通過(guò) Scavenge 算法進(jìn)行垃圾回收，在 Scavenge 具體實(shí)現(xiàn)中，主要采用了一種復(fù)制的方式的方法—— Cheney 算法。

Cheney 算法將堆內(nèi)存一分為二，一個(gè)處于使用狀態(tài)的空間叫 From 空間，一個(gè)處于閑置狀態(tài)的空間稱(chēng)為 To 空間。分配對(duì)象時(shí)，先是在 From 空間中進(jìn)行分配。

當(dāng)開(kāi)始進(jìn)行垃圾回收時(shí)，會(huì)檢查 From 空間中的存活對(duì)象，將其復(fù)制到 To 空間中，而非存活對(duì)象占用的空間將會(huì)被釋放。完成復(fù)制后，F(xiàn)rom 空間和 To 空間的角色發(fā)生對(duì)換。

當(dāng)一個(gè)對(duì)象經(jīng)過(guò)多次復(fù)制后依然存活，他將會(huì)被認(rèn)為是生命周期較長(zhǎng)的對(duì)象，隨后會(huì)被移動(dòng)到老生代中，采用新的算法進(jìn)行管理。

還有一種情況是，如果復(fù)制一個(gè)對(duì)象到 To 空間時(shí)，To 空間占用超過(guò)了 25%，則這個(gè)對(duì)象會(huì)被直接晉升到老生代空間中。

對(duì)于老生代中的對(duì)象，主要采用標(biāo)記-清除和標(biāo)記-整理算法。標(biāo)記-清除 和前文提到的標(biāo)記一樣，與 Scavenge 算法相比，標(biāo)記清除不會(huì)將內(nèi)存空間劃為兩半，標(biāo)記清除在標(biāo)記階段會(huì)標(biāo)記活著的對(duì)象，而在內(nèi)存回收階段，它會(huì)清除沒(méi)有被標(biāo)記的對(duì)象。

而標(biāo)記整理是為了解決標(biāo)記清除后留下的內(nèi)存碎片問(wèn)題。

前面的三種算法，都需要將正在執(zhí)行的 JavaScript 應(yīng)用邏輯暫停下來(lái)，待垃圾回收完畢后再恢復(fù)。這種行為叫作“全停頓”（stop-the-world）。

在 V8 新生代的分代回收中，只收集新生代，而新生代通常配置較小，且存活對(duì)象較少，所以全停頓的影響不大，而老生代就相反了。

為了降低全部老生代全堆垃圾回收帶來(lái)的停頓時(shí)間，V8將標(biāo)記過(guò)程分為一個(gè)個(gè)的子標(biāo)記過(guò)程，同時(shí)讓垃圾回收標(biāo)記和JS應(yīng)用邏輯交替進(jìn)行，直到標(biāo)記階段完成。

經(jīng)過(guò)增量標(biāo)記改進(jìn)后，垃圾回收的最大停頓時(shí)間可以減少到原來(lái)的 1/6 左右。

內(nèi)存泄漏（Memory Leak）是指程序中己動(dòng)態(tài)分配的堆內(nèi)存由于某種原因程序未釋放或無(wú)法釋放，造成系統(tǒng)內(nèi)存的浪費(fèi)，導(dǎo)致程序運(yùn)行速度減慢甚至系統(tǒng)崩潰等嚴(yán)重后果。

內(nèi)存泄漏的常見(jiàn)場(chǎng)景：

緩存:存在內(nèi)存中數(shù)據(jù)一只沒(méi)有被清掉

作用域未釋放（閉包）

無(wú)效的 DOM 引用

沒(méi)必要的全局變量

定時(shí)器未清除(React中的合成事件，還有原生事件的綁定區(qū)別)

事件監(jiān)聽(tīng)為清空

內(nèi)存泄漏優(yōu)化

通信協(xié)議全解

我的這篇文章非常詳細(xì)介紹了 http1.0 http1.1 http2.0 https websocket等協(xié)議

性能優(yōu)化不完全手冊(cè)

如何優(yōu)化你的超大型React應(yīng)用

我的這兩篇文章基本上涵蓋了前端基礎(chǔ)的性能優(yōu)化，后期我會(huì)再出專(zhuān)欄。

1.preload,prefetch,dns-prefetch等

什么是preload

使用 preload 指令的好處包括：

允許瀏覽器來(lái)設(shè)定資源加載的優(yōu)先級(jí)因此可以允許前端開(kāi)發(fā)者來(lái)優(yōu)化指定資源的加載。

賦予瀏覽器決定資源類(lèi)型的能力，因此它能分辨這個(gè)資源在以后是否可以重復(fù)利用。

瀏覽器可以通過(guò)指定 as 屬性來(lái)決定這個(gè)請(qǐng)求是否符合 content security policy。

瀏覽器可以基于資源的類(lèi)型（比如 image/webp）來(lái)發(fā)送適當(dāng)?shù)?accept 頭。

Prefetch

Prefetch 是一個(gè)低優(yōu)先級(jí)的資源提示，允許瀏覽器在后臺(tái)（空閑時(shí)）獲取將來(lái)可能用得到的資源，并且將他們存儲(chǔ)在瀏覽器的緩存中。一旦一個(gè)頁(yè)面加載完畢就會(huì)開(kāi)始下載其他的資源，然后當(dāng)用戶(hù)點(diǎn)擊了一個(gè)帶有 prefetched 的連接，它將可以立刻從緩存中加載內(nèi)容。

DNS Prefetching

DNS prefetching 允許瀏覽器在用戶(hù)瀏覽頁(yè)面時(shí)在后臺(tái)運(yùn)行 DNS 的解析。如此一來(lái)，DNS 的解析在用戶(hù)點(diǎn)擊一個(gè)鏈接時(shí)已經(jīng)完成，所以可以減少延遲?？梢栽谝粋€(gè) link 標(biāo)簽的屬性中添加 rel="dns-prefetch" 來(lái)對(duì)指定的 URL 進(jìn)行 DNS prefetching，我們建議對(duì) Google fonts，Google Analytics 和 CDN 進(jìn)行處理。

2.servece-worker,PWA漸進(jìn)式web應(yīng)用

PWA文檔

3.localstorage,sessionstorage,cookie,session等。
瀏覽器的會(huì)話存儲(chǔ)和持久性存儲(chǔ)
4.瀏覽器緩存的實(shí)現(xiàn)機(jī)制的實(shí)現(xiàn)

跨域解決的辦法

Q：為什么會(huì)出現(xiàn)跨域問(wèn)題？

A：出于瀏覽器的同源策略限制，瀏覽器會(huì)拒絕跨域請(qǐng)求。

注：嚴(yán)格的說(shuō)，瀏覽器并不是拒絕所有的跨域請(qǐng)求，實(shí)際上拒絕的是跨域的讀操作。瀏覽器的同源限制策略是這樣執(zhí)行的：

通常瀏覽器允許進(jìn)行跨域?qū)懖僮鳎–ross-origin writes），如鏈接，重定向；

通常瀏覽器允許跨域資源嵌入（Cross-origin embedding），如 img、script 標(biāo)簽；

通常瀏覽器不允許跨域讀操作（Cross-origin reads）。

Q：什么情況才算作跨域？

A：非同源請(qǐng)求，均為跨域。名詞解釋?zhuān)和?—— 如果兩個(gè)頁(yè)面擁有相同的協(xié)議（protocol），端口（port）和主機(jī)（host），那么這兩個(gè)頁(yè)面就屬于同一個(gè)源（origin）。

Q：為什么有跨域需求?

A：場(chǎng)景 —— 工程服務(wù)化后，不同職責(zé)的服務(wù)分散在不同的工程中，往往這些工程的域名是不同的，但一個(gè)需求可能需要對(duì)應(yīng)到多個(gè)服務(wù)，這時(shí)便需要調(diào)用不同服務(wù)的接口，因此會(huì)出現(xiàn)跨域。

方法：JSONP,CORS,postmessage,webscoket，反向代理服務(wù)器等。

上篇已經(jīng)結(jié)束，歡迎你關(guān)注，等待下篇非常硬核的文章出爐～

期待你加入我們哦～

現(xiàn)在一群滿(mǎn)了，所以新開(kāi)了一個(gè)二群