在iOS應(yīng)用中旁舰，UITableView應(yīng)該是使用率最高的視圖之一了。iPod箭窜、時鐘磺樱、日歷婆咸、備忘錄续担、Mail、天氣乖仇、照片询兴、電話、短信警儒、Safari眶根、App Store属百、iTunes、GameCenter?幾乎所有自帶的應(yīng)用中都能看到它的身影厌丑，可見它的重要性渔呵。
然而在使用第三方應(yīng)用時，卻經(jīng)常遇到性能上的問題耕驰，普遍表現(xiàn)在滾動時比較卡类茂，特別是tablecell中包含圖片的情況時巩检。
實際上只要針對性地優(yōu)化一下，這種問題就不會有了兢哭。有興趣的可以看看LazyTableImages這個官方的例子程序，雖然也要從網(wǎng)上下載圖片并顯示舍咖，但滾動時絲毫不卡锉桑。
下面就說說我對UITableView的了解。不過由于我也是初學(xué)者攻柠，或許會說錯或遺漏一些后裸，因此僅供參考。
首先說下UITableView的原理浪谴。有興趣的可以看看《About
Table Views in iOS-Based Applications》因苹。
UITableView是UIScrollView的子類扶檐，因此它可以自動響應(yīng)滾動事件（一般為上下滾動）。
它 內(nèi)部包含0到多個UITableViewCell對象，每個tablecell展示各自的內(nèi)容醋虏。當(dāng)新cell需要被顯示時哮翘，就會調(diào)用tableView:cellForRowAtIndexPath:方法來獲取或創(chuàng)建一個cell；而不可視時阻课，它又會被釋放艰匙。由此可見员凝，同一時間其實只需要存在一屏幕的cell對象即可，不需要為每一行創(chuàng)建一個cell旺上。
此外，UITableView還可以分為多個sections窃这，每個區(qū)段都可以有自己的head征候、foot和cells。而在定位一個cell時朴上，就需要2個字段了：在哪個section卒煞，以及在這個section的第幾行畔裕。這在iOSSDK中是用NSIndexPath來表述的，UIKit為其添加了indexPathForRow:inSection:這個創(chuàng)建方法具练。
其他諸如編輯之類的就不提了甜无，因為和本文無關(guān)岂丘。
介紹完原理，接下來就開始優(yōu)化吧铜邮。
使用不透明視圖寨蹋。
不透明的視圖可以極大地提高渲染的速度。因此如非必要秸苗，可以將tablecell及其子視圖的opaque屬性設(shè)為YES（默認(rèn)值）评姨。
其中的特例包括背景色，它的alpha值應(yīng)該為1（例如不要使用clearColor）胁后；圖像的alpha值也應(yīng)該為1攀芯，或者在畫圖時設(shè)為不透明。
不要重復(fù)創(chuàng)建不必要的table
cell殖演。
前面說了年鸳，UITableView只需要一屏幕的UITableViewCell對象即可搔确。因此在cell不可見時，可以將其緩存起來膳算，而在需要時繼續(xù)使用它即可座硕。
而UITableView也提供了這種機制，只需要簡單地設(shè)置一個identifier即可：
static NSString *CellIdentifier = @"xxx";UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];if (cell == nil) {? ? cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];}
值得一提的是涕蜂，cell被重用時华匾，它內(nèi)部繪制的內(nèi)容并不會被自動清除，因此你可能需要調(diào)用setNeedsDisplayInRect:或setNeedsDisplay方法机隙。
此 外蜘拉，在添加tablecell的時候，如果不需要動畫效果有鹿，最好不要使用insertRowsAtIndexPaths:withRowAnimation:方法，而是直接調(diào)用reloadData方法印颤。因為前者會對所有indexPaths調(diào)用tableView:cellForRowAtIndexPath:方法，即便該cell并不需要顯示（不知道是不是bug）穿肄，這就可能創(chuàng)建大量多余的cell年局。勘誤：只是在模擬器上測試如此咸产，真機調(diào)試時沒有這種bug矢否。
減少視圖的數(shù)目。
UITableViewCell包含了textLabel脑溢、detailTextLabel和imageView等view僵朗，而你還可以自定義一些視圖放在它的contentView里赖欣。然而view是很大的對象，創(chuàng)建它會消耗較多資源验庙，并且也影響渲染的性能顶吮。
如果你的tablecell包含圖片，且數(shù)目較多粪薛，使用默認(rèn)的UITableViewCell會非常影響性能悴了。奇怪的是，使用自定義的view违寿，而非預(yù)定義的view湃交，明顯會快些。
當(dāng)然藤巢，最佳的解決辦法還是繼承UITableViewCell搞莺，并在其drawRect:中自行繪制：
- (void)drawRect:(CGRect)rect {? ? ? ? if (image) {? ? ? ? [image drawAtPoint:imagePoint];? ? ? ? self.image = nil;? ? } else {? ? ? ? [placeHolder drawAtPoint:imagePoint];? ? }? ? ? ? ? [text drawInRect:textRect withFont:font lineBreakMode:UILineBreakModeTailTruncation];}
不過這樣一來，你會發(fā)現(xiàn)選中一行后掂咒，這個cell就變藍了才沧，其中的內(nèi)容就被擋住了。最簡單的方法就是將cell的selectionStyle屬性設(shè)為UITableViewCellSelectionStyleNone俏扩，這樣就不會被高亮了糜工。
此外還可以創(chuàng)建CALayer，將內(nèi)容繪制到layer上录淡，然后對cell的contentView.layer調(diào)用addSublayer:方法捌木。這個例子中，layer并不會顯著影響性能嫉戚，但如果layer透明刨裆，或者有圓角、變形等效果彬檀，就會影響到繪制速度了帆啃。解決辦法可參見后面的預(yù)渲染圖像。
不要做多余的繪制工作窍帝。
在實現(xiàn)drawRect:的時候努潘，它的rect參數(shù)就是需要繪制的區(qū)域，這個區(qū)域之外的不需要進行繪制坤学。
例如上例中疯坤，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判斷是否需要繪制image和text深浮，然后再調(diào)用繪制方法压怠。
預(yù)渲染圖像。
你會發(fā)現(xiàn)即使做到了上述幾點飞苇，當(dāng)新的圖像出現(xiàn)時菌瘫，仍然會有短暫的停頓現(xiàn)象蜗顽。解決的辦法就是在bitmapcontext里先將其畫一遍，導(dǎo)出成UIImage對象雨让，然后再繪制到屏幕雇盖，詳細(xì)做法可見《利用預(yù)渲染加速iOS設(shè)備的圖像顯示》。
不要阻塞主線程宫患。
做到前幾點后刊懈，你的tableview滾動時應(yīng)該足夠流暢了，不過你仍可能讓用戶感到不爽娃闲。常見的現(xiàn)象就是在更新數(shù)據(jù)時虚汛，整個界面卡住不動，完全不響應(yīng)用戶請求皇帮。
出現(xiàn)這種現(xiàn)象的原因就是主線程執(zhí)行了耗時很長的函數(shù)或方法卷哩，在其執(zhí)行完畢前，無法繪制屏幕和響應(yīng)用戶請求属拾。其中最常見的就是網(wǎng)絡(luò)請求了将谊，它通常都需要花費數(shù)秒的時間，而你不應(yīng)該讓用戶等待那么久渐白。
解 決辦法就是使用多線程尊浓，讓子線程去執(zhí)行這些函數(shù)或方法。這里面還有一個學(xué)問纯衍，當(dāng)下載線程數(shù)超過2時栋齿，會顯著影響主線程的性能。因此在使用ASIHTTPRequest時襟诸，可以用一個NSOperationQueue來維護下載請求瓦堵，并將其maxConcurrentOperationCount設(shè)為2。而NSURLRequest則可以配合GCD來實現(xiàn)歌亲，或者使用NSURLConnection的setDelegateQueue:方法菇用。
當(dāng)然，在不需要響應(yīng)用戶請求時陷揪，也可以增加下載線程數(shù)惋鸥，以加快下載速度：
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {? ? if (!decelerate) {? ? ? ? queue.maxConcurrentOperationCount = 5;? ? }}- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView {? ? queue.maxConcurrentOperationCount = 5;}- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {? ? queue.maxConcurrentOperationCount = 2;}
此外，自動載入更新數(shù)據(jù)對用戶來說也很友好悍缠，這減少了用戶等待下載的時間揩慕。例如每次載入50條信息，那就可以在滾動到倒數(shù)第10條以內(nèi)時扮休，加載更多信息：
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
if (count - indexPath.row < 10 && !updating) {
updating = YES;
[self update];
}
}// update方法獲取到結(jié)果后，設(shè)置updating為NO
還有一點要注意的就是當(dāng)圖片下載完成后拴鸵，如果cell是可見的玷坠，還需要更新圖像：
NSArray *indexPaths = [self.tableView indexPathsForVisibleRows];for (NSIndexPath *visibleIndexPath in indexPaths) {? ? if (indexPath == visibleIndexPath) {? ? ? ? MyTableViewCell *cell = (MyTableViewCell *)[self.tableView cellForRowAtIndexPath:indexPath];? ? ? ? cell.image = image;? ? ? ? [cell setNeedsDisplayInRect:imageRect];? ? ? ? break;? ? }}// 也可不遍歷蜗搔，直接與頭尾相比較，看是否在中間即可八堡。
最后還是前面所說過的insertRowsAtIndexPaths:withRowAnimation:方法樟凄，插入新行需要在主線程執(zhí)行，而一次插入很多行的話（例如50行）兄渺，會長時間阻塞主線程缝龄。而換成reloadData方法的話，瞬間就處理完了挂谍。
補充:
1視圖的混合 (Composing)
當(dāng)多個視圖（或者說CALayer）重疊在一起顯示時叔壤，GPU 會首先把他們混合到一起。如果視圖結(jié)構(gòu)過于復(fù)雜口叙，混合的過程也會消耗很多 GPU 資源炼绘。為了減輕這種情況的GPU 消耗，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次妄田，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無用的 Alpha通道合成俺亮。當(dāng)然，這也可以用上面的方法疟呐，把多個視圖預(yù)先渲染為一張圖片來顯示脚曾。圖形的生成。CALayer 的border启具、圓角本讥、陰影、遮罩（mask）富纸，CASharpLayer 的矢量圖形顯示囤踩，通常會觸發(fā)離屏渲染（offscreenrendering），而離屏渲染通常發(fā)生在 GPU 中晓褪。當(dāng)一個列表視圖中出現(xiàn)大量圓角的 CALayer堵漱，并且快速滑動時，可以觀察到 GPU資源已經(jīng)占滿涣仿，而 CPU 資源消耗很少勤庐。這時界面仍然能正常滑動好港，但平均幀數(shù)會降到很低愉镰。為了避免這種情況，可以嘗試開啟CALayer.shouldRasterize 屬性钧汹，但這會把原本離屏渲染的操作轉(zhuǎn)嫁到 CPU上去丈探。對于只需要圓角的某些場合，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果拔莱。最徹底的解決辦法碗降，就是把需要顯示的圖形在后臺線程繪制為圖片隘竭，避免使用圓角、陰影讼渊、遮罩等屬性动看。
2,預(yù)渲染
微博的頭像在某次改版中換成了圓形，所以我也跟進了一下爪幻。當(dāng)頭像下載下來后菱皆，我會在后臺線程將頭像預(yù)先渲染為圓形并單獨保存到一個 ImageCache 中去。對于 TableView 來說挨稿，Cell 內(nèi)容的離屏渲染會帶來較大的 GPU 消耗仇轻。在 Twitter Demo 中，我為了圖省事兒用到了不少layer 的圓角屬性叶组，你可以在低性能的設(shè)備（比如 iPad3）上快速滑動一下這個列表拯田，能感受到雖然列表并沒有較大的卡頓，但是整體的平均幀數(shù)降了下來甩十。用 Instument 查看時能夠看到 GPU已經(jīng)滿負(fù)荷運轉(zhuǎn)船庇，而 CPU 卻比較清閑。為了避免離屏渲染侣监，你應(yīng)當(dāng)盡量避免使用 layer 的 border鸭轮、corner、shadow橄霉、mask等技術(shù)窃爷，而盡量在后臺線程預(yù)先繪制好對應(yīng)內(nèi)容。
