UItableView效能優化

在iOS應用中，UITableView應該是使用率最高的檢視之一了。iPod、時鐘、日曆、備忘錄、Mail、天氣、照片、電話、簡訊、Safari、App Store、iTunes、Game Center⋯幾乎所有自帶的應用中都能看到它的身影，可見它的重要性。
然而在使用第三方應用時，卻經常遇到效能上的問題，普遍表現在滾動時比較卡，特別是table cell中包含圖片的情況時。
實際上只要針對性地優化一下，這種問題就不會有了。有興趣的可以看看LazyTableImages這個官方的例子程式，雖然也要從網上下載圖片並顯示，但滾動時絲毫不卡。
下面就說說我對UITableView的瞭解。不過由於我也是初學者，或許會說錯或遺漏一些，因此僅供參考。

首先說下UITableView的原理。有興趣的可以看看《About Table Views in iOS-Based Applications》。
UITableView是UIScrollView的子類，因此它可以自動響應滾動事件（一般為上下滾動）。
它內部包含0到多個UITableViewCell物件，每個table cell展示各自的內容。當新cell需要被顯示時，就會呼叫tableView:cellForRowAtIndexPath:方法來獲取或建立一個cell；而不可視時，它又會被釋放。由此可見，同一時間其實只需要存在一螢幕的cell物件即可，不需要為每一行建立一個cell。
此外，UITableView還可以分為多個sections，每個區段都可以有自己的head、foot和cells。而在定位一個cell時，就需要2個欄位了：在哪個section，以及在這個section的第幾行。這在iOS SDK中是用NSIndexPath來表述的，UIKit為其新增了indexPathForRow:inSection:這個建立方法。
其他諸如編輯之類的就不提了，因為和本文無關。

介紹完原理，接下來就開始優化吧。

1. 使用不透明檢視。
   不透明的檢視可以極大地提高渲染的速度。因此如非必要，可以將table cell及其子檢視的opaque屬性設為YES（預設值）。
   其中的特例包括背景色，它的alpha值應該為1（例如不要使用clearColor）；影象的alpha值也應該為1，或者在畫圖時設為不透明。

   
   

   當一個view是透明的，iOS需要渲染一個畫素兩次或多次，這是因為一個畫素同時屬於很多subviews。這是一個非常耗時的過程。

   通過程式碼或者InterfaceBuilder能夠很簡單的做到。開發者應該多次檢查所有的subviews是不透明的。

   對於自定義程式碼，你可以通過程式碼來設定，如下：

   view.opaque = YES;

   
   
2. 不要重複建立不必要的table cell。
   前面說了，UITableView只需要一螢幕的UITableViewCell物件即可。因此在cell不可見時，可以將其快取起來，而在需要時繼續使用它即可。
   而UITableView也提供了這種機制，只需要簡單地設定一個identifier即可：
   

   static NSString *CellIdentifier = @"xxx";
   UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
   if (cell == nil) {
           cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
   }

   值得一提的是，cell被重用時，它內部繪製的內容並不會被自動清除，因此你可能需要呼叫setNeedsDisplayInRect:或setNeedsDisplay方法。
   此外，在新增table cell的時候，如果不需要動畫效果，最好不要使用insertRowsAtIndexPaths:withRowAnimation:方法，而是直接呼叫reloadData方法。因為前者會對所有indexPaths呼叫tableView:cellForRowAtIndexPath:方法，即便該cell並不需要顯示（不知道是不是bug），這就可能建立大量多餘的cell。勘誤：只是在模擬器上測試如此，真機除錯時沒有這種bug。
   
3. 減少檢視的數目。
   UITableViewCell包含了textLabel、detailTextLabel和imageView等view，而你還可以自定義一些檢視放在它的contentView裡。然而view是很大的物件，建立它會消耗較多資源，並且也影響渲染的效能。
   如果你的table cell包含圖片，且數目較多，使用預設的UITableViewCell會非常影響效能。奇怪的是，使用自定義的view，而非預定義的view，明顯會快些。
   當然，最佳的解決辦法還是繼承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];
   }

   不過這樣一來，你會發現選中一行後，這個cell就變藍了，其中的內容就被擋住了。最簡單的方法就是將cell的selectionStyle屬性設為UITableViewCellSelectionStyleNone，這樣就不會被高亮了。
   此外還可以建立CALayer，將內容繪製到layer上，然後對cell的contentView.layer呼叫addSublayer:方法。這個例子中，layer並不會顯著影響效能，但如果layer透明，或者有圓角、變形等效果，就會影響到繪製速度了。解決辦法可參見後面的預渲染影象。
   
4. 不要做多餘的繪製工作。
   在實現drawRect:的時候，它的rect引數就是需要繪製的區域，這個區域之外的不需要進行繪製。
   例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判斷是否需要繪製image和text，然後再呼叫繪製方法。
   
5. 預渲染影象。
   你會發現即使做到了上述幾點，當新的影象出現時，仍然會有短暫的停頓現象。解決的辦法就是在bitmap context裡先將其畫一遍，匯出成UIImage物件，然後再繪製到螢幕，詳細做法可見《利用預渲染加速iOS裝置的影象顯示》。
   
6. 不要阻塞主執行緒。
   做到前幾點後，你的table view滾動時應該足夠流暢了，不過你仍可能讓使用者感到不爽。常見的現象就是在更新資料時，整個介面卡住不動，完全不響應使用者請求。
   出現這種現象的原因就是主執行緒執行了耗時很長的函式或方法，在其執行完畢前，無法繪製螢幕和響應使用者請求。其中最常見的就是網路請求了，它通常都需要花費數秒的時間，而你不應該讓使用者等待那麼久。
   解決辦法就是使用多執行緒，讓子執行緒去執行這些函式或方法。這裡面還有一個學問，當下載執行緒數超過2時，會顯著影響主執行緒的效能。因此在使用ASIHTTPRequest時，可以用一個NSOperationQueue來維護下載請求，並將其maxConcurrentOperationCount設為2。而NSURLRequest則可以配合GCD來實現，或者使用NSURLConnection的setDelegateQueue:方法。
   當然，在不需要響應使用者請求時，也可以增加下載執行緒數，以加快下載速度：
   

   - (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;
   }

   此外，自動載入更新資料對使用者來說也很友好，這減少了使用者等待下載的時間。例如每次載入50條資訊，那就可以在滾動到倒數第10條以內時，載入更多資訊：
   

   - (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
           if (count - indexPath.row < 10 && !updating) {
                   updating = YES;
                   [self update];
           }
   }
   // update方法獲取到結果後，設定updating為NO

   還有一點要注意的就是當圖片下載完成後，如果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:方法，插入新行需要在主執行緒執行，而一次插入很多行的話（例如50行），會長時間阻塞主執行緒。而換成reloadData方法的話，瞬間就處理完了。
   

7、減少預載入時間

通常，我會通過快取來重用圖片，同時減少初始化的過程。當OS需要為TableView渲染一個新的cell，會通過呼叫下面的方法來返回一個新的cell：

因此，如果你在這裡阻塞了太長的時間，UserInterface渲染的過程就會被阻塞；它將不能做任何事情或顯示任何新的東西。這就是為什麼使用者看到在某個地方滾動停止的原因。

為了使這個過程儘可能的快，你可以去除一些邏輯，延遲計算，通過重用來快取資料和圖片。另外一個方法是通過首先使用預設的圖片和資料來重用cell。當要獲取圖片或資料的時候，你可以使用多執行緒，然後稍後進行填充。從使用者的角度來看，這種方法將會使得滾動更加流程，載入圖片的速度更快。

8、快取高度

無論是否需要建立一個新的cell，你需要快取rows的高度，因為這是TableView所需要的資訊。如果你的cell的高度是固定的，你不必擔心。然而，如果它不是固定的，你需要確保你的cell計算足夠的快。

可以嘗試使用如下程式碼：

避免使用下面的程式碼：

當需要渲染cell或者在動畫過程中需要編輯/重排序cell的時候，OS會多次執行第一段程式碼段。xiang像第二段程式碼中有一個迴圈，無論是否需要知道cell的高度，OS都會執行一個重複100次的迴圈。

9、避免使用圖形特效

避免在UIImage中使用複雜的圖形特效(例如漸變)。

總結

• 恰當的重用cell：這是第一步，也是最重要的一步。重用一個cell非常簡單，但是很多應用都會漏了這一步。因此，你如果有很多效能問題，確保多次檢查這方面的問題。

• 恰當的 快取/重用 圖片/資料：另外一個重要的步驟就是當返回一個cell顯示的時候，減少資料載入和邏輯處理的時間。

• 減少總的載入和計算時間：並不是僅僅只有IO會減慢和阻塞UI執行緒；任何資料的處理都會減慢這個過程。因此，你應該總是儘可能的減少這個過程的處理時間。

• 自行繪製cell：在渲染table view的時候，為了充分利用GPU計算密集型的優勢，你應該考慮使用直接繪製的方法。這樣會顯著的提升渲染的速度，增加測量的效能；fps幾乎接近最大。你可以通過複寫drawRect方法繪製自己的cell，然後在每個元素中呼叫不同的方法繪製每個UI元素。

• 透明度：當開發者將他們的UI元素放進view的時候，這是經常會遇到的小問題。如果他們沒有設定view為不透明，渲染的時候就要對同一個點繪製兩次或多次。

• 快取高度：這是開發者經常會犯的另一個小錯誤。每當需要一個新的cell，每次都會有兩個主要的方法被呼叫。

• 避免圖形特效：在cell中有越多的特效，渲染的過程就越慢。因此，你應該對此進行測試。你可以使用CoreAnimation來檢視每個UI元素渲染的效率。

• 編輯/重排序效能：滾動效能優化，對於編輯或重排序來說，可能會帶來一些問題，因為UIKit和動畫框架已經多subview進行了優化。如果你是自己繪製的話，這些框架的優化將不起作用。