注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

左岸

web前端

 
 
 

日志

 
 

【转】web app在分辨率问题上的考虑  

2012-08-10 16:34:19|  分类: 移动客户端 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
 移动互联网上的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> 代码需编写和维护多套,且不断更新,嗅探器多

  评论这张
 
阅读(356)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017