web app在分辨率问题上的考虑
移动互联网上的web app开发，非常常见的分辨率方面的做法是设置viewport的width为device width。这么做最大的好处是可以无视具体设备的分辨率，抛弃掉viewport的dpi缩放，让浏览器的像素和物理设备的真实像素保持1:1，无任何缩放，优点非常明显 —— 界面很细腻。而这么做的话，最大的挑战有两方面：在产品的美术设计上，在大分辨率和小分辨率小，都能保证美术的UI不会挤在一块儿挤变形或分得太开很难看;在技术上，在保持代码的弹性，能适应不同的分辨率。具体来说，有两种不同的方法可以应付这两方面挑战：
1）做一套比较简单的UI，在美术和排版设计上，保证图片可以自由伸展 —— css中的滑动门设计，大家懂的吧？设计就做个类似滑动门的设计，保证两头不变，中间可以自由拉伸。技术上别在最外层设一个固定宽度了，流体布局，你懂的。这种做法实现成本最低，但相应的，在美术设计上也会有很大的限制，不能对不同的分辨率做相应的最好设计，一般来说，美术设计都会相对很简单。
2）针对不同的分辨率，做几套不同的美术排版设计，然后在技术上写几套不同的代码，嗅探一下设备的分辨率，不同分辨率用不同的代码。这么做的好处是不同的分辨率下都能有最适合的美术排版设计，但相应的，开发和维护的成本都会大增，而且非常令人头痛的是pc、android、ios、winphone等不同设备的分辨率不同，舍弃哪些，选择哪些，如何向未来兼容等等都是头痛的问题。
一般来说，用第一种解决方案是比较常见的做法，毕竟实现成本低，可维护性高。但用第一种方案的话，有个前提条件是“界面允许向下滚屏”，因为内容是固定的，但宽度是不确定的，所以高度也是不确定的。如果设备宽度够宽的话，那么高度自然就小，比如一段文本在320px宽度下占10行，在640宽度下可能就只占5行了。“界面允许向下滚屏”是采用这种方案的一个必要条件。
但有些应用，对滚屏就非常敏感了，它们希望只用一屏来显示内容。这时，第一种方案就无法使用了。我们当然可以选择第二种方案，但其实还有另一种方案——使用viewport，设置一个固定宽度，在浏览器里开发的时候，只用针对这个固定宽度来开发，通过dpi的缩放来适应各种设备的真实分辨率。关于viewport在ios和android下的具体设置可以参考我上一篇博客：http://hi.baidu.com/cly84920/blog/item/b3c292a778a30e8bd04358f2.html 。
但其实通过设置viewport也会遇到头痛的问题 —— 在android下，设置缩放是通过手动指定dpi来实现的，并不是直接设置缩放后的width(这点和ios不同)，这就遇到一个麻烦了，dpi和具体的物理尺寸是直接相关的，3.5寸、4.0寸、7寸、9寸甚至平板电视40~60多寸，要想通过dpi，在浏览器里保持同一个width的话，就必须得知各个设备的真实分辨率和其物理尺寸，动态地计算出dpi的值，通过js去设置viewport，可是，物理尺寸在js中拿不到啊! 好的解决办法没有了，只能针对主流设置进行取舍了，不可能照顾到所有设备了。在面向未来的兼容上，是个头疼的问题。
在“不滚屏”这个制约条件下，我共能想到三种实现方法，列了一下优缺点：
1）设置viewport的宽度为800（目前android主流的分辨率为480 * 800），高度取所有主流设备的最低高度。
【优点】：
<1> 图片只设计一套、美术排版一套、程序只开发和维护一套
<2> 向前兼容更好（不用时刻关心最新的市场行情——新的主流分辨率）
<3> 兼容新的设备更容易（不用去调查新设备的分辨率在市场上的分布，只针对viewport的800宽编程）
【缺点】：
<1> 有dpi缩放，质量会失真
<2> 兼容android设备时，无法得知物理尺寸，无法很好兼容所有尺寸的设备
2）设置width为device width，但主体区域仍然按800像素宽进行设计和编码，主体区域居中，其余地方用背景图铺满，也就是一个假满屏。
【优点】：
<1> 无dpi缩放
<2> 图片只设计一套、美术排版一套（背景图要求比较大），程序开发和维护一套
<3> 兼容新的设备容易
【缺点】：
<1> 在大分辨率小，主体区域会显得非常小，影响可用性
<2> 向前兼容不好
3）设置width为device width，真正按deveice width去设计主体区域，也就是一个真满屏。
【优点】：
<1> 无dpi绽放
<2> 对各个平台用户界面设计保持最佳。
【缺点】：
<1> 图片出多套
<2> 排版设计复杂度高，考虑各种分辨率情况
<3> 向前兼容性不好，需时间关注市场最新动向，对新的主流分辨率进行支持
<4> 兼容其它终端麻烦，需再做调查，再开发新版本
<5> 代码需编写和维护多套，且不断更新，嗅探器多
