摘要：方案未引起重視，并沒有做出相應處理。頁面中元素的布局是相對的，因此一個元素的布局發生變化，會聯動地引發其他元素的布局發生變化。這里可以使用的和來分析的性能。寫在最后性能優化是一門做減法的藝術。

歡迎關注我的個人公眾號，不定期更新自己的工作心得。

題記：可以把這篇文章看成一次事故記錄，一次線上事故。此刻我能坐在這里寫下這篇文章，要感謝我司沒有開除我，或者說我解決了這次性能問題，所以我有機會寫下這篇文章。

我司全球購業務改版，將原生的全球購頁面采用Hybird模式開發，這是我司H5頁面第一次出現在以及入口位置，作為開發者顯得很是興奮。

根據設計稿，如期完成工作，測試也已準備好，部分Android低端機中顯示出卡頓現象，出于對自身技能的肯定，誤以為是硬件性能問題，并未引起過多關注。

未引起重視，并沒有做出相應處理。

上到pre環境后，發現部分iPhone機型出現崩潰，初步排查在iOS 8.4系統上DOM節點高度達到10000px以上奔潰率100%，其他8-9之間的系統版本當分頁數據使得DOM達到10000px以上快速滾動會出現卡頓，9以上iOS系統與Android4.4以上系統均表現良好。定位問題后，迅速進行更多特殊機型與相應系統的測試，期間借遍了公司幾百位小伙伴的手機，在此向他們表示感謝。

你問我為什么，我只能說測試環境沒有這么多數據，至于為什么沒有？呵呵，你懂得！

iOS將UIWebview切換為WKWebview，WKWebview為iOS在8以上系統中新加入的一個高性能Webview，具體哪里好，可以點這里 這里 還有這里 ，由于iOS已經發版（對的，在H5頁面還在pre環境測試的時候，iOS已經發版了）這個方案只能作為下一個版本了

臨時降低數據顯示總量，同時尋找性能瓶頸（這里要和運營的同學說聲sorry）

針對iOS 8以下以及8.4系統 Android 4.4以下系統做自動降級處理。

測試不能僅僅做功能測試，還要做性能測試

開發人員常使用chrome、Firefox等瀏覽器的開發工具進行開發，這里要注意的是：瀏覽器開發工具只能模擬手機UI與交互，其性能要遠遠強于手機環境。

開發過程中常用微信、QQ、手機瀏覽器進行測試，這是不可取的，因為最終環境不一，容易給自己造成錯覺，覺得在微信 QQ的Webview中沒問題，就OK了

deadline 真的要好好定。很多人認為H5很靈活，并不依賴于iOS發版，可以將測試定在iOS發版的那幾天進行。其實這真的是巨大的錯誤，后面我會說明。

經過降級后，仍然存在很多問題，同時我們也在抓緊研究后續升級方案。經過協調，將系統切回了老版本暫時使用原生替代H5（感覺很受打擊~）。

數據量不足，對運營影響很大

對降級機型的體驗很差，數據統計顯示，受影響的機型還是有一定份額

由于此次H5是存在于以及目錄，所以設計上是常駐內存以保證體驗，UIWebview的內存一直得不到釋放，同事系統中其他頁面也使用到了UIWebview，長時間使用仍然會出現崩潰。

距離iOS和Android下一次發版還有一段時間，不可能一直降級

無論如何解決性能問題，這是唯一目標！

經過一個星期枯燥而漫長的努力與實驗，從以下幾個方面徹底解決了性能瓶頸；

1. 去除iScroll

iScroll是我們內部框架中引入的一個第三方組件,官方的介紹是「Smooth scrolling for the web」，奈何在大數據量面前性能確實令人堪憂。如果數據量少，還是推薦使用的。

2. 高性能DOM渲染

在對比了競品，和天貓、JD等知名廠商H5實現后，確實郁悶了一段時間，同樣的數據量為什么別人可以做到？最后得到兩個結論：

別人DOM節點沒我們復雜，由于我們采用了內部研發的m-fast框架，框架頂層就確定了DOM結構的復雜性，例如：框架預設了整個布局為上、下、左、右、中的布局，即使我的頁面只是一個流式布局。

別人H5頁面沒有圖片輪播！對，你沒看錯，一個圖片輪播居然對性能影響如此之大

居于上面這兩點，我開始了DOM性能研究

m-fast框架采用模板預編譯技術，將頁面模板編譯為js文件，在通過異步加載的方式載入，所以，網頁的渲染大致符合上面這五個步驟

JavaScript。一般來說，我們會使用JavaScript來實現一些視覺變化的效果。比如用jQuery的animate函數做一個動畫、對一個數據集進行排序、或者往頁面里添加一些DOM元素等。當然，除了JavaScript，還有其他一些常用方法也可以實現視覺變化效果，比如：CSS Animations, Transitions和Web Animation API。

計算樣式。這個過程是根據CSS選擇器，比如.headline或.nav > .nav_item，對每個DOM元素匹配對應的CSS樣式。這一步結束之后，就確定了每個DOM元素上該應用什么CSS樣式規則。

布局。上一步確定了每個DOM元素的樣式規則，這一步就是具體計算每個DOM元素最終在屏幕上顯示的大小和位置。web頁面中元素的布局是相對的，因此一個元素的布局發生變化，會聯動地引發其他元素的布局發生變化。比如，``元素的寬度的變化會影響其子元素的寬度，其子元素寬度的變化也會繼續對其孫子元素產生影響。因此對于瀏覽器來說，布局過程是經常發生的。

繪制。繪制，本質上就是填充像素的過程。包括繪制文字、顏色、圖像、邊框和陰影等，也就是一個DOM元素所有的可視效果。一般來說，這個繪制過程是在多個層上完成的。

渲染層合并。由上一步可知，對頁面中DOM元素的繪制是在多個層上進行的。在每個層上完成繪制過程之后，瀏覽器會將所有層按照合理的順序合并成一個圖層，然后顯示在屏幕上。對于有位置重疊的元素的頁面，這個過程尤其重要，因為一旦圖層的合并順序出錯，將會導致元素顯示異常。

如果你修改一個DOM元素的“paint only”屬性，比如背景圖片、文字顏色或陰影等，這些屬性不會影響頁面的布局，因此瀏覽器會在完成樣式計算之后，跳過布局過程，只做繪制和渲染層合并過程。

如果你修改一個非樣式且非繪制的CSS屬性，那么瀏覽器會在完成樣式計算之后，跳過布局和繪制的過程，直接做渲染層合并。這種方式在性能上是最理想的，對于動畫和滾動這種負荷很重的渲染，我們要爭取使用這種渲染流程。

1. 簡化瀏覽器重繪的復雜度

繪制，是填充像素的過程，這些像素將最終顯示在用戶的屏幕上。通常，這個過程是整個渲染流水線中耗時最長的一環，因此也是最需要避免發生的一環。

CSS屬性中，除了transform和opacity之外，修改任何屬性都會觸發繪制

如果布局被觸發，那么接下來繪制一定會被觸發。因為改變一個元素的幾何屬性就意味著該元素的所有像素都需要重新渲染！

如果改變元素的非幾何屬性，也可能觸發繪制，比如背景、文字顏色或者陰影效果，盡管這些屬性的改變不會觸發布局。

2. 減小瀏覽器重繪區域

繪制并非總是在內存中的單層畫面里完成的。實際上，瀏覽器在必要時將會把一幀畫面繪制成多層畫面，然后將這若干層畫面合并成一張圖片顯示到屏幕上。

這種繪制方式的好處是，使用tranforms來實現移動效果的元素將會被正常繪制，同時不會觸發對其他元素的繪制。

在頁面中創建一個新的渲染層的最好方式就是使用CSS屬性will-change，Chrome/Opera/Firefox都支持該屬性。同時再與transform屬性一起使用，就會創建一個新的組合層：

.moving-element {
  will-change: transform;
}

對于那些目前還不支持will-change屬性、但支持創建渲染層的瀏覽器，比如Safari和Mobile Safari，你可以使用一個3D transform屬性來強制瀏覽器創建一個新的渲染層：

.moving-element {
  transform: translateZ(0);
}

但需要注意的是：不要創建太多的渲染層。因為每創建一個新的渲染層，就意味著新的內存分配和更復雜的層的管理。

3. 避免大規模、復雜的布局

上面提到的，由于框架的限制，頁面布局相對需求來說復雜很多。開發中應該盡量避免復雜的DOM結構，復雜的DOM結構更容易引起大面積的重繪。

4. 優先使用渲染層合并屬性

渲染層的合并，就是把頁面中完成了繪制過程的部分合并成一層，然后顯示在屏幕上。

使用transform/opacity來實現動畫效果，目前只有transforms和opacity這兩個屬性不會觸發瀏覽器的布局和繪制，對網頁元素這兩個屬性的修改會直接觸發渲染層合并。

5. 優化JavaScript的執行效率

對于動畫效果的實現，避免使用setTimeout或setInterval，請使用requestAnimationFrame。

把耗時長的JavaScript代碼放到Web Workers中去做。

這里可以使用Chrome DevTools的Timeline和JavaScript Profiler來分析JavaScript的性能。

性能優化是一門做減法的藝術。我們首要要盡力簡化頁面渲染過程，然后要使渲染過程的每一步都盡量高效。

CSS Triggers

render performance

simplify paint