网站移动版本开发踩坑实录一

  
      最近公司项目需要开始做wap版本开发，虽然在上一家公司也有做过类似的工作，由于当时公司产品没有严格要求适配各个移动设备，也并没有很多动作效果和图片自适应这类的效果，相对来说体系没有那么成熟，更多是在wap版本上可以用就ok了（其实更多的工作集中在功能和cssser身上，交互效果没有那么强，唯一做的好玩一点的工作是菜单滑动、图片缩放［未被上线过］），因此基本上没有在移动端踩各种坑；说了这么多上一家公司的wap版本，下面开始讲讲现在做的项目让我在wap版本上踩的各种坑开始说起。
   第一坑：技术选型，在我的印象里移动端开发第一要务就是尽量把资源所带来的浏览问题减下去，当然无论开发什么功能都希望找到一个快捷的库来让开发效率更高，在移动端开发一直忌惮jquery库的大小，因此我看了一下zepto这个库，相对来说比较小只有9.8k，并且用起来跟jquery类似，没有太多的二次学习的成本。因此看过各种文档之后毅然的开始紧张的边熟悉边开发的过程，说了好几十个字第一个坑怎么还没出现呢（没有掌声，我就不说，哈哈）？产品需求（为什么产品那么多需求555），菜单切换时有滚动动画，上下运动那种，标签项目要切换到最上边；再次切换就scrollTop到头部，然后我傻乎乎的写了一段代码
  　<code>$(dom).animate({scrollTop:0}, function() {});</code>
然后各种不好使啊，怎么会不滚动到首部呢，既然移动端不行，命令行测试吧，已经不行；后来我就到github上的项目去反馈了一下，开发者很友善的回复我zepto没有完美适配jq，animate使用的是css的属性进行动画效果，而不是dom属性。＝＝！我以前那么豪爽的用的scrolltop竟然XX了，无奈使用了requestanimationFrame去适应浏览器绘制的帧频去搞个运动的动画了（如果你稍微了解这个家伙的话，你一定会质疑在移动设备上的支持情况，对确实支持不好，不过张鑫旭写过关于它的文章,请自行查看）。
   第二坑：zepto在animate上不就动画没有达到我要的嘛，既然实现了想要的效果，那就继续吧，然后继续开始写关于搜索结果排序的页面，作为一个偷懒的程序员的我也很想拿jq那一套插件去适应zepto，既然是排序那就用用tinysort吧，试试一下什么不行，其中有关$.fn有段代码不行，时间问题没有去花时间了解而是直接上网找zepto竟然没有tinysort这类插件（其实zepto在插件方面确实有很多在jquery上有，这里没有的）。一生气自己根据yy了一个sort代码，用起来没问题，后来经过产品测试得到了一个让我震‘精’的回复，我需求理解错了，不是单页面数据排序，然后忍痛删除了。继续写代码吧.......。啊又来了一个新页面哦，什么日历，哈哈这个不用愁datapicker是不错的选择，－－！555竟然也没有类似的插件，好吧我又yy了一个插件。
   第三坑：哦终于出来激动人心的新功能了，自适应。全站文本图片自适应哦0_0突然觉得我需要脑补了，自适应样式可以搞定文字和排版的布局，当时图片自动调整，需要js吧，js嘛不是事，但是tmd旋转屏幕标准在各个浏览器上怎么的也要按照标准来一下吧，没有。好吧。
   

   if(window.orientation !== undefined) {
       $(window).on('orientationchange', function() {
            doSomething();
       });	
   } else if(screen.orientation !== undefined){
       $(screen).on('orientationchange', function() {
           doSomething();	
       });
   } else {
       $(window).on('resize', function() {
          doSomething();	
       });	
   }	

　　

  然后为什么出现这段代码你绕行去看看相关文档，前两个判断是在看《javascript高级程序设计》看到的，后来结合网上的说话，加了一个resize让浏览器转啊转啊然后动态调整，自适应啊，高大上然后就是各种神逻辑，搞定。想的美。。。。。。妈蛋竟然发现iphone5s(测试那台机器有问题，另找了几个没问题)上浏览器旋转以后的竟然多出来一段空白区，然后这时候我就去看用xcode模拟器调试，竟然没问题。mac链接调试。。。。。在控制台上看获取的body区域竟然没问题，我一直以为是旋转你有我的那个div没有处理造成页面撑开了，然后排查以后竟然发现没问题。所以我深深的怀疑是特定系统的特定版本浏览器的问题（怀疑旋转以后重绘时机问题，然后我就假定一下是不是android上没有问题，是不是选旋转在重汇呢？iphone则反过来呢哈哈这段是我yy的），既然有问题就要想办法解决，虽然我想到让整体区域重绘的办法，但是我一直不想使用，因为对于浏览器来说

  

$(document.body).hide();
setTimeout(function() {
      $(document.body).show()
}, 20);

这样整体重绘真的好嘛，下下策。虽然我没有想好，但希望有高明办法的朋友说说你的解决办法。
  第四坑：之前有了解过history.pushstate。感觉超好用的，哈哈然后贸然的在移动端就途省事的使用了这个家伙，然后悲剧了，竟然发现在不同设备上竟然支持程度不一样，caniuse一下5555，心碎啊，然后改用了hash去让浏览器产生历史记录...。
  继续坑嘛？这个确实算不上是坑。场景是这样的，项目wap版本首页上需要一个轮播效果，同时轮播图片上左右滑动进行翻看，上下滑动是正常浏览上下移动，点击是查看。。。。。。问题来了，touchstart，touchend，touchmove做相应的代码逻辑然后在android上没问题，在ios设备上，左右可以，上下在竟然不好使。后来我去看了京东，天猫，去哪儿（这个不是在首页，是旅游的一个子入口），爱奇艺的对应的m版本，虽然首页都是滚动，但是各自的特种都不一样，京东的m版本旋转屏幕的时候竟然动画会出现乱序滚动一下，然后继续播放；天猫的虽然稳定没有问题，但是不是自适应（只是不满足我们现有的行为）；去哪er那个上下滑动移动竟然无效；爱奇艺的竟然是纯js一次加入两个dom，动的时候删除然后再次加入。。。。。。。最后经过各种观察，写出来一段yy的代码总算搞定。。。。。。。
  第一期跌跌撞撞，紧张的上去了，虽然有两个功能延期，但基本有解决思路了，时间紧张造成大脑错乱啊，第一步踩坑结束。