构建自适应的手机页面

[mishe]

第一种方案

<meta name="viewport" content="target-densitydpi=device-dpi,width=640,user-scalable=no" />

修正方案
<meta name="viewport" content="width=640,initial-scale=0.5,maximum-scale=0.5,minimum-scale=0.5,user-scalable=no">

简便易行，适用情况：

网页设计仅针对手机屏幕，并且没有需要根据手机屏幕尺寸进行UI调整的内容，既没有媒体查询的CSS
产品层面可以不考虑非主流设备或浏览器的兼容性，例如黑莓的某些设备或搜狗浏览器这类的不支持640定宽渲染的浏览器
当手机横竖切换时，能够容忍部分手机在横屏浏览网页时，可能出现的问题(潜在问题)。
这个方案是强制让手机浏览器按640的比例来呈现网页，让浏览器去做尺寸适配；这个方案我觉得其实非常好，绝大多数的场景都可以支持，而且开发起来简单高效，不需要考虑各种尺寸和样式表的单位换算问题。

这个方案有点类似css zoom，就是浏览器将整个网页进行了缩放，注意一点：PC端的使用浏览器的开发工具进行缩放的时候，譬如使用iphone 5s 模式预览，可能会有问题，比如border:1px的时候可能会不可见，字体会有些模糊等，但是手机端展现的时候不会出现这些问题，因为绝大多数手机目前屏幕分辨率都足够高，而且专门针对viewport做了处理，所以这个问题可以忽略。

这个方案可能会造成文字模糊问题，可以用-webkit-font-smoothing:antialiased来改善这个bug

第二种方案

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no" />

上面这个不用解释了，绝大多数知名网站都这么做的，但是为了能够让图片和字体去做自适应，通常的做法是使用rem来作为单位，然后再启用javascript判定屏幕宽度，动态改变html元素的fontsize。

为了方便计算，通常会默认将html的font-size设置为100px，这样方便计算，例如你的网页字体是16px,只需要写成0.16rem就行了，然后假如设计稿是按640宽度设计，切图的时候完全按设计稿来进行单位换算，然后在js中获取屏幕宽度，根据比例：100/x = 640/documentWidth 计算html的字体大小即可，当然要加入一个window.resize事件重新计算，以防横竖屏切换。

第二种方案有几个弊端：

由于背景图片无法做缩放，(background-size:cover|contain)只能针对单张图片，而对于sprite css image无力解决，所以这里要求如果有背景图，全部制作成单张的，然后再加上background-size:cover|contain，这里凸显出使用css font的好处了...
页面中的所有单位都需要用rem来计算，虽然 X/100是很简单的计算，但是书写的时候还是让人厌烦。
如果有图片必须指定宽度，不然图片会按原始宽度进行渲染，当屏幕尺寸与设计预期尺寸不一致时，就会出错了。
根据上面的描述，我做了两个工具：

制作时依然采用px作为单位，通过watch插件监听css文件的改变，然后动态转换px2rem。
根据图片生成auto convert css icon文件，类似grunt-sprite，但只生成对应的css，而不合成图片,这样对于将以往的css sprite工具生成的图片可以低成本切换成单一图片ICON
开发思路是这样：

开发时区分目录，例如src表示源码，dest目录标示转换后的静态文件，目前上规模的工程都这么做，应该没什么成本了，然后css依然使用像素作为单位。
通过grunt或gulp插件来监听文件改变，然后做copy,sync之类的处理，同时这里将css中的px按设定的比率转换成rem。
不能在网页中直接嵌入内联style，或者需要自行转换单位之后嵌入。
监听脚本：
(注：这里假定开发的时候依据的宽度的640，默认字体是32像素)

// 根据屏幕宽度适配字体大小
$(window).on('resize', function () {
  var width = document.documentElement.clientWidth;
  $('html').css('font-size', (width / 640 * 32) + 'px');
}).triggerHandler('resize');

总结

第一个定宽开发的方案其实非常适合小团队做推广页面，因为这样避免了各种工具的整合，降低了开发复杂度。

第二个方案适合需要适应绝大多数尺寸浏览器的项目，同时如果配置好打包工具，可以很大程度降低难度，将开发和部署解耦，开发代码比较清晰。

[mishe]

第一种方案在webview中存在严重的兼容问题！！！ vwebview不支持target-densitydpi=device-dpi

[mishe]

第二中方案的补充方案：不考虑安卓4.3及以下版本，单位尺度可以使用vw

[mishe]

https://zhuanlan.zhihu.com/p/25216275

[mishe]

配合JS，第一方案就是最佳的开发实践了

[mishe]

#152