HTML5+CSS3方式实现mobie app的瓶颈

 　　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向后兼容方案是通过javascript+css+html来模拟html5的一些特性，但过多的js存在于mobie app中会不会得不偿失。

　　个人觉得，移动互联网的发展趋势一定也是从C/S模式向B/S模式转变。但面临的困难就是，手机端的浏览器更多，对web标准的支持也不尽相同，适配各种分辨率的手机屏幕也是让人很崩溃的一件事情。相信以后的移动互联网也将适应现在的格局：web方式浏览信息，app方式游戏，工具等。