影響UITableView滾動(dòng)的流暢性優(yōu)化的原因
1、在代理方法中做了過(guò)多的計(jì)算占用了UI線程的時(shí)間
2瞒御、cell中view的組織復(fù)雜然眼；eg:使用layer并不會(huì)有太大影響，但是layer層如果使用了透明葵腹、圓角、變形等效果屿岂，就會(huì)影響到繪制速度践宴；
在代理方法中做了過(guò)多的計(jì)算占用了UI線程的時(shí)間
關(guān)于第一點(diǎn)首先要明白 tableView的代理的調(diào)用順序
1、通過(guò)代理設(shè)置行數(shù) number of rows
2爷怀、通過(guò)代理沒(méi)行設(shè)置行高度 heightForRoeAtIndexPath
3阻肩、通過(guò)代理設(shè)置當(dāng)前屏幕可見(jiàn)的元素 cellForRowAtIndexPath（實(shí)測(cè)顯示4寸屏的手機(jī)會(huì)取屏幕顯示數(shù)量+2,3.5寸屏幕同4寸數(shù)量，雖然3.5寸屏幕可顯示的cell的數(shù)量要小于4寸）
4运授、繪制cell?
關(guān)于第一點(diǎn)烤惊，首先要明白tableView的代理（這里是指datasource 和 delegate 的那套代理方法，下同方法的調(diào)用順序和時(shí)機(jī)吁朦。對(duì)于一般的應(yīng)用會(huì)有如下的順序呢：
1柒室、向代理要 ?number of rows.
2、對(duì)于每行向代理要 heoght For Row At IndexPath
3逗宜、向當(dāng)前屏幕要可見(jiàn)的cell For Row At IndexPath(實(shí)測(cè)顯示4寸屏的手機(jī)會(huì)取屏幕顯示數(shù)量 +2雄右， 3.5 寸屏幕同4 寸屏幕數(shù)量空骚，雖然 3.5 寸可顯示的 cell 數(shù)量要小于 4 寸屏)
4、然后 cell 就顯示出來(lái)了
tableView:heig htForRowAtIndexPath：
很多人把優(yōu)化重點(diǎn)放到了 cell for row at indexPath 那個(gè)代理方法里了擂仍，在這里盡可能的少計(jì)算囤屹，但是卻忽略了另一個(gè)很輕松就能提升加載速度的方法：
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
tableView在每次 reload data 時(shí)都會(huì)要所有cell的高度！這就是說(shuō)你有100 行 cell 逢渔。走100 次這個(gè)代理方法來(lái)設(shè)置cell 的高度肋坚，而不是當(dāng)前屏幕顯示的cell 的數(shù)量的高度，雖然在 iOS7下多了計(jì)算 cell 的高度的 方法肃廓，但是減少計(jì)算高度時(shí)的時(shí)間智厌，對(duì)于提升加載tableView的速度有非常明顯的提高
-（CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath(iOS7專用)
但是有人說(shuō)了“我早聽(tīng)人說(shuō)了，reloadData方法盡量不要調(diào)用亿昏，我插入新行都用insertRowAtIndexPaths:WithROwAnimation: 刪除也用delegate那個(gè)峦剔，這個(gè)中性了吧？”角钩；這樣也不能忽略heightForRowAtIndexPath 這個(gè)回調(diào)的重要性吝沫，因?yàn)樵诿看蝿h除或者插入一行后同樣也要調(diào)用以便返回所有行的這個(gè)回調(diào)方法！是所有行递礼！你沒(méi)有看錯(cuò)惨险，所有所以只需減少一個(gè)代理方法的計(jì)算量，就可以明顯的提升加載速度脊髓。
對(duì)于減少tableView:heihghtForRowAtIndexPath:計(jì)算量辫愉，就盡量讓這個(gè)方法的計(jì)算計(jì)算復(fù)雜度為O(1);就是只是簡(jiǎn)單的從數(shù)組中取出一個(gè)值，然后返回将硝！
也許有人要問(wèn)了恭朗，我們的應(yīng)用都是動(dòng)態(tài)的高度，就像微博那樣的依疼，不定數(shù)量的文字痰腮，還有圖片，大小也不固定律罢，這些怎么返回固定的高度鞍蛑怠？
我指的固定高度并不是row的高度都一定那種固定误辑，而是讓在tableView:heightForRowAtIndexPath:這個(gè)回調(diào)里取這個(gè)高度的時(shí)間是近乎固定的
對(duì)于高度的計(jì)算沧踏，還有個(gè)小細(xì)節(jié)需要注意，就是入如果row 的高度都一定巾钉，那么就刪除tableView:heightForRowAtIndexPath：這個(gè)方法翘狱，設(shè)置tableView的rowHeight屬性，相似的numberOfRowsInSection:系列的方法砰苍，我就不寫(xiě)出來(lái)了盒蟆，蘋果文檔里寫(xiě)這樣做可以減少調(diào)用時(shí)間踏烙。
現(xiàn)在回歸正題，對(duì)于cell的高度不固定历等，傳統(tǒng)的方法是為cell寫(xiě)個(gè)計(jì)算行高的類方法讨惩，傳入那些動(dòng)態(tài)的元素（文字、圖片等）然后返回計(jì)算的高度寒屯。在tableView:hieghtForRoeAtIndexPath:中調(diào)用這個(gè)方法荐捻，填入需要的參數(shù)計(jì)算cell高度。這當(dāng)然沒(méi)有什么問(wèn)題寡夹，只是要是計(jì)算量很復(fù)雜处面，你每次reoadData,光計(jì)算行高就花去rowCount *單行高評(píng)價(jià)計(jì)算時(shí)間 ，想想有100行菩掏，你不定期的要reloadData 或者 insert(delete)row ...... 結(jié)局辦法就是：
? ?用空間換時(shí)間
將計(jì)算行高的時(shí)間提前到從服務(wù)器請(qǐng)求會(huì)數(shù)據(jù)的時(shí)候魂角，計(jì)算完了高度一并寫(xiě)回數(shù)據(jù)庫(kù) ，別告訴我你在你在主線程里阻塞式的處理網(wǎng)絡(luò)請(qǐng)求智绸。野揪。。瞧栗。斯稳。。面壁思過(guò)去吧迹恐，別浪費(fèi)了 GCD挣惰，NSOPerationQueue的青春。最先想到的還是NSThread同學(xué)殴边，證明你已經(jīng)老了憎茂。〈赴叮∈＃現(xiàn)在幾乎大部分的多線程操作都不需要NSThread和Runloop了
tableView:cellForRowAtIndexPath:
說(shuō)完了計(jì)算cell的行高的優(yōu)化，現(xiàn)在來(lái)談 tableView:cellForRowAtIndexPath: 回調(diào)的優(yōu)化能耻。優(yōu)化思路同上，也是通過(guò)預(yù)處理來(lái)減少這個(gè)回調(diào)中的計(jì)算時(shí)間亡驰。這個(gè)回調(diào)重點(diǎn)談的是對(duì)圖片異步加載的優(yōu)化
圖片異步加載無(wú)非就是在這個(gè)方法里發(fā)起異步請(qǐng)求晓猛，圖片加載完成后根據(jù) UIImageView 的引用設(shè)置時(shí)間。有經(jīng)驗(yàn)的程序員可能會(huì)使用懶加載的方式減少快速滑動(dòng)時(shí)由于網(wǎng)絡(luò)請(qǐng)求過(guò)于頻繁與切換線程顯示圖片造成的卡頓凡辱。這里還有個(gè)問(wèn)題戒职，拿回來(lái)的圖片一定和最后顯示的大小不一樣，有時(shí)候偷懶透乾，直接設(shè)置imageView 的contentMode 屬性為 imageView自己”壓縮“洪燥，這是一個(gè)很取巧的方法磕秤，但是 tableView 的滾動(dòng)速度也會(huì)造成不容忽視的影響。對(duì)圖片變形需要對(duì)圖片做 transForm,每次變換圖片都要對(duì)圖片乘以一個(gè)變幻矩陣捧韵，如果你的圖片很多市咆，計(jì)算量是不可忽視的。
? ? ? ? 優(yōu)化建議：從網(wǎng)絡(luò)請(qǐng)求回來(lái)的圖片先根據(jù)需要顯示的圖片大小切成合適大小的圖再来，每次只顯示處理過(guò)的大小的圖片蒙兰，當(dāng)查看大圖時(shí)再顯示大圖。如果服務(wù)器能但會(huì)處理好的大圖和圖片的大小更好芒篷。
使用Instrument 的 Core Animation 模板可以查看圖片的壓縮情況搜变。
? ? ? ? Instrument 中的 Core Animation 模板只有在調(diào)試真機(jī)時(shí)才有，調(diào)適模擬器上的應(yīng)用沒(méi)有這個(gè)模板Ｕ肼Ｄ铀！但是可以再模擬器的Debug菜單下找到這些調(diào)適選項(xiàng)篡帕、
切記：調(diào)適應(yīng)用性能一定要用真機(jī)殖侵，Mac 的性能完爆 iPhone,所以不要說(shuō)我的應(yīng)用在模擬機(jī)上調(diào)適不卡啊赂苗！ 模擬器只是模擬iOS 軟件的運(yùn)行環(huán)境愉耙，不能模擬硬件性能！
Color Misaligned Images 這些選項(xiàng)對(duì)設(shè)備的所有應(yīng)用有效拌滋，也就是你不需要選擇 target 就能調(diào)適它（方便競(jìng)品分析：）
對(duì)于 MisAligned Images 會(huì)有兩種顏色：一種是洋紅色朴沿，一種是黃色、
Misaligned Images 洋紅色是因?yàn)橄袼貨](méi)對(duì)齊败砂，比如上面的label赌渣。一般情況下是因?yàn)橄袼貨](méi)對(duì)齊。需要抵抗鋸齒昌犹，像素會(huì)出現(xiàn)模糊的現(xiàn)象坚芜。
? ? ? ? 解決辦法：在設(shè)置 view 的 frame 的時(shí)候，在高分屏避免出現(xiàn)21.3,6.7這樣的小數(shù)斜姥，尤其是x,y坐標(biāo)鸿竖，用ceil 或 floor 或 round 取整。每 0.5 個(gè)點(diǎn)對(duì)應(yīng)一個(gè) pixel,o.3,0.7這樣就難為iPhone 了铸敏。低分屏不要出現(xiàn)小數(shù)
黃色是因?yàn)轱@示的圖片實(shí)際大小與顯示大小不同缚忧，對(duì)圖片進(jìn)行了拉伸，測(cè)試顯示使用 imageView 顯示實(shí)際大小的圖也會(huì)變黃杈笔。
? ? ?減少洋紅色和黃色可以提升滾動(dòng)的流暢性
手動(dòng) Drawing 試圖提升流暢性
如果通過(guò)上面的方法闪水，滾動(dòng)速度還不能達(dá)到可以容忍的速度，那就只剩下最后y一個(gè)方法了：手動(dòng)繪制視圖
手動(dòng)繪制方法蒙具，不是直接子類化UITableViewCell ,然后覆蓋drawRect：方法球榆，這樣你會(huì)得到一個(gè)大黑塊朽肥！ 因?yàn)閏ell 中不是只有一個(gè) contentView。 如果不了解 cell 的層次結(jié)構(gòu)持钉，可以去 Reveal 去看下衡招。
繪制cell 不建議使用 UIView ，建議使用 CALayer, UIView 的繪制是建立在 CoreGraphic上的右钾，使用的是CPU蚁吝。 CALAyer 使用的是 Core Animation,CPU，GPU通吃舀射，有系統(tǒng)決定使用哪個(gè)窘茁。 View 的繪制是自下向上的一層一層的繪制，然后渲染脆烟； layer 處理的是 Texure, 利用 GPU 的 Texture cache 和獨(dú)立的浮點(diǎn)數(shù)計(jì)算單元加速紋理的處理
問(wèn)題已解： 在UIView 的 drawRect 里使用 CG開(kāi)頭的繪圖命令只是觸發(fā)的偽離屏渲染山林，繪圖還是靠 CPU 同步的在主線程繪制，在 layer 中觸發(fā)的 離屏渲染會(huì)觸發(fā)真正的離屏渲染邢羔，在一個(gè)獨(dú)立的進(jìn)程里繪制驼抹。
https://lobste.rs/s/ckm4uw/a_performance-minded_take_on_ios_design/comments/itdkfh
GPU 不喜歡透明，所以所有的圖一定要弄成不透明拜鹤，
