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


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