移動前端框架重構幾個關鍵問題

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