PC的早期階段，也是傳統的C/S模式居多，後進化到B/S模式，併產生了SaaS、雲端計算等概念和應用。從客戶端進化到瀏覽器最大好處是客戶端無需更新，減少了大量的更新成本，只需伺服器端進行更新。

這也是為什麼現在流行webQQ,google docs,photoshop網頁版的原因。現在同時很多軟體廠商也在製作他們的web版本，國內的一些ERP廠商也開始了這條道路。iPhone、android的巨大成功揭開了移動網際網路的大幕，網際網路企業都想在移動網際網路的的巨大市場中分得一杯羹。遊戲、sns、微博、視訊、本地生活服務都在大力發展移動網際網路，推出了自己的app.

mobie native app指使用手機官方提供的SDK和開發語言開發的手機客戶端軟體，它能夠很好的使用手機提供的一些介面來操作手機的軟硬體資源。隨著html5和css3的流行和webkit對html5和css3的較好支援，很多人開始使用html5和css3來製作mobie app.如前所述，使用web方式製作mobie app最大的好處是，客戶端無需更新，並且資料顯示很多手機使用者不是經常更新他的app程式，同時相對於native app,web方式修改app的介面的成本更低一些。所以說，對於對介面的靈活性有較高要求的app,比較傾向於用web方式實現mobie app.

android和iphone都提供了webview的控制元件，這個控制元件實質是一個webkit瀏覽器核心，用於解析html、css、js程式碼。所以，native app可以呼叫webview空間來展示我們的web頁面。同時，由於對css3的較好支援，native那種絢麗的介面就可以用html+css較好的實現出來，達到逼真的native app的效果。

但是，web實現mobie app有一些瓶頸。以下是我在專案實戰中碰到的，如果各位看官有好的解決方案，請不吝賜教。

其一，根據百度移動網際網路發展趨勢報告2010Q4,iphone下下載一個1.407k的網頁，建立連線耗時1.35s左右，傳輸耗時0.15s左右。這樣，導致app在建立連線的時候，螢幕處於白屏狀態。也就是說這個app在一秒多的時間內，完全處於白屏狀態，再加上3G、GPRS網路的不穩定，有時候等待app響應需要幾秒甚至1幾秒的時間，這對於速度就是生命的mobie app來說，無疑是個致命的缺陷。

其二，有人說，native app也需要建立tcp連線，同樣需要耗時這麼長時間。很對，那麼目前常用的解決方案是什麼呢。開機畫面+loading圖片，有了這兩個，程式不會處於假死狀態，使用者擁有耐心繼續等待。

那麼，web app是否也能這樣做呢？

首先，程式開啟同樣顯示開機畫面，畫面結束後切換介面（webview）,webview如果無loading圖片依然是在建立連線，依然處於白屏狀態。因為我們無法在開機畫面的時間內對程式進行預載入。

然後，使用native方式在webview外面蒙上一層，上面放上loading圖片，但是webview沒有提供web頁面開始渲染的介面，指提供了web頁面load完成的介面。也就是說，如果通過native方式在webview上放置一個loading圖片的話，那麼這個圖片指能在頁面完全載入完消失，這樣也會影響使用者體驗。這裏再提供一種方式，實現這種loading圖片的效果：放置一個靜態頁面在本地，點選開啟靜態頁面，無需建立連線。而後通過ajax方式請求資料來替換頁面內容。這種方式，也是Nokia widget的實現方式，但是這種方式的效率比較低下。

其三，難以實現本地儲存。本地儲存是html5的一個重要成果之一，但是，基於android存在多版本系統。android低版本中的webkit對html5和css3支援的並不好。簡單的兩個例子是：input type=「number」會導致低版本android的webkit直接crash,css3的圓角在低版本的android webkit中也會出現明顯裂縫。現在常用的html5向後相容方案是通過java+css+html來模擬html5的一些特性，但過多的js存在於mobie app中會不會得不償失。

個人覺得，移動網際網路的發展趨勢一定也是從C/S模式向B/S模式轉變。但面臨的困難就是，手機端的瀏覽器更多，對web標準的支援也不盡相同，適配各種解析度的手機螢幕也是讓人很崩潰的一件事情。相信以後的移動網際網路也將適應現在的格局：web方式瀏覽資訊，app方式遊戲，工具等。

本文來自搜狐公眾平臺