眾所周知，行動端不僅應該被快速加載，光有內容沒有用戶體驗也是不可以的，同時還應該流暢運行，比如快速響應的交互，如絲般順滑的動畫……
在實際開發中如何做到上面所說的效果呢？
1. 確認渲染效能的分析標準
2. 準備尺去衡量渲染效能標準
3. 對耗時多的地方進行最佳化
我們可以粗略的得到下面的最佳化目標
#第一個是首屏呈現時間，網路上的資料已經非常非常多了，壓縮代碼，使用webp圖片，使用sprite，按需加載，“直出”，CDN……
第二個是16ms 優化，本篇重點講16ms的優化。
一.瀏覽器渲染 原理介紹
#大多數裝置的更新頻率是60次/秒，（1000/60 = 16.6ms）也就說是瀏覽器對每一幀畫面的渲染工作要在16ms內完成，超出這個時間，頁面的渲染就會出現卡頓現象，影響使用者體驗。
這就是上圖的
如果改變屬性在上面圖中越往左，那麼影響就越大，效率就越低。
瀏覽器渲染的流程如下：
取得DOM 並將其分割為多個層(RenderLayer)
#將每個層柵格化，並獨立的繪製進位圖中
將這些點陣圖作為紋理上傳至GPU
複合多個圖層來產生最終的螢幕影像(終極layer)。
從上面圖可以看出，如果只是改變composite（渲染層合併），那效率就會大大提升。
下面粗略地列出要改變哪些樣式會分別改變渲染過程的哪一模組。
從上圖可以看到 transform，opacity 只會改變composite（渲染層合併），為什麼呢？因為開啟了GPU加速。
開啟GPU 加速
字面上的解釋： 紋理能夠以很低的代價映射到不同的位置，而且還能夠以很低的代價透過把它們應用到一個非常簡單的矩形網格中進行變形。
【字面上的理解非常地繞口，還是老道理，能用圖講清的道理不要用文字。 】
小tips：先選取timeline的某一幀，然後選擇下面的layer標籤tab，可以左右拖曳該模組出現3d
我們可以看到頁面上由如下層組成：
雖然我們最終在瀏覽器上看到的只是一個影印版，也就是最終只有一個層。類似於PhotoShop軟體中的「圖層」概念，最後合併所有可視圖層，輸出一張圖片到螢幕上
但是實際上一個頁面會因為有些規則被分成對應的層，一旦被獨立出來之後，便不會再影響其他dom的佈局，因為它改變之後，只是「貼上」了頁面。
目前下面這些因素都會造成Chrome建立層：
3D 或透視轉換(perspective transform) CSS 屬性
使用加速影片解碼的
擁有3D (WebGL) 上下文或加速的2D 上下文的
混合插件(如Flash)
對自己的opacity 做CSS 動畫或使用一個動畫webkit 變換的元素
擁有加速CSS 過濾器的元素
元素有一個包含複合層的後代節點(換句話說，就是一個元素擁有一個子元素，該子元素在自己的層裡)
元素有一個z-index 較低且包含一個複合層的兄弟元素(換句話說就是該元素在複合層上面渲染)
在webkit核心的瀏覽器中，如果有上述情況，則會建立一個獨立的layer。
要注意的是，不要建立過多的渲染層，這意味著新的記憶體分配和更複雜的層管理。不要濫用GPU加速，注意看 composite layouts 是否超出了 16ms
說了這麼多瀏覽器渲染的原理，如果沒有尺測量也毫無用處。那麼，下面就選尺去測量：Google開發工具的Timeline。
二. Google開發工具Timeline 的常用功能
1. 點擊左上角的錄製之後，錄製結束之後會產生下面的樣子，紅色區域內就是幀了，移動上去可以看到每一幀的頻率，如果>60fps，就是比較流暢，如果。
2. 在timeline下面，可以看到各個模組的耗時，可以定位到耗時較大的函數上面，對該函數進行最佳化。
3. 依照下面步驟選擇，即可看到獨立的層，高亮重繪的區域，方便找出不必要重繪的區域，進行最佳化
選擇之後，目前頁面會出現下面2中顏色邊框
黃色邊框：有動畫3d變換的元素，表示放到了一個新的複合層（composited layer）中渲染
藍色的柵格：這些分塊可以看作是比層更低一級的單位，Chrome以這些分塊為單位，一次上傳一個分塊的內容到GPU。
工具也有了，瀏覽器渲染的原理也知道了，接下來是結合實際專案進行最佳化.
三. 在實際專案中進行16.6ms 最佳化
結合上面的渲染流程圖，我們可以針對性的分析並優化下面的一些步驟
優化JavaScript的執行效率
#降低樣式計算的範圍和複雜度
避免大規模、複雜的佈局
簡化繪製的複雜度、減少繪製區域
優先使用渲染層合併屬性、控制層數量
對使用者輸入事件的處理函數去抖動（行動裝置）
#1. 讀寫分離，大量操作
JavaScript腳本運行的時候，它能取得的元素樣式屬性值都是上一格畫面的，都是舊的值。
因此，如果你在目前幀取得屬性之前又對元素節點有改動，那就會導致瀏覽器必須先套用屬性修改，結果執行佈局過程，最後再執行JavaScript邏輯。
// 先写后读，触发强制布局
function logBoxHeight() {
// 更新box样式
box.classList.add('super-big');
// 为了返回box的offersetHeight值
// 浏览器必须先应用属性修改，接着执行布局过程
console.log(box.offsetHeight);
}優化之後：
// 先读后写，避免强制布局
function logBoxHeight() {
// 获取box.offsetHeight
console.log(box.offsetHeight);
// 更新box样式
box.classList.add('super-big');
}2. 閉包快取計算結果 （需要頻繁的調用，計算的函數）
getMaxWidth: (function () {
var cache = {};
function getwidth() {
if (maxWidth in cache) {
return cache[maxWidth];
}
var target = this.node,
width = this.width,
screen = document.body.clientWidth,
num = target.length,
maxWidth = num * width + 10 * num + 20 - screen;
cache[maxWidth] = maxWidth;
return maxWidth;
}
return getwidth;
})(),改成這種方式後，直接蹭蹭～ 減少了10多ms
#3. 對使用者輸入事件的處理函數去抖動
如果被觸摸的元素綁定了輸入事件處理函數，例如touchstart/touchmove/touchend，那麼渲染層合併線程必須等待這些被綁定的處理函數執行完畢才能執行，也就是使用者的滾動頁面操作被阻塞了，表現出的行為就是滾動出現延遲或卡頓。
簡而言之就是你必須確保使用者輸入事件綁定的任何處理函數都能夠快速的執行完畢，以便騰出時間來讓渲染層合併線程完成他的工作。
輸入事件處理函數，例如scroll/touch事件的處理，都會在requestAnimationFrame之前被呼叫執行。因此，如果你在上述輸入事件的處理函數中做了修改樣式屬性的操作，那麼這些操作就會被瀏覽器暫存起來。
然後在呼叫requestAnimationFrame的時候，如果你在一開始就做了讀取樣式屬性的操作，那麼將會觸發瀏覽器的強制同步佈局操作(即在javascript階段中執行佈局)，這樣會導致多次佈局，效率低。
優化如下：
window.requestAnimationFrame(function () {
context.animateTo(nowPos); //需要更新位置的交给RAF
});4. 減少不必要的重繪
#續上面，開啟paint flashing 之後，可以看到瀏覽器重新繪製了哪些區域。發現有些不必要重繪的區域也重繪了～給這些開啟GPU優化（上文中提到）
#直接看timeline 效果，全綠了～懸著的心終於放下了
行動端開發的小技巧很多，今天先帶給大家這個高效能開發的技巧，更多知識請繼續關注我們網站PHP.cn
相關閱讀：
行動端開發必備知識( 轉載)_html/css_WEB-ITnose
#行動端開發的一些技巧_html/css_WEB-ITnose
以上是如何能做到高效能行動端開發的詳細內容。更多資訊請關注PHP中文網其他相關文章！
