响应式Web设计(Responsive Web design)的理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境（系统平台、屏幕尺寸、屏幕定向等）进行相对应的布局。

以我粗浅的理解，响应式的提出，其实就是单纯的根据不同的尺寸，以最优的展示方式呈现罢了，仅仅而已，不能再多了，如果真要更多点，便是根据不同的尺寸对静态资源加载上有所控制，节约流量，换句话说，响应式设计不涉及业务逻辑，jser神马都不需要做，css同事便可完全解决，但事实上最近碰到的需求完全不是这么回事嘛。

以最简单图片轮播来说，手机上是这个样子的：

而在ipad横屏上，却变成了这个样子了：

我当时就醉了，iPad竖着保持手机样式，横着iPad样式，什么CSS有这么伟大，可以完成这个功能，而真实的场景是这个样子的：

手机端：首页搜索页->list页面->详情页->预定页

但是到了ipad横屏上：首页左屏是搜索页，右边是日期选择/城市选择/......，然后到了list页面，左边是list，右边是详情页，单击左边的list左边详情直接变化！

其实单独页面做的话，好像没有什么问题，但是手机业务早已铺开了，老板的意思是，代码要重用，还是全局改改CSS实现就好啦，我当时真为我们的UED捏了一把汗。到了具体业务实现的同事那里情况又变了，UED只是给出了两个设计好了的静态html+css，要怎么玩还得那个业务同事自己搞。

那天我去支援时，看到了其牛逼的实现，不由的菊花一紧，里面媒体查询都没有用，直接display: none 搞定一切问题了，这个对手机程序带来了很大的负担：原来一个view就是用于手机，现在无端的在里面加入了大量的pad端程序，直接造成了两个结果：

① 业务逻辑变得复杂，容易出BUG

② js尺寸变大，对手机端来说，流量很宝贵

虽然知道他那种做法不可取，当时忙于其它事情，并且天意难违，天意难测也只有听之任之，但是这里要说一点，响应式布局不太适合业务复杂的webapp，各位要慎重！

ipad版本应该怎么做？

虽然如此，问题还是需要解决，并且需要在框架层做出解决，这类需求本不应强加与CSS，好在曾经我们业务层的View设计基本是满足条件的，现在只需要扩展即可，仍然以blade框架为例：

每个页面片完成的工作仅仅依赖了一个View类，既然View是类，那么继承mobile的View，实现ipad的View，似乎是可能的，这一切的基石便是继承

继承的意义

我们这里的View Controller index.js开始是不完全满足我们的需求的，我们做一些调整，这里是调整前的代码：

 调整前的代码
 对应HTML模板

调整后的代码如下：

 View Code

PS：上面的代码是我几个月前写的，今天一看又觉得可以优化，当真优化无极限啊！！！

变化的关键点是每次我点击的事件全部放到了Index这个类的prototype上：

 1 searchItemAction: function (e) {
 2   var gindex = $(e.currentTarget).attr('data-group');
 3   var index = $(e.currentTarget).attr('data-index');
 4   this.forward(this.uidata[gindex].data[index].uiname);
 5 },
 6 
 7 closeSearchAction: function () {
 8   this.closeSearch();
 9 },
10 
11 demoItemAction: function (item, groupIndex, index, e) {
12    scope.demoItemAction(item, groupIndex, index, e);
13 },

这里粒度到哪个程度与具体业务相关，我这里不做论述，于是我这里继承至index产生一个新的index类：index.ipad.js，这个是其基本实现：

 1 define([getViewClass('index'), getViewTemplatePath('index'), 'UIGroupList'], function (View, viewhtml, UIGroupList) {
 2   return _.inherit(View, {
 3 
 4     onCreate: function ($super) {
 5       $super();
 6     },
 7 
 8     onPreShow: function ($super) {
 9       $super();
10       this.turning();
11     },
12 
13     onShow: function ($super) {
14       $super();
15       this.initGoupList();
16     },
17 
18     onHide: function ($super) {
19       $super();
20     },
21 
22     events: {
23 
24     },
25 
26     searchItemAction: function (e) {
27       var gindex = $(e.currentTarget).attr('data-group');
28       var index = $(e.currentTarget).attr('data-index');
29       this.forward(this.uidata[gindex].data[index].uiname);
30     },
31 
32     demoItemAction: function (item, groupIndex, index, e) {
33       scope.forward(item.uiname);
34     }
35 
36   });
37 });

这个时候直接运行blade/ipad/debug.html#index.ipad的话，页面与原来index保持一致：

第二步便是重写其事件的关键位置了，比如要跳出的两个事件点：

 1 searchItemAction: function (e) {
 2   var gindex = $(e.currentTarget).attr('data-group');
 3   var index = $(e.currentTarget).attr('data-index');
 4   this.forward(this.uidata[gindex].data[index].uiname);
 5 },
 6 
 7 demoItemAction: function (item, groupIndex, index, e) {
 8   scope.forward(item.uiname);
 9 }
10 
11 //简单改变
12 
13 searchItemAction: function (e) {
14   var gindex = $(e.currentTarget).attr('data-group');
15   var index = $(e.currentTarget).attr('data-index');
16   alert(this.uidata[gindex].data[index].uiname);
17 },
18 
19 demoItemAction: function (item, groupIndex, index, e) {
20    alert(item.uiname);
21 }

这个时候原版本的跳转，变成了alert：

这个时候便需要进一步重写了，比如这里：我点击alert，事实上是想在右边加载那个子view，所以框架全局控制器APP需要新增loadSubView的接口了：

新增接口

loadSubView要实现实例化某一View非常简单，但是该接口的工作并不轻松，换句话说会非常复杂，因为：

History与路由归一化是mobile与pad版本整合的难点

mobile的view与ipadview是公用的，所以本身不存在主次关系，是业务给予了其主次，这里需要一个管理关系

子View的实例化会涉及到复杂的History与路由管理，我们这里先绕过去，下个阶段再处理，因为完成pad版本，框架的MVC核心要经过一次重构

 1 //这里暂时不处理History逻辑，也不管子View的管理，先单纯实现功能
 2 //这样会导致back的错乱，View重复实例化，这里先不予关注
 3 loadSubView: function (viewId, wrapper, callback) {
 4 
 5   //子View要在哪里显示需要处理
 6   if (!wrapper[0]) return;
 7 
 8   this.loadView(viewId, function (View) {
 9 
10     var curView = new View(this, viewId, wrapper);
11 
12     //这个是唯一需要改变的
13     curView.turning = $.proxy(function () {
14       curView.show();
15       curView.$el.show();
16     }, this);
17     curView.onPreShow();
18     callback && callback(curView);
19 
20   });
21 
22 },

在样式上再做一点调整就变成这个样子了：

这里History管理还是乱的，但是整个这个方案是可行的，所以我们前哨战是成功的，方案可行的话便需要详细的设计了

结语

今天，我们对ipad与mobile统一使用一套view代码做了研究，有以下收获与问题：

① 继承可实现ipad与mobile代码复用，并且不会彼此污染，至少不会污染mobile程序

② pad版本中History与路由管理需要重构

③ MVC需要重构，特别是View一块，甚至需要完全重新写

④ 样式方面还需要处理优化

总而言之，今天的收获还是有的，剩下的问题，需要在核心框架上动大动作了，最后的目标是能够出一套同用于ipad与mobile的框架。

源码：

https://github.com/yexiaochai/blade

demo在此：

http://yexiaochai.github.io/blade/ipad/debug.html#index.ipad

深蓝互联成立于2013年，是一家物联网硬件开发及软件应用服务商，获得多次获得国家高新技术企业资质的企业。深蓝互联专注软硬件技术开发的专业性技术公司。我们从事软硬件开发十年，擅长SaaS 平台开发、APP小程序开发、软硬件结合开发，在视觉识别处理、数据架构、云计算、多线程高并发和集群、数据安全加密和防护方便有很深的技术积累。

 

我们拥有专业优秀的设计和技术团队，以极具创意的 UI 设计、精湛卓越的开发技术，专业的网络策划团队。公司多年来投入打造物联网SaaS平台，集成了公司研发的多款智能物联网终端（智能鲜米机、生鲜售货机、自助洗车机、小区电瓶车充电系统等）。

 

公司一直坚持以研发为导向，打造软硬件结合的物联网平台系统。将一直坚持提高开发的技术实力更好的为我们的客户服务！

 

文章来自深蓝互联http://www.szdbi.com/WEBkaifajishu/407.html转载请注明出处！