移动端兼容性浅析
Posted ysx_小鱼
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了移动端兼容性浅析相关的知识，希望对你有一定的参考价值。
“移动网民的规模将在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标准等实质性的问题更加清晰，相较上述两种思路，我们更倾向于各司其职思路清晰的第二种方案，我们可根据不同终端做不同的交互设计、视觉设计，研究不同的前端技术、用户体验，适合的才是更好的。做为前端工程师，让我们理解原理，探索实践，跨终端任重而道远。
以上是关于移动端兼容性浅析的主要内容，如果未能解决你的问题，请参考以下文章