隨着Html5的正式定稿，移動前端步入APP世界的步伐也隨之加速。目前主流的兩大手機系統廠商（google、蘋果）都是Html5的參與者，所以這兩大系統在對html5的支持上基本是沒什么問題的。然而對於很多開發者來說，也許僅僅是因為使用前的一番可行性分析便放棄這種方案。因為很多資料都敘述着Html5相比原生App的各種不足。其中最尷尬的一條莫過於“性能”問題。因為這個問題，剛開始接觸的時候我也有很強的抵觸情緒。但后來慢慢的發現，其實很多時候性能本就不是問題。適當的調整Html和Css，我們的網頁同樣可以無限接近原生程序。而且個人認為，大多數時候程序是否流暢並非取決於某種編程語言，而是取決於寫程序的人。相比通過各種代碼填充來完成目標任務，我更喜歡把技術當做藝術，寫代碼也應該有所追求。（扯淡扯遠了。）
其實，Html5相比原生App的開發有很多誘人的方面。
其一：可快速迭代。 最簡單最直接的一個：IOS程序每次上傳都需要通過漫長的審核時間，如果趕時間的話這是個問題，而且耐心等待之后未必就能得到一個我們想要的結果，審核不通也不是不可能。Html5開發完成之后也不用再次上傳審核。（若與原生程序有交互變更，此項無效）
其二：跨平台。Html跨平台的特性早已不是一天兩天的事了。IOS開發完成的同時，Android也基本完成。開發效率和成本上相比原生應用確實有較明顯的優勢。
其三：轉發率高。現在打開微信朋友圈就能看到各種分享。如：文章分享，產品分享，XX店鋪等。通過連接轉發可以實現快速分享，提高流量。
談完優勢，再說說自身經歷。本是一名老老實實的C#程序員，沒事就學習各種程序優化（sql為主）的我在幾個月前突然轉向移動網頁開發。在一個不算小的團隊里前端工程師是一枚傳統前端工程師。除能完成簡單的手機布局外其他一竅不通，於是乎關於JavaScript、前端性能優化等各種重擔都落到了我這里。由於前端所完成的僅僅是以html的形式展現出效果圖的模樣，很少涉及到性能問題。於是漫長的學習之路由此開始了。
究竟什么樣的頁面是需要優化的頁面？
1、頁面上下滑動時感覺卡頓不流暢或是基本不動；
2、動畫效果卡頓，看上去感覺一幀一幀的跳動；
簡單點說，就是感覺卡。也許iphone6不卡但是iphone4上會卡，也許iphone上不卡三星上感覺卡、魅族、小米、華為、聯想？國內屌絲機各有個的長相各有各的特色，比如魅族的MX，其他手機都很正常的時候它就卡。Html兼容一直都不是一件容易的事。
上述問題該如何破？
解決問題的關鍵在於找到問題的所在。砍柴還得有裝備，工具很重要。以前用chrome，是因為感覺這貨比較好使（直到放棄多年來一直鍾愛的IE）。幾個月前才發現這是一個調試工具也很好使的瀏覽器（簡直就是神器）。其實關於html性能問題，很多博客上都有解釋重繪這個事。下面主要談談如何用chrome鑒別重繪元素。
打開chrome，開啟開發者工具(F12)。打開模擬器，並選擇需要模擬的設備，在Console中選擇Rendering 選中第一條（Show paint rectangles）。若打開開發者工具后沒看見下方Console這塊可以按下Esc。
完成上述操作后，請將視線移動到左側網頁上的綠色矩形框上。
ps：一直都很喜歡淘寶的廣告，創意從未間斷過。
這個綠色框就是瀏覽器重繪的部分。這個框越大，說明重繪的區域也就越大。重繪並沒什么問題，這很正常，不正常的是大面積重繪，比如上圖中的時間跳動，如果僅僅是時間那個區域重繪並沒有什么問題，要是整個頁面都一直閃着個綠框框那就完蛋了。為何大面積重繪會出現性能問題，這個還得從瀏覽器渲染上談起。那是一個很長的故事，有興趣的朋友可以找些資料看看。簡單的舉例就是，瀏覽器把html文檔解析成網頁展現到我們面前，其中間是一個“漫長”的過程。再載入文檔之后需要對html進行分割、讀取並計算其樣式大小、然后進行圖層繪制、合並圖層等一系列操作。整個過程其實使用最多的部件是CPU和GPU。
重繪的面積大小和回流（reflows）有關，關於回流其實可以這樣理解，當改變一個元素后對其它節點元素產生影響。就如同可石子投入水中引起的波紋一樣，波紋所到之處基本都會有所影響。而在Html中子節點的變化會引起祖先的回流，同時也會影響到部分兄弟節點，大部分的回流將導致頁面的重新渲染。那么如何降低回流，減小重繪面積呢？淘寶時間不也只更新了一小塊么！這里提供兩種方法：
1、使用 position 屬性的 fixed 值或 absolute 值。
2、創建獨立的Layer（層）（為避免和div（層）產生混淆文中盡量同一使用Layer）。
繼續看淘寶：
第一種方法已經很明顯了就不再贅述。說說第二種方法吧。首先說說在Chrome中如何查看獨立的Layer呢。如上圖，選擇Show composited layer borders后在頁面上獨立的Layer上回顯示一個橘黃色邊框。那么又要如何才能建立獨立的Layer呢？
在Chrome中創建獨立的Layer僅需要符合下述條件之一：
-
- 有3D元素的屬性；
- video標簽並使用加速視頻解碼；
- canvas元素並啟用3D；
- 插件，比如flash；
- CSS動畫；
- CSS濾鏡；
- 有一個后代元素是獨立的layer；
- 元素的相鄰元素是獨立layer。
看上去挺多挺復雜的，其實最簡單、最容易理解、也最容易濫用的是第一條。實現第一條僅需要在元素的樣式里加上:transform:translateZ(0);-webkit-transform:translateZ(0);就可以了。我們將淘寶往下滑動一點，找一個元素試試看。
還是看淘寶：
當加上css樣式后對應的元素上出現了橘黃色邊框，事實證明這招是有效的。而在Chrome中這樣做可以啟用GPU硬件加速。初次看到加速兩個字讓人覺得無比興奮，仿佛找到了克敵制勝的無敵神招。可是，首先這是在chrome下，其次大量使用真的好嗎？
其實就算是在chrome下GPU也未必能排上用場，首先需要確定你的GPU驅動程序不在chromium的黑名單中。因為某些GPU驅動程序存在錯誤，可能會影響瀏覽器穩定，所以會被加入到黑名單里。在chrome地址欄里輸入about:gpu可以查看相關的GPU信息。現在再說說GPU加速的事情吧，簡單點解釋就是通過GPU渲染的Layer，GPU會將圖層信息緩存起來，到下次改變的時候就只需要重新渲染修改過的部分。這樣固然是快，但是會加大系統RAM和GPU的內存開銷。在配置參差不齊的移動設備上，過多的層不僅不能加速，反而會嚴重影響性能。很多時候我們在感覺到移動網頁較卡的時候不防試試減少頁面上的Layer試試。
通過Chrome我們還可以鑒別一些其他影響性能的方面。比如：
上面兩幅圖，左邊一幅是百度.新聞的移動網頁版，箭頭指向的是這個頁面的loading效果（就是一種一直一直轉動的感覺）。右邊是以前最常用的一種loading。在效果上兩種方式都一樣，一直不停的轉動。而區別在於右邊的loading是一個帶有背景圖片的div，通過css3使其產生轉動效果；而右邊則是一張Gif動態圖片。雖然效果上一樣，但在瀏覽其中我們可以看到右邊的loading會有一個不停閃動的綠色框（頻率相當高）。gif動畫會導致瀏覽器不斷的進行繪制、柵格化、合成，整個過程相當影響性能，所以最好干掉它。
簡而言之言而簡之：
1、減少重繪，減小重繪面積（改良布局，創建獨立的Layer），降低重繪頻率。
2、合理使用GPU加速，避免過度依賴GPU而導致性能下降。
說完布局，再簡單談談動畫吧。
常用的JavaScript動畫在移動web上很多時候都顯得心有余而力不足（不給力啊）。這個原因很多，JavaScript動畫通常是通過定時改變元素樣式屬性的方式來實現，JavaScript的運行是在一個獨立線程里完成的，作為單線程程序，JavaScript會因為某個耗時動作而影響下一幀動畫的執行。而且，JavaScript的定時也並沒有想象中的那么守時，如在setinterval中設置每毫秒輸出一個數，當輸出到2000次的時候，當真就只需要2秒鍾嗎？相比之下更加推薦使用CSS3來完成相關動畫效果。首先Css由獨立線程完成，它和JavaScript的運行並不沖突，其次Css3很多屬性不會觸發重繪（當然JavaScript里也可以是改變的css3的屬性）。從流暢度上來講的話Css3基本上完勝JavaScript，而且操作較容易。關於Css3相關知識就不再贅述。
然而Css3的動畫也並沒有想象中那般完美。
首先，在動畫控制上不夠靈活，整動畫過程不太好監控。
其次，其兼容性不太好。僅移動端而言，位移動畫通常使用transform，但在某些瀏覽器中需要使用-webkit-transform（如微信里的瀏覽器）。
雖然Css3並非完美解決方案，但實際使用中大多數時候是完全可以解決我們所遇到的問題（遇到復雜問題再解決吧，事在人為嘛，解決問題也是一種樂趣）。 且目前的移動應用上並不推薦過於復雜的效果設計。
注：上述內容僅是一個C#程序員的個人見解，若有不當之處，煩請指正。☺