記一次前端面試的全過程

時間 2019-11-06

原文原文鏈接

引言

接上一篇面試總結一年半經驗，百度、有贊、阿里面試總結，把這段時間的面試總結結束一下吧。css

本文主要記錄一下當天面試的全過程（可能有遺漏，事隔三四天了，我已經儘可能回憶了），答案亦爲參考答案，僅供借鑑。前端

正文

有贊一面結束後過了兩天就收到了二面的邀請，我回復面試邀請的短信，說最近可能請假太多，能不能約到晚上面試，對方很很爽快的答應了，就約在了晚上七點半，我回復能夠的，而後次日，收到了確切的面試的時間和地點，時間定在了晚上7點15分。webpack

到了面試當天，我提早了五分鐘下班，照着百度地圖的提示路線（約1小時9分鐘），到了公交站等車。。。而後等呀等，等了十五分鐘公交還沒來，怕本身遲到，就打了個滴滴過去，到了面試地點以後上到了公司的前臺，前臺沒有人，多是由於到飯點了，前臺去吃飯了吧。而後看到前臺那層樓好多人在打乒乓球，你們也玩得挺開心，看起來環境也很不錯，當時想，誒呀，原來有讚的環境這麼好。等了一下子以後，看了一下短信，發現面試邀請裏留有面試官的聯繫電話，果斷打了過去，過了一下子面試官到前臺接我，而後找了一個會議室，開始了當天的面試。web

面試官：先自我介紹吧面試

我：巴拉巴拉...segmentfault

面試官：先說一下你上一家公司的研發部署流程瀏覽器

我：巴拉巴拉...(其實這個是我絕活，每次均可以吹好久)緩存

面試官：既然大家是文件覆蓋式發佈，那大家的緩存是怎麼刷新的性能優化

我：從公司的業務出發，巴拉巴拉...（還沒說完）

面試官：那我如今就不談業務，你說一下瀏覽器的緩存方案吧

我：哦，脫離業務呀，首先，瀏覽器有兩種緩存方案，一種是強緩存一種是協商緩存。

面試官：嗯，那怎麼使用強緩存？

我：瀏覽器在第一次請求資源的時候，服務端響應頭裏能夠設置expires字段，該字段表示該資源的緩存過時時間，第二次請求的時候，若是時間還在該緩存時間以內，則會直接使用緩存，不然從新加載資源，這個expires字段有個缺陷，就是它必須服務端和客戶端的時間嚴格同步才能生效，因此如今不少人不會使用改方案。另一種方案是第一次請求資源的時候，服務端設置響應頭cache-control: max-age，這樣設置的意思是告訴瀏覽器，這個資源何時過時，等第二次請求資源的時候，判斷是否超出了過時時間，若是沒超出，直接使用緩存。

面試官：cache-control這個頭是服務端設置的仍是客戶端設置的？

我：cache-control服務端設置的

面試官：cache-control的其餘值，你也說一下吧

我：首先是public，客戶端和服務端均可以緩存；而後是private，只能客戶端緩存；no-store，不使用緩存；no-cache，使用協商緩存。

面試官：那你往下說，說一下協商緩存

我：協商緩存有兩種，一種是Last-Modified，就是第一次請求資源的時候，服務端會在響應頭裏面設置該字段，表示該資源的最後修改時間，瀏覽器第二次請求該資源的時候，會在請求頭裏面加上一個字段If-Modified-Since，值爲第一次請求的時候服務端返回的Last-Modified的值，服務端會判斷資源當時的最後更改時間與請求頭裏面的If-Modified-Since字段是否相同，若是相同，則告訴客戶端使用緩存，不然從新下載資源。而後另一種協商緩存時使用ETag，原理與Last-Modified相似，就是第一次請求的時候，服務端會根據資源的內容或者最後修改時間生成一個標識，而後在響應頭裏面設置爲ETag返回給客戶端，客戶端第二次請求的時候會在請求頭裏面帶上這個ETag，也就是在請求頭裏面加上If-None-Match字段，服務端接收到了ETag以後判斷是否與原來第一次的標識相同，若是相同，則告訴客戶端使用緩存。

說一下Last-modified/If-Modified-Since和If-None-Match/ETag兩種方案的優缺點

我：嗯呢，這個我想想（我並不知道，僞裝思考一下）......我以爲其實ETag其實也是有的時候是根據資源的最後修改時間生成的，原理和Last-modified好像有點相似，而ETag須要耗費服務端的資源去生成，因此性能較低。。。（雖然不會，也儘可能說說，萬一面試官也不知道呢。哈哈哈哈）

面試官：那說一下性能優化的方案吧

我：首先，減小HTTP請求次數，好比說合並CSS和JS文件，可是也不要徹底的合併在同一個文件裏面，一個域名分散三四個資源，這樣方便瀏覽器去並行下載，固然瀏覽器對每一個域名的並行下載個數有限制，一個域名分配三四個資源雖然增長了HTTP請求數量，可是對比並行下載來講，性價比更高。

面試官：爲何瀏覽器要限制同一域名並行下載資源的個數。

我：嗯呢，這個我也想一下（其實我也不知道）......這個我沒有深究過，難道是由於瀏覽器啓動了太多下載線程的緣由？

面試官：下載資源和線程有什麼關係？

我：除了了每一個標籤頁是一個進程之外，瀏覽器有一個進程是專門用來管理下載，我以爲大概是每下載一個資源啓動一個線程吧（反正我也不知道，也猜猜結果是否是這樣）

面試官：（沉默了一下子），進程和線程區別是什麼

我：進程是分配內存的最小單位，線程是CPU調度的最小單位，進程能夠包含多個線程。

面試官：nodejs用得多嗎？說一下nodejs進程之間是怎麼通訊的

我：nodejs用的比較少，nodejs能夠啓動子線程，而後用主線程來監聽訂閱子線程的消息，子線程之間的通訊，由主線程來控制。（大概錯了吧，應該是進程）

面試官：好吧，性能優化繼續往下說

我：減小HTTP請求數量還能夠把圖標合併在同一張圖片裏面，使用的時候用background-position去控制。而後首屏的時候圖片使用懶加載的形式，儘可能在須要顯示的時候在加載它，固然佔位符和圖片儘可能指定寬度和高度，避免圖片加載完以後替換圖片瀏覽器會進行迴流。

面試官：圖片懶加載怎麼實現

我：監聽瀏覽器的滾動事件，結合clientHeight、offsetHeight、scrollTop、scrollHeight等等變量計算當前圖片是否在可視區域，若是在，則替換src加載圖片，固然這個滾動事件要主要節流。

面試官：怎麼判斷圖片是否加載完成

我：使用onload事件。

面試官：好吧，你繼續往下說。

我：性能優化的話，還能夠合理的利用緩存，儘可能把CSS和JS文件使用外鏈的形式，雖然使用內聯的CSS和JS在空緩存的時候更快，由於內聯的樣式和腳本不須要發送HTTP請求，可是爲了儘可能發揮瀏覽器的緩存功能，儘可能使用外鍊形式。

我：而後儘可能把CSS放在頭部，JS放在底部。

面試官：假如如今頁面裏放在head的css文件下載速度很慢，頁面會出現什麼狀況？

我：大概頁面會等待這個CSS的下載，這個時候頁面是白屏狀態，而後這個CSS資源會有一個超時時間，假如超過了這個超時時間，這個資源至關於會下載失敗，瀏覽器會直接跳過這個CSS資源，根據已有的CSS資源生成CSS規則樹，進而生成Render樹，而後渲染頁面。

面試官：假如我如今在頁面動態添加了一個CSS文件，頁面必定會迴流嗎？

我：只要加入的CSS影響到了頁面的結構，那麼瀏覽器就會迴流。

面試官：例如頁面這個CSS文件中有translate3d呢？

我：其實我感受它不會迴流，由於translate3d只是變換了本身的位置，不會影響其餘元素的位置，可是其實是會形成迴流的。

面試官：那假如我在頁面裏面加了一個<div style="position:absolute;width:0;hegiht:0"></div>呢，會迴流嗎

我：不會，由於沒有影響頁面結構的變化。

面試官：好吧，那你繼續往下說

我：性能優化，儘可能使用CDN。

面試官：CDN的原理是啥？

我：首先，瀏覽器會先請求CDN域名，CDN域名服務器會給瀏覽器返回指定域名的CNAME，瀏覽器在對這些CNAME進行解析，獲得CDN緩存服務器的IP地址，瀏覽器在去請求緩存服務器，CDN緩存服務器根據內部專用的DNS解析獲得實際IP，而後緩存服務器會向實際IP地址請求資源，緩存服務器獲得資源後進行本地保存和返回給瀏覽器客戶端。

面試官：你來實現如下剛剛說的節流函數吧

。。。當時有點不記得什麼是防抖，什麼節流，把函數寫成了防抖。（這個時候有一我的走進了會議室，好像是一面小哥）

var debounce = function(fn, delay, context) {
  let timer = null;
  return function() {
    if (timer) {
      clearTimeout(timer);
    }
    timer = setTimeout(() => {
      const arg = Array.prototype.slice.call(arguments);
      fn.apply(context, arg);
    }, delay)
  }
}

// 測試部分
var run = function(text) {
  console.log(text);
}

run = debounce(run, 200);

run('run1');
run('run2');

setTimeout(() => {
  run('run3');
}, 201)

複製代碼