高飞宇 | Goofy

转载自：http://hax.iteye.com/blog/978184

最近我做了一点儿针对手机的Web开发和相关研究。按说，Web自设计之初，就已经考虑了设备无关性。然而，现实总是不尽如人意。 

我们知道大多数网页都是针对桌面显示器开发和测试的，但是手机屏幕通常要比桌面显示器小很多，比如iPhone也就是320px。那么那些网页在手机上如何浏览呢？

一种是把网页缩放到很小，你可以看到整个网页但是看不清字了；或者只看网页的一个局部，然后上下左右移动来看其他部分。现在的手机浏览器把两种模式结合使用。（或许还有第三种——分析网页，将其中内容抽取出来，重组，然后呈现，不过这里不讨论这种方式。）

如果仅仅是出现横向滚动条，那问题倒不是很大。对于那些采用固定布局的“像素级精确设计”确实就是如此。但是使用自适应布局的网页就有问题了。比如一个三栏布局，其中一个边栏可能只有20%宽度，320px的屏幕上只有60多像素，只能放5个汉字，排版不美观不要说，如果里面有一些图片，很可能图片的宽度都超过60像素，造成overflow，从而破坏了布局。另一种常见布局方式是采用固定大小的边栏，例如240px宽，而主体部分则自适应宽度。然而对于320px的屏幕来说，本来是次要的边栏占据了3/4空间，主要部分却只有1/4空间，另外也极有可能因为内容包含图片等造成overflow。

说到这里，那些喜欢固定布局的人（比如那些热衷于960px grid排版的同志们——哦，最近淘宝升级成1000并放弃了栅格！不过那仍然是固定布局）可能要乐了，你们倡导了半天流式布局，结果在mobile设备上表现反而很糟糕，真是费力不讨好。

真正掌握CSS的同志（是的，珍稀动物！）肯定会反驳。上面这些问题其实都很容易解决。比如设定min-width。还有，适应不同屏幕大小的“正确”的方案，应该用media
query。

问题是，大多数网页没有这么做！或者说不是按照“正确”的方式写的！未必是网页作者不懂CSS，而只是他们压根没费心考虑过手机大小的屏幕（毫不惭愧的说，本人也是其中一份子）。你可以试着把桌面浏览器收缩成320px宽（或者可以试着zoom
in到300%），可以看到不少网页会发生严重的布局错乱，至少也是浏览体验上的大幅下降。为了迎合这些网页，手机浏览器厂商发明了两个viewport。

简单来说，就是手机浏览器把自己冒充为拥有一个更宽的屏幕，这样页面的布局就能跟桌面浏览器一样了。不同浏览器冒充的数值不一样：iPhone是神奇的980——960它表弟；Android是保守的800——冒充一个800*600的显示器；而Windows
Phone 7则是1024——冒充一个1024*768的显示器（充分体现微软的庸俗特质）。

原本布局就是按照viewport（桌面上的浏览器窗口）大小来进行的，现在决定布局的viewport和窗口分裂了，产生了两个viewport。

两个viewport其实并不新鲜。就像前面说的，所有做固定布局的同学其实都在不自觉使用两个viewport——固定布局，其实相当于人为设定了布局viewport。

使用独立的布局viewport还有一个好处，那就是缩放变得很简单，不用引起relayout。

在浏览器的历史上，主要有两种不同的缩放方式，一种是以IE6为代表的缩放（文字大小），实质是改变root元素的字体大小。另一种是像素缩放，实质是改变CSS
pixel的大小（即1个css像素不再对应1个物理像素），或者说改变了浏览器的内部DPI。（Firefox还支持真正的字体缩放，与改变root元素的字体大小不同，它会缩放所有元素的font-size最终使用的值（used
value），因此不仅对于以em设定的字体大小有效，对于以px和pt等所有单位设定的字体大小都有效。）

在桌面浏览器上，因为缩放时viewport的物理大小是固定的，如果进行像素缩放，实际就意味着viewport以CSS
pixel计算的宽度和高度会随之改变，比如若放大到200%，CSS宽高就会缩小到原来的50%。而这必然引起relayout。

相反，在mobile浏览器上，像素缩放时，布局viewport的物理大小可随之缩放，因此其CSS宽高值是不变的，就不必引起relayout。这不仅避免了relayout的大量计算，也更符合移动设备上的用户体验（考虑一下你如何缩放地图就明白了）。

虽然两个viewport能比较好的解决在手机上浏览过往网页的问题，然而，这毕竟是一个向后看的方案，体验毕竟是受限的。想象在320宽的窗口里看960固定布局的网页，不可避免的要时常缩放和使用横向滚动条。在触摸屏上我们可以用手势来控制，会方便一点，但是仍然很麻烦。所以绝大多数移动Web开发者最终还是选择针对小屏幕（重新）进行设计。

不过一个显然的问题是，如果我的网页已经考虑了小屏幕，甚至就是专门为手机设计的，那么我其实不需要两个viewport（也不需要缩放），这时候怎么办？更一般的问题是，如果我设计的网页不是针对960或者800或者1024的呢（至少你选了960，就排除了800和1024；你选了800，就排除了960和1024；你选了1024，就排除了800和960……）？

于是Apple发明了viewport的meta标签，例如：
<meta
name=”viewport” content=”width=320,
initial-scale=1.0, minimum-scale=1.0,
maximum-scale=1.0″>

其中width表示网页的布局layout宽度。initial-scale表示初始时的缩放比例，minimum-scale和maximum-scale分别表示最小和最大缩放比例。这样，上面这个meta就表示布局宽度320像素，初始缩放为1倍（即不缩放），且禁止用户缩放（因为最大最小缩放都为1倍）——一个专为iPhone优化的网页通常就会用这样的设置。

如果你是针对960设计的，那么可以用这样一个meta：
<meta name=”viewport”
content=”width=960, initial-scale=0.33″>

这表示布局宽度为960像素，初始缩放为0.33，也就是，会缩小到大约1/3，这样正好可以在320像素的宽度里看到整个网页。你也可以不设initial-scale，因为手机浏览器大多默认会初始缩放到可容纳整个网页宽度。

嗯，看上去不错吧。

可是，说到底，手机浏览器的这种设计，实际上揭示了一个难堪的真相——你们这些网页仔，其实从来没真正做好过屏幕适应。因为一个能自动完美适应不同屏幕大小的“正确”方案，width的取值就不应该是一个固定数字。幸好，safari的工程师在发明viewport时还是给我们留了点面子，width的取值除了像320或960这样的数字，也可以是关键字device-width（其实我认为更合适的词是auto），表示采用设备宽度。

然而，历史总是杯具的重复自己。微软就又（嗯，我为什么要说“又”呢？）贡献了这样一个例子：Window Phone
7的设备宽度通常至少是480，那么按理说，如果viewport中设置了width=device-width，layout宽度应该是480像素，可是IE mobile会将viewport设为320！这是神马原因呢？

原来据说微软收集的数据表明，有大量站点使用了device-width，但是其实只为320像素宽（也就是iPhone的宽度）优化——比如直接用一个固定宽度320px的<div>将内容wrap起来！我勒个去，诸位移动Web开发者，你们有木有这么干？有木有！

那后面的故事就不用说了。微软当然是做出了一个“正确”的选择。

另外需要注意的是，width只是设置layout宽度，还要乘上缩放比例，才能得到最终的显示宽度。那么对于480像素的屏幕来说，若device-width“被320”，那initial-scale应该是1.5才能占满整个屏幕宽度。可是如前所述，针对性优化的网页会把initial-scale设成1.0！

对此微软是如何处理的呢？文档语焉不详，而其模拟器要在Windows
7上才能运行，所以我也暂时没有进行实测，不过据我推测，其initial-scale应该仍旧会保持1.0，也就是这1.5会变成额外的缩放因子。实际上其他移动浏览器已经这样做了，比如Fennec（Firefox的移动版）就是如此。Android和iPhone
4也都有类似的设计，为什么会这样？这样会不会产生新问题？留待下一篇博客再讨论。