客戶端主要有兩種選擇:一種是基于瀏覽器HtML5頁面的，一種是Native模式的。到底是選擇HTML5還是Native， Native 如何解決快速迭代問題?
 
1.是Native還是HTML5
 
當(dāng)前移動端主要還是以Native實(shí)現(xiàn)為主，從用戶體驗角度來考慮，Native的實(shí)現(xiàn)要比HTML5更流暢，同時Native還可以基于本地做很多在瀏覽器里不能做的優(yōu)化，如大數(shù)據(jù)的存儲、可以定制的通信協(xié)議、更方便地保持長連接以及更容易實(shí)現(xiàn)的實(shí)時消息推送。


 
當(dāng)然HTML5也有無法比擬的優(yōu)勢，比如客戶端更輕量級、服務(wù)端發(fā)布更迅速、不需要用戶升級版本等。長期來看，移動端是否會像早期PC那樣從富客戶端轉(zhuǎn)向瀏覽器呢?筆者覺得未必，理由如下。
 
首先，相比HTMLS， Native實(shí)現(xiàn)性能優(yōu)勢更好。當(dāng)前移動端都在追求極致體驗，App無疑會比HTMLS有更多的優(yōu)勢；其次，移動端屏幕較小，基于網(wǎng)頁的交互和App相比還有很多限制。最重要的是，不同的商家會主推帶有品牌標(biāo)識的App還是會向統(tǒng)一-的瀏覽器靠攏?從目前的趨勢看，App會是手機(jī)端上爭奪的重點(diǎn)，所以筆者推測直接基于手機(jī)端的瀏覽器的應(yīng)用不會成為主流的前端。
 
2. HTML5的頁面優(yōu)化
 
HTMLS頁面優(yōu)化一般可以從以下幾個地方人手。
 
第一，CSS內(nèi)聯(lián)異步加載。如果頁面中有內(nèi)容要依賴CSS的加載，很多時候就會出現(xiàn)白屏一這其實(shí)就是CSS阻塞了加載，CSS出不來就導(dǎo)致看不到首屏。CSS內(nèi)聯(lián)加載可以節(jié)省異步HTTP請求，CSS內(nèi)聯(lián)異步加載后可以大大緩解白屏問題。不過，就算內(nèi)聯(lián)以后也要觀察異步CSS文件的大小，并且異步之后要觀察domReady的時間變化。當(dāng)然CSS內(nèi)聯(lián)也有可能會導(dǎo)致repaint和reflow的問題，并且由于異步內(nèi)容增大，服務(wù)端的性能開銷也會增加。
 
第二，其他的優(yōu)化。端上的優(yōu)化已經(jīng)有一整套的優(yōu)化方法列表了， 這里介紹一些我們在實(shí)踐中發(fā)現(xiàn)并驗證過的一些特別的優(yōu)化點(diǎn)，如assets 合并、整合頁面中inline的JSICSS到外部文件、將iframe改為JSONP調(diào)用、背景圖合并和將非首屏內(nèi)容加載改為異步等。
 
第三，bigpipe首屏加載。2012年的時候，F(xiàn)acebook有一個比較火的技術(shù)叫bigpipe，可以提升頁面的首屏加載效果，于是我們嘗試過采用類似的技術(shù)測試首屏的加載效果，
 
點(diǎn)擊鏈接http://www.webpagetest.org/video/compare.php?tests=140318 M5_ 7GV%2C140318 Z2 7CJ&thumbSize=200&ival=100&end full，可以通過webpagetest看到頁面的優(yōu)化效果。
 
3. Cookie壓縮
 
在無線場景下要額外注意Cookie，如果沒有留意，它可能會占用你一次無線請求下的大部分內(nèi)容，而且有可能并不會讓你察覺，所以有必要對Cookie進(jìn)行壓縮測試。Cookie是在HTTP的頭部，通常的gzip和deflate都是針對HTTP body的壓縮但并不能壓縮Cookie，要想對Cookie做壓縮測試必須單獨(dú)處理，壓縮方式是將Cookie的多個K/V對看成普通的文本，進(jìn)行文本壓縮。
 
4. URL短域名
 
URL短域名也很好理解，如果無線數(shù)據(jù)傳輸中有大量的域名，而域名又比較長，就會產(chǎn)生很多無謂的數(shù)據(jù)傳輸，最典型的應(yīng)用像微博的hp://.cn，可以節(jié)省很多字節(jié)。但是像這種直接使用真實(shí)的t.cn的短域名是比較奢華的辦法，比較簡單的是使用約定的標(biāo)簽替換，在解析時再替換回去。
 
5. CDN前置緩存
 
在有大量靜態(tài)數(shù)據(jù)請求的頁面中使用CDN前置緩存對網(wǎng)站的加速訪問非常有效。對比分析了杭州主站和CDN上的兩張圖片，一張是空圖片，一張是50KB大小的圖片?？請D片用于測試RTT， 50KB的圖片用于測試網(wǎng)速。
 
6.如何實(shí)現(xiàn)端的快速迭代
 
前面介紹了無線場景下端的優(yōu)化措施，那么當(dāng)我們使用Native來實(shí)現(xiàn)時，遇到的一個問題是基于App的Native如何解決客戶端更新和服務(wù)端的快速迭代問題，一-般有兩種思路:一種是客戶端用同-一種技術(shù)開發(fā)，然后通過工具編譯技術(shù)把它編譯成不同平臺，上能夠執(zhí)行的代碼，如當(dāng)前的React Native； 另一種思路是將客戶端中經(jīng)常需要更新的模塊做成動態(tài)推送的，用模板+數(shù)據(jù)的方式，在不同的客戶端平臺上實(shí)現(xiàn)一個小的解析引擎來實(shí)現(xiàn)快速個性化的定制。
 
那么再說回來，基于前面的這些推斷，網(wǎng)站建設(shè)多終端和服務(wù)端交互主要是以數(shù)據(jù)+模板的方式為主，那么服務(wù)端提供格式化的數(shù)據(jù)將成為必然選項。所以涉及的問題就是服務(wù)端既要提供格式化的數(shù)據(jù)( HTTP JOSN數(shù)據(jù))，又要支持傳統(tǒng)的PC的方式:基于JOSN數(shù)據(jù)渲染出HTML頁面。我們在后面會進(jìn)一步介紹如何解決無線和傳統(tǒng)PC之間的這種差異。