基于HTML开发手机应用的新模式

1     引子

不知什么时候开始，iOS和Android火了，手机应用程序员的薪水突地坐上了神舟5号，一夜之间一升再升，直接摆脱了地球引力，飞出大气层。然而，不是每个公司都有这样的实力和魄力，养得起程序员中的高富帅。

屌丝老板想做手机应用充高富帅，但养不起高富帅程序员；屌丝程序员想跻身高富帅，但不会做手机应用。于是，物竞天择的屌丝群中，冒出了一撮聪明人，他们认为用浏览器也可以做手机应用。事实证明，这群人的想法行得通，尽管头上还顶着“非主流”三个字。

2     预览和调试

2.1   难以忍受的模拟器

做手机开发的童靴们，最不可忍受的应该是模拟器了；每次修改和调试程序，模拟器都需要对应用进行卸载和安装，并同步调试进程，最恶心的是偶尔还要重启模拟器，这真真是一个磨砺心性的强大武器（高富帅也有难受的时候？）。

屌丝们的梦想是基于HTML的，可以省去很多工作，比如代码的编译，打包，重新发布等工作。但不可避免，界面的调整和功能的调试，大部分时候还是会回归到模拟器中来（事实上，直接通过USB连手机调试，比模拟器快N倍，不过这样一来对屌丝们的装备就有所要求了）。

2.2   姑且一试

基于HTML开发手机应用，不论是网页应用，还是基于各类框架（PhongGap、AppCan、Rexsee之流）的本地应用，其事实上都有一个重要的基础媒介：浏览器（这大概也是WebKit名声大噪的原因之一）。

到这里，童靴们大概还没明白我要说什么？

其实我想说：咱们就直接用Chrome充当模拟器吧。

我们知道（iOS和Android）手机上的浏览器都是基于WebKit内核，唯一的区别就是WebKit的版本不一样。当然，这会导致一个比较严重的问题，就是WebKit不同的版本，对HTML和CSS标准的支持有些差异。

恩，这也让我们学会一个铁则：尽量采用兼容性比较好的HTML标签和CSS属性！

既然如此，那么用Chrome做模拟器，就显得理所当然了。尽管手机和PC的分辨率不一样，在一些细节的展现和处理上会有些微差异；但胜在PC的速度够快够方便，不管是调试程序逻辑，还是界面流程，都是流畅自如畅快淋漓。

3     方法与模式

3.1   js的渗透程度

很多童靴害怕接管太多的事件，希望最大程度的借助浏览器及各种框架（jqMobi、jQueryMobile之流）本身的功能，并且潜意识里觉得（更多的是期望）二者已经为我们提供了足够好的封装。

然而事实并非如此，手机不同于PC，用户喜欢用更少的流量和更快的速度，浏览更多的内容。如果仅仅是采用浏览器和框架提供的功能，至少我们就无法使用缓存（说localStorage更贴切点）。所以我们必须认真考虑js代码的渗透程度，也可以理解为程序中有多少链接是由js来控制的？这没有标准答案。但好在可以给童靴们提供一条建议：但凡页面内容是动态请求而来的，请接管这个链接。

3.2   代码的一致性

上面提到用Chrome充当模拟器，事实上代码在Chrome和手机浏览器上运行，还是会有一定的差异，特别是我们采用了框架的情况下（如：PhoneGap）。

解决差异的办法，可以沿用古老的门面模式来实现。

假设我们需要在页面上输出设备名称（我们知道，在Chrome中是没有