前端面試資源整理（一）

紫日殘月發表於2018-03-20
前端面試

Js相關

執行環節和作用域

執行環節定義了函式或者變數可以訪問的其它資料，決定了他們各自的行為。
每個執行環境都有一個與之關聯的變數物件，在環境中定義的所有變數和函式都儲存在這個變數中，並且是我們無法訪問。
每個函式都有自己的執行環境，當執行流進入一個函式的時候，就把函式的執行環境壓入執行環境棧，執行完畢後，再將環境推出，把控制權交給之前的執行環境。

當程式碼在一個環境中執行的時候，會建立變數物件的作用域鏈，作用域鏈的用途是保證對執行環境有權訪問的所有變數和函式的有序訪問。
作用域鏈的前端,始終都是當前執行程式碼所在環境的變數物件.如果這個環境是函式,則將其活動物件作為變數物件.作用域鏈中的下一個變數物件來自包含環境,最終到全域性物件window.
延長作用域鏈 try catch 和 with語句.

垃圾回收機制

  1. 標記清除 (比較常用)

垃圾收集器在執行的時候會給儲存在記憶體中的所有變數都加上標記,然後,他會去掉環境中的變數以及被環境中變數引用的變數的標記.
而在此之後有標記的變數將被視為準備刪除的變數.

  1. 引用計數.

跟蹤記錄每個值被引用的次數 ,通過引用來適當增加他的引用次數,當引用計數為0時,表明該變數可以被清除.

typeof 操作符

undefiend/變數未定義 boolean/布林值 string/字串 number/數值 object物件或者null function/函式 symbol/Symbol

相等(==)規則

  1. 如果有一個運算元為布林值,則先轉為數值(false 0 true 1);
  2. 如果一個運算元為字串,另一個為數值,將字串轉換為數值
  3. 如果一個運算元為物件,另一個不是,呼叫物件的valurOf方法,用得到的原始值呼叫之前的規則比較;

[注意]:

  1. null和 undefiend是相等的;
  2. 比較之前,不能見null和undefined轉換為其他任何值;
  3. 如果有一個運算元為NaN,返回false,即便兩個NaN比較也是false
  4. 如果兩個都是物件,比較是不是同一個物件,如果兩個運算元指向同一個物件,返回true.

全等(===)規則

全等比較前不會轉換運算元,其他情況一樣.

瀏覽器快取

可以分為 強快取和協商快取

1.強快取：不會向伺服器傳送請求，直接從快取中讀取資源，在chrome控制檯的network選項中可以看到該請求返回200的狀態碼，並且size顯示from disk cache或from memory cache；

2.協商快取：向伺服器傳送請求，伺服器會根據這個請求的request header的一些引數來判斷是否命中協商快取，如果命中，則返回304狀態碼並帶上新的response header通知瀏覽器從快取中讀取資源；

3.兩者的共同點是，都是從客戶端快取中讀取資源；區別是強快取不會發請求，協商快取會發請求

強快取

Expires：response header裡的過期時間，瀏覽器再次載入資源時，如果在這個過期時間內，則命中強快取。

Cache-Control：當值設為max-age=300時，則代表在這個請求正確返回時間（瀏覽器也會記錄下來）的5分鐘內再次載入資源，就會命中強快取。

Expires和Cache-Control:max-age=* 的作用是差不多的，區別就在於 Expires 是http1.0的產物，Cache-Control是http1.1的產物，兩者同時存在的話，Cache-Control優先順序高於Expires；在某些不支援HTTP1.1的環境下，Expires就會發揮用處。所以Expires其實是過時的產物，現階段它的存在只是一種相容性的寫法

協商快取

ETag和If-None-Match：這兩個要一起說。Etag是上一次載入資源時，伺服器返回的response header，是對該資源的一種唯一標識，只要資源有變化，Etag就會重新生成。瀏覽器在下一次載入資源向伺服器傳送請求時，會將上一次返回的Etag值放到request header裡的If-None-Match裡，伺服器接受到If-None-Match的值後，會拿來跟該資原始檔的Etag值做比較，如果相同，則表示資原始檔沒有發生改變，命中協商快取。

Last-Modified和If-Modified-Since：這兩個也要一起說。Last-Modified是該資原始檔最後一次更改時間，伺服器會在response header裡返回，同時瀏覽器會將這個值儲存起來，在下一次傳送請求時，放到request header裡的If-Modified-Since裡，伺服器在接收到後也會做比對，如果相同則命中協商快取。

區別

首先在精確度上，Etag要優於Last-Modified。Last-Modified的時間單位是秒，如果某個檔案在1秒內改變了多次，那麼他們的Last-Modified其實並沒有體現出來修改，但是Etag每次都會改變確保了精度；如果是負載均衡的伺服器，各個伺服器生成的Last-Modified也有可能不一致。

第二在效能上，Etag要遜於Last-Modified，畢竟Last-Modified只需要記錄時間，而Etag需要伺服器通過演算法來計算出一個hash值。

第三在優先順序上，伺服器校驗優先考慮Etag。

瀏覽器快取過程

瀏覽器第一次載入資源，伺服器返回200，瀏覽器將資原始檔從伺服器上請求下載下來，並把response header及該請求的返回時間一併快取；

下一次載入資源時，先比較當前時間和上一次返回200時的時間差，如果沒有超過cache-control設定的max-age，則沒有過期，命中強快取，不發請求直接從本地快取讀取該檔案（如果瀏覽器不支援HTTP1.1，則用expires判斷是否過期）；如果時間過期，則向伺服器傳送header帶有If-None-Match和If-Modified-Since 的請求；

伺服器收到請求後，優先根據Etag的值判斷被請求的檔案有沒有做修改，Etag值一致則沒有修改，命中協商快取，返回304；如果不一致則有改動，直接返回新的資原始檔帶上新的Etag值並返回 200；

如果伺服器收到的請求沒有Etag值，則將If-Modified-Since和被請求檔案的最後修改時間做比對，一致則命中協商快取，返回304；不一致則返回新的last-modified和檔案並返回 200；

使用者行為對瀏覽器快取的控制

位址列訪問，連結跳轉是正常使用者行為，將會觸發瀏覽器快取機制；

F5重新整理，瀏覽器會設定max-age=0，跳過強快取判斷，會進行協商快取判斷；

ctrl+F5重新整理，跳過強快取和協商快取，直接從伺服器拉取資源。

跨域

什麼是跨域

說到跨域,首先就要提到一個前端的安全概念,即瀏覽器的同源策略.
簡單來說,就是瀏覽器為了保證使用者資訊的安全，防止惡意的網站竊取資料,只允許同源的js指令碼操作本頁面。
那如果我們需要在同一個頁面中請求非同源的資料怎麼辦呢？這個就涉及到跨域問題了。

什麼是同源

同源需要同時滿足以下三個條件：

  1. 協議相同
  2. 域名相同
  3. 埠相同

注意：父域名一樣，子域名不一樣也是非同源的。

同源限制

如果非同源,以下三種行為將受到限制:
（1） Cookie、LocalStorage 和 IndexDB 無法讀取。
（2） DOM 無法獲得。
（3） AJAX 請求不能傳送。

跨域方法

  1. JSONP

這是一種最常用也是支援度比較高的跨域方式，其原理動態插入script標籤，通過script標籤引入一個js檔案，這個js檔案載入成功後會執行我們在url引數中指定的函式，並且會把我們需要的json資料作為引數傳入。

優點是相容性好，簡單易用，支援瀏覽器與伺服器雙向通訊。缺點是隻支援GET請求。

  1. CORS

伺服器端對於CORS的支援，主要就是通過設定Access-Control-Allow-Origin來進行的。如果瀏覽器檢測到相應的設定，就可以允許Ajax進行跨域的訪問。
以上兩種方式主要用來跟後臺資料互動.

  1. 通過修改document.domain來跨子域

將子域和主域的document.domain設為同一個主域.前提條件：這兩個域名必須屬於同一個基礎域名!而且所用的協議，埠都要一致，否則無法利用document.domain進行跨域
主域相同的使用document.domain
此方法可以用來解決跨域cookie本地儲存的跨域訪問,LocalStorage 和 IndexDB 無法通過這種方法，規避同源政策，而要使用下文介紹的PostMessage API。

  1. 使用window.name來進行跨域

window物件有個name屬性，該屬性有個特徵：即在一個視窗(window)的生命週期內,視窗載入的所有的頁面都是共享一個window.name的，每個頁面對window.name都有讀寫的許可權，window.name是持久存在一個視窗載入過的所有頁面中的
以上兩種主要用在 使用`iframe來實現頁面結構的頁面.完成DOM之間的跨域互動.

  1. 使用HTML5中新引進的window.postMessage方法來跨域傳送資料

該方法允許跨視窗通訊，不論這兩個視窗是否同源。
方法的第一個引數是具體的資訊內容，第二個引數是接收訊息的視窗的源（origin），即”協議 + 域名 + 埠”。也可以設為*，表示不限制域名，向所有視窗傳送。
postMessage/addEventListener 基本類似於一個全域性的事件管理器.可以通過這兩個介面來傳送/監聽 事件,從而完成資訊互動.

節流

不管怎麼觸發，都是按照指定的間隔來執行，同樣給個基本版。

請輸入程式碼function throttle(func, wait) {
  var timer
  return function() {
    var context = this
    var args = arguments
    if (!timer) {
      timer = setTimeout(function () {
        timer = null
        func.apply(context, args)
      }, wait)
    }
  }
}

防抖

不管你觸發多少次，都等到你最後觸發後過一段你指定的時間才觸發。按照這個解釋，寫一個基本版的。

function debounce(func, wait) {
  var timer
  return function() {
    var context = this
    var args = arguments
    clearTimeout(timer)
    timer = setTimeout(function() {
      func.apply(context, args)
    }, wait)
  }
}

HTMl&Css

元素水平居中

  • 如果需要居中的元素為常規流中inline元素，為父元素設定text-align: center;即可實現
  • 如果需要居中的元素為常規流中block元素，1）為元素設定寬度，2）設定左右margin為auto。3）IE6下需在父元素上設定text-align: center;,再給子元素恢復需要的值
  • 如果需要居中的元素為浮動元素，1）為元素設定寬度，2）position: relative;，3）浮動方向偏移量（left或者right）設定為50%，4）浮動方向上的margin設定為元素寬度一半乘以-1
  • 如果需要居中的元素為絕對定位元素，1）為元素設定寬度，2）偏移量設定為50%，3）偏移方向外邊距設定為元素寬度一半乘以-1
  • 如果需要居中的元素為絕對定位元素，1）為元素設定寬度，2）設定左右偏移量都為0,3）設定左右外邊距都為auto

元素豎直居中

  • 需要居中元素為單行文字，為包含文字的元素設定大於font-size的line-height：

如塊級格式化上下文

(block formatting context),
建立規則：

  1. 根元素（html）
  2. 浮動元素（float不是none）
  3. 絕對定位元素（position取值為absolute或fixed）
  4. display取值為inline-block,table-cell, table-caption,flex, inline-flex之一的元素
  5. overflow不是visible的元素

作用：

  1. 可以包含浮動元素
  2. 不被浮動元素覆蓋
  3. 阻止父子元素的margin摺疊

CSS元素匹配

　　根據css rules 與dom tree 生成render tree。瀏覽器先產生一個元素集合，這個集合往往由最後一個部分的索引產生（如果沒有索引就是所有元素的集合）。
然後向上匹配，如果不符合上一個部分，就把元素從集合中刪除，直到真個選擇器都匹配完，還在集合中的元素就匹配這個選擇器了。

舉個例子，有選擇器：
body.ready #wrapper > .lol233
　　先把所有 class 中有 lol233 的元素拿出來組成一個集合，然後上一層，對每一個集合中的元素，如果元素的 parent id 不為 #wrapper 則把元素從集合中刪去。 再向上，從這個元素的父元素開始向上找，沒有找到一個 tagName 為 body 且 class 中有 ready 的元素，就把原來的元素從集合中刪去。至此這個選擇器匹配結束，所有還在集合中的元素滿足。

為什麼從後往前匹配因為效率和文件流的解析方向。

　　1）效率，找元素的父親和之前的兄弟比遍歷所有兒子快而且方便。

　　2）關於文件流的解析方向，是因為現在的 CSS，一個元素只要確定了這個元素在文件流之前出現過的所有元素，就能確定他的匹配情況。應用在即使 html 沒有載入完成，瀏覽器也能根據已經載入的這一部分資訊完全確定出現過的元素的屬性。

為什麼是用集合

主要也還是效率。
基於 CSS Rule 數量遠遠小於元素數量的假設和索引的運用，遍歷每一條 CSS Rule 通過集合篩選，比遍歷每一個元素再遍歷每一條 Rule 匹配要快得多。

position四個值的區別

先看下各個屬性值的定義：

1、static：預設值。沒有定位，元素出現在正常的流中（忽略 top, bottom, left, right 或者 z-index 宣告）。

2、relative：生成相對定位的元素，通過top,bottom,left,right的設定相對於其正常位置進行定位。可通過z-index進行層次分級。

3、absolute：生成絕對定位的元素，相對於 static 定位以外的第一個父元素進行定位。元素的位置通過 “left”, “top”, “right” 以及 “bottom” 屬性進行規定。可通過z-index進行層次分級。

4、fixed：生成絕對定位的元素，相對於瀏覽器視窗進行定位。元素的位置通過 “left”, “top”, “right” 以及 “bottom” 屬性進行規定。可通過z-index進行層次分級。

static與fixed的定位方式較好理解，在此不做分析。下面對應用的較多的relative和absolute進行分析：

1、relative。定位為relative的元素脫離正常的文字流中，但其在文字流中的位置依然存在，依然佔有原來的位置，後面的元素無法向前補充。

2、absolute。定位為absolute的層脫離正常文字流，但與relative的區別是其在正常流中的位置不在存在，相當於被提升到另一個層面去了，後面的元素會補佔它的位置。

relative與absolute的主要區別：

首先，是上面已經提到過的在正常流中的位置存在與否。

其次，relative定位的層總是相對於其最近的父元素，absolute定位的層總是相對於其最近的定義為absolute或 relative的父層，而這個父層並不一定是其直接父層。如果其父層中都未定義absolute或relative，則其將相對body進行定位。

fixed：生成絕對定位的元素，相對於瀏覽器視窗進行定位。

響應式設計和自適應設計

　　自適應佈局（Adaptive Layout）

　　自適應佈局（Adaptive）的特點是分別為不同的螢幕解析度定義佈局。佈局切換時頁面元素髮生改變，但在每個佈局中，頁面元素不隨視窗大小的調整發生變化。
就是說你看到的頁面，裡面元素的位置會變化而大小不會變化；你可以把自適應佈局看作是靜態佈局的一個系列。

　　流式佈局（Liquid Layout）

　　流式佈局（Liquid）的特點（也叫”Fluid”) 是頁面元素的寬度按照螢幕進行適配調整，主要的問題是如果螢幕尺度跨度太大，那麼在相對其原始設計而言過小或過大的螢幕上不能正常顯示。

　　響應式佈局（Responsive Layout）

分別為不同的螢幕解析度定義佈局，同時，在每個佈局中，應用流式佈局的理念，即頁面元素寬度隨著視窗調整而自動適配。

可以把響應式佈局看作是流式佈局和自適應佈局設計理念的融合。

其它

HTTP狀態碼及其含義

1XX 提示資訊 – 表示請求已被成功接收，繼續處理

100 (繼續) 請求者應當繼續提出請求。 伺服器返回此程式碼表示已收到請求的第一部分，正在等待其餘部分。
101 (切換協議) 請求者已要求伺服器切換協議，伺服器已確認並準備切換。

2XX 成功 – 表示請求已被成功接收，理解，接受
200 (成功) 伺服器已成功處理了請求。 通常，這表示伺服器提供了請求的網頁。
201 (已建立) 請求成功並且伺服器建立了新的資源。

3XX 重定向 – 要完成請求必須進行更進一步的處理
304 (未修改) 自從上次請求後，請求的網頁未修改過。 伺服器返回此響應時，不會返回網頁內容。

4XX 客戶端錯誤 – 請求有語法錯誤或請求無法實現
400 (錯誤請求) 伺服器不理解請求的語法。
401 (未授權) 請求要求身份驗證。 對於需要登入的網頁，伺服器可能返回此響應。
403 (禁止) 伺服器拒絕請求。
404 (未找到) 伺服器找不到請求的網頁。

5XX 伺服器端錯誤 – 伺服器未能實現合法的請求
500 (伺服器內部錯誤) 伺服器遇到錯誤，無法完成請求。
501 (尚未實施) 伺服器不具備完成請求的功能。 例如，伺服器無法識別請求方法時可能會返回此程式碼。
502 (錯誤閘道器) 伺服器作為閘道器或代理，從上游伺服器收到無效響應。
503 (服務不可用) 伺服器目前無法使用(由於超載或停機維護)。 通常，這只是暫時狀態。
504 (閘道器超時) 伺服器作為閘道器或代理，但是沒有及時從上游伺服器收到請求。
505 (HTTP 版本不受支援) 伺服器不支援請求中所用的 HTTP 協議版本。

sessionStorage,localStorage,cookie區別

  1. 都會在瀏覽器端儲存，有大小限制，同源限制
  2. cookie會在請求時傳送到伺服器，作為會話標識，伺服器可修改cookie；web storage不會傳送到伺服器
  3. cookie有path概念，子路徑可以訪問父路徑cookie，父路徑不能訪問子路徑cookie
  4. 有效期：cookie在設定的有效期內有效，預設為瀏覽器關閉；sessionStorage在視窗關閉前有效，localStorage長期有效，直到使用者刪除
  5. 共享：sessionStorage不能共享，localStorage在同源文件之間共享，cookie在同源且符合path規則的文件之間共享
  6. localStorage的修改會促發其他文件視窗的update事件
  7. cookie有secure屬性要求HTTPS傳輸
  8. 瀏覽器不能儲存超過300個cookie，單個伺服器不能超過20個，每個cookie不能超過4k。web storage大小支援能達到5M

網站優化

  • content方面

    1. 減少HTTP請求：合併檔案、CSS精靈、inline Image
    2. 減少DNS查詢：DNS查詢完成之前瀏覽器不能從這個主機下載任何任何檔案。方法：DNS快取、將資源分佈到恰當數量的主機名，平衡並行下載和DNS查詢
    3. 避免重定向：多餘的中間訪問
    4. 使Ajax可快取
    5. 非必須元件延遲載入
    6. 未來所需元件預載入
    7. 減少DOM元素數量
    8. 將資源放到不同的域下：瀏覽器同時從一個域下載資源的數目有限，增加域可以提高並行下載量
    9. 減少iframe數量
    10. 不要404

  • Server方面

    1. 使用CDN
    2. 新增Expires或者Cache-Control響應頭
    3. 對元件使用Gzip壓縮
    4. 配置ETag
    5. Flush Buffer Early
    6. Ajax使用GET進行請求
    7. 避免空src的img標籤

  • Cookie方面

    1. 減小cookie大小
    2. 引入資源的域名不要包含cookie

  • css方面

    1. 將樣式表放到頁面頂部
    2. 不使用CSS表示式
    3. 使用<link>不使用@import
    4. 不使用IE的Filter

  • Javascript方面

    1. 將指令碼放到頁面底部
    2. 將javascript和css從外部引入
    3. 壓縮javascript和css
    4. 刪除不需要的指令碼
    5. 減少DOM訪問
    6. 合理設計事件監聽器

  • 圖片方面

    1. 優化圖片：根據實際顏色需要選擇色深、壓縮
    2. 優化css精靈
    3. 不要在HTML中拉伸圖片
    4. 保證favicon.ico小並且可快取

  • 移動方面

    1. 保證元件小於25k
    2. Pack Components into a Multipart Document
  • 檔案合併， 減少呼叫其他頁面、檔案的數量。
  • 檔案最小化/檔案壓縮

即將需要傳輸的內容壓縮後傳輸到客戶端再解壓，這樣在網路上傳輸的 資料量就會大幅減小。通常在伺服器上的Apache、Nginx可以直接開啟這個設定，也可以從程式碼角度直接設定傳輸檔案頭，增加gzip的設定，也可以 從 負載均衡裝置直接設定。不過需要留意的是，這個設定會略微增加伺服器的負擔。建議伺服器效能不是很好的網站，要慎重考慮。

  • 使用 CDN 託管

CDN的全稱是Content Delivery Network，即內容分發網路。其基本思路是儘可能避開網際網路上有可能影響資料傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。其目的是使使用者可就近取得所需內容，解決 Internet網路擁擠的狀況，提高使用者訪問網站的響應速度。

  • 快取的使用

Ajax呼叫都採用快取呼叫方式，一般採用附加特徵引數方式實現，注意其中的<script src=”xxx.js?{VERHASH}”，{VERHASH}就是特徵引數，這個引數不變化就使用快取檔案，如果發生變化則重新下載新檔案或更新資訊。

  • css檔案放置在head，js放置在文件尾部
  • 在伺服器端配置control-cache last-modify-date
  • 在伺服器配置Entity-Tag if-none-match
  • 可再結合H5新特性裡的預載入，圖片優化方面，可對圖片進行壓縮，JPG的推薦jpegmin這個軟體，png的推薦https://tinypng.com/，前面這兩個是壓縮後不會失真的，gif的推薦GIF Optimizer，但可能會有毛邊。

從瀏覽器位址列輸入url到顯示頁面的步驟(以HTTP為例)

  1. 在瀏覽器位址列輸入URL

  2. 瀏覽器檢視快取，如果請求資源在快取中並且新鮮，跳轉到轉碼步驟

    1. 如果資源未快取，發起新請求
    2. 如果已快取，檢驗是否足夠新鮮，足夠新鮮直接提供給客戶端，否則與伺服器進行驗證。

    3. 檢驗新鮮通常有兩個HTTP頭進行控制Expires和Cache-Control：

      • HTTP1.0提供Expires，值為一個絕對時間表示快取新鮮日期
      • HTTP1.1增加了Cache-Control: max-age=,值為以秒為單位的最大新鮮時間
  3. 瀏覽器解析URL獲取協議，主機，埠，path
  4. 瀏覽器組裝一個HTTP（GET）請求報文

  5. 瀏覽器獲取主機ip地址，過程如下：

    1. 瀏覽器快取
    2. 本機快取
    3. hosts檔案
    4. 路由器快取
    5. ISP DNS快取
    6. DNS遞迴查詢（可能存在負載均衡導致每次IP不一樣）

  6. 開啟一個socket與目標IP地址，埠建立TCP連結，三次握手如下：

    1. 客戶端傳送一個TCP的SYN=1，Seq=X的包到伺服器埠
    2. 伺服器發回SYN=1， ACK=X+1， Seq=Y的響應包
    3. 客戶端傳送ACK=Y+1， Seq=Z
  7. TCP連結建立後傳送HTTP請求
  8. 伺服器接受請求並解析，將請求轉發到服務程式，如虛擬主機使用HTTP Host頭部判斷請求的服務程式
  9. 伺服器檢查HTTP請求頭是否包含快取驗證資訊如果驗證快取新鮮，返回304等對應狀態碼
  10. 處理程式讀取完整請求並準備HTTP響應，可能需要查詢資料庫等操作
  11. 伺服器將響應報文通過TCP連線傳送回瀏覽器

  12. 瀏覽器接收HTTP響應，然後根據情況選擇關閉TCP連線或者保留重用，關閉TCP連線的四次握手如下：

    1. 主動方傳送Fin=1， Ack=Z， Seq= X報文
    2. 被動方傳送ACK=X+1， Seq=Z報文
    3. 被動方傳送Fin=1， ACK=X， Seq=Y報文
    4. 主動方傳送ACK=Y， Seq=X報文
  13. 瀏覽器檢查響應狀態嗎：是否為1XX，3XX， 4XX， 5XX，這些情況處理與2XX不同
  14. 如果資源可快取，進行快取
  15. 對響應進行解碼（例如gzip壓縮）
  16. 根據資源型別決定如何處理（假設資源為HTML文件）
  17. 解析HTML文件，構件DOM樹，下載資源，構造CSSOM樹，執行js指令碼，這些操作沒有嚴格的先後順序，以下分別解釋

  18. 構建DOM樹：

    1. Tokenizing：根據HTML規範將字元流解析為標記
    2. Lexing：詞法分析將標記轉換為物件並定義屬性和規則
    3. DOM construction：根據HTML標記關係將物件組成DOM樹
  19. 解析過程中遇到圖片、樣式表、js檔案，啟動下載

  20. 構建CSSOM樹：

    1. Tokenizing：字元流轉換為標記流
    2. Node：根據標記建立節點
    3. CSSOM：節點建立CSSOM樹

  21. 根據DOM樹和CSSOM樹構建渲染樹:

    1. 從DOM樹的根節點遍歷所有可見節點，不可見節點包括：1）script,meta這樣本身不可見的標籤。2)被css隱藏的節點，如display: none
    2. 對每一個可見節點，找到恰當的CSSOM規則並應用
    3. 釋出可視節點的內容和計算樣式

  22. js解析如下：

    1. 瀏覽器建立Document物件並解析HTML，將解析到的元素和文字節點新增到文件中，此時document.readystate為loading
    2. HTML解析器遇到沒有async和defer的script時，將他們新增到文件中，然後執行行內或外部指令碼。這些指令碼會同步執行，並且在指令碼下載和執行時解析器會暫停。這樣就可以用document.write()把文字插入到輸入流中。同步指令碼經常簡單定義函式和註冊事件處理程式，他們可以遍歷和操作script和他們之前的文件內容
    3. 當解析器遇到設定了async屬性的script時，開始下載指令碼並繼續解析文件。指令碼會在它下載完成後儘快執行，但是解析器不會停下來等它下載。非同步指令碼禁止使用document.write()，它們可以訪問自己script和之前的文件元素
    4. 當文件完成解析，document.readState變成interactive
    5. 所有defer指令碼會按照在文件出現的順序執行，延遲指令碼能訪問完整文件樹，禁止使用document.write()
    6. 瀏覽器在Document物件上觸發DOMContentLoaded事件
    7. 此時文件完全解析完成，瀏覽器可能還在等待如圖片等內容載入，等這些內容完成載入並且所有非同步指令碼完成載入和執行，document.readState變為complete,window觸發load事件
  23. 顯示頁面（HTML解析過程中會逐步顯示頁面）

什麼是web語義化,有什麼好處

web語義化是指通過HTML標記表示頁面包含的資訊，包含了HTML標籤的語義化和css命名的語義化。
HTML標籤的語義化是指：通過使用包含語義的標籤（如h1-h6）恰當地表示文件結構
css命名的語義化是指：為html標籤新增有意義的class，id補充未表達的語義，如Microformat通過新增符合規則的class描述資訊
為什麼需要語義化：

  • 去掉樣式後頁面呈現清晰的結構
  • 盲人使用讀屏器更好地閱讀
  • 搜尋引擎更好地理解頁面，有利於收錄
  • 便團隊專案的可持續運作及維護

Cmd和amd

模組化是軟體系統的屬性，這個系統被分解為一組高內聚，低耦合的模組。
那麼在理想狀態下我們只需要完成自己部分的核心業務邏輯程式碼，其他方面的依賴可以通過直接載入被人已經寫好模組進行使用即可。

首先，既然是模組化設計，那麼作為一個模組化系統所必須的能力：

1. 定義封裝的模組。
2. 定義新模組對其他模組的依賴。
3. 可對其他模組的引入支援。

不同之處
兩者的主要區別如下：

  1. 定位有差異。

RequireJS 想成為瀏覽器端的模組載入器，同時也想成為 Rhino / Node 等環境的模組載入器。
Sea.js 則專注於 Web 瀏覽器端，同時通過 Node 擴充套件的方式可以很方便跑在 Node 環境中。

  1. 遵循的規範不同。
    RequireJS 遵循 AMD（非同步模組定義）規範，S
    ea.js 遵循 CMD （通用模組定義）規範。
    規範的不同，導致了兩者 API 不同。Sea.js 更貼近 CommonJS Modules/1.1 和 Node Modules 規範。
  2. CMD 推崇依賴就近，AMD 推崇依賴前置。看程式碼：
  3. 推廣理念有差異。RequireJS 在嘗試讓第三方類庫修改自身來支援 RequireJS，目前只有少數社群採納。Sea.js 不強推，採用自主封裝的方式來“海納百川”，目前已有較成熟的封裝策略。
  4. 對開發除錯的支援有差異。Sea.js 非常關注程式碼的開發除錯，有 nocache、debug 等用於除錯的外掛。RequireJS 無這方面的明顯支援。
  5. 外掛機制不同。RequireJS 採取的是在原始碼中預留介面的形式，外掛型別比較單一。Sea.js 採取的是通用事件機制，外掛型別更豐富。

相關文章