移动前端框架重构几个关键问题
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 本文转自 海角在眼前 博客园博客，原文链接： http://www.cnblogs.com/lovesong/p/5478116.html，如需转载请自行联系原作者
