不同浏览器内核
?
??在寫前端的時候，了解了一些瀏覽器兼容的問題，印象最深的還是圓角和漸變（感謝千年弦歌）。
? 瀏覽器最重要或者說核心的部分是“Rendering Engine”，我們一般稱之為“瀏覽器內核”。? 它負責對網頁語法的解釋（如HTML、JavaScript）并渲染（顯示）網頁。
? 相同的代碼在不同的瀏覽器呈現出來的效果不一樣，那么就很有可能是不同的瀏覽器內核導致的。
? 那么問題來了?——
?
一、整理一下主流瀏覽器的內核：
Trident（windows）——IE
? 其他：世界之窗，360安全瀏覽器， 遨游2.0（3.0以上版本開始采用webkit內核），搜狗瀏覽器，騰訊TT
? trident直譯是三叉的（還是美國一個口香糖牌子，什么鬼跑偏了）
Gecko(跨平臺)——FireFox????直譯是壁虎，gecko是Netscape6開始采用的內核，后來的Mozilla FireFox (火狐瀏覽器) 也采用了該內核，Gecko的特點是代碼完全公開，因此，其可開發程度很高，全世界的程序員都可以為其編寫代碼，增加功能。
因為這是個開源內核，因此受到許多人的青睞，Gecko內核的瀏覽器也很多，這也是Geckos內核雖然年輕但市場占有率能夠迅速提高的重要原因。
Presto——Opera前內核==
??presto直譯是急板的，說變就變的。該內核在2003年的Opera7中首次被使用，該款引擎的特點就是渲染速度的優化達到了極致，也是之前公認網頁瀏覽速度最快的瀏覽器內核，然而代價是犧牲了網頁的兼容性。
Webkit——蘋果的safari(win/mac/iphone/ipad) 、google的chrome、opera(2015轉webkit)、塞班手機瀏覽器、Android手機默認的瀏覽器、搜狗瀏覽器、QQ瀏覽器
? 蘋果公司自己的內核，也是蘋果的Safari瀏覽器使用的內核。
其中基于webkit的chromium內核的有——搜狗瀏覽器、QQ瀏覽器、chrome、360、opera（這個內核現在才是最快的）
知乎上看到一句話：Chromium不是靠采用WebKit贏的，是靠它在WebKit基礎上做出了自己的特色而贏的。
?
然而，現在國內很多瀏覽器都采用了雙核，例如360極速/安全瀏覽器、獵豹瀏覽器、遨游瀏覽器、搜狗瀏覽器。
國產雙核瀏覽器都有兩個核，分別是IE兼容內核（也叫兼容模式）和基于Chromium開發的極速內核（也叫極速模式或高速模式）。
簡單來說，基于Chromium內核的極速模式上網速度會更快，并且支持各種瀏覽器擴展插件（也就是添加各種你想要的功能），唯一的缺陷就是不支持國內某些不更新的網站（例如政府和部分銀行的）。一般情況下使用極速模式來上網就對了，當發現網頁顯示不正常時，再手動切換到IE兼容模式就行。
一般切換方式：在地址欄上點一下“IE圖標”或者“閃電圖標”就能切換到另一個內核。
?
二、瀏覽器渲染原理Web頁面運行在各種各樣的瀏覽器當中，瀏覽器載入、渲染頁面的速度直接影響著用戶體驗簡單地說，頁面渲染就是瀏覽器將html代碼根據CSS定義的規則顯示在瀏覽器窗口中的這個過程。先來大致了解一下瀏覽器都是怎么干活的：
1. 用戶輸入網址（假設是個html頁面，并且是第一次訪問），瀏覽器向服務器發出請求，服務器返回html文件；
2. 瀏覽器開始載入html代碼，發現<head>標簽內有一個<link>標簽引用外部CSS文件；
3. 瀏覽器又發出CSS文件的請求，服務器返回這個CSS文件；
4. 瀏覽器繼續載入html中<body>部分的代碼，并且CSS文件已經拿到手了，可以開始渲染頁面了；
5. 瀏覽器在代碼中發現一個<img>標簽引用了一張圖片，向服務器發出請求。此時瀏覽器不會等到圖片下載完，而是繼續渲染后面的代碼；
6. 服務器返回圖片文件，由于圖片占用了一定面積，影響了后面段落的排布，因此瀏覽器需要回過頭來重新渲染這部分代碼；
7. 瀏覽器發現了一個包含一行Javascript代碼的<script>標簽，趕快運行它；
8. Javascript腳本執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個
（style.display=”none”）。杯具啊，突然就少了這么一個元素，瀏覽器不得不重新渲染這部分代碼； 9. 終于等到了</html>的到來，瀏覽器淚流滿面…… 10. 等等，還沒完，用戶點了一下界面中的“換膚”按鈕，Javascript讓瀏覽器換了一下<link>標簽的CSS路徑； 11. 瀏覽器召集了在座的各位<span><ul><li>們，“大伙兒收拾收拾行李，咱得重新來過……”，瀏覽器向服務器請求了新的CSS文件，重新渲染頁面。 so...頁面為什么會慢？那是因為瀏覽器要花時間、花精力去渲染，尤其是當它發現某個部分發生了點變化影響了布局，需要倒回去重新渲染，內行稱這個回退的過程叫reflow。reflow問題是可以優化的，我們可以盡量減少不必要的reflow。比如開頭的例子中的<img>圖片載入問題，這其實就是一個可以避免的reflow——給圖片設置寬度和高度就可以了。這樣瀏覽器就知道了圖片的占位面積，在載入圖片前就預留好了位置。
另外，有個和reflow看上去差不多的術語：repaint，中文叫重繪。 如果只是改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部布局的屬性，將只會引起瀏覽器repaint。repaint的速度明顯快于 reflow（在IE下需要換一下說法，reflow要比repaint 更緩慢)
?
三、從瀏覽器的渲染原理講CSS性能
?
平時我們幾乎每天都在和瀏覽器打交道，寫出來的頁面很有可能在不同的瀏覽器下顯示的不一樣。苦逼的前端攻城師們為了兼容各個瀏覽器而不斷地去測試和調試，還在腦子中記下各種遇到的BUG及解決方案，而我們好像并沒有去主動地關注和了解下瀏覽器的工作原理。如果我們對此做一點了解，我想在項目過程中就可以根據它有效的避免一些問題以及對頁面性能做出相應的改進。
我們來看一下加載頁面時瀏覽器的具體工作流程:
1、解析HTML以重建DOM樹（Parsing HTML to construct the DOM tree ）：渲染引擎開始解析HTML文檔，轉換樹中的標簽到DOM節點，它被稱為“內容樹”。
2、構建渲染樹（Render tree construction）：解析CSS（包括外部CSS文件和樣式元素），根據CSS選擇器計算出節點的樣式，創建另一個樹 —- 渲染樹。
3、布局渲染樹（Layout of the render tree）:?從根節點遞歸調用，計算每一個元素的大小、位置等，給每個節點所應該出現在屏幕上的精確坐標。
4、繪制渲染樹（Painting the render tree）?: 遍歷渲染樹，每個節點將使用UI后端層來繪制。
主要的流程就是：構建一個dom樹，頁面要顯示的各元素都會創建到這個dom樹當中，每當一個新元素加入到這個dom樹當中，瀏覽器便會通過css引擎查遍css樣式表，找到符合該元素的樣式規則應用到這個元素上。
注意了：css引擎查找樣式表，對每條規則都按從右到左的順序去匹配。 看如下規則：
| 1 | #nav??li {} |
看起來很快，實際上很慢，盡管這讓人有點費解#_#。我們中的大多數人，尤其是那些從左到右閱讀的人，可能猜想瀏覽器也是執行從左到右匹配規則的，因此會推測這條規則的開銷并不高。在腦海中，我們想象瀏覽器會像這樣工作：找到唯一的ID為nav的元素，然后把這個樣式應用到直系子元素的li元素上。我們知道有一個ID為nav的元素，并且它只有幾個Li子元素，所以這個CSS選擇符應該相當高效。
事實上，CSS選擇符是從右到左進行匹配的。了解這方面的知識后，我們知道這個之前看似高效地規則實際開銷相當高，瀏覽器必須遍歷頁面上每個li元素并確定其父元素的id是否為nav。
| 1 | *{} |
額，這種方法我剛寫CSS的也寫過，殊不知這種效率是差到極點的做法，因為*通配符將匹配所有元素，所以瀏覽器必須去遍歷每一個元素，這樣的計算次數可能是上萬次！
| 1 | ul#nav{} ul.nav{} |
在頁面中一個指定的ID只能對應一個元素，所以沒有必要添加額外的限定符，而且這會使它更低效。同時也不要用具體的標簽限定類選擇符，而是要根據實際的情況對類名進行擴展。例如把ul.nav改成.main_nav更好。
| 1 | ul li li li .nav_item{} |
對于這樣的選擇器，之前也寫過，最后自己也數不過來有多少后代選擇器了，何不用一個類來關聯最后的標簽元素，如.extra_navitem，這樣只需要匹配class為extra_navitem的元素，效率明顯提升了
對此，在CSS書寫過程中，總結出如下性能提升的方案：
?? 選用高效的選擇符，可以減少頁面的渲染時間，從而有效的提升用戶體驗,你可以看一下CSS selectors Test，這個實驗的重點是評估復雜選擇符和簡單選擇符的開銷。也許當你想讓渲染速度最高效時，你可能會給每個獨立的標簽配置一個ID，然后用這些ID寫樣式。那的確會超級快，也超級荒唐！這樣的結果是語義極差，后期的維護難到了極點。
?
?
?
轉載于:https://www.cnblogs.com/luodatou/p/5463854.html
總結
- 上一篇： 兼容浏览器将NodeList对象转换为数
- 下一篇： 对于理想的团队模式的设想和对软件流程的理