携程2015 Open House获奖项目：响应式的蜕变

响应式的蜕变

Ctrip Tech

本文不再从最基本的语法开始行文，而在列举一些最基本的信息之后，开始探讨传统响应式设计的问题，与在实践当中思考出来的改进方法，从而实现一次次的蜕变。

目前为止，平台众多，各种屏幕纷繁复杂下面我们看一下移动平台设备分布和屏幕分辨率分布：

我们看到平台分布虽几大厂商占据绝对优势地位，但是非主流平台仍然占领了一定的市场占有率，而移动屏幕的分辨率则更是五花八门，那么:

1) 为不同平台开发原生应用？

2) 为同一平台开发多个分辨率版本的应用？

3) 使用一个web页面展示在所有平台上？

这些都不可行，开发成本和用户体验让这些选择困难重重，而达不到目标，解决方案就是响应式设计。

响应式的定义：

页面的设计与开发应当根据设备环境进行相应的响应和调整，而设备环境包括：屏幕尺寸，屏幕方向，系统平台，用户行为导致的变化等。

响应式的优点：

1、所有平台使用一个域名，一套代码，seo友好

2、适应所有平台，所有分辨率

3、获得各种平台的最佳用户体验，各平台设计风格一致

4、开发成本低，维护成本低

5、技术门槛低，大量前后端开发人员都可参与

6、不同平台加载不同的资源，减少冗余代码

响应式的注意事项：

1、设计思想不同，补习响应式相关知识（布局，图片）

2、低端浏览器支持的不好

3、底层框架支持（Lizard，cQuery）

4、依赖的资源要适应响应式设计（head,侧边栏问题）

5、回归成本加大

6、hybrid中对设备的判断一致性问题（小pad，大分辨率问题）

响应式设计，基本都是依赖css的media query来实现，实现过程大致可以分为如下三个过程：

1) Meta 标签，用于适应屏幕

2) HTML 结构，构建网页布局

3) Media Queries，构建响应式样式

但是，响应式并没有那么简单，它的实现，需要从产品，ued，测试，开发，进行通力的合作，才能设计出优秀的响应式作品。

一、产品

要有响应式的设计理念，这个是自产品开始的，mobile first，响应式的设计边界的界定，伸缩式结构的设计，一致的用户体验要求，一致的界面设计风格，极端分辨率的处理，如果混合了Hybrid开发，还需要保证h5和Hybrid对设备的判断一致性问题，确认native和Hybrid的任务划分，如侧边栏由native实现还是Hybrid实现，全局浮层是交由native处理，还是全权交由Hybrid设计实现，低端浏览器和低端设备的支持情况的决策......

二、UED

Ued的设计要满足响应式的需求，首先要做的是响应式的布局, 无论哪种响应，基础的dom结构必须保持不变，否则将极大的降低响应式的效用，虽然即使完全不同也能实现。

还有响应式图片的设计，响应式的增量css设计，或者是分模块的css设计，背景图片可以使用双倍图，也可以使用image-set，这个需要作出选择，html5响应式图片现在有了srcset, 类似image-set，通常情况下，srcset 里面的资源是具有 fallback 特性的，也就是说第一个图片资源无法加载的时候可以跳过加载后面的备用资源。

三、测试

测试也要抛弃掉原来的那种单独平台的测试思想，现在你面对的是一套代码实现的所有平台的不同响应，从高版本到低版本，从ios到Android到其他平台，从高分辨率到低分辨率，从原生应用到Hybrid应用到html5应用，等等，不同边界之间的资源引用的异同，效果的异同，交互的异同，后端资源响应的异同，要进行的回归工作和可能存在的相互影响的状况，测试都要关心。

四、最后开发

开发人员将面临更多的问题，要实现响应式，项目依赖的外部资源要支持响应式设计，比如响应式的头尾，响应式的侧边栏等，然后非常重要的是你基础框架是否支持响应式，如果不支持你需要为不同的环境响应不同的基础框架，这会大大增加你的代码开发量和代码质量，以及项目的复杂度，需要对环境进行探测，你需要知道低端浏览器对你使用的html5的特性的支持情况，通常你可以使用Modernizr来完成这个工作，当然你还要面临pc上众多浏览器的兼容问题，不过现在已经有一些工具可以很好的辅助你完成这个工作，而你关心的重点仍然应该是你的业务逻辑，当然你还可能面临在Hybrid下某些厂商出品的手机，出厂参数就写的是错误的，这会导致native对手机屏幕的探测不正确而导致与h5规则下对屏幕的计算偏差特别大，当然你可以统一都用html5的规则，或者native加入白名单的方式来处理这个问题。

最后我们来谈谈按需加载

即使以上问题你都处理的非常好，你的响应式设计的性能也许并不高，因为css Media Query自身提供的条件加载资源并非真正的按条件加载资源，实际上，他会把所有的响应式资源都下载到本地，然后根据Media Query进行判断，到底哪一种响应是符合当前Media Query判断条件的，这会引起极大的带宽浪费，而且非常影响加载速度和用户体验，而我们非常需要的是真正的按条件加载资源，按需加载。要说清楚这个问题，先看一张UML图：

首先，根据产品需求，我们划分了响应式的边界，大致可以分为手机版，pad版，和pc版，当然这个维度可以根据需要划分，你想怎么分就怎么分，当然得符合你的需求。

在页面开始运行的时候，我们通过一个devEnv()函数来获取当前匹配的环境，由于产品要求一套代码既要在h5环境运行，还要在Hybrid下运行，所以在这个函数内部就需要根据navigator.userAgent来进行第一次判别，在判别出Hybrid还是h5大环境之后，就需要针对性的判别目前环境适用于手机版，pad版还是pc版了。当然这个判断也可以后移到服务端，由服务端配合来实现响应式，这个系统的复杂度就会很高，可以实现，但是并不一定好用。而再环境判别的时候，你也许需要用到，window.matchMedia. 这实际上Media query的js版本。

然后，你需要在编码阶段就定义好，哪些资源是要在h5中加载，哪些在pad中加载，哪些在pc上加载，哪些是共用部分，无论哪个环境都需要加载，并结合打包工具如grunt进行打包和压缩，并将这些资源配置到你的页面。

最后，在html环境下，你要run一个核心函数fnMediaQuery，他将根据你设定好的配置，和触发条件，真正的下载与环境对应的资源，而非当前环境下的资源则不会加载， 从而实现按需加载，按需执行，而在Hybrid环境下，由于一些现实原因，如部分功能在手机上使用native，而在pad上使用Hybrid开发，造成环境判断依赖于native的判断给定，从而走出另外的分支，响应式也进行了很好的处理，但是最好的方式还是统一一个功能的实现，避免出现这种环境判断的依赖，导致逻辑负责度提高，而且渲染效率相应的会受到一些影响。

响应式的实现，后期应该还会进化，最好的结果就是浏览器集成实现资源的按需加载，并且对性能的提升上面做更进一步的优化，我相信响应式带给客户的是优秀的用户体验，而带给企业的将是成本的大幅降低，并保持产品的一致性和提高产品对新平台，新设备的适应性。