随着移动设备的发展，移动设备以迅猛的势头分刮着PC的占有率，ipad或者android pad的市场占有率稳步提升，所以我们的程序需要在ipad上很好的运行，对于公司来说有以下负担：设备系统上来说主要分为android ios；尺寸上看又以手机与pad为一个分界线，如果再加一个H5站点，其开发所投入资源不可谓不小！
Hybrid的出现，解决了大部分问题，针对尺寸上的问题有一种东西叫做响应式设计，这个响应式设计似乎可以解决我们的问题，所以今天我就来告诉大家什么是响应式设计，或者说我这种外行以为的响应式设计。
响应式Web设计(Responsive Web design)的理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境（系统平台、屏幕尺寸、屏幕定向等）进行相对应的布局。
以我粗浅的理解，响应式的提出，其实就是单纯的根据不同的尺寸，以最优的展示方式呈现罢了，仅仅而已，不能再多了，如果真要更多点，便是根据不同的尺寸对静态资源加载上有所控制，节约流量，换句话说，响应式设计不涉及业务逻辑，jser神马都不需要做，css同事便可完全解决，但事实上最近碰到的需求完全不是这么回事嘛。
我当时就醉了，iPad竖着保持手机样式，横着iPad样式，什么CSS有这么伟大，可以完成这个功能，而真实的场景是这个样子的：
手机端：首页搜索页->list页面->详情页->预定页
但是到了ipad横屏上：首页左屏是搜索页，右边是日期选择/城市选择/......，然后到了list页面，左边是list，右边是详情页，单击左边的list左边详情直接变化！
其实单独页面做的话，好像没有什么问题，但是手机业务早已铺开了，老板的意思是，代码要重用，还是全局改改CSS实现就好啦，我当时真为我们的UED捏了一把汗。到了具体业务实现的同事那里情况又变了，UED只是给出了两个设计好了的静态html+css，要怎么玩还得那个业务同事自己搞。
那天我去支援时，看到了其牛逼的实现，不由的菊花一紧，里面媒体查询都没有用，直接display: none 搞定一切问题了，这个对手机程序带来了很大的负担：原来一个view就是用于手机，现在无端的在里面加入了大量的pad端程序，直接造成了两个结果：
虽然知道他那种做法不可取，当时忙于其它事情，并且天意难违，天意难测也只有听之任之，但是这里要说一点，响应式布局不太适合业务复杂的webapp，各位要慎重！
虽然如此，问题还是需要解决，并且需要在框架层做出解决，这类需求本不应强加与CSS，好在曾经我们业务层的View设计基本是满足条件的，现在只需要扩展即可，仍然以blade框架为例：
每个页面片完成的工作仅仅依赖了一个View类，既然View是类，那么继承mobile的View，实现ipad的View，似乎是可能的，这一切的基石便是继承
我们这里的View Controller index.js开始是不完全满足我们的需求的，我们做一些调整，这里是调整前的代码：
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);
7 closeSearchAction: function () {
11 demoItemAction: function (item, groupIndex, index, e) {
12 scope.demoItemAction(item, groupIndex, index, e);
这里粒度到哪个程度与具体业务相关，我这里不做论述，于是我这里继承至index产生一个新的index类：index.ipad.js，这个是其基本实现：
1 define([getViewClass('index'), getViewTemplatePath('index'), 'UIGroupList'], function (View, viewhtml, UIGroupList) {
2 return _.inherit(View, {
4 onCreate: function ($super) {
8 onPreShow: function ($super) {
13 onShow: function ($super) {
18 onHide: function ($super) {
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);
32 demoItemAction: function (item, groupIndex, index, e) {
33 scope.forward(item.uiname);
这个时候直接运行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);
7 demoItemAction: function (item, groupIndex, index, e) {
8 scope.forward(item.uiname);
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);
19 demoItemAction: function (item, groupIndex, index, e) {
这个时候便需要进一步重写了，比如这里：我点击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) {
6 if (!wrapper[0]) return;
8 this.loadView(viewId, function (View) {
10 var curView = new View(this, viewId, wrapper);
13 curView.turning = $.proxy(function () {
18 callback && callback(curView);
这里History管理还是乱的，但是整个这个方案是可行的，所以我们前哨战是成功的，方案可行的话便需要详细的设计了
今天，我们对ipad与mobile统一使用一套view代码做了研究，有以下收获与问题：
① 继承可实现ipad与mobile代码复用，并且不会彼此污染，至少不会污染mobile程序
③ MVC需要重构，特别是View一块，甚至需要完全重新写
总而言之，今天的收获还是有的，剩下的问题，需要在核心框架上动大动作了，最后的目标是能够出一套同用于ipad与mobile的框架。
https://github.com/yexiaochai/blade
http://yexiaochai.github.io/blade/ipad/debug.html#index.ipad
本文转自叶小钗博客园博客，原文链接：http://www.cnblogs.com/yexiaochai/p/4148235.html，如需转载请自行联系原作者