[轉] 詳細整理：UITableView優化技巧

時間 2019-11-07

標籤詳細整理 uitableview 優化技巧简体版

原文原文鏈接

原文： http://www.cocoachina.com/ios/20150602/11968.html

最近在微博上看到一個很好的開源項目VVeboTableViewDemo，是關於如何優化UITableView的。加上正好最近也在優化項目中的相似朋友圈功能這塊，思考了不少關於UITableView的優化技巧，相信這塊是難點也是痛點，因此決定詳細的整理下我對優化UITableView的理解。html

UITableView做爲iOS開發中最重要的控件之一，其中的實現原理非常考究。Apple在這塊的優化水平直接決定了iOS的體驗能甩安卓幾條街，哈哈，扯淡扯多了。。。好了，廢話很少說，直接進入主題。首先來談談我對UITableView的認識：ios

UITableView的簡單認識git

UITableView 最核心的思想就是UITableViewCell的重用機制。簡單的理解就是：UITableView只會建立一屏幕（或一屏幕多一點）的 UITableViewCell，其餘都是從中取出來重用的。每當Cell滑出屏幕時，就會放入到一個集合（或數組）中（這裏就至關於一個重用池），當要顯示某一位置的Cell時，會先去集合（或數組）中取，若是有，就直接拿來顯示；若是沒有，纔會建立。這樣作的好處可想而知，極大的減小了內存的開銷。github

　　知道UITableViewCell的重用原理後，咱們來看看UITableView的回調方法。UITableView最主要的兩個回調方法是 tableView:cellForRowAtIndexPath:和tableView:heightForRowAtIndexPath:。理想上我們是會認爲UITableView會先調用前者，再調用後者，由於這和咱們建立控件的思路是同樣的，先建立它，再設置它的佈局。但實際上卻並不是如此，咱們都知道，UITableView是繼承自UIScrollView的，須要先肯定它的contentSize及每一個Cell的位置，而後纔會把重用的 Cell放置到對應的位置。因此事實上，UITableView的回調順序是先屢次調用 tableView:heightForRowAtIndexPath:以肯定contentSize及Cell的位置，而後纔會調用 tableView:cellForRowAtIndexPath:，從而來顯示在當前屏幕的Cell。web

舉個例子來講：若是如今要顯示 100個Cell，當前屏幕顯示5個。那麼刷新（reload）UITableView時，UITableView會先調用100次 tableView:heightForRowAtIndexPath:方法，而後調用5次 tableView:cellForRowAtIndexPath:方法；滾動屏幕時，每當Cell滾入屏幕，都會調用一次 tableView:heightForRowAtIndexPath:、tableView:cellForRowAtIndexPath:方法。數組

看到這裏，想必大夥也都能隱約察覺到，UITableView優化的首要任務是要優化上面兩個回調方法。事實也確實如此，下面按照我探討進階的過程，來研究如何優化：緩存

優化探索，項目拿到手時代碼是這樣：網絡

 
         - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { 
        
         ContacterTableCell *cell = [tableView dequeueReusableCellWithIdentifier:@ 
         "ContacterTableCell" 
         ]; 
        
         if  
         (!cell) { 
        
         cell = (ContacterTableCell *)[[[NSBundle mainBundle] loadNibNamed:@ 
         "ContacterTableCell"  
         owner:self options:nil] lastObject]; 
        
         } 
        
         NSDictionary *dict = self.dataList[indexPath.row]; 
        
         [cell setContentInfo:dict]; 
        
         return  
         cell; 
        
         } 
        
         - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { 
        
         UITableViewCell *cell = [tableView cellForRowAtIndexPath:indexPath]; 
        
         return  
         cell.frame.size.height; 
        
         }

看到這段代碼，對於剛畢業的我來講，以爲仍是蠻巧妙的，但巧歸巧，當Cell很是複雜的時候，直接卡出翔了。。。特別是在個人Touch4上，這我能忍？！好吧，依據上面UITableView原理的分析，咱們先來分析它爲何卡？異步

這樣寫，在Cell賦值內容的時候，會根據內容設置佈局，固然也就能夠知道Cell的高度，想一想若是1000行，那就會調用1000+頁面Cell個數次 tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath方法，而咱們對Cell的處理操做，都是在這個方法裏的！什麼賦值、佈局等等。開銷天然很大，這種方案Pass。。。改進代碼。async

改進代碼後：

 
         - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { 
        
         NSDictionary *dict = self.dataList[indexPath.row]; 
        
         return  
         [ContacterTableCell cellHeightOfInfo:dict]; 
        
         }

思路是把賦值和計算佈局分離。這樣讓tableView:cellForRowAtIndexPath:方法只負責賦值，tableView:heightForRowAtIndexPath:方法只負責計算高度。注意：兩個方法儘量的各司其職，不要重疊代碼！二者都須要儘量的簡單易算。Run一下，會發現UITableView滾動流暢了不少。。。

基於上面的實現思路，咱們能夠在得到數據後，直接先根據數據源計算出對應的佈局，並緩存到數據源中，這樣在tableView:heightForRowAtIndexPath:方法中就直接返回高度，而不須要每次都計算了。

 
         - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { 
        
         NSDictionary *dict = self.dataList[indexPath.row]; 
        
         CGRect rect = [dict[@ 
         "frame" 
         ] CGRectValue]; 
        
         return  
         rect.frame.height; 
        
         }

其實上面的改進方法並非最佳方案，但基本能知足簡單的界面！記得開頭個人任務嗎？像朋友圈那樣的圖文混排，這種方案仍是扛不住的！咱們須要進入更深層次的探究：自定義Cell的繪製。

咱們在Cell上添加系統控件的時候，實質上系統都須要調用底層的接口進行繪製，當咱們大量添加控件時，對資源的開銷也會很大，因此咱們能夠索性直接繪製，提升效率。是否是說的很抽象？廢話很少說，直接上代碼：

首先須要給自定義的Cell添加draw方法，（固然也能夠重寫drawRect）而後在方法體中實現：

 
         //異步繪製 
        
         dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ 
        
         CGRect rect = [_data[@ 
         "frame" 
         ] CGRectValue]; 
        
         UIGraphicsBeginImageContextWithOptions(rect.size, YES, 0); 
        
         CGContextRef context = UIGraphicsGetCurrentContext(); 
        
         //整個內容的背景 
        
         [[UIColor colorWithRed:250/255.0 green:250/255.0 blue:250/255.0 alpha:1] set]; 
        
         CGContextFillRect(context, rect); 
        
         //轉發內容的背景 
        
         if  
         ([_data valueForKey:@ 
         "subData" 
         ]) { 
        
         [[UIColor colorWithRed:243/255.0 green:243/255.0 blue:243/255.0 alpha:1] set]; 
        
         CGRect subFrame = [_data[@ 
         "subData" 
         ][@ 
         "frame" 
         ] CGRectValue]; 
        
         CGContextFillRect(context, subFrame); 
        
         [[UIColor colorWithRed:200/255.0 green:200/255.0 blue:200/255.0 alpha:1] set]; 
        
         CGContextFillRect(context, CGRectMake(0, subFrame.origin.y, rect.size.width, .5)); 
        
         } 
        
         { 
        
         //名字 
        
         float leftX = SIZE_GAP_LEFT+SIZE_AVATAR+SIZE_GAP_BIG; 
        
         float x = leftX; 
        
         float y = (SIZE_AVATAR-(SIZE_FONT_NAME+SIZE_FONT_SUBTITLE+6))/2-2+SIZE_GAP_TOP+SIZE_GAP_SMALL-5; 
        
         [_data[@ 
         "name" 
         ] drawInContext:context withPosition:CGPointMake(x, y) andFont:FontWithSize(SIZE_FONT_NAME) 
        
         andTextColor:[UIColor colorWithRed:106/255.0 green:140/255.0 blue:181/255.0 alpha:1] 
        
         andHeight:rect.size.height]; 
        
         //時間+設備 
        
         y += SIZE_FONT_NAME+5; 
        
         float fromX = leftX; 
        
         float size = [UIScreen screenWidth]-leftX; 
        
         NSString *from = [NSString stringWithFormat:@ 
         "%@  %@" 
         , _data[@ 
         "time" 
         ], _data[@ 
         "from" 
         ]]; 
        
         [from drawInContext:context withPosition:CGPointMake(fromX, y) andFont:FontWithSize(SIZE_FONT_SUBTITLE) 
        
         andTextColor:[UIColor colorWithRed:178/255.0 green:178/255.0 blue:178/255.0 alpha:1] 
        
         andHeight:rect.size.height andWidth:size]; 
        
         } 
        
         //將繪製的內容以圖片的形式返回，並調主線程顯示 
        
         UIImage *temp = UIGraphicsGetImageFromCurrentImageContext(); 
        
         UIGraphicsEndImageContext(); 
        
         dispatch_async(dispatch_get_main_queue(), ^{ 
        
         if  
         (flag==drawColorFlag) { 
        
         postBGView.frame = rect; 
        
         postBGView.image = nil; 
        
         postBGView.image = temp; 
        
         } 
        
         } 
        
         //內容若是是圖文混排，就添加View，用CoreText繪製 
        
         [self drawText]; 
        
         }}

上述代碼只貼出來部分功能，但大致的思路都是同樣的，各個信息都是根據以前算好的佈局進行繪製的。這裏是須要異步繪製，但若是在重寫drawRect方法就不須要用GCD異步線程了，由於drawRect原本就是異步繪製的。對於圖文混排的繪製，能夠移步Google，研究下CoreText，這塊內容太多了，不便展開。

好了，至此，咱們又讓UITableView的效率提升了一個等級！但咱們的步伐還遠遠不止這些，下面咱們還能夠從UIScrollView的角度出發，再次找到突破口。

滑動UITableView時，按需加載對應的內容

直接上代碼：

 
         //按需加載 - 若是目標行與當前行相差超過指定行數，只在目標滾動範圍的先後指定3行加載。 
        
         - (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset{ 
        
         NSIndexPath *ip = [self indexPathForRowAtPoint:CGPointMake(0, targetContentOffset->y)]; 
        
         NSIndexPath *cip = [[self indexPathsForVisibleRows] firstObject]; 
        
         NSInteger skipCount = 8; 
        
         if  
         (labs(cip.row-ip.row)>skipCount) { 
        
         NSArray *temp = [self indexPathsForRowsInRect:CGRectMake(0, targetContentOffset->y, self.width, self.height)]; 
        
         NSMutableArray *arr = [NSMutableArray arrayWithArray:temp]; 
        
         if  
         (velocity.y<0) { 
        
         NSIndexPath *indexPath = [temp lastObject]; 
        
         if  
         (indexPath.row+33) { 
        
         [arr addObject:[NSIndexPath indexPathForRow:indexPath.row-3 inSection:0]]; 
        
         [arr addObject:[NSIndexPath indexPathForRow:indexPath.row-2 inSection:0]]; 
        
         [arr addObject:[NSIndexPath indexPathForRow:indexPath.row-1 inSection:0]]; 
        
         } 
        
         } 
        
         [needLoadArr addObjectsFromArray:arr]; 
        
         } 
        
         }

記得在tableView:cellForRowAtIndexPath:方法中加入判斷：

 
         if  
         (needLoadArr.count>0&&[needLoadArr indexOfObject:indexPath]==NSNotFound) { 
        
         [cell clear]; 
        
         return 
         ; 
        
         }

滾動很快時，只加載目標範圍內的Cell，這樣按需加載，極大的提升流暢度。

寫了這麼多，也差很少該來個總結了！UITableView的優化主要從三個方面入手：

提早計算並緩存好高度（佈局），由於heightForRowAtIndexPath:是調用最頻繁的方法；
異步繪製，遇到複雜界面，遇到性能瓶頸時，可能就是突破口；
滑動時按需加載，這個在大量圖片展現，網絡加載的時候很管用！（SDWebImage已經實現異步加載，配合這條性能槓槓的）。

除了上面最主要的三個方面外，還有不少幾乎大夥都很熟知的優化點：

正確使用reuseIdentifier來重用Cells
儘可能使全部的view opaque，包括Cell自身
儘可能少用或不用透明圖層
若是Cell內現實的內容來自web，使用異步加載，緩存請求結果
減小subviews的數量
在heightForRowAtIndexPath:中儘可能不使用cellForRowAtIndexPath:，若是你須要用到它，只用一次而後緩存結果
儘可能少用addView給Cell動態添加View，能夠初始化時就添加，而後經過hide來控制是否顯示

尾巴

肯定不少人會很是好奇，爲何我都是手動用代碼建立Cell的？如今主流不都是Xib、Storyboard什麼的嘛？個人回答是：要想提升效率，仍是手動寫有用！拋開Xib、Storyboard須要系統自動轉碼，給系統多加了一層負擔不談，自定義Cell的繪製更是無從下手，因此，在我看來，複雜的須要高效的界面，仍是手動寫代碼吧！！！

最後若是大家的項目都是用的Xib、Storyboard，並須要優化UITableView的話，sunnyxx大神提出了好的方案：http://blog.sunnyxx.com/2015/05/17/cell-height-calculation/ 大夥能夠自行研究研究。

知識是須要不斷學習的，做爲剛上路的我，若是有什麼理解不到位的，歡迎大夥留言指正，若是你有什麼更牛逼的想法，但願一塊兒交流交流。

註明：本篇的分析源碼來源於開源項目VVeboTableViewDemo

參考：https://github.com/johnil/VVeboTableViewDemo

本人附註：coreText 是底層的文字圖片處理技術，能夠對富文本進行復雜的排版，將更高地提高性能，能夠參考巧哥的這篇文章：

http://blog.devtang.com/blog/2015/06/27/using-coretext-1/