好多坑

移动端走到的几个吭

1. button

对于botton在IOS上会有一个margin。需要进行重置

2. 滚动到底部

之前做的一个插件，当滚动到底部的时候检测然后进行新的内容的加载，但是经常会出现失效的情况（之所以这样是因为考虑到性能，窗口大小的获取之获取了一次，然后缓存起来），后来看了下，同样的一个页面，窗口的大小，从页面一开始进来的大小和在本页进行刷新，所获取的窗口大小是不一致的，解决方案有两种

1
1. 对于获取窗口大小，每次检测的时候进行一次计算，这样就不
会有计算失误的情况
2. 第一次获取的时候讲整体的代码延迟处理,setTimeout(f,0)
即可

3.ios滚动

出现了一个比较神奇的问题，就是当用户按住屏幕进行滚动后，比如出发了加载更多的一个loading动画，然后此时用手按住屏幕，会发现动画暂停了

4.input输入框

设置input类型为number的时候，当输入的number的类型不合法的时候，input会自动过滤为空

5.ios宽度百分比问题

在5c上，具体的版本号忘记了，比较老的也，对宽度的处理有点异常，对宽度比如算出来是45.8.都会舍成45，很容易造成布局的乱

6.scroll事件

DOM元素中塞内容的时候会触发一次scroll。应该是节点变多之后的效果，这个也可以理解

7.ios点击闪烁

ios上点击一个区域会出现闪烁的问题，可以对那个闪烁的元素加一个

1
-webkit-tap-highlight-color: rgba(0,0,0,0);

8.input placehold问题

input placehold在老的安卓机子上面。计算原来设置了text-align:right也不会居中，有一个办法使用

1
::-webkit-input-placeholder｛text-aligh:right｝

可以，但是再旧点的版本就不行了,不过还可以使用

1
::-webkit-input-placeholder {direction: rtl;}

9.刷新字体大小变小

有些手机上（小米+魅族）一开始进入的时候正常，但是进行一些操作之后会出现字体的变小，貌似都是那些body下的父元素没有设置过字体大小的元素会出现，解决的办法就是强制给一个字体大小

10.js关闭键盘

对于一些场景需要用js来关闭那些唤起的键盘。可以通过document.activeElement.blur();来将键盘关闭

11.缩放问题

对于一些页面在meta中设置了user-scalable=no的页面，发现在oppo上meta没有用。可以继续缩放，这个奇葩问题暂无解决方案

12.浮动的处理

左边是浮动，右边一个bfc的时候不需要加margin-left。在一些手机上会以浮动元素的右侧开始计算。会容易有益处，比如华为安卓

##总结

  1. 经常做一些内嵌页面的时候，会受到客户端的影响，有时候遇到的一些奇葩问题也许不是前端的，是客户端的，找到果断报
  2. 感觉最近做的俩移动的页面，其实难度并不大，但是兼容的问题真是好折腾，基本上整体的时间算下来，应该是后期测试联调改bug的时间大于前期的开发时间，而且一旦涉及到一些自己引组建资源问题的时候，需要找对应的开发也比较耗费时间

  3. 移动端有时候的联调，真是不方便，虽然有各种各样的联调方式，但是总会跟客户端的浏览器有点差异，打个log也相当的蛋疼，看到一个native开发的也在debug版本中顶部加了一个log的小窗口，所以自己也做了一个雷同的，还有比较大的优化空间，先贴代码

  4. 做好工程化还是很有必要的，其实也就是grunt这类的打包，前期比较折腾比较累，但是一旦配置好之后，后期就是爽歪歪的享受，大大节省开发的时间

  5. 整体项目的分层结构设计还是比较考验人的，一般不太会一蹴而就的，都是需要开发了多次之后慢慢修改，然后磨合调整修改到一个比较舒服的状态，对于一些旧的代码，千万不要心软偷懒放任不管，要是一开始就放任了，第二次第三次就更加不会去处理了，最夸张的情况下，就是这个页面经历了多个人的手，最后每个人都不敢在前人的代码上进行修改，一些老旧的代码越叠越多，还是很容易出问题的，到时候排查也是一个超级累的过程
  6. 关于一些组件的抽取，感觉这个力度还是很难把控的，松的耦合度可以让这个组件可以有更大的普适度去黏合各种场景，但是相应的代价就是可能这个组件里面本身完成事情就不多，很多的工作需要附加在使用这个组件的场景里去完成。 而其实，作为开发者，最喜欢的就是写完一个组件之后，我在我的应用场景里面仅仅做一个最简单的调用就可以完成这个功能那是最爽的了，不过一般这样的组件相应的就会有比较强的耦合性，这个也是比较纠结的一件事情

  7. 对于在客户端遇到需要处理一些多页面链路的问题，比如A-B—C这样的链路，但是从C返回B的过程中，需要将从C一些信息带回到B，在做的时候考虑想到了三个方案

    (1) url里加参数
(2) postMessage
(3) 本地存储

    A. 对于url里加参数，有点恶心，不好处理A-B中url里面也有参数的问题，虽然可以通过命名不一样的参数名字来绕开，但是感觉还是太奇怪了，而且这样的链路页面会跳的时候，感觉最好使用history.back()来处理（对于A—B-C，正常的逻辑，回到B页面后点击回退到A，要是用open方式打开用户手点到回退按钮，就会回到C），这样的情况下感觉就不是很合适了
    B. postMessage，在浏览器端还是不错的支持度，但是在移动端上，兼容性并不能得到保证，为了求稳还是没有使用
    C. 本地存储，这是最终采用的方案，使用的过程中唯一需要注意的就是要缕清楚不同页面直接跳转过程中，何时读取存储内容的时机，以及清除存储内容的时机，而且有一个不好地方就是，本地存储会一直有，要是A-B—C这样的链路走，这是正常的流程，对于一些直接跳转到B页面的这样的异常流程需要多多注意