影響UITableView滾動(dòng)的流暢性優(yōu)化的原因

1、在代理方法中做了過多的計(jì)算占用了UI線程的時(shí)間

2、cell中view的組織復(fù)雜；eg:使用layer并不會(huì)有太大影響，但是layer層如果使用了透明、圓角、變形等效果，就會(huì)影響到繪制速度；

在代理方法中做了過多的計(jì)算占用了UI線程的時(shí)間

關(guān)于第一點(diǎn)首先要明白 tableView的代理的調(diào)用順序

1、通過代理設(shè)置行數(shù) number of rows

2、通過代理沒行設(shè)置行高度 heightForRoeAtIndexPath

3、通過代理設(shè)置當(dāng)前屏幕可見的元素 cellForRowAtIndexPath（實(shí)測顯示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ī)。對于一般的應(yīng)用會(huì)有如下的順序呢：

1、向代理要 ?number of rows.

2、對于每行向代理要 heoght For Row At IndexPath

3、向當(dāng)前屏幕要可見的cell For Row At IndexPath(實(shí)測顯示4寸屏的手機(jī)會(huì)取屏幕顯示數(shù)量 +2， 3.5 寸屏幕同4 寸屏幕數(shù)量，雖然 3.5 寸可顯示的 cell 數(shù)量要小于 4 寸屏)

4、然后 cell 就顯示出來了

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的高度！這就是說你有100 行 cell 。走100 次這個(gè)代理方法來設(shè)置cell 的高度，而不是當(dāng)前屏幕顯示的cell 的數(shù)量的高度，雖然在 iOS7下多了計(jì)算 cell 的高度的 方法，但是減少計(jì)算高度時(shí)的時(shí)間，對于提升加載tableView的速度有非常明顯的提高

-（CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath(iOS7專用)

但是有人說了“我早聽人說了，reloadData方法盡量不要調(diào)用，我插入新行都用insertRowAtIndexPaths:WithROwAnimation: 刪除也用delegate那個(gè)，這個(gè)中性了吧？”；這樣也不能忽略heightForRowAtIndexPath 這個(gè)回調(diào)的重要性，因?yàn)樵诿看蝿h除或者插入一行后同樣也要調(diào)用以便返回所有行的這個(gè)回調(diào)方法！是所有行！你沒有看錯(cuò)，所有所以只需減少一個(gè)代理方法的計(jì)算量，就可以明顯的提升加載速度。

對于減少tableView:heihghtForRowAtIndexPath:計(jì)算量，就盡量讓這個(gè)方法的計(jì)算計(jì)算復(fù)雜度為O(1);就是只是簡單的從數(shù)組中取出一個(gè)值，然后返回！

也許有人要問了，我們的應(yīng)用都是動(dòng)態(tài)的高度，就像微博那樣的，不定數(shù)量的文字，還有圖片，大小也不固定，這些怎么返回固定的高度啊？

我指的固定高度并不是row的高度都一定那種固定，而是讓在tableView:heightForRowAtIndexPath:這個(gè)回調(diào)里取這個(gè)高度的時(shí)間是近乎固定的

對于高度的計(jì)算，還有個(gè)小細(xì)節(jié)需要注意，就是入如果row 的高度都一定，那么就刪除tableView:heightForRowAtIndexPath：這個(gè)方法，設(shè)置tableView的rowHeight屬性，相似的numberOfRowsInSection:系列的方法，我就不寫出來了，蘋果文檔里寫這樣做可以減少調(diào)用時(shí)間。

現(xiàn)在回歸正題，對于cell的高度不固定，傳統(tǒng)的方法是為cell寫個(gè)計(jì)算行高的類方法，傳入那些動(dòng)態(tài)的元素（文字、圖片等）然后返回計(jì)算的高度。在tableView:hieghtForRoeAtIndexPath:中調(diào)用這個(gè)方法，填入需要的參數(shù)計(jì)算cell高度。這當(dāng)然沒有什么問題，只是要是計(jì)算量很復(fù)雜，你每次reoadData,光計(jì)算行高就花去rowCount *單行高評(píng)價(jià)計(jì)算時(shí)間 ，想想有100行，你不定期的要reloadData 或者 insert(delete)row ...... 結(jié)局辦法就是：

? ?用空間換時(shí)間

將計(jì)算行高的時(shí)間提前到從服務(wù)器請求會(huì)數(shù)據(jù)的時(shí)候，計(jì)算完了高度一并寫回數(shù)據(jù)庫 ，別告訴我你在你在主線程里阻塞式的處理網(wǎng)絡(luò)請求。。。。。。面壁思過去吧，別浪費(fèi)了 GCD，NSOPerationQueue的青春。最先想到的還是NSThread同學(xué)，證明你已經(jīng)老了。。。現(xiàn)在幾乎大部分的多線程操作都不需要NSThread和Runloop了

tableView:cellForRowAtIndexPath:

說完了計(jì)算cell的行高的優(yōu)化，現(xiàn)在來談 tableView:cellForRowAtIndexPath: 回調(diào)的優(yōu)化。優(yōu)化思路同上，也是通過預(yù)處理來減少這個(gè)回調(diào)中的計(jì)算時(shí)間。這個(gè)回調(diào)重點(diǎn)談的是對圖片異步加載的優(yōu)化

圖片異步加載無非就是在這個(gè)方法里發(fā)起異步請求，圖片加載完成后根據(jù) UIImageView 的引用設(shè)置時(shí)間。有經(jīng)驗(yàn)的程序員可能會(huì)使用懶加載的方式減少快速滑動(dòng)時(shí)由于網(wǎng)絡(luò)請求過于頻繁與切換線程顯示圖片造成的卡頓。這里還有個(gè)問題，拿回來的圖片一定和最后顯示的大小不一樣，有時(shí)候偷懶，直接設(shè)置imageView 的contentMode 屬性為 imageView自己”壓縮“，這是一個(gè)很取巧的方法，但是 tableView 的滾動(dòng)速度也會(huì)造成不容忽視的影響。對圖片變形需要對圖片做 transForm,每次變換圖片都要對圖片乘以一個(gè)變幻矩陣，如果你的圖片很多，計(jì)算量是不可忽視的。

? ? ? ? 優(yōu)化建議：從網(wǎng)絡(luò)請求回來的圖片先根據(jù)需要顯示的圖片大小切成合適大小的圖，每次只顯示處理過的大小的圖片，當(dāng)查看大圖時(shí)再顯示大圖。如果服務(wù)器能但會(huì)處理好的大圖和圖片的大小更好。

使用Instrument 的 Core Animation 模板可以查看圖片的壓縮情況。

? ? ? ? Instrument 中的 Core Animation 模板只有在調(diào)試真機(jī)時(shí)才有，調(diào)適模擬器上的應(yīng)用沒有這個(gè)模板！！！但是可以再模擬器的Debug菜單下找到這些調(diào)適選項(xiàng)、

切記：調(diào)適應(yīng)用性能一定要用真機(jī)，Mac 的性能完爆 iPhone,所以不要說我的應(yīng)用在模擬機(jī)上調(diào)適不卡啊！ 模擬器只是模擬iOS 軟件的運(yùn)行環(huán)境，不能模擬硬件性能！

Color Misaligned Images 這些選項(xiàng)對設(shè)備的所有應(yīng)用有效，也就是你不需要選擇 target 就能調(diào)適它（方便競品分析：）

對于 MisAligned Images 會(huì)有兩種顏色：一種是洋紅色，一種是黃色、

Misaligned Images 洋紅色是因?yàn)橄袼貨]對齊，比如上面的label。一般情況下是因?yàn)橄袼貨]對齊。需要抵抗鋸齒，像素會(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)對應(yīng)一個(gè) pixel,o.3,0.7這樣就難為iPhone 了。低分屏不要出現(xiàn)小數(shù)

黃色是因?yàn)轱@示的圖片實(shí)際大小與顯示大小不同，對圖片進(jìn)行了拉伸，測試顯示使用 imageView 顯示實(shí)際大小的圖也會(huì)變黃。

? ? ?減少洋紅色和黃色可以提升滾動(dòng)的流暢性

手動(dòng) Drawing 試圖提升流暢性

如果通過上面的方法，滾動(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ì)算單元加速紋理的處理

問題已解： 在UIView 的 drawRect 里使用 CG開頭的繪圖命令只是觸發(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 不喜歡透明，所以所有的圖一定要弄成不透明，