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

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.三、4.4？

在iPhone上，因为分配给浏览器的内存多，动画效果是不错的，不管是CSS3仍是js控制的。但在Android上，即使是加上GPU加速，但是效果仍是很差，特别是Android4.三、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