UITableView優(yōu)化技巧

轉(zhuǎn)自: longxdragon
最近在微博上看到一個(gè)很好的開(kāi)源項(xiàng)目VVeboTableViewDemo,是關(guān)于如何優(yōu)化UITableView的。加上正好最近也在優(yōu)化項(xiàng)目中的類似朋友圈功能這塊,思考了很多關(guān)于UITableView的優(yōu)化技巧,相信這塊是難點(diǎn)也是痛點(diǎn),所以決定詳細(xì)的整理下我對(duì)優(yōu)化UITableView的理解。
UITableView作為iOS開(kāi)發(fā)中最重要的控件之一,其中的實(shí)現(xiàn)原理很是考究。直接進(jìn)入主題。首先來(lái)談?wù)勎覍?duì)UITableView的認(rèn)識(shí):

UITableView的簡(jiǎn)單認(rèn)識(shí)

  • UITableView最核心的思想就是UITableViewCell的重用機(jī)制。簡(jiǎn)單的理解就是:UITableView只會(huì)創(chuàng)建一屏幕(或一屏幕多一點(diǎn))的UITableViewCell,其他都是從中取出來(lái)重用的。每當(dāng)Cell滑出屏幕時(shí),就會(huì)放入到一個(gè)集合(或數(shù)組)中(這里就相當(dāng)于一個(gè)重用池),當(dāng)要顯示某一位置的Cell時(shí),會(huì)先去集合(或數(shù)組)中取,如果有,就直接拿來(lái)顯示;如果沒(méi)有,才會(huì)創(chuàng)建。這樣做的好處可想而知,極大的減少了內(nèi)存的開(kāi)銷。

  • 知道UITableViewCell的重用原理后,我們來(lái)看看UITableView的回調(diào)方法。UITableView最主要的兩個(gè)回調(diào)方法是
    tableView:cellForRowAtIndexPath:
    tableView:heightForRowAtIndexPath:
    理想上我們是會(huì)認(rèn)為UITableView會(huì)先調(diào)用前者,再調(diào)用后者,因?yàn)檫@和我們創(chuàng)建控件的思路是一樣的,先創(chuàng)建它,再設(shè)置它的布局。但實(shí)際上卻并非如此,我們都知道,UITableView是繼承自UIScrollView的,需要先確定它的contentSize及每個(gè)Cell的位置,然后才會(huì)把重用的Cell放置到對(duì)應(yīng)的位置。所以事實(shí)上,UITableView的回調(diào)順序是先多次調(diào)用tableView:heightForRowAtIndexPath:以確定contentSize及Cell的位置,然后才會(huì)調(diào)用tableView:cellForRowAtIndexPath:,從而來(lái)顯示在當(dāng)前屏幕的Cell.

舉個(gè)例子來(lái)說(shuō):如果現(xiàn)在要顯示100個(gè)Cell,當(dāng)前屏幕顯示5個(gè)。那么刷新(reload)UITableView時(shí), UITableView會(huì)先調(diào)用100次tableView:heightForRowAtIndexPath:方法,然后調(diào)用5次tableView:cellForRowAtIndexPath:方法;滾動(dòng)屏幕時(shí),每當(dāng)Cell滾入屏幕,都會(huì)調(diào)用一次tableView:heightForRowAtIndexPath:.tableView:cellForRowAtIndexPath:方法。

看到這里,想必大伙也都能隱約察覺(jué)到,UITableView優(yōu)化的首要任務(wù)是要優(yōu)化上面兩個(gè)回調(diào)方法。事實(shí)也確實(shí)如此,下面按照我探討進(jìn)階的過(guò)程,來(lái)研究如何優(yōu)化:

1.1 優(yōu)化探索,項(xiàng)目拿到手時(shí)代碼是這樣:

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

當(dāng)Cell非常復(fù)雜的時(shí)候,直接卡出翔了。。。特別是在我的Touch4上,這我能忍?!好吧,依據(jù)上面UITableView原理的分析,我們先來(lái)分析它為什么卡?這樣寫,在Cell賦值內(nèi)容的時(shí)候,會(huì)根據(jù)內(nèi)容設(shè)置布局,當(dāng)然也就可以知道Cell的高度,想想如果1000行,那就會(huì)調(diào)用1000+頁(yè)面Cell個(gè)數(shù)次tableView:(UITableView *)tableViewcellForRowAtIndexPath:(NSIndexPath *)indexPath方法,而我們對(duì)Cell的處理操作,都是在這個(gè)方法里的!什么賦值、布局等等。開(kāi)銷自然很大,這種方案Pass。。。改進(jìn)代碼。

1.2 改進(jìn)代碼后:

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

思路是把賦值和計(jì)算布局分離。這樣讓tableView:cellForRowAtIndexPath:方法只負(fù)責(zé)賦值,tableView:heightForRowAtIndexPath:方法只負(fù)責(zé)計(jì)算高度。注意:兩個(gè)方法盡可能的各司其職,不要重疊代碼!兩者都需要盡可能的簡(jiǎn)單易算。Run一下,會(huì)發(fā)現(xiàn)UITableView滾動(dòng)流暢了很多。。

基于上面的實(shí)現(xiàn)思路,我們可以在獲得數(shù)據(jù)后,直接先根據(jù)數(shù)據(jù)源計(jì)算出對(duì)應(yīng)的布局,并緩存到數(shù)據(jù)源中,這樣在tableView:heightForRowAtIndexPath:方法中就直接返回高度,而不需要每次都計(jì)算了。

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

其實(shí)上面的改進(jìn)方法并不是最佳方案,但基本能滿足簡(jiǎn)單的界面!記得開(kāi)頭我的任務(wù)嗎?像朋友圈那樣的圖文混排,這種方案還是扛不住的!

1.3 我們需要進(jìn)入更深層次的探究:自定義Cell的繪制。

我們?cè)贑ell上添加系統(tǒng)控件的時(shí)候,實(shí)質(zhì)上系統(tǒng)都需要調(diào)用底層的接口進(jìn)行繪制,當(dāng)我們大量添加控件時(shí),對(duì)資源的開(kāi)銷也會(huì)很大,所以我們可以索性直接繪制,提高效率。是不是說(shuō)的很抽象?廢話不多說(shuō),直接上代碼:

首先需要給自定義的Cell添加draw方法,(當(dāng)然也可以重寫drawRect)然后在方法體中實(shí)現(xiàn):

 //異步繪制

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
      CGRect rect = [_data[@"frame"] CGRectValue];    
      UIGraphicsBeginImageContextWithOptions(rect.size, YES, 0);    
      CGContextRef context = UIGraphicsGetCurrentContext(); 
     //整個(gè)內(nèi)容的背景
      [[UIColor colorWithRed:250/255.0 green:250/255.0 blue:250/255.0 alpha:1] set]; 
       CGContextFillRect(context, rect);

    //轉(zhuǎn)發(fā)內(nèi)容的背景
    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];
 
     //時(shí)間+設(shè)備 
     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]; 
    }

   //將繪制的內(nèi)容以圖片的形式返回,并調(diào)主線程顯示
    UIImage *temp = UIGraphicsGetImageFromCurrentImageContext(); 
    UIGraphicsEndImageContext();    
    dispatch_async(dispatch_get_main_queue(), ^{
      if (flag==drawColorFlag) { 
          postBGView.frame = rect; 
          postBGView.image = nil; 
          postBGView.image = temp; 
     }
 }

//內(nèi)容如果是圖文混排,就添加View,用CoreText繪制 
[self drawText];

上述代碼只貼出來(lái)部分功能,但大體的思路都是一樣的,各個(gè)信息都是根據(jù)之前算好的布局進(jìn)行繪制的。這里是需要異步繪制,但如果在重寫drawRect方法就不需要用GCD異步線程了,因?yàn)?strong>drawRect本來(lái)就是異步繪制的。對(duì)于圖文混排的繪制,可以移步Google,研究下CoreText,這塊內(nèi)容太多了,不便展開(kāi)。
好了,至此,我們又讓UITableView的效率提高了一個(gè)等級(jí)!但我們的步伐還遠(yuǎn)遠(yuǎn)不止這些,下面我們還可以從UIScrollView的角度出發(fā),再次找到突破口。

1.4 滑動(dòng)UITableView時(shí),按需加載對(duì)應(yīng)的內(nèi)容直接上代碼:

 //按需加載 - 如果目標(biāo)行與當(dāng)前行相差超過(guò)指定行數(shù),只在目標(biāo)滾動(dòng)范圍的前后指定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+3<datas.count) {
                      [arr addObject:[NSIndexPath indexPathForRow:indexPath.row+1 inSection:0]]; 
                      [arr addObject:[NSIndexPath indexPathForRow:indexPath.row+2 inSection:0]]; 
                      [arr addObject:[NSIndexPath indexPathForRow:indexPath.row+3 inSection:0]];
                }
          } else { 
          NSIndexPath *indexPath = [temp firstObject]; 
          if (indexPath.row>3) { 
              [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;
  }

滾動(dòng)很快時(shí),只加載目標(biāo)范圍內(nèi)的Cell,這樣按需加載,極大的提高流暢度。

1.5 寫了這么多,也差不多該來(lái)個(gè)總結(jié)了!

  • UITableView的優(yōu)化主要從三個(gè)方面入手:

  • 提前計(jì)算并緩存好高度(布局),因?yàn)閔eightForRowAtIndexPath:是調(diào)用最頻繁的方法;

  • 異步繪制,遇到復(fù)雜界面,遇到性能瓶頸時(shí),可能就是突破口;

  • 滑動(dòng)時(shí)按需加載,這個(gè)在大量圖片展示,網(wǎng)絡(luò)加載的時(shí)候很管用?。⊿DWebImage已經(jīng)實(shí)現(xiàn)異步加載,配合這條性能杠杠的)。

除了上面最主要的三個(gè)方面外,還有很多幾乎大伙都很熟知的優(yōu)化點(diǎn)

  1. 正確使用reuseIdentifier來(lái)重用Cells
  2. 盡量使所有的view opaque,包括Cell自身
  3. 盡量少用或不用透明圖層
  4. 如果Cell內(nèi)現(xiàn)實(shí)的內(nèi)容來(lái)自web,使用異步加載,緩存請(qǐng)求結(jié)果
  5. 減少subviews的數(shù)量
  6. 在heightForRowAtIndexPath:中盡量不使用cellForRowAtIndexPath:,如果你需要用到它,只用一次然后緩存結(jié)果
  7. 盡量少用addView給Cell動(dòng)態(tài)添加View,可以初始化時(shí)就添加,然后通過(guò)hide來(lái)控制是否顯示

尾巴
肯定很多人會(huì)非常好奇,為什么我都是手動(dòng)用代碼創(chuàng)建Cell的?現(xiàn)在主流不都是Xib、Storyboard什么的嘛?我的回答是:要想提高效率,還是手動(dòng)寫有用!拋開(kāi)Xib、Storyboard需要系統(tǒng)自動(dòng)轉(zhuǎn)碼,給系統(tǒng)多加了一層負(fù)擔(dān)不談,自定義Cell的繪制更是無(wú)從下手,所以,在我看來(lái),復(fù)雜的需要高效的界面,還是手動(dòng)寫代碼吧!??!

注明:本篇的分析源碼來(lái)源于開(kāi)源項(xiàng)目VVeboTableViewDemo
參考:https://github.com/johnil/VVeboTableViewDemo

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容