ACM_Someone like you

界面流暢度 大都跟list scrollView有緊密關聯(lián)

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

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

以上兩種狀態(tài)的描述 都是基于主觀感覺,對于開發(fā)者來說 確實應該有一個臨界指標來參考,自己寫的東西是否還有優(yōu)化的空間呢.

 Frames per Second(每秒幀數(shù))   這個指標 可以通過Instruments 工具中的 Core Animation來觀察.(xCode -> Tools -> Instrument)

幀數(shù)為 0 說明頁面處于靜止 只要頁面一動起來,這個幀數(shù)就會有變化 然后再趨于靜止.也就是說頁面 滾動起來幀數(shù)是一個呈”非對稱”拋物線的走勢.

所以達到峰值的幀數(shù) 會呈現(xiàn)連續(xù)變化的一個狀態(tài) 那么這個就是是它的流暢度 ,一般普通的一個list 滾動起來 流暢度 達到60左右 (親測自己的app的一個普通頁面),一個復雜頁面53 - 60(親測).網(wǎng)上有人這么說”45幀每秒，這個幀率已經(jīng)讓人感覺到不那么順滑了，如果低于40幀每秒，普通用戶就會察覺明顯的不流暢了”.所以大家可以根據(jù)這些做參考,或者 是 測試自己的應用 比較幾個普通頁面 和一個復雜頁面也可以有一個相對的參照.就可從理論上分析 是否這個相對比較復雜的頁面是否值得優(yōu)化呢. 

可以優(yōu)化的地方(就是平常拍腦門能想到的地方)

1.CPU:可以通過Instruments里面的工具檢測cpu等 查出 到底是實現(xiàn)的哪個功能比較增加CPU的負擔

2.如果是tableView. 組織數(shù)據(jù)很繁瑣沒有用model來映射? 是否cell重用? 繪制高度的方法是不是很冗長,不斷的在重復計算? 需要刷新tableView 使用了不恰當?shù)胤绞?

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

一般情況下我們會這樣做:

.layer.masksToBounds = YES;

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

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

原因:

導致拖慢幀率的原因其實都是Off-Screen Rendering（離屏渲染).

離屏渲染:是指CPU在當前屏幕緩沖區(qū)以外再開辟一個新的緩沖區(qū)進行渲染操作.

離屏渲染是一個很好優(yōu)化性能的方式，但是頻繁發(fā)生離屏渲染(滾動屏幕 就會很頻繁啊)是非常耗時的。如果是一個圓角幾乎不會對幀率有太大影響,關鍵數(shù)量要是好多個.通過上面的定義可以看出”離屏渲染”關鍵不是渲染 而是 離屏.

離屏代價:主要是創(chuàng)建緩沖區(qū)和上下文切換的原因。創(chuàng)建新的緩沖區(qū)代價都不算大，付出最大代價的是上下文切換!!!!!(滿紙荒唐言 一把辛酸淚  誰被坑過 誰知道)

關于上下文切換:

上下文切換在哪都是一個相當耗費時間的操作,不論是 CPU渲染或是進程切換.其過程:

(1)我們要保證當前屏幕渲染環(huán)境

(2)切換到一個新的繪制環(huán)境—>申請繪制資源—>初始化環(huán)境—>開始繪制—>繪制結束—>銷毀繪制環(huán)境

(3)回到主屏幕呈現(xiàn) 或者 再開辟一個新的離屏渲染重復(2)

解決:

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

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

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

.layer.rasterizationScale = [UIScreen mainScreen].scale;//需要適當設置"抗鋸齒"  否則在retina的設備上這些視圖會出現(xiàn)鋸齒狀。(具體了解參看 layer 屬性)

(2)如果可以用切圖遮罩代替的話 會效率很高

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

參考資源

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

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