lgmcolin / lgmrain.github.com Goto Github PK

最近刚开始接触移动端项目，其中遇到了挺多问题，不禁感慨移动端的坑真深。相比之下pc浏览器端的兼容性弱爆了，毕竟很多问题都积累了很多的解决方案。移动端开发需要考虑的东西挺多，包括android和ios系统的差异，手机性能，页面渲染等方面。下面主要说下我遇到的一些问题和解决方案。

滚动禁用a标签的一些效果

页面在touchstart的时候触发a标签的一些效果，比如hover时会有box-shadow,影响到页面scroll，解决的方法是在body上加上pointer-events:none; 其实如果单纯在效果上不要显示只需要采用css覆盖掉产生效果部分的样式，不过考虑到性能问题还是有些影响。
具体的实现代码：

.disable-active {
  pointer-events: none;
}

seajs.use(['$'], function ($) {
   var timer;
   window.addEventListener('scroll',function(){
        clearTimeout(timer);
        if( !$('body').hasClass('disable-active') ){
             $('body').addClass('disable-active');
        }
        timer = setTimeout(function(){
             $('body').removeClass('disable-active');                  
        },500);
    },false);    
});

需要注意的点，如果在body中有些元素应用了pointer-events:auto;那么需要在判断滚动的时候也加上子元素的pointer-events:none; 可以这样

.disable-active,
.disable-active * {
    pointer-events: none !important;
}

fixed布局

ios系统 fixed在ios5之后，才正式开始支持fixed的布局，不过即使ios5之后，开始支持fixed属性，在实际使用中，还是有很多小坑在。比较安全的做法是，在固定的布局里面，尽可能保持里面的结构简单，不要出现过于复杂的布局。
对于部分浏览器是否支持fixed的判断：

var div = document.createElement('div');
div.style.cssText = 'display:none;position:fixed;z-index:100;';
body.appendChild(div);
console.log(window.getComputedStyle(div).position != 'fixed');  

通常我们习惯使用 position:fixed 实现头部、底部模块定位，在使用过程可能会遇到一些无法找到较好方案解决的问题，比如：

• 横屏时fix布局元素不能自适应宽度
• -webkit-transform也会影响到fixed的定位，用-webkit-transform进行变换之后，fixed元素不再fixed
• fix复杂布局中的input在触发focus时出现的位置偏移，
• 滚动时fix定位异常

对于上面这些问题我多少遇到过，不过在解决方面暂时还没有很好的方法，在测试方面测试的范围也不广，如果大家有好的解决方法，欢迎一起探讨。

键盘

因为手机的界面很小，所以软键盘在某些时候会对页面有一定的影响。android和ios的处理方式也有挺大不同，ios对于从下方推出键盘的时候，如果输入控件在页面推出之后，在键盘的高度的上方的话，则键盘是以一个浮层的方式弹出，并且将那个触发的控件推到键盘的上方。如果那个控件在页面底部，如果推出的键盘会覆盖该控件，系统会将整个页面向上推，直到将那个控件推到键盘上方为止。而android的实现的不同，有部分的android的实现和ios一样，有些android的机型的实现却不同，如果发现触发的input控件比键盘的高度底的时候，会自动将整个document的高度增加，增加到这个控件的高度超过键盘的高度为止。

对于某些js模拟弹窗类型，会造成定位问题。可以通过判断控件的事件计算当前位置重新定位。

键盘的事件 弹起和收起键盘。这个也是非常纠结的问题。在ios6之前，当控件获得focus的时候，如果不是用户触发的事件，键盘是不会弹起的，在ios6之后，设置了一个属性可以做到，在android上，只要不是用户触发的事件都无法触发。暂时还没有解决方案。键盘的收起，可以通过js的blur的方式来实现。

未完待续..

最近真是懒啊...

onscroll事件

ios mobile safari下，onscroll过程页面js进程会停止所以onscroll事件只会执行一次；可是android下的滑动却不会阻止js进程，可能因为事件周期不稳定有时候滑动停止才会执行一次onscroll事件。

touchend事件

在一些android机型中，很多时候轻微滑动不会触发touchend事件，所以有时候要自己判断touchend事件是否执行过了用一个定时器再执行一次

弹框浮层

有些android机型下会出现点击穿透现象，如果浮层内容较多又得实现内部滚动，使用还是慎重

页面闪动

android下一些转场效果利用translate实现可能出现闪动，可以尝试替换成translate3d。另外，在实现屏幕旋转的时候，如果触发旋转事件内部有相关dom属性的计算与转场过程中的样式出现冲突也会看到闪动的效果。

iscroll

尽量避免在android上使用iscroll，用原生滚动替换。使用iscroll可能引发一些奇怪的bug；Android 4.0+ 原生Web滚动实现已与Native一致，无需iSroll的方案来Hack。

ios5以上多个个设置滚动的属性 -webkit-overflow-scrolling: touch，不过在Webview场景下偶尔也曾触发过渲染Bug，如渲染后白屏；在 -webkit-overflow-scrolling: touch 元素上需有绑定有touchstart事件，来解决iOS7下一个Bug: http://stackoverflow.com/questions/18736297/webkit-overflow-scrolling-touch-broken-in-ios7

Cookies vs Tokens认证

http 协议是无状态协议，但是大部分请求是在 server 端和 client 端需要保持状态的，有2种不同的方法可以实现 server 端对 client 端请求的认证：

1. 最常用的 Cookies 认证方式，web 服务器通过 HTTP 请求头 Set-Cookie 指定要存储的 cookie 值用于识别改用户，再次访问会带上这个 cookie
2. Token 认证方式，在每一次 client 的请求都会带上这个 token，服务器端会对请求带过来的 token 进行安全校验

我们常用 cookie 这种方式，不过 cookie 也有下面几个缺点:

• 默认情况下, cookie 只在浏览器会话期存在.退出浏览器就会丢失。不过可以用 expires 设置 cookie 的过期时间，cookie 可以在有效期内保存起来（浏览器关闭后也不删除）
• 当设置 domain 属性的时候，设置的服务器下的文件都可以调用到该 cookie，比如支付宝这边常设置domain=alipay.com，如果子域被 xss 了，那么主站也会收到攻击
• cookie 有大小的限制，大多数浏览器对 cookie 的大小有 4096 字节的限制
• cookie 是可以被禁用的
• 潜在的安全风险 cookie 可能会被篡改

相比之下，使用token认证有下面几个好处:

1. 可以跨域CORS

cookie 不能用于跨域认证，通过 token 方式可以允许你利用ajax请求任何一个服务器，因为 token 是通过 http header 去传输信息的。如果你设置一个 cookie 的域名为 .alipay.com， 它将可以被 alipay.com 和a.alipay.com 获取，这样用户登录并且转到 a.alipay.com 后也能很容易地从主域名找回这个 cookie 。如果你想要在 a.alipay.com 中获取 alipay.com 的cookie，token 的方式可以通过在 cookie 中存储登陆 alipay.com 获取到的 cookie。

2. 无状态, 可以不需要通过 session 维护状态

可以保存在 client 端的 cookie 或者 local storage 中，但你可能会想“我把 token 保存到 cookie ，不就跟以前没有任何分别？”。可是在这种情况下你只是把 cookie 当作一个储存机制，而不是一种验证机制。比如说，这个 cookie 不会被Web框架用于用户验证，所以没有 CSRF 攻击的危险。

3. XSS比 CSRF 要更容易防范

XSS 攻击的原理是，攻击者插入一段可执行的 JavaScripts 脚本，该脚本会读出用户浏览器的 cookie 并将它传输给攻击者，攻击者得到用户的 Cookie 后，即可冒充用户。但是要防范 XSS 也很简单，在写入 cookie 时，将 HttpOnly 设置为 true，客户端 JavaScripts 就无法读取该 cookie 的值，就可以有效防范 XSS 攻击。因为 token 也是储存在本地的 session storage 或者是客户端的 cookie 中，也是会受到 XSS 攻击。所以在使用 token 的时候，必须要考虑过期机制，不然攻击者就可以永久持有受害用户帐号。token可以作为防CSRF攻击方法方式之一，相比 XSS，CSRF 的危害性更大，因为大多数 Web 框架都已经内置了 XSS 防范机制。

4. token 可以像cookie一样设置有效期，而且你可以有更多的操作方法。

在 token 的使用中，一旦 token 过期，只需要重新获取一个。你可以使用一个接口去刷新 token：(a). 让旧的 token 失；(b) 检查这个用户是不是还存在，权限是否被取消或者任何对你的程序来说是有必要的；(c).得到一个更新了有效期的tn

5. 手机端一些本地应用也可以校验

如果是本地如 ios android 不支持 cookie，可能需要调用容器 api 注入 cookie，相比之下，还是 token 这种验证方式比较简单

token需要注意的： 如果存储私密的信息，需要对 token 进行加密。虽然 TLS/SSL 机制可以隔绝大多数中间人攻击，但是如果 token 中带有了用户的敏感信息，开发者也应该要加密这些信息。

说了上面这些，采用 Cookies 还是token 进行授权认证，还是得看具体的场景需求了