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：

不要一股腦加了幾百個字體圖標作為內置圖標， 雖然使用上簡單了，但是有很多冗餘。

閱讀更多 蒲公英的憂傷 的文章

關鍵字: jQuery 0verflow WebKit