PC的早期阶段，也是传统的C/S模式居多，后进化到B/S模式，并产生了SaaS、云计算等概念和应用。从客户端进化到浏览器***好处是客户端无需更新，减少了大量的更新成本，只需服务器端进行更新。这也是为什么现在流行WebQQ, google docs, photoshop网页版的原因。现在同时很多软件厂商也在制作他们的Web版本，国内的一些ERP厂商也开始了这条道路。iPhone、Android的巨大成功揭开了移动互联网的大幕，互联网企业都想在移动互联网的的巨大市场中分得一杯羹。游戏、sns、微博、视频、本地生活服务都在大力发展移动互联网，推出了自己的app。
mobie native app指使用手机官方提供的SDK和开发语言开发的手机客户端软件，它能够很好的使用手机提供的一些接口来操作手机的软硬件资源。随着HTML 5和css3的流行和Webkit对HTML 5和css3的较好支持，很多人开始使用HTML 5和css3来制作移动应用。如前所述，使用Web方式制作移动应用***的好处是，客户端无需更新，并且数据显示很多手机用户不是经常更新他的app程序，同时相对于native app，Web方式修改app的界面的成本更低一些。所以说，对于对界面的灵活性有较高要求的app，比较倾向于用Web方式实现移动应用。
Android和iPhone都提供了Webview的控件，这个控件实质是一个Webkit浏览器内核，用于解析html、css、js代码。所以，native app可以调用Webview空间来展示我们的Web页面。同时，由于对css3的较好支持，native那种绚丽的界面就可以用html+css较好的实现出来，达到逼真的native app的效果。
但是，Web实现移动应用有一些瓶颈。以下是我在项目实战中碰到的，如果各位看官有好的解决方案，请不吝赐教。
其一，根据百度移动互联网发展趋势报告2010Q4，iPhone下下载一个1.407k的网页，建立连接耗时1.35s左右，传输耗时0.15s左右。这样，导致app在建立连接的时候，屏幕处于白屏状态。也就是说这个app在一秒多的时间内，完全处于白屏状态，再加上3G、GPRS网络的不稳定，有时候等待app响应需要几秒甚至1几秒的时间，这对于速度就是生命的移动应用来说，无疑是个致命的缺陷。
其二，有人说，native app也需要建立tcp连接，同样需要耗时这么长时间。很对，那么目前常用的解决方案是什么呢。开机画面+loading图片，有了这两个，程序不会处于假死状态，用户拥有耐心继续等待。那么，Web app是否也能这样做呢。首先，程序打开同样显示开机画面，画面结束后切换界面(Webview)，Webview如果无loading图片依然是在建立连接，依然处于白屏状态。因为我们无法在开机画面的时间内对程序进行预加载。然后，使用native方式在Webview外面蒙上一层，上面放上loading图片，但是Webview没有提供Web页面开始渲染的接口，指提供了Web页面load完成的接口。也就是说，如果通过native方式在Webview上放置一个loading图片的话，那么这个图片指能在页面完全加载完消失，这样也会影响用户体验。这里再提供一种方式，实现这种loading图片的效果：放置一个静态页面在本地，点击打开静态页面，无需建立连接。而后通过ajax方式请求数据来替换页面内容。这种方式，也是Nokia widget的实现方式，但是这种方式的效率比较低下。
其三，难以实现本地存储。本地存储是HTML 5的一个重要成果之一，但是，基于Android存在多版本系统。Android低版本中的Webkit对HTML 5和css3支持的并不好。简单的两个例子是：input type="number"会导致低版本Android的Webkit直接crash，css3的圆角在低版本的Android Webkit中也会出现明显裂缝。现在常用的HTML 5向后兼容方案是通过javascript+css+html来模拟HTML 5的一些特性，但过多的js存在于移动应用中会不会得不偿失。
个人觉得，移动互联网的发展趋势一定也是从C/S模式向B/S模式转变。但面临的困难就是，手机端的浏览器更多，对Web标准的支持也不尽相同，适配各种分辨率的手机屏幕也是让人很崩溃的一件事情。相信以后的移动互联网也将适应现在的格局：Web方式浏览信息，app方式游戏，工具等。
