陳子舜，騰訊Web前端研發專家。先后負責QQ空間、開放平臺、SNS應用產品的Web前端研發工作和團隊管理；業界筆名Puterjam，著名博客平臺PJBlog作者； 長期專注于海量服務業務的Web前端架構設計、運營優化、創新解決方案研究，同時也是多終端移動互聯網技術研究和實踐的先驅者。<<
<
HTML5早在2004年就開始被WHATWG提出。歷經8年時間的發展，HTML5技術已經不再是紙上談兵。目前W3C 的HTML Group中已有76個公司參與新的標準制定、貢獻力量。未來前端開發的責任和前景非常重要，HTML5技術可以給我們的產品體驗帶來更多的機會，那么我們如何升級現有的胖子業務？ 8月21日晚，騰訊Web前端研發專家陳子舜，在騰訊大講堂為大家帶來了騰訊海量業務前端底層架構的詳細解析，以及用戶體驗和我們該如何進行新技術的蛻變。 在中國特殊情況下，要使用這些新技術并非一帆風順、仍有很多困擾： 1. IE族（6 7 8 9）整體支持不濟，其中IE6用戶占了絕大多數； 2. HTML5技術發展非常迅速，我們該從何開始？ 3. 這些技術是否只能用在手機上？ 4. 如果用到我們項目中, 該如何開展？ ......
<<
這些問題或許成為我們的障礙，但絕對不會影響到我們對HTML5技術的熱情！ 對于一個真正的前端架構師，這些障礙只是浮云。 首先，HTML5是解決眾多舊Web時代前端問題的革新解決方案集合。 其次，實戰HTML5不能以‘僅在項目中用到’為目標，而是應該以更加前瞻的眼光去看這些技術背后、其誕生和繁衍到底經歷了什么。 最后，要看不同的HTML5技術能解決我們工作中的什么問題，更要看這些問題還有沒有其他解決方案。 帶著疑問回到項目中去思考，游走于HTML5各種技術背后的原因。 非同源資源的共享 在分享開始，子舜帶大家一起回顧，2004年web界誕生的一個非常偉大的請求解決方案 -- AJAX
<
這個方案的出現，讓我們體驗到了前后端數據交換不刷新頁面帶來的快感，給產品帶來了更好的體驗。但是新技術的普及并不那么順利，這里也讓我們遇到了很多問題, 其中在AJAX的實現中最麻煩的事情就是跨域問題（跨域問題的主要產生場景是由于很多大型Web站點，采用動靜分離的資源部署方式，往往前端HTML頁面和需要交互的Web接入端動態資源使用不同的域名，便于運營）。 由于當時環境比較差、用戶的硬件設備也比較糟糕，所以我們最早的proxy跨域解決方案并不成熟。 “請求數過多，頁面渲染慢，proxy頁面維護成本過高” 在以前QQ空間復雜的網絡環境下，每個iframe的創建和渲染的成本都在0.5s左右，這是一筆非常昂貴的開銷。
<
隨后，我們意識到XMLHttpRequest的局限，升級成為現在常用的JSONP的方式。 JSONP看起來是一個不錯的方案，解決了Proxy帶來的各種問題。在騰訊的前端應用中， JSONP請求組件也經歷了多代演化（[keyName]_callback隔離方式，htmlFile組件隔離方式，documentFragment隔離方式，iframe+js:隔離方式），但這些方式是否完美呢？ 本著不完美主義的技術追求者，我們也對JSONP提出了很多苛刻的挑戰。JSONP越來越不能滿足我們對海量業務的要求，我們希望更多去控制、去了解請求的過程。而JSONP無法滿足，每次請求都在頁面上花費很多script標簽（尤其在多請求并發的情況下），服務端不可用、網絡異常、數據損壞導致JSON格式破壞的幾種情況，無法非常方便得區分監控，給用戶提供高可用的服務只能靠開發人員的經驗來做勉強的保證。
一個web業務，在異步請求過程中無法更好的關注和控制請求本身的狀態，其實在很多方面，體驗和解決方案都會變得非常不可控；柔性可用原則也無法達到最大化貫徹，技術的瓶頸和長時間的習慣，導致大家可能越來越少去關注這些問題。雖然對于這些問題都有不同的解決方案，但我們覺得這些解決方案并非完美。 HTML5為了解決現有技術方案背后的一系列原因和問題，提出了XmlHttpRequset 2.0 。新的標準給我們帶來了更多的優化機會。
1. 數據移植性: a. JSON在應用中使用已經非常廣泛，但是我們還是因為舊有JSONP方式的關系，需要把用以觸發JSONP調用的_callback( )外套剔除，剩下的純JSON結構，可以更靈活的用在更多場景，不局限于瀏覽器JS引擎。 2. 數據可控性: a. XHR一直都可以在請求的時候定制化很多個性的HTTP request頭信息，不需要增加自己希望的額外信息到query string。例如：現有的靜態資源服務器端按需合并，因為沒有使用XHR（目前是JSONP），只能把希望在Web服務器上按需合并的文件的文件列表在URL query string上用某種我們自創的協議列出來，看上去比較迷惑。 b. XHR2.0標準，給到數據控制行為可以在數據發起前，加載中、加載后進行多種時間點的判斷，甚至可以給到用戶準確的加載時間，更好的控制和監控數據狀態幫助我們更精確的實現系統柔性可用。甚至可以控制數據是否需要中斷請求，以及告訴后端什么時候發起200或304響應。 3. 多樣化的數據提交方式: a. XHR未來是一個趨勢，可以統一web業務上所有的請求方式，使web業務對網絡的方案一致化； b. POST有專門的對象統一處理； c. 文件和二進制流也可以直接發送； 技術預言隨后伴隨著實踐，我們希望 “業務后面可以回歸到使用XHR進行請求的方式”。 所以我們在朋友網上做了一些技術嘗試，這次嘗試主要還是先從跨域的方案開始實踐。早在3月份，騰訊海量httpserver QZHTTP已經支持了XHR 2.0的CORS方案。同時從發布后的數據分析來看，節約掉的iframe開銷可以獲得 0.5~0.6 秒的提升。
其實部署并非順利，跨域方案在IE8/IE9下其實還是存在明顯的技術缺陷。微軟認為跨域的請求是不應該帶cookie信息的，微軟的IE10才能真正支持到XHR 2.0的cookie授權信息。所以現階段在PC上要使用跨域的CORS還是不能做到非常徹底的部署。團隊成員開始回歸最初的思考：與其更加較勁這些細節，為何不開始部署不跨域的服務？
<
進行同域的部署，有非常多可選方案，并且很多方案都非常成熟。通過各種代理，動態加速的方案，可以減少前端在請求方面的做的過多的兼容性問題，從而從底層解放開發在不同請求方式的選型。把時間更加專注在業務功能上。 另一方面，前端開發在實際工作中除了一直在追求方案的極致優化，架構的模塊化等語言成面的極致，同時也是海量業務的護航者。 所以前端的監控和性能的測量也是我們一直關注的方向，子舜提出：“測量是優化的第一步”。為了提供更好的服務，我們需要對各個環節的網絡情況、硬件情況進行了解。所以HTML5也是為了解決這個問題，提供了更加詳細的監控手段。
<
HTML5的Timing，提供了更多細致的監控能力。從本地緩存讀取，到DNS解釋時間；從TCP連接建立花費，到瀏覽器首頁渲染的時間。都可以非常精準地提供更多業務的監控方式。 同時，未來的時間點監控也將會更高精度超越毫秒的時間戳。目前，這一系列的數據已經在公司很多業務都開始進行測量，給后端運營同學提供更多有意義的數值參考，更加及時，精準得發現我們的業務在不同地區，不同運營商中更加精細的業務數據。
在分享的下半場，子舜帶來了更有意思的分享內容：
長期以來我們一直都非常關注用戶的網絡情況，而且也在這方面做了非常多的實踐。隨著中國帶寬的不斷優化和提升，網絡問題會得到越來越多的改善。 但優化工作是否就可以告一段落？反之，我們的前端優化將會迎來更多更深入的挑戰。
例如，我們的業務，特別是社交業務，功能越來越復雜，用戶對業務的要求也越來越高。同時也開始有很多業務開始終端化，硬件條件將會帶來前所未有的挑戰。 我們開始思考：是否要像客戶端開發一樣、做更加深入的性能優化思考？
QQ空間今年最大的一個突破就是開始用可觀的數據開始反映業務性能問題。 QQ空間的用戶平均停留在30分鐘以上的用戶接近35%。這些用戶都是實實在在得長期掛在空間，并且他們也是一直在忍受著我們業務因為功能邏輯復雜，導致使用過程中頁面渲染性能效率低下的背景下，非常艱難地使用我們的產品。
接下來，第一件事情就是解決用戶CPU的問題。
瀏覽器沒有獲取CPU的接口，但是我們有辦法模擬出CPU的曲線。 瀏覽器的setTimeout和setInterval，很多時候我們都用來做延遲處理，但由于瀏覽器的引擎單線程性，這兩個接口都是一個非常不穩定的存在。如果在瀏覽器CPU資源消耗過高，并且js api處理時間過長，前端的定時器都是無法準確在我們期望的時間點上進行執行的，很多時候都是會延遲，而這個延遲可以被我們利用做成一個差值比例。通過這個比例，我們可以繪制出和當前CPU比較吻合的曲線。
在頁面渲染的測量上，我們做了非常大膽的嘗試，同時也給在前端的各種功能添加以及優化給出了更多有效的數據舉證；給業務的按需加載有了更加具體的數值參考。前端一直以來的按需加載能力將會成為平衡CPU高峰的重要工具，相輔相成。
回到主題，那HTML5在我們的業務是否也會有CPU優化的更多方案思考？答案顯而易見！HTML5在更加底層的方式做了更多的優化能力，而這里最具潛力的是，GPU加速。
在分享的最后環節，子舜給大家帶來了頁面渲染在GPU中的優化方案。 首先，在大家常用的chrome/webkit瀏覽器中，GPU是在另外一個線程上處理的，這也就和以前的瀏覽器渲染單線程帶來了一個非常好的優化。 GPU處理渲染和合成，其實會讓web頁面渲染得到更加合理的分配，GPU在處理動畫及圖片上有非常強的優勢，同時也可以減少遺忘在CPU中處理整個頁面帶來的內存消耗問題。 但我們可以把所有渲染都交給GPU么？答案是不能！GPU雖然在圖像和動畫處理上有先天的優勢，但也有很多不足，比如文字處理和合成、頁面樹的合成，CPU還是會比GPU更加擅長。 為了可以在業務中更好得利用到GPU，我們需要知道瀏覽器到底會在什么時候使用到GPU合成技術。如下圖所示：
很多很熟悉的字眼，其實大家在經常使用css3的時候已經潛移默化在使用到瀏覽器提供的GPU能力了（小Tips: 但是這些也需要非常小心，特別是重構的同學，不要在一些沒有動畫的dom上加太多css3的動畫處理或者帶有css集成的dom。因為會增加前期dom樹在渲染上不必要的GPU負擔) 那我們如何更好得利用這個資源，子舜也給大家提供了一些HTML5 GPU 加速的銀彈。
GPU在合適的時間去使用，HTML5的這些動畫能力是作為局部動畫使用，會給網頁動畫帶來驚人的效率和幀數的提升。
分享中，舜子帶來了一個非常常見的拖拽案例，這個拖拽案例分別在普通的left和top計算，以及css3 transform的差別。
通過chrome的timeline曲線可以看到，前面的Left/Top位移，帶來了非常多的rendering和 painting成本，這些工作都是在CPU的幫助下完成的工作，而這些工作如果換在終端上實現，大部分的終端CPU都無法順利完成這一個任務。 而右邊的曲線，可以看到render工作基本上就不存在了，同時瀏覽器頁把paint的工作交給了GPU處理，從FPS線也可以看到移動速度是有很大的提升穩定在30~60之間。 可以看到GPU確實在發揮其優勢，同時我們可以更好得開始去利用這些資源。但CSS3動畫是否可以取代js動畫？以前setTimeout不準的情況在我們進入HTML5領域需要做游戲的朋友是否會有障礙呢？ 這個問題已有專家提出過，CSS3無法取代JS動畫，但目前JS動畫都依賴setTimeout，其實是一個死胡同。因為setTimeout單線程的不準確性，如果setTimeout超過16ms又會給設備帶來超過25%的能耗浪費，CPU也會因此帶來更多的資源浪費。 所以為了解決這個問題，HTML5的專家也提出為JS動畫，以及canvas游戲專門提供一個可以讓瀏覽器知道開發需要進行動畫處理的方式。requestAnimationFrame
繼續剛才的拖拽實驗, 如果在GPU和RAF的加速下，在曲線圖上可以看到很多時候曲線是在60FPS之上的，而且這個曲線峰值也會出現更多超過60FPS的數值。
可以看到瀏覽器頁開始準確得獲知我們希望做的事情，從而更大程度上平衡CPU的資源，以及頁面渲染和線程之間的資源，給頁面動畫讓出合理的資源，減少了堵塞問題。 在分享的最后，子舜也給大家帶來一些學習HTML5的建議。
Q: 為啥jsonp不支持post？
A:JSONP是個泛的叫法，在舜子 剛才的講解中，意思應該是說，在跨域的場景下不方便簡單高效的做出響應形式為JSONP的POST請求，但是依賴代理頁面還是可以做到的，不過這是傳統做法，應用HTML5 CORS會有更好的解決方案。
Q：HTML5是否會加速桌面操作系統的變化?chrome是否會成為google os的承載平臺?有聯系嗎?
A：隨著未來3年HTML5的飛速發展以及帶寬的提高，基于HTML5技術的WebOS必將更加凸顯出實用的意義，而對于傳統桌面OS，將可以使用HTML5技術來構建本地應用和在線應用！
Q：跨域？
A： 跨域通信請求的通用方案可以參考這篇文章：http://url.cn/7PYImM
Q：通過xhr清本地文件緩存，對于圖片文件不知是否可行？
A：圖片可以的，其實就是用XHR發一個顯式設置no-cache header的request，URL一定要和你被cache的資源的url一致。不過XHR在不跨一級域的情況下，這樣的事情筆記哦好做，傳統方式用代理頁搞定，如果跨一級域，可能要依賴CORS或者IE8+的XDR（不過XDR限制很多，一言難盡）
Q：html5能在cpu性能方面有一個較大的提高呢？
A：Intel的#IDF2012#有一個專門的HTML5專場，專場中Intel的專家展示了很多他們從底層對HTML5性能優化的技術，相信不久的將來我們將會受益！
Q： 想了解下使用什么方法或工具來監控Web App在移動設備上的耗電量？
A：目前還沒有直接的辦法，但是間接的辦法有的，還是通過檢查JS執行的延遲率大致模擬CPU消耗，CPU消耗的模擬值持續較高的話，一般就代表更耗電，當然也可以給W3.org提建議，在HTML5 performance接口群中添加獲取能耗信息的接口，我覺得。
源文：http://djt.qq.com/article-325-1.html
