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：
不要一股脑加了几百个字体图标作为内置图标， 虽然使用上简单了，但是有很多冗余。
总结
这几个问题是在公司框架重构想起的，感触最深的问题。
本文为原创文章，转载请保留原出处，方便溯源，如有错误地方，谢谢指正。