前端面試資源整理（一）

時間  2019-11-16
標籤 前端 面試 資源 整理 欄目 快樂工作 简体版
原文   原文鏈接

Js相關

執行環節和做用域

執行環節定義了函數或者變量能夠訪問的其它數據，決定了他們各自的行爲。
每一個執行環境都有一個與之關聯的變量對象，在環境中定義的全部變量和函數都保存在這個變量中，而且是咱們沒法訪問。
每一個函數都有本身的執行環境，當執行流進入一個函數的時候，就把函數的執行環境壓入執行環境棧，執行完畢後，再將環境推出，把控制權交給以前的執行環境。javascript

當代碼在一個環境中執行的時候，會建立變量對象的做用域鏈，做用域鏈的用途是保證對執行環境有權訪問的全部變量和函數的有序訪問。
做用域鏈的前端,始終都是當前執行代碼所在環境的變量對象.若是這個環境是函數,則將其活動對象做爲變量對象.做用域鏈中的下一個變量對象來自包含環境,最終到全局對象window.
延長做用域鏈 try catch 和 with語句.css

垃圾回收機制

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

垃圾收集器在運行的時候會給存儲在內存中的全部變量都加上標記,而後,他會去掉環境中的變量以及被環境中變量引用的變量的標記.
而在此以後有標記的變量將被視爲準備刪除的變量.html

  1. 引用計數.

跟蹤記錄每一個值被引用的次數 ,經過引用來適當增長他的引用次數,當引用計數爲0時,代表該變量能夠被清除.前端

typeof 操做符

undefiend/變量未定義 boolean/布爾值 string/字符串 number/數值 object對象或者null function/函數 symbol/Symboljava

相等(==)規則

  1. 若是有一個操做數爲布爾值,則先轉爲數值(false 0 true 1);
  2. 若是一個操做數爲字符串,另外一個爲數值,將字符串轉換爲數值
  3. 若是一個操做數爲對象,另外一個不是,調用對象的valurOf方法,用獲得的原始值調用以前的規則比較;

[注意]:web

  1. null和 undefiend是相等的;
  2. 比較以前,不能見null和undefined轉換爲其餘任何值;
  3. 若是有一個操做數爲NaN,返回false,即使兩個NaN比較也是false
  4. 若是兩個都是對象,比較是否是同一個對象,若是兩個操做數指向同一個對象,返回true.

全等(===)規則

全等比較前不會轉換操做數,其餘狀況同樣.算法

瀏覽器緩存

能夠分爲 強緩存和協商緩存chrome

1.強緩存：不會向服務器發送請求，直接從緩存中讀取資源，在chrome控制檯的network選項中能夠看到該請求返回200的狀態碼，而且size顯示from disk cache或from memory cache；數據庫

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

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四個值的區別

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

一、static：默認值。沒有定位，元素出如今正常的流中（忽略 top, bottom, left, right 或者 z-index 聲明）。

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

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

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

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

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

二、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 採起的是通用事件機制，插件類型更豐富。
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程