一个用户,访问一个web页面的真实场景是怎样的呢?
下面是某用户访问某站点的一个场景:
- 小明打开了自己的电脑,访问了Super xing
- 小明体内洪荒之力无法控制,疯狂拖动浏览器改变其宽度感受页面布局变化;
- 卧槽,发现页面居然是响应式的,不由得感叹:实现的够骚气!
很显然,小明要么是雷蜜胡粉心碎抓狂,要不就是前端开发职业病发作难耐。作为真实的用户是不会把浏览器刻意缩小去体验的,你想想看你平时上网的时候,会把浏览器窗口拉到很小吗?怕是嫌屏幕小,恨不得显示器大到铺满办公桌吧~~
回到传统的响应式开发
传统的响应式实现往往基于基于media query查询,例如:
@media screen and (max-width: 480px) {
/* 窄屏下 */
}
这是基于CSS的布局控制,因此,当我们缩小浏览器窗口,可以即时看到布局变化。但是,这种实现在我看来,除了让总监大人可以方便体验窄屏效果外,就然并卵了! 而反倒是有可能增加了额外的资源消耗和开发成本。
@media可以即时控制宽窄布局,很自然地,我们的JS逻辑也要一并跟上。假如说,PC和mobile有很多不同的交互逻辑,我们的HTML是同一套,当我们在响应PC和Mobile零界点不停变换的时候,我们的JS逻辑是不是也要跟着即时变化!
这就导致问题来了,CSS浏览器渲染,本身即时响应。但JS且不一样,我们必须实时监测是PC宽度还是Mobile宽度,同时PC的click事件和Mobile的touch事件可能就在同一个元素上搞基了,也蛮累心的。为了我们自己省心,我们就可能去限制设计师再做响应式设计的时候,两者差异不要太大。我去,技术已经不是帮助产品设计体验升级,而是去制约设计了,贵司的设计师好惨!
还有一个问题就是资源消耗的问题,拿网站头图举例,PC的头图可能是张大大的长图,Mobile是个方方的图片。即时响应也就意味着这两个图都可能会被加载。
那有没有什么办法既能满足响应式的需求,同时我们开发这边不要那么烦心呢?
试试使用screen.width来做伪响应式开发。
首先要了解下不会说谎的screen.width,screen.width顾名思义就是屏幕的宽度,对,屏幕的宽度,与显示器宽度没有任何关系,就算你把显示器宽度缩小到芝麻糊那么大,screen.width还是不会变。
由于screen.width不会说谎,我们就可以瞬间确定用户实现的宽屏设备还是窄屏设备,而@media screen的宽度是浏览器的可用宽度,很容易就被用户欺骗的。
只要我们确认了用户的屏幕尺寸,我们就可以在一开始就确定我们的页面布局以及所需要的交互,例如,可以在标签内放入这么一段内联script:
(function(doc, win) { var screenWidth = 0, size = 'M', root = doc.documentElement; if (window.screen && screen.width) { screenWidth = screen.width; if (screenWidth > 1920) { // 超大屏,例如iMac size = 'L'; } else if (screenWidth < 480) { // 小屏,如手机 size = 'S'; } } // 标记CSS root.className = size; // 标记JS win.SIZE = size; })(document, window);
上面的脚本在页面加载的一开始,就确定了是大屏,普通屏还是小屏,然后再执行响应的渲染和脚本执行。您可以根据自己实际项目,修改上面的size变量。 于是乎,我们无论是CSS渲染还是JS逻辑处理,都是1条线下来,完全没有@media screen即时切换而不得已耦合在一起的JS逻辑处理。
样式如下
/*// 移动端样式*/
.S .container {
width:100%;
height: 100px;
background: green;
}
/*// PC 端样式*/
.M .container{
width: 500px;
text-align: center;
height: 300px;
margin: 30px auto;
background: red;
}
js 处理
if (window.SIZE == 'S') {
console.log('移动端');
} else {
console.log('桌面端');
// 桌面端的处理
}