遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？TableView的性能優化

Table cell中包含圖片的情況時。
實際上只要針對性地優化一下，這種問題就不會有了。有興趣的可以看看 LazyTableImages這個官方的例子程序，雖然也要從網上下載圖片並顯示，但滾動時絲毫不卡。

——我看了LazyTableImages這個例子，讓我印象深刻的是下方這段代碼：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = nil;

    NSUInteger nodeCount = self.entries.count;

    if (nodeCount == 0 && indexPath.row == 0)
    {
        // add a placeholder cell while waiting on table data
        cell = [tableView dequeueReusableCellWithIdentifier:PlaceholderCellIdentifier forIndexPath:indexPath];
    }
    else
    {
        cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

        // Leave cells empty if there's no data yet
        if (nodeCount > 0)
        {
            // Set up the cell representing the app
            AppRecord *appRecord = (self.entries)[indexPath.row];

            cell.textLabel.text = appRecord.appName;
            cell.detailTextLabel.text = appRecord.artist;

            // Only load cached images; defer new downloads until scrolling ends
            if (!appRecord.appIcon)
            {
                if (self.tableView.dragging == NO && self.tableView.decelerating == NO)
                {
                    [self startIconDownload:appRecord forIndexPath:indexPath];
                }
                // if a download is deferred or in progress, return a placeholder image
                cell.imageView.image = [UIImage imageNamed:@"Placeholder.png"];                
            }
            else
            {
               cell.imageView.image = appRecord.appIcon;
            }
        }
    }

    return cell;
}

重要的兩個註釋：
// Only load cached images; defer new downloads until scrolling ends
// if a download is deferred or in progress, return a placeholder image

1、上方這個註釋我們可以翻譯爲。只加載緩衝好的圖片，新的下載直到scrolling end，就是上拉下拉結束以後纔去進行下載圖片然後刷新

即：
if (self.tableView.dragging == NO && self.tableView.decelerating == NO)
{
[self startIconDownload:appRecord forIndexPath:indexPath];
}

2、使用不透明視圖。

（我們可以用instrument工具進行測試，在半透明的情況下是一堆綠色的，app需要消耗性能去渲染，所以不透明是最好的）
不透明的視圖可以極大地提高渲染的速度。因此如非必要，可以將table cell及其子視圖的opaque屬性設爲YES（默認值）。
其中的特例包括背景色，它的alpha值應該爲1（例如不要使用clearColor）；圖像的alpha值也應該爲1，或者在畫圖時設爲不透明。

3、不要重複創建不必要的table cell。

前面說了，UITableView只需要一屏幕的UITableViewCell對象即可。因此在cell不可見時，可以將其緩存起來，而在需要時繼續使用它即可。
而UITableView也提供了這種機制，只需要簡單地設置一個identifier即可：

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

值得一提的是，cell被重用時，它內部繪製的內容並不會被自動清除，因此你可能需要調用setNeedsDisplayInRect:或setNeedsDisplay方法。
此外，在添加table cell的時候，如果不需要動畫效果，最好不要使用insertRowsAtIndexPaths:withRowAnimation:方法，而是直接調用reloadData方法。因爲前者會對所有indexPaths調用tableView:cellForRowAtIndexPath:方法，即便該 cell並不需要顯示（不知道是不是bug），這就可能創建大量多餘的cell。勘誤：只是在模擬器上測試如此，真機調試時沒有這種bug。

4、減少視圖的數目。

UITableViewCell包含了textLabel、detailTextLabel和imageView等view，而你還可以自定義一些視圖放在它的contentView裏。然而view是很大的對象，創建它會消耗較多資源，並且也影響渲染的性能。
如果你的table cell包含圖片，且數目較多，使用默認的UITableViewCell會非常影響性能。奇怪的是，使用自定義的view，而非預定義的view，明顯會快些。
當然，最佳的解決辦法還是繼承UITableViewCell，並在其drawRect:中自行繪製：

- (void)drawRect:(CGRect)rect { 
    if(image) { 
        [image drawAtPoint:imagePoint]; 
    } else {
        [placeHolder drawAtPoint:imagePoint]; 
    } 
    [text drawInRect:textRectwithFont:fontlineBreakMode:UILineBreakModeTailTruncation];
     }

不過這樣一來，你會發現選中一行後，這個cell就變藍了，其中的內容就被擋住了。最簡單的方法就是將cell的selectionStyle屬性設爲UITableViewCellSelectionStyleNone，這樣就不會被高亮了。
此外還可以創建CALayer，將內容繪製到layer上，然後對cell的contentView.layer調用addSublayer:方法。這個例子中，layer並不會顯著影響性能，但如果layer透明，或者有圓角、變形等效果，就會影響到繪製速度了。解決辦法可參見後面的預渲染圖像。

5、不要做多餘的繪製工作。

在實現drawRect:的時候，它的rect參數就是需要繪製的區域，這個區域之外的不需要進行繪製。
例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判斷是否需要繪製image和text，然後再調用繪製方法。

6、預渲染圖像。

你會發現即使做到了上述幾點，當新的圖像出現時，仍然會有短暫的停頓現象。解決的辦法就是在bitmap context裏先將其畫一遍，導出成UIImage對象，然後再繪製到屏幕，詳細做法可見《利用預渲染加速iOS設備的圖像顯示》。

7、不要阻塞主線程。

做到前幾點後，你的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 *)cellforRowAtIndexPath:(NSIndexPath *)indexPath { 
    if (count - indexPath.row < 10&& !updating) { 
        updating = YES; 
    } 
}
// update方法獲取到結果後，設置updating爲NO

還有一點要注意的就是當圖片下載完成後，如果cell是可見的，還需要更新圖像：

NSArray *indexPaths = [self.tableViewindexPathsForVisibleRows];
for (NSIndexPath *visibleIndexPath in indexPaths) {
    if (indexPath == visibleIndexPath) {
         MyTableViewCell *cell = (MyTableViewCell*)[self.tableView cellForRowAtIndexPath:indexPath]; 
        [cell setNeedsDisplayInRect:imageRect]; 
    } 
}// 也可不遍歷，直接與頭尾相比較，看是否在中間即可。

最後還是前面所說過的insertRowsAtIndexPaths:withRowAnimation:方法，插入新行需要在主線程執行，而一次插入很多行的話（例如50行），會長時間阻塞主線程。而換成reloadData方法的話，瞬間就處理完了。

總結：

遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？

可能造成tableView卡頓的原因有：
1.最常用的就是cell的重用，註冊重用標識符

如果不重用cell時，每當一個cell顯示到屏幕上時，就會重新創建一個新的cell；
如果有很多數據的時候，就會堆積很多cell。
如果重用cell，爲cell創建一個ID，每當需要顯示cell 的時候，都會先去緩衝池中尋找可循環利用的cell，如果沒有再重新創建cell

2.避免cell的重新佈局

cell的佈局填充等操作 比較耗時，一般創建時就佈局好
如可以將cell單獨放到一個自定義類，初始化時就佈局好

3.提前計算並緩存cell的屬性及內容

當我們創建cell的數據源方法時，編譯器並不是先創建cell 再定cell的高度而是先根據內容一次確定每一個cell的高度，高度確定後，再創建要顯示的cell，滾動時，每當cell進入憑虛都會計算高度，提前估算高度告訴編譯器，編譯器知道高度後，緊接着就會創建cell，這時再調用高度的具體計算方法，這樣可以方式浪費時間去計算顯示以外的cell

4.減少cell中控件的數量

儘量使cell得佈局大致相同，不同風格的cell可以使用不用的重用標識符，初始化時添加控件，
不適用的可以先隱藏

5.不要使用ClearColor，無背景色，透明度也不要設置爲0

渲染耗時比較長

6.使用局部更新

如果只是更新某組的話，使用reloadSection進行局部更新

7.加載網絡數據，下載圖片，使用異步加載，並緩存

8.少使用addView 給cell動態添加view

9.按需加載cell，cell滾動很快時，只加載範圍內的cell

10.不要實現無用的代理方法，tableView只遵守兩個協議

11.緩存行高：estimatedHeightForRow不能和HeightForRow裏面的layoutIfNeed同時存在，這兩者同時存在纔會出現“竄動”的bug。所以我的建議是：只要是固定行高就寫預估行高來減少行高調用次數提升性能。如果是動態行高就不要寫預估方法了，用一個行高的緩存字典來減少代碼的調用次數即可

12.不要做多餘的繪製工作。

在實現drawRect:的時候，它的rect參數就是需要繪製的區域，這個區域之外的不需要進行繪製。
例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判斷是否需要繪製image和text，然後再調用繪製方法。

13.預渲染圖像。

當新的圖像出現時，仍然會有短暫的停頓現象。解決的辦法就是在bitmap context裏先將其畫一遍，導出成UIImage對象，然後再繪製到屏幕；

14.使用正確的數據結構來存儲數據。

tableView卡頓解決方案：

1.最常用的就是cell的重用，註冊重用標識符（每當需要顯示cell 的時候，都會先去緩衝池中尋找可循環利用的cell，如果沒有再重新創建cell）

2.減少cell中控件的數量（view是很大的對象，創建它會消耗較多資源，並且也影響渲染的性能。所以不用的不要加上去，不適用的可以先隱藏）

3.少使用addView 給cell動態添加view.

4.使用不透明視圖（半透明情況下app需要消耗性能去渲染，不透明的視圖可以極大地提高渲染的速度）。

5.使用局部更新(如果只是更新某組的話，使用reloadSection進行局部更新)

6.加載網絡數據，下載圖片，使用異步加載，並緩存.

7.不要實現無用的代理方法，tableView只遵守兩個協議.

8.使用正確的數據結構來存儲數據。

9.當處理一些全屏大圖一類的耗資源的操作，可以用預渲染圖像，在bitmap context裏先將其畫一遍，導出成UIImage對象，然後再繪製到屏幕。

黑碼哥

發佈了229 篇原創文章 · 獲贊 832 · 訪問量 38萬+

他的留言板關注

遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？TableView的性能優化

1、上方這個註釋我們可以翻譯爲。只加載緩衝好的圖片，新的下載直到scrolling end，就是上拉下拉結束以後纔去進行下載圖片然後刷新

2、使用不透明視圖。

3、不要重複創建不必要的table cell。

4、減少視圖的數目。

5、不要做多餘的繪製工作。

6、預渲染圖像。

7、不要阻塞主線程。

總結：

遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？

棧--瀏覽器前進後退應用

iOS 14新特性

動態數組、鏈表複雜度

② cocoapods原理及 PodSpec 文件上傳操作

⑤ 遠程私有庫

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？TableView的性能優化

1、上方這個註釋我們可以翻譯爲。只加載緩衝好的圖片，新的下載直到scrolling end，就是上拉下拉結束以後纔去進行下載圖片然後刷新

2、 使用不透明視圖。

3、 不要重複創建不必要的table cell。

4、 減少視圖的數目。

5、 不要做多餘的繪製工作。

6、 預渲染圖像。

7、 不要阻塞主線程。

總結：

遇到tableView卡頓嘛？會造成卡頓的原因大致有哪些？

2、使用不透明視圖。

3、不要重複創建不必要的table cell。

4、減少視圖的數目。

5、不要做多餘的繪製工作。

6、預渲染圖像。

7、不要阻塞主線程。