每次都會被問到這個TableView的性能如何優化，今天就來一探究竟吧!
常見的影響tableView的性能的幾點：
- 主線程干了與繪制無關的事情，凡是耗時的都有影響。當然把復雜的事情放到異步線程中去，假如計算時間比較久的話，滑動時也可能出現空白的情況，也是很蛋疼的。
1、大量的對象的創建和銷毀，過多的時候肯定是有影響，這個無須多說。
2、文本的計算多的話，放在主線程肯定就有影響。很多時候我們可以都把那個計算提前算出來。
3、服務器下發的圖片和實際的尺寸不一致，不得不去手動改尺寸，而重新計算尺寸就是有影響性能的。
4、重復去讀圖片，可以采取緩存的方法去避免重復。
5、設置圓角。其實單純的設置圓角很簡單，它不會帶來任何性能損耗。
view.layer.cornerRadius = 10.0f;
因為在默認情況下，這個屬性只會影響視圖的背景顏色和 border。而我們加上
label.layer.cornerRadius = 10.0f;
label.layer.masksToBounds = true；
也就是說設置 masksToBounds才會導致離屏渲染，從而影響性能的。具體可以看看
iOS高效添加圓角效果實戰講解。
6、cell 不復用，這個基本不會用到，我們現在一般都會用的吧。
7、圖片的透明，盡量不要用，渲染過程相對比會多好幾倍
8、用AutoLayout 某種程度是會重新計算的，自然是耗時的。
9、刪除某一組就reload section,刪除某一個cell就reloadRow。
- 上述有些點上現在是不可避免的，例如自動布局這塊，現在的項目基本都是用的，但是隨著硬件的性能越來越好，小性能的缺失是可以忽略的(個人觀點)。
以下是UIKit性能調優實戰講解 bestswifter 文章中提到的，在此直接摘抄下。
- 避免圖層混合
- 確保控件的opaque屬性設置為true，確保backgroundColor和父視圖顏色一致且不透明（就是不要設置View 的顏色 為Clear）
- 如無特殊需要，不要設置低于1的alpha值 （alpha = 1.0）
- 確保UIImage沒有alpha通道
- 避免臨時轉換
- 確保圖片大小和frame一致，不要在滑動時縮放圖片( 和重新計算尺寸有關)
- 確保圖片顏色格式被GPU支持，避免勞煩CPU轉換 （CPU 要做的事太多了）
- 慎用離屏渲染
絕大多數時候離屏渲染會影響性能 （shouldRasterize（光柵化、masks（遮罩）、shadows（陰影）、edge antialiasing（抗鋸齒）、group opacity（不透明）、復雜形狀設置圓角等、漸變...） - 重寫drawRect方法，設置圓角、陰影、模糊效果，光柵化都會導致離屏渲染
- 設置陰影效果是加上陰影路徑
- 滑動時若需要圓角效果，開啟光柵化
View 設置成 [UIColor clearColor]其實是影響性能的
cell高度這個問題呢
1、異步處理？
2、提前處理？
3、緩存 ？
- 固定高度時，盡量直接用下面這個，而不用那個代理中的高度返回
self.tableView.rowHeight = 44;
- (CGSize)sizeThatFits:(CGSize)size;
- (CGRect)boundingRectWithSize:(CGSize)size options:(NSStringDrawingOptions)options attributes:(nullable NSDictionary<NSString *, id> *)attributes context:(nullable NSStringDrawingContext *)context
- 上面相對來說，是我們平常計算高度最常用的方法，前者是 View 本身的，后者是 String 的，但是他們放在什么位置呢，我的想法是提前計算好，不要等到真正滑動時再來算，這樣相對來說，對性能的影響就減少啦。例如數據返回的時候，順便立馬就將其需要計算的高度，然后等到需要數據更新時，高度也一并返回把高度給計算好。
其實這個地方有個問題，當我們用自動布局的時候，數據更新的時候一般還是會重新計算一下約束的，還是有影響的。
寫的很粗糙，歡迎大家指正
