UITableView滑動性能優化擴展

一點UITableView滑動性能優化擴展

影響UITableView的滑動，有哪些因素呢？ 
關於這一點，人眼能識別的幀率是60左右，這也就是爲何，電腦屏幕的最佳幀率是60Hz。 
屏幕一秒鐘會刷新60次（屏幕在一秒鐘會從新渲染60次），那麼每次刷新界面之間的處理時間，就是1/60,也就是1/60秒。也就是說，全部會致使計算、渲染耗時的操做都會影響UITableView的流暢。下面舉例說明：

1.在主線程中作耗時操做 
耗時操做，包括從網絡下載、從網絡加載、從本地數據庫讀取數據、從本地文件中讀取大量數據、往本地文件中寫入數據等。（這一點，相信你們都知道，要儘可能避免在主線程中執行，通常都是建立一個子線程來執行，而後再回到主線程）

2.動態計算UITableViewCell的高度，時間太久 
在iOS7以前，每個Cell的高度，只會計算一次，後面再次滑到這個Cell這裏，都會讀取緩存的高度，也即高度計算的代理方法不會再執行。可是到了iOS8,不會再緩存Cell的高度了，也就是說每次滑到某個Cell，代理方法都會執行一次，從新計算這個Cell的高度（iOS 9之後沒測試過）。 
因此，若是計算Cell高度的這個過程過於複雜，或者某個計算使用的算法耗時很長，可能會致使計算時間大於1/60，那麼必然致使界面的卡頓，或不流暢。

關於這一點，我之前的作法是在Cell中定義一個public方法，用來計算Cell高度，而後計算完高度後，將高度存儲在Cell對應的Model中（Model裏定義一個屬性來存高度），而後在渲染Cell時，咱們依然須要動態計算各個子視圖的高度。（多是沒用什麼太過複雜的計算或算法，時間都很短滑動也順暢）

其實，更優的作法是：再定義一個ModelFrame對象，在子線程請求服務器接口返回後，轉換爲對象的同時，也把各個子視圖的frame計算好，存在ModelFrame中，ModelFrame 和 Model 合併成一個Model存儲到數組中。這樣在爲Cell各個子控件賦值時，僅僅是取值、賦值，在計算Cell高度時，也僅僅是加法運算。

3.界面中背景色透明的視圖過多 
爲何界面中背景色透明的視圖過多會影響UITableView的流暢？

不少文章中都提到，可使用模擬器—>Debug—>Color Blended Layers來檢測透明背景色，把透明背景色改成與父視圖背景色同樣的顏色，這樣來提升渲染速度。

簡單說明一下，就是屏幕上顯示的全部東西，都是經過一個個像素點呈現出來的。而每個像素點都是經過三原色（紅、綠、藍）組合呈現出不一樣的顏色，最終纔是咱們看到的手機屏幕上的內容。在 iPhone5 的液晶顯示器上有1,136×640=727,040個像素，所以有2,181,120個顏色單元。在15寸視網膜屏的 MacBook Pro 上，這一數字達到15.5百萬以上。全部的圖形堆棧一塊兒工做以確保每次正確的顯示。當你滾動整個屏幕的時候，數以百萬計的顏色單元必須以每秒60次的速度刷新，這是一個很大的工做量。

每個像素點的顏色計算是這樣的： 
R = S + D * (1 - Sa) 
結果的顏色 是子視圖這個像素點的顏色 + 父視圖這個像素點的顏色 * （1 - 子視圖的透明度） 
固然，若是有兩個兄弟視圖疊加，那麼上面的中文解釋可能並不貼切，只是爲了更容易理解。

若是兩個兄弟視圖重合，計算的是重合區域的像素點： 
結果的顏色 是 上面的視圖這個像素點的顏色 + 下面這個視圖該像素點的顏色 * （1 - 上面視圖的透明度）

只有當透明度爲1時，上面的公式變爲R = S，就簡單的多了。不然的話，就很是複雜了。 
每個像素點是由三原色組成，例如父視圖的顏色和透明度是（Pr,Pg,Pb,Pa)，子視圖的顏色顏色和透明度是（Sr,Sg,Sb,Sa)，那麼咱們計算這個重合區域某像素點的顏色，須要先分別計算出紅、綠、藍。 
Rr = Sr + Pr * (1 - Sa)， 
Rg = Sg + Pg * (1 - Sa)， 
Rb = Sb + Pb * (1 - Sa)。 
若是父視圖的透明度，即Pa = 1,那麼這個像素的顏色就是(Rr,Rg,Rb)。 
可是，若是父視圖的透明Pa 不等 1，那麼咱們須要將這個結果顏色當作一個總體做爲子視圖的顏色，再去與父視圖組合計算顏色，如此遞推。

 

因此設置不透明時，能夠爲GPU節省大量的工做，減小大量的消耗。