移动前端框架重构几个关键问题

1. 是否该废弃iscroll？

我得出的结论是，是该废弃了。那当时为什么要用iscroll？

原因有三个：

1. 因为别人也用了。

2. 为了iPhone上页面滑动更顺畅。

3. 为了用上拉、下拉刷新。

关于这三个原因有几点观点：

1. 人最容易跟风，编程也是。当别人用了的时候，会认为我自己也要用，而不清楚为什么要用，本质为了解决什么。

2. Android上不用iscroll时，页面拖动效果是可以的。

    iPhone上不用iscroll时，页面拖动效果确实有问题。但是！在滑动块加上-webkit-overflow-scrolling:touch;  效果非常好！！

    所以别用iPhone做借口去使用。

3. 本质上，上下拉刷新跟iscroll没什么关系，只是借iscroll间接实现。所以如果作为框架的开发者，就别使用iscroll，可以减少26.1KB（压缩版）js库。如果是普通开发者想偷懒，那就看着用。

Finally：

iscroll该废弃用，明确为什么想用很重要。

2. 效果设计图以什么为准？

我不是做效果设计图的，但是对设计图有点想法。很多框架是以iPhone原生效果做的，这样控件效果、页面风格就跟iPhone一样（Android上也是）；也有人会有自己一套设计图风格，既不是Android原生也不是iPhone原生效果。

Finally：

各自应用该有怎么的设计图，像什么没什么好说的。但对于做框架来说，我觉得偏向原生效果总归是好的。

——自己设计的那一套真的比原生还好吗？

3. Android动画效果（页面切换），效果不是很好，特别是Android4.3、4.4？

在iPhone上，由于分配给浏览器的内存多，动画效果是不错的，无论是CSS3还是js控制的。但在Android上，即便是加上GPU加速，可是效果还是不好，特别是Android4.3、4.4，动画还是存在卡顿情况。

有人说把下面：

@-webkit-keyframes slideLeftIn {
     0% { -webkit-transform: translate3d(100%,0,0)}
     100% { -webkit-transform: translate3d(0,0,0)}
}
@-webkit-keyframes slideLeftOut {
     0% { -webkit-transform: translate3d(0,0,0)}
     100% { -webkit-transform: translate3d(-100%,0,0)}
}
@-webkit-keyframes slideRightIn {
     0% { -webkit-transform: translate3d(-100%,0,0)}
     100% { -webkit-transform: translate3d(0%,0,0) }
}
@-webkit-keyframes slideRightOut {
     0% { -webkit-transform: translate3d(0%,0,0)}
     100% { -webkit-transform: translate3d(100%,0,0)}
}

改成：

@-webkit-keyframes slideLeftIn {
     0% { -webkit-transform: translate3d(100%,0,0)}
     100% { -webkit-transform:none;  }
}
@-webkit-keyframes slideLeftOut {
     0% { -webkit-transform:none; }
     100% { -webkit-transform: translate3d(-100%,0,0)}
}
@-webkit-keyframes slideRightIn {
     0% { -webkit-transform: translate3d(-100%,0,0)}
     100% {   -webkit-transform:none;  }
}
@-webkit-keyframes slideRightOut {
     0% {  -webkit-transform:none;   }
     100% { -webkit-transform: translate3d(100%,0,0)}
}

这样可以加速。但是经过实践检验，根本没什么用，页面卡顿的还是卡顿。

Finally：

既然现实已经如此，那么我们能做的是：

1. 避免使用大片区域的动画效果（特别是单页页面切换）。

2. 不使用单页。

4. 是否不该用单页？

单页的坏处：

1. 增加了开发人员的开发复杂度，是页面DOM变得过于复杂。

2. 存在无法释放的内存（可能是框架本身，或开发者自己弄出来的）。

3. 单页的页面切换效果在Android自带浏览器效果不好。

4. 页面路由问题，当想直接打开某个子页，必须经过主页，然后跳转到子页。存在两层加载中问题。

Finally：

也鉴于在单页中这些痛苦问题，无聊是移动Web，还是Hybrid应用，我觉得都不要使用单页。

5. 对于zepto，是否换回jquery？

zepto和jquery的现状：

1.zepto很久没更新了，而jquery在持续发展。

2.jquery毕竟是大众使用的，群众基础多。

3.很多控件是以jquery为基础，可能无法转换用zepto。

Finally：

zepto作为一个jquery的缩减版，目的是想在移动Web的基础库上有更小的体积。而我在想，真的需要为了减少这么几十kb的大小去使用zepto吗？zepto（54.78KB，包含触摸事件部分），jquery 1.7（91.6KB），这两个数字都是压缩版的。

对于Hybrid 应用来说，这几十KB的问题根本不是问题，都是本地资源，加载速度可以忽略不计。

对于移动Web应用来说，jquery可以使用压缩版和缓存做优化。

所以我觉得，真心使用jquery就可以了。有种有趣的现象，就是有人为了引用某个控件（基于jquery），就同时引入zepto和jquery，这反而增加了资源体积。

6.tap事件？

这是zepto里面根据几个触摸事件模拟出来的事件，为了提高点击事件触发的速度，但是存在经典的“穿透”问题。所以如果只是为了提速，或者废弃使用zepto，完全可以使用fastclick，提高响应速度。

Finally：

回归本质，使用click，在click基础上使用fastclick。

7.字体图标多少为好？

字体图标使用的本质是为了图标在不同设备不失真、可以变颜色等字体能设置属性。绝不是为了这样做更酷，看起来页面没有引用一张图片。

那字体图标内置多少个为好，我认为是尽量少，左右上下等图标，大概10个左右。字体图标越少，体积越小；其他使用图片还可以利用到缓存。

Finally：

不要一股脑加了几百个字体图标作为内置图标， 虽然使用上简单了，但是有很多冗余。

 

总结

这几个问题是在公司框架重构想起的，感触最深的问题。

 

本文为原创文章，转载请保留原出处，方便溯源，如有错误地方，谢谢指正。

本文地址 ：http://www.cnblogs.com/lovesong/p/5478116.html