移动端兼容性浅析

“移动网民的规模将在2013年底达到5.0亿,增速为19.1%。预计到2017年,移动网民将赶超PC网民,成为互联网的第一大用户群体,移动端将成为网民最主要的上网渠道。互联网的加速渗透和全民移动互联有望在下一个5年实现。在过去的几年时间里,移动智能设备快速普及,配置迅速提升,许多过去在PC端才能完成的需求都转移到了移动端,导致PC端流量也逐渐向移动端转移。未来几年许多互联网产品移动端的流量即将超过PC端,整个互联网的使用场景产生巨大变迁。”

——《2014年中国移动互联网行业年度研究报告》

来自艾瑞的《2014年中国移动互联网行业年度研究报告》向我们展示着在未来的互联网世界,移动端将成为主要战场,若想在浪潮汹涌中屹立不倒,我们就要开始移动端,开始一个新的征程。

作为一名前端工程师,我们享受过或仍在享受着pc端各种“非现代”浏览器的“折磨”,面对移动端我们又将面临哪些兼容性的考验呢?篇幅所限本文将向各位展示我们在移动端开发过程中针对兼容性问题的一点经验,主要包括方案选型及入门基础,如果您是大牛、大神或是大神牛欢迎指点、指正,如果您是和我一样的移动端新鸟欢迎探讨共同学习。

在移动端的兼容性上主要需要关注哪些方面的问题,对其又是如何定级的呢。由于要考虑设备(pc设备or移动设备)、厂商、机型、操作系统及版本、浏览器及版本等多方面因素,移动端兼容性被毫不夸张得称为“后IE6时代”。如何在成本允许的情况下将页面更好地呈现给用户,让我们先来看一组数据:

由图可见,智能手机占据了常用移动设备终端95.2%的份额,而智能手机中安卓及IOS两大平台占比总和达到了89%,综合成本、效率及整体效果考虑,我们暂且将移动端浏览器的兼容性定级为:兼容IOS和安卓平台的主流机型、系统及浏览器。

目前针对跨终端的方案,主要分为两大阵营:一套资源Vs两套资源。第一种是通过响应式或页面终端判断去实现一套资源适配所有终端;第二种是通过终端判断分别调取两套资源以适配所有终端。这两种思路我们并不能斩钉截铁的说哪一个更优选,正所谓“合适的才是最好的”。下面来对这两种思路进行简单的对比:

思路一:通过响应式或页面终端判断去实现一套资源适配所有终端

优势:只需维护一套资源,维护成本较低。

劣势:需加载适配各个终端的各个资源,在不同终端通过响应式布局实现不同展现,部分交互效果需要在页面中做终端判断,代价较大,若图片资源为一套,部分图片在超高分辨率设备(例如iphone系列)下会失真,且在非wifi情况下即使加了延时加载也易出现加载慢的情况。

技术选型:jquery(或原生js等)+ 响应式 + 前端模块加载器(seajs或RequireJS等)+ css预处理器(sass 或less等)。jquery较好的兼容性配合响应式可相对代价较小地实现跨终端。前端模块加载器主要负责按需加载,以提高页面加载速度,css预处理器的变量、运算、嵌套等特性可大大提高手动计算响应式的效率,妈妈再也不用担心我把比例算错了。当然后两者可参考需求及成本决定是否采用。

思路二:通过终端判断分别调取两套资源以适配所有终端

优势:可根据不同端做个性设计及个性化信息推送且可按需加载,如移动端可配合重力感应、不同手势做各种炫酷拽效果,pc页面可不受流量限制做适合pc端的效果。

劣势:需维护两套资源,维护成本增加。

技术选型:zepto(或xui等移动端轻量级框架)+ 响应式 + 前端模块加载器 + css预处理器 + 终端适配。zepto作为jquery的移动端版本,依然延续其自身优势,大幅优化了移动端API且摒弃了兼容“非现代浏览器”的冗余代码,成为移动端轻便可用的js框架代表,对于习惯了jquery的同学来说简直是不二之选!

终端适配目前一般通过ua判断来实现。ua判断可放在服务端也可放在页面中,在代理服务器中做跳转更快、更准确且不走应用程序层,即使浏览器禁用了js依然可以跳转到相应的地址,同时秉承着公共服务放在服务端这样的云端服务理念,我们选择了通过代理服务器做终端适配。

User-Agent嗅探,即Web浏览器发送一个Web页面或资源请求时,会发送一个User-Agent首部作为HTTP请求的一部分,那么我们就可以在服务器端获取想要的信息,进而判断并引导用户到达相应的页面地址。

下面我们通过详细分析一个http请求中的user-agent首部来了解其原理:

要点明晰及注意事项:

css像素与设备像素:二者的区别在于前者是抽象的,用于浏览器渲染页面,而后者是设备的最小物理单位。可参考A pixel is not a pixel is not a pixel进行理解。

视口:移动端浏览器有两个视口,即可见视口与布局视口,二者的区别在于前者为基于移动设备屏幕的实际宽度,而后者为我们为页面定义的用于浏览器渲染的大小。 可参考A tale of two viewports进行理解。

媒体查询:找准断点。

响应式布局:当上下文环境发生变化时可考虑变化布局来展现优雅。当元素脱离文档流绝对定位时,才是相对高度定义的。

响应式字体:font-face绝对会对你的站产生巨大的影响。当容器中定义字体单位为em时要注意继承性,例如:当我们定义某个块级元素的“font-size:1.5em; line-height: 2em;”时,line-height的实际行高为1.5em*2即3em。

文档声明:文档声明建议用html5的:<!DOCTYPE html>,它指示浏览器关于页面使用哪个 HTML 版本进行编写的指令。同时需要定义文档的视口信息,如:<meta name=“viewport” content=“width=device-width, initial-scale=1, user-scalable=no”>width=device-width告诉浏览器渲染该页面的宽度等于设备宽度,initial-scale=1告诉浏览器初始化缩放的比例1:1,user-scalable=no禁止用户缩放页面。

兼容性测试:

调试工具推荐chrome的模拟器加真机测试,更多关于debug的工具可以参考Debugging Mobile Web Page这篇文章。

总结:

移动端开启了一个时代,它不是虚无缥缈或者高不可攀的,它反而让曾经被忽视的渲染方式及web标准等实质性的问题更加清晰,相较上述两种思路,我们更倾向于各司其职思路清晰的第二种方案,我们可根据不同终端做不同的交互设计、视觉设计,研究不同的前端技术、用户体验,适合的才是更好的。做为前端工程师,让我们理解原理,探索实践,跨终端任重而道远。

时间: 2024-10-27 13:29:20

移动端兼容性浅析的相关文章

某移动社交应用服务端架构浅析

原文http://blog.csdn.net/lvjin110/article/details/12958463 TA是一款是基于地理位置的社交应用,帮助你与你不认识的.但就在附近的人进行即时沟通.TA是一款陌生人约会交友应用,无论你在银行排队.乘坐公交.咖啡厅或公园散步等任何地方,随时随地就能与附近有趣的陌生人进行即时沟通.分享照片.约会和交友-- 转眼间,离开该研发团队快半年了,在此期间不少网友问到后端架构,及技术细节.出于技术分享为目的,现将服务端架构及设计思路分享给大家. 如下图: 上图

移动端兼容性问题解决方案

1. IOS移动端click事件300ms的延迟响应 移动设备上的web网页是有300ms延迟的,玩玩会造成按钮点击延迟甚至是点击失效.这是由于区分单击事件和双击屏幕缩放的历史原因造成的, 2007年苹果发布首款iphone上IOS系统搭载的safari为了将适用于PC端上大屏幕的网页能比较好的展示在手机端上,使用了双击缩放(double tap to zoom)的方案,比如你在手机上用浏览器打开一个PC上的网页,你可能在看到页面内容虽然可以撑满整个屏幕,但是字体.图片都很小看不清,此时可以快速

PC端兼容性

目前,对 HTML5 和 CSS3 支持最好的是 Chrome 和 Safari , Firefox 和 Opera 次之,IE9 开始拥抱标准. 一.CSS3 属性 从表中可以看出,除了 Overflow Scrolling 还没有浏览器支持之外,其它属性在 Windows 平台,Chrome 和 Safari 全部支持,其次支持比较好的是 Opera 和 Firefox,曾经一片红叉的 IE 开始迎头赶上,开始支持部分 CSS3 属性.在 Mac 平台情况要好很多,Safari .Chrom

移动端兼容性处理1

移动端 HTML5 audio autoplay 失效问题 由于自动播放网页中的音频或视频,会给用户带来一些困扰或者不必要的流量消耗,所以苹果系统和安卓系统通常都会禁止自动播放和使用 JS 的触发播放,必须由用户来触发才可以播放. 解决方法: 先通过用户 touchstart 触碰,触发播放并暂停(音频开始加载,后面用 JS 再操作就没问题了). document.addEventListener('touchstart', function () { document.getElementsB

实战的移动端兼容性解决

ISO input[type="number"]{-webkit-text-fill-color:black; -webkit-opacity:1; opacity: 1;} 解决ios里,input框内color设置black,文字任为灰色 input {-webkit-appearance: none;} http://blog.csdn.net/u012518659/article/details/49913999 这篇文章说的比较详细 可以参考一下

前端 PC端兼容性问题总结

1.如果图片加a标签在IE9-中会有边框 解决方案: img{border:none;} 2.rgba不支持IE8 解决方案:可以用 opacity  eg: opacity:0.7;/*FF chrome safari opera*/ filter:alpha(opacity:70);/*用了ie滤镜,可以兼容ie*/ 但是,需要注意的是,opacity会影响里面元素的透明度 3. display:inline-block ie6/7不支持 解决方案: display:inline-block

[移动端]移动端上遇到的各种坑与相对解决方案

mobileHack 这里收集了许多移动端上遇到的各种坑与相对解决方案 1.问题:手机端 click 事件会有大约 300ms 的延迟 原因:手机端事件 touchstart –> touchmove –> touchend or touchcancel –> click,因为在touch事件触发之后,浏览器要判断用户是否会做出双击屏幕的操作,所以会等待300ms来判断,再做出是否触发click事件的处理,所以就会有300ms的延迟 解决方法:使用touch事件来代替click事件,如

兼容性测试

浏览器兼容性 IE(IE6  IE7  IE8--->IE Develop  ToolBar)  :http://spoon.net/browsers Google(43   45 46) 火狐 分辨率兼容性 版本兼容性 服务端兼容性

[移动端]移动端上遇到的各种坑与相对解决方式

mobileHack 这里收集了很多移动端上遇到的各种坑与相对解决方式 1.问题:手机端 click 事件会有大约 300ms 的延迟 原因:手机端事件 touchstart –> touchmove –> touchend or touchcancel –> click.由于在touch事件触发之后,浏览器要推断用户是否会做出双击屏幕的操作,所以会等待300ms来推断,再做出是否触发click事件的处理.所以就会有300ms的延迟 解决方法:使用touch事件来取代click事件.如