iOS 優化界面流暢度的探討

界面流暢度 大都跟list scrollView有緊密關聯

流暢的視覺:就是如絲般順滑

不流暢視覺:」卡頓」,」抖動」,」遲頓感」

以上兩種狀態的描述 都是基於主觀感受,對於開發者來講 確實應該有一個臨界指標來參考,本身寫的東西是否還有優化的空間呢.

 Frames per Second(每秒幀數)   這個指標 能夠經過Instruments 工具中的 Core Animation來觀察.(xCode -> Tools -> Instrument)

幀數爲 0 說明頁面處於靜止 只要頁面一動起來,這個幀數就會有變化 而後再趨於靜止.也就是說頁面 滾動起來幀數是一個呈」非對稱」拋物線的走勢.

因此達到峯值的幀數 會呈現連續變化的一個狀態 那麼這個就是是它的流暢度 ,通常普通的一個list 滾動起來 流暢度 達到60左右 (親測本身的app的一個普通頁面),一個複雜頁面53 - 60(親測).網上有人這麼說」45幀每秒，這個幀率已經讓人感受到不那麼順滑了，若是低於40幀每秒，普通用戶就會察覺明顯的不流暢了」.因此你們能夠根據這些作參考,或者 是 測試本身的應用 比較幾個普通頁面 和一個複雜頁面也能夠有一個相對的參照.就可從理論上分析 是否這個相對比較複雜的頁面是否值得優化呢. 

 

能夠優化的地方(就是日常拍腦門能想到的地方)

1.CPU:能夠經過Instruments裏面的工具檢測cpu等 查出 究竟是實現的哪一個功能比較增長CPU的負擔

2.若是是tableView. 組織數據很繁瑣沒有用model來映射? 是否cell重用? 繪製高度的方法是否是很冗長,不斷的在重複計算? 須要刷新tableView 使用了不恰當地方式?

3.在滾動視圖中 圓角的處理

通常狀況下咱們會這樣作:

.layer.masksToBounds = YES;

.layer.cornerRadius = imageView.size.width * 0.5;

這個方法在滾動視圖中會是特別影響性能

緣由:

致使拖慢幀率的緣由其實都是Off-Screen Rendering（離屏渲染).

離屏渲染:是指CPU在當前屏幕緩衝區之外再開闢一個新的緩衝區進行渲染操做.

離屏渲染是一個很好優化性能的方式，可是頻繁發生離屏渲染(滾動屏幕 就會很頻繁啊)是很是耗時的。若是是一個圓角幾乎不會對幀率有太大影響,關鍵數量要是好多個.經過上面的定義能夠看出」離屏渲染」關鍵不是渲染 而是 離屏.

離屏代價:主要是建立緩衝區和上下文切換的緣由。建立新的緩衝區代價都不算大，付出最大代價的是上下文切換!!!!!(滿紙荒唐言 一把辛酸淚  誰被坑過 誰知道)

關於上下文切換:

上下文切換在哪都是一個至關耗費時間的操做,不管是 CPU渲染或是進程切換.其過程:

(1)咱們要保證當前屏幕渲染環境

(2)切換到一個新的繪製環境—>申請繪製資源—>初始化環境—>開始繪製—>繪製結束—>銷燬繪製環境

(3)回到主屏幕呈現 或者 再開闢一個新的離屏渲染重複(2)

解決:

那麼如何應對這個問題呢？不要在滾動視圖使用cornerRadiu 可使用下面的方法

(1)非要做死使用layer.ornerRadius,記得還要添加下面方法

.layer.shouldRasterize = YES;  //這樣大部分狀況下能夠立刻挽救你的幀數在55幀每秒以上。shouldRasterize = YES會使視圖渲染內容被緩存起來，下次繪製的時候能夠直接顯示緩存，固然要在視圖內容不改變的狀況下。(具體解釋  layer的頭文件,進入查看這個屬性的英文說明  不覺明厲)

.layer.rasterizationScale = [UIScreen mainScreen].scale;//須要適當設置"抗鋸齒"  不然在retina的設備上這些視圖會出現鋸齒狀。(具體瞭解參看 layer 屬性)

(2)若是能夠用切圖遮罩代替的話 會效率很高

(3)預先緩存住 圓角的圖片(預處理圓角圖片在後臺處理，處理完畢後緩存起來，再在主線程顯示),來避免了離屏渲染

 

參考資源

http://www.zhihu.com/question/20382396  (知乎)

http://www.cnblogs.com/ioriwellings/p/5011993.html (更具體的解決方案)