- 單頁or多頁
- webapp
- 現狀
- 優劣之分
- 網絡傳輸優化
- 綜述
- fake頁-首屏加速
- 降低請求數
- 降低請求量
- 緩存Ajax/localstorage
- DOM操作優化
- 綜述
- 關于頁面渲染
- 減少使用定位屬性（fixed/absolute）
- 奇技淫巧
- 內存資源優化
- 體驗優化
- 區域滾動
- 點擊響應
- 結語
單頁or多頁
本文僅代表個人觀點，不足請見諒，歡迎賜教。
webapp
小釵從事單頁相關的開發一年有余，期間無比的推崇webapp的網站模式，也整理了很多移動開發的知識點，但是現在回過頭來看，webapp究竟是好還是不好真是一言難盡喲！
webapp使用JavaScript修改頁面；緊接著再從服務器傳遞更多數據然后再修改頁面，如此循環。
java webapi？從性能的角度看，在現代瀏覽器中單頁面Web App已經能夠和普通native應用程序相媲美，而且幾乎所有的操作系統都支持現代的瀏覽器。
所以，很多人認為webapp是HTML5流行過程中最大的贏家，那么他有哪些特定呢？
SPA（single page application），即單頁webapp，它具有以下優點：
用戶體驗，對于內容的改動不需要加載整個頁面。這樣不會出現白頁情況，頁面與頁面無縫切換，甚至帶有一定動畫效果。
請求量少，請求內容無需服務器解析，對服務器壓力較小，消耗更少的帶寬，比如每次不需要接收完整的html結構，而只需要json數據。
當然，單頁應用也不是完美無瑕的，他也具有以下問題：
web前端優化策略？由于歷史原因，單頁應用對SEO支持不是太好，需要對SEO做特殊處理。
首次加載量過大，首屏加載慢，所以首屏需要做特殊處理。
本身入門門檻就高，加之view編碼需要釋放資源，以免heap值過高，對編碼人員的要求較高。
現狀
傳說中的webapp足以媲美native app，事實上這個足以還有很大的距離，小釵預計這個“足以”需要用2-3年時間填平，所以事實是什么呢？
在web下的優化，事實上移動端的webapp模式的網站很少很少，一淘半年前還是，這兩天一看又變回來了，小釵雖然對webapp抱有信心，但是信心從何而來呢？
攜程webapp獨樹一幟，去哪兒ipad介入webapp，但是國內主流網站依舊是傳統網站，主要原因不過有二：
① SEO
② 不想吃螃蟹
web前端優化。所以，攜程的webapp在國內，何其可貴，說到這里，我都要哭出來了......
優劣之分
孰優孰劣非是小釵可以論斷，求穩，webapp不比傳統網站；求SEO，webapp需要其它解決方案；說垃圾收集，webapp需要自己釋放資源。
說體驗，webapp需要考慮首屏加載；說動畫，webapp要考慮低端手機，所以webapp還有很長一段路需要走！
小釵相信，現在的webapp效果不可媲美native app，總有一天，當webapp不再制約于網絡、設備，那么webapp的春天不會遠。
web頁面優化、雖說如此，現階段webapp也會有許多優化心得、奇技淫巧可以拿出來說說的，這里小釵做一次分享，希望可以對webapp的同學有所幫助。?
網絡傳輸優化
綜述
前端優化分為兩個切入點：網絡傳輸與DOM操作，而網絡傳輸是制約一個網站速度的主要因素。
網絡傳輸的優化要點是，零請求，無流量，其意是最大程度的減少請求數，降低請求量。
對webapp模式的應用來說，首屏加載慢是一個不可避免的問題，所以提升webapp首屏加載速度是提升整體網站速度的關鍵。
fake頁-首屏加速
javascript插件、
以上是一個網站首頁的加載時間，我們分別取其150kb與30kb網速的加載速度，可以看出會慢！若他是webapp，我們可以做一些優化
我們應該避免頁面長時間白頁，這個時候便提出了fake頁的概念。頁面渲染只需要完整的HTML以及CSS，這個便是第一個優化點。
web項目優化。從數據請求數以及請求量來說，webapp首頁的響應應該比較慢，若是任由js加載完成再渲染頁面，用戶很有可能失去耐心。
但是從DOMContentLoaded來看，首頁事實上頁面響應比較迅速，所以這個加載結束后頁面第一屏便渲染結束，然后再異步加載js，當js改變后再動態改變dom結構中的一些關鍵點
這個時候一個靜態HTML頁面，裝載首屏的基本內容，讓首頁快速顯示
然后js加載結束后會馬上重新渲染整個頁面，這個樣子，用戶就可以很快的看到頁面響應，給用戶一個快的錯覺，給人感覺快得多。
降低請求數
webview優化、由webapp首頁來說，不可避免的使用的js文件較多，這些文件分為兩類：
① 框架js-css
② 各個業務團隊js-css
所以可以限定每個業務團隊只會加載這四個文件，以最小降低請求數，這里又涉及到并行加載，數量與容量有一個臨界值，如何取這個臨界值需要各位自己去實驗?
降低請求量
css app。雖說圖片壓縮是不必說的事情，但是總會有些時候你會發現一些網站的圖片尺寸很大，這個需要處理，而且必須處理。
以框架庫為例，除了核心包以外，不需要的UI或者功能庫可以剔除，用到了再動態加載，減少首次加載量，這個一開始就得做好，做不好后期就不好改
以業務團隊為例，首次加載的js與html模板會將常用的幾個頁面壓縮合并，其它頁面訪問時再請求，若是想提升首屏加載便可以只下載需要的頁面文件。
另外，以下兩點尤其需要注意：
web優化，① 若是你們是要的還是jQuery庫的話，可以考慮換成zepto了
② 勿胡亂引用第三方庫，若是要引用一定是讀懂源碼的情況下重寫使用之，這樣的好處是，吃得透，萬一有問題，能改，而不是沒辦法又換庫
緩存Ajax/localstorage
該方案的原理與前面類似，我們發送Ajax請求時候，應該緩存一些非實時數據，比如城市信息和常用聯系人，但是我們只能緩存非敏感信息，
產品搜索頁至列表頁的請求數據會緩存30s-60s，若是過期時間內用戶回到列表頁的話不會重新請求數據
android webview與js交互？這對服務器壓力，頁面響應皆是有利的，這個在30s內事實上意義不大，可以減少一次請求。
另外，對于get和post的效率，曾經有人做過一次測試：
get100次平均耗時323ms；post100次平均耗時589ms，所以post方式是比get慢的，但post請求的優點是安全，并且參數沒有長度限制。
是選擇post還是選擇get，皆需要處理，避免截斷url，或者處處post。-
lazyload
只顯示首屏頁面，其它內容需要時再加載，比如列表頁、圖片lazyload，皆需要做
DOM操作優化
綜述
DOM操作主要分為頁面渲染與資源清理（heap控制），兩者之間又相輔相成，若是DOM操作一塊處理不好，其產生的感覺就不再是慢，而是卡
所以DOM操作優化的主要目的就是消滅頁面卡的問題，這個在移動端尤為重要。
關于頁面渲染
瀏覽器會解析三個東西：HTML、Javascript、CSS
瀏覽器首先會根據HTML生成DOM Tree，其次會根據CSS生成CSS Rule Tree，javascript可以通過DOM API與CSS API操作DOM Tree與CSS Rule Tree，從而引起頁面變化。
瀏覽器解析結束會通過DOM Tree與CSS Rule Tree形成render tree，只有display不為none的元素才會形成render Tree，render Tree形成后瀏覽器會調用GUI繪制頁面，在此之前做的一件事情便是layout或者說reflow。上面的描述簡單而言可以分為以下流程：
l? 生成DOM樹
l? 計算CSS樣式
l? 構建render tree
l? reflow，定位元素位置大小
l? 繪制頁面
在這個過程中，若是javascript動態改變DOM Tree便會引起reflow
頁面中的元素改變，只要不影響尺寸，比如只是顏色改變只會引起repaint不會引起回流
否則，reflow不可避免，這個時候便需要重新計算形成render Tree
reflow分為局部回流與全局回流，會影響下面的，不會影響上面的元素
reflow耗用的系統資源較大，DOM Tree中受到影響的節點皆會reflow，然后影響其子節點最壞的情況是所有節點reflow，該問題引發的現象便是低性能的電腦風扇不停的轉，手機變得很熱，并且非常耗電，以下操作可能引起reflow
l? 操作dom結構
l? 動畫
l? DOM樣式修改
l? 獲取元素尺寸的API
減少使用定位屬性（fixed/absolute）
static元素處于文檔流中，其渲染速度是最快的，我們做過一個測試：
100個absolute元素與100個static元素渲染時差在0.01-0.007ms
100000個元素渲染差距便增至30ms左右，這個微小的時差在移動端變得尤為明顯，比如：
小米/三星手機（1000左右），便存在明顯的渲染問題，具體表現為：
l? 定位元素在手機上不能顯示。
l? 定位元素動畫效果失效。
以上問題便是UI渲染失效多導致，最好的解決方案是減少使用定位元素，否則只能引起強烈reflow才能解決。
另外，產品經常會有fixed的相關需求，比如支付按鈕一直出現在低端，這個需求會造成兩個問題：
l? fixed元素遭遇文本框時失效，可能會飄到頁面中間阻擋輸入
l? 影響效率
問題一原因與移動端的實現有關，暫時沒有完美的解決方案，問題二便與渲染直接關聯
滾屏時，頁面上所有的像素會跟著滾動，顯卡對全屏幕上下移動的處理很快，但是若是出現一個fixed元素或者有元素不跟著一起滾動，那么滾動對手機瀏覽器來說就是一個負擔，這種滾動的性能甚至體現在了iphone 4s，因為滾動可能會造成reflow，這個現象體現在：
使用absolute配合javascript模擬fixed效果時，會有斷片的效果，該問題在iphone5s便不會出現這個問題。
奇技淫巧
當然，我們不能忽略產品的需求，fixed類需求應該在技術上得到解決，還用戶一個良好的體驗。
虛擬鍵盤導致fixed元素錯位
fixed元素一定會伴隨虛擬鍵盤的出現，但是虛擬鍵盤只是“貼”在了viewport上，表面上不會對dom產生“任何”影響，但是這個時候fixed元素表現卻變得怪異起來，會錯位。
應用層面解決問題方案是，虛擬鍵盤彈出時將fixed元素設置為static，虛擬鍵盤消失時候設置回來。
由于虛擬鍵盤出現并未拋出事件，而檢測scroll或者resize事件，皆會有一定延遲，會出現閃爍現象，所以現有最好的方案是setinterval定時器監控當前獲取焦點元素是否為文本元素，若是是的話便需要處理，如此便可解決fixed元素錯誤問題。
fixed元素滑動慣性平滑度
我們常常遇到這種產品需求，tab標簽欄開始固定，當滾動向下超過該標簽欄后便會變成fixed元素，一直出現在頭部，這樣的需求在電腦上沒有問題，但是在iPhone5s以下的手機常常會出現小范圍錯位或者快速移動大范圍錯位的問題。
這個時候我們可以引起reflow迫使瀏覽器重繪以解決這個問題，這里推薦一個奇怪的hack寫法：同時設置三個image元素的src屬性，便可以全范圍解決該難題，? 該方案被團隊證實并得到應用。
//三圖片src，引發reflow，處理fixed方案慣性問題
var el = this.els.ctlc.find('img');
$(el[0]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');
$(el[1]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');
$(el[2]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');
另外，上圖中的tab標簽下面的藍線具有動畫，但是在小米或者三星手機上可能不會移動，這個時候也可以動態引起reflow解決這個BUG。
其它
l? CSS選擇器盡量使用id與class，避免過度層疊
l? 避免使用數值，比如：border: none不會引起渲染，而boder: 0會
l? 動畫時候讓元素脫離文檔流，以免導致大量reflow
l? 避免逐條修改DOM樣式，改以className實現同樣功能
l? 操作DOM時將display設置為none，因為這種元素不會影響渲染，或者操作fragment對象取代操作顯示在頁面上的DOM
l? 避免將獲取DOM樣式屬性的操作寫在循環中，可能引起重復reflow
內存資源優化
移動端的javascript
首先，移動端的性能與PC端的性能完全不在一個數量級上，比如，我哥做過一個測試，使用innerHTML繪制大段，之后想獲取HTML的ID節點，事實上是獲取不到的，這種問題在單頁模擬多頁，動態創建DOM會經常發生
var element?? = $('<div id = "test">...大量結構...</div>');
$(root).html(element)
$('#test)? //為空
這類問題匪夷所思，因為頁面UI渲染與DOM操作是互斥的，但是就算出現了這個問題，一個解決方案是使用settimeout，更好的方案是使用DOMNodeRemoved事件監控頁面DOM改變，將我們的DOM操作回調放入以確保渲染結束。
以上問題只是為了說明移動端的性能問題，這類性能問題會導致很多莫名其妙的問題，而且很多與渲染有關。但是這也從側面說明了移動端資源的緊缺，若是heap值過大，會導致操作出現卡的現象，更有甚者，會引起頁面假死直接退出。
webapp的模式，完全依賴于瀏覽器的垃圾回收，基本就是作死，因為傳統頁面一旦刷新頁面整個資源完全釋放，而webapp沒有刷新這類操作，只有一個狀態到兩一個狀態，不相關的內存會保留，資源必須手動釋放，或者說，框架必須提供垃圾釋放的機制。
這個由圖表heap值變化可以清晰看出。
而view切換過程中，不用的資源若是不手動設置為null會導致變量得不到回收便脫離框架控制而失控了。所以我們在webapp的過程中需要注意：
l? 釋放沒有使用的閉包
l? 觀察者需要得到清理
l? 釋放定時器
l? view切換過程中，在destroy中釋放view相關資源
——感謝艾倫友情支援
閉包陷阱
在我們工作過程中，濫用局部變量極有可能引起閉包陷阱，這個問題不止是性能問題，在邏輯上會引起錯誤，而且不易發現，比如，在AMD閉包中使用一個局部變量
var _attributes = {};
callback ($.extend(_attributes, opts));
如此操作，會改變_ attributes對象，若是一個實例還無問題，但是兩個實例的話便會發生變量污染。
這只是一個例子，但是在代碼中濫用局部變量可能會引起不必要的隱憂，戒之慎之。
webapp資源釋放
根據前面的描述，我們可以得出一個結論：
無論是view還是UI組件我們得提供統一的destroy接口，以便讓用戶繼承釋放資源。
若是view的資源得不到釋放導致heap值過高，webapp模式的網站其價值大減。這里有幾點可以考慮：
l ?webapp中view實例保存不超過5個，多了便釋放dom結構以及內存引用（臨界值自己判斷最優）
l? view隱藏時釋放內部資源，解除DOM事件句柄
l? UI組件與view相同，需要統一釋放機制
但是單頁應用由于頁面不會刷新，總有一些資源得不到釋放，此問題任重道遠，平時編寫過程可以做以下優化：
l? 使用函數替換邏輯
讓我們的函數產生一個返回值替換函數中的大段邏輯，這樣的第一個好處便是邏輯清晰，第二個好處是這些函數在不同的函數中，這個函數被使用后便會自動得到釋放。
l? 清理閉包引用
當一個閉包函數或者什么使用結束后，若不會再使用，便需要手動清理該變量，以便解除閉包之間的引用關系，從而釋放資源。
l? 使用對象屬性或者方法
一個對象可以引用其他對象的屬性或者方法，比如obj.foo = thatObj;這種情況下，我們可以隨時刪除對象解除引用關系，然后便可以清理資源。
動畫與假死
動畫而言建議采用CSS3實現動畫，CSS3中又推薦采用最新的接口，比如使用transform取代top/lelf操作，這樣操作效率搞得多。
若是采用動畫可以將對應元素設置為absolute以減少回流，另外最關鍵一點還是
避免移動DOM樹過多的節點，這個時候需要駁回產品無理需求，比如：
產品要求日期滾屏組件，顯示半年的數據，這半年的數據便是180個DOM樹
這個級別的DOM一旦移動整個手機會直接卡死，甚至構建DOM樹，渲染頁面也會出現假死現象，該問題需要規避。
Application Cache
Application Cache是HTML5為webapp離線使用而增加的API，與localstorage、cookie等不同，Application Cache存儲的是一系列請求資源允許瀏覽器在請求資源時不必通過網絡，設計得當的話可以實現離線應用。
使用Application Cache主要是在網絡性能上提升，有效降低了網絡延遲，提升請求加速
?
但是也會有一些問題，比如新版本緩存不立刻生效；manifest中的請求路徑相對于manifest文件，而非加載頁面；更新/回滾等問題，所以使用與否還得論證。
體驗優化
區域滾動
移動端經常需要實現區域滾動的需求，成熟的也有IScroll解決方案，但是方案卻不理想。
就官方的例子便會出現以下問題：
l? 頭部消失
l? 偶爾不能顯示文本框焦點，或者焦點錯位
若是以上問題可忽略，但是文本框不見了這種事情，我是不會接受的
導致的原因與組織瀏覽器默認事件有關，所以，我這里不太推薦各位大范圍的使用區域滾動，而改在區域使用，
就去哪兒的ipad版本在一個具有文本框的地方使用了IScroll，其提高的用戶體驗與導致的問題一樣引人入勝。
事實上，小釵及其推崇IScroll庫，雖說他有這樣那樣問題，但是，IScroll是最有可能帶來移動端革命的庫，因為他可以：
① 解決webapp區域滾動
② 變相解決fixed問題
③ 解決動畫過程帶來的長短頁問題
總而言之，IScroll方案的提出，是讓webapp媲美native app靠近了一大步，真正的平起平坐還需要瀏覽器的支援
點擊響應
click本身在移動端響應是沒有問題的，但是我們點擊下來300ms 的延遲卻是事實，這種事實造成的原因就是
手機需要知道你是不是想雙擊放大網頁內容
所以click點擊響應慢，而touch卻不會有這樣的限制，于是移動端的touch相當受歡迎，至于鼠標慢，他究竟有多慢，我會告訴你每次會慢300ms
所以該問題需要處理，具體見：http://www.cnblogs.com/yexiaochai/p/3462657.html#_h2_7
結語
webapp不是一天兩天的事情，總有一天，webapp會綻放其應有的風采！
?
http://www.cnblogs.com/yexiaochai/p/3759959.html
