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：
不要一股腦加了幾百個字體圖標作為內置圖標， 雖然使用上簡單了，但是有很多冗余。
總結
這幾個問題是在公司框架重構想起的，感觸最深的問題。
本文為原創文章，轉載請保留原出處，方便溯源，如有錯誤地方，謝謝指正。