[性能優化]UITableView性能優化的一點感悟及計算UILabel高度的新方法

前言 

在使用過程當中發現，咱們App的首頁在快速滑動時會出現掉幀，以及在上拉加載更多時會抖動，由於首頁模塊是之前的同事寫的，不少代碼已不適應當前的需求，因此產生了優化的想法，優化主要分爲如下幾個方面：

• 緩存cell高度（發現了一種計算Label高度的新方法）
  
• 優化cellForRow方法
  
• 圖片加載優化
  
• 禁止tableView預估高度
  
• 刪除無用數據處理邏輯
  

緩存cell高度

在Feed流中，UITableViewCell的高度一般是變化的，須要根據返回的數據中的cell類型以及label的文字長度來計算高度，而在UITableView中func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell

是一個高頻調用的方法，爲了減小CPU的計算，儘量減小掉幀，因此須要將高度進行緩存，在咱們的項目中，首頁的數據是這樣一個操做流程後臺返回的JSON->FeedListModel->FeedsModel->各類cell的ViewModel(例如小圖片的cell對應的model-SmallImageCellViewModel，大圖片的cell對應的-BigImageCellViewModel)FeedListModel主要是包含了一些頁碼信息和FeedsModel數組FeedsModel儲存着後臺返回的cell所需的信息BigImageCellViewModel是cell對FeedsModel進行處理後獲得cell所需的信息

優化之前，咱們的高度是經過BigImageCellViewModel中計算屬性height去獲取的

var height: CGFloat {

      guard let title = title else {

return ((UIScreen.mainWidth - 30) * 9)/16.0 + 62

}

let constraintRect = CGSize(width: UIScreen.mainWidth - 30, height: 38.5)

let attributes = [NSAttributedStringKey.font: UIFont.boldSystemFont(ofSize: 16)]

let rect = title.boundingRect(with: constraintRect,

options: .usesLineFragmentOrigin,

attributes: attributes,

context: nil)

if let type = itemType, type == ItemType.sohuVideo {

return ((UIScreen.mainWidth - 30) * 9)/16.0 + rect.height + 62

}

return ((UIScreen.mainWidth - 30) * 9)/16.0 + rect.height + 62

}

這樣的話每次取值時，會須要經過計算而後返回height屬性，因此一開始我也是把計算屬性改爲存儲屬性了，可是仍是很耗時（後來才發現是由於高度是存在BigImageCellViewModel中的，而每次數據更新後，因爲業務須要會對當前的列表數據從新遍歷處理，生成新的BigImageCellViewModel，新的BigImageCellViewModel的高度天然是每次須要計算），在使用instruments分析時發現，在加載數據時，1s內有20%的時候是用於計算每一個cell的高度，由於計算cell高度時須要根據model.title肯定cell中的標題Label顯示幾行，從而肯定Label的高度，進而算出cell的高度，而計算Label高度通常都是使用這個方法，

@available(iOS 7.0, *)

open func boundingRect(with size: CGSize, options: NSStringDrawingOptions = [], attributes: [NSAttributedString.Key : Any]? = nil, context: NSStringDrawingContext?) -> CGRect

由於即使是同一個字符串，字體大小同樣，字體不一樣時，高度會不必定同樣，這個方法會根據字符串和對應字體進行繪製計算後獲得的高度，並且這個操做是在主線程進行的，因此會致使掉幀，而後我就網上查閱資料怎麼優化這個方法，網上這方面的資料比較少由於這個方法的耗時自己是可接受範圍之內的，只是咱們的height沒有真正緩存上致使這個方法測試時特別耗時，這種思路是思路一在子線程中調用這個方法，而後對height進行賦值，相似於這樣：

思路一 異步計算Label高度

var height：CGFloat = 70

let queue = DispatchQueue.global()

queue.async {

let labelRect = title.boundingRect(with: constraintRect,

options: .usesLineFragmentOrigin,

attributes: attributes,

context: nil)

height = labelRect.height + 50

}

就是經過先給height賦一個機率最大的值，而後經過異步計算後，獲得一個準確值，再給height賦值上，可是在實際測試中發現，大部分cell取的是咱們預設的高度默認值，這樣在下次reloadData時，cell的高度會取算出來的值，而後會致使tableView的contentSize變化，視圖抖動而後我就本身思考，其實咱們的標題並不複雜，大部分是中文，其餘是數字，標點符號，字母，而後我就測試了一下在UIFont.boldSystemFont(ofSize: 16)下，中文，數字，標點符號，字母的大小，而後測試發現中文 15pt 數字是8pt左右，主要的一些標點符號16pt 小寫字母大概8pt，大寫自貿銀11pt，就想能不能經過對標題字符串進行遍歷，判斷字符的類型來計算標題的總寬度，以後再將總寬度除以標題的最大寬度獲得行數，而後計算得出cell高度，代碼以下：

思路二 計算Label高度的新方法 經過遍歷字符串來計算高度

-(CGFloat)calculateTotalWidthInBold16 {

CGFloat totalWidth = 0;

for (int i = 0; i < self.length; i++) {

unichar character = [self characterAtIndex:i];

//中 佔15pt 數字 佔7 英文 a 8.2 A 10.1 B 10.6 ， ? 16.6pt

if ([[NSCharacterSet decimalDigitCharacterSet] characterIsMember:character]) {//數字

totalWidth += 8;

} else if ([[NSCharacterSet lowercaseLetterCharacterSet] characterIsMember:character]) {//小寫字母

totalWidth += 10;

} else if ([[NSCharacterSet uppercaseLetterCharacterSet] characterIsMember:character]) {//大寫字母

totalWidth += 12;

} else if ([[NSCharacterSet punctuationCharacterSet] characterIsMember:character]) {//標點符號

totalWidth += 17;

} else if (character >= 0x4E00 && character <= 0x9FA5) {

totalWidth += 15;

} else {

totalWidth += 15;

}

}

return totalWidth + 5;

}

在不緩存高度的狀況下，這個方法可以很快得計算出高度，讓tableview達到平均55幀以上的幀率，可是缺點是須要對使用的字體下進行測試，在UIFont.boldSystemFont(ofSize: 16)字體下，中文是固定的15pt，可是數字，小寫字母，大寫字母的長度不是固定的，因此若是須要作到很是準確，須要對每一個數字，字母在這個字體下的長度進行測試。

在緩存高度的狀況下，與boundingRect方法相比，這個方法也可以提升計算速度，只是收益不那麼明顯

優化cellForRow方法

由於tableView的cellForRow方法也是一個調用頻率特別高的方法，因此應該避免在cellForRow對cell進行約束脩改，frame變化等操做，

open func cellForRow(at indexPath: IndexPath) -> UITableViewCell? // returns nil if cell is not visible or index path is out of range

主要是把這部分代碼註釋掉了，這部分操做主要是爲了隱藏最後一個cell的分割線，可是咱們是預加載的，其實不多能看到最後一個cell的底部，因此其實沒有必要

default: //feed流

let cellViewModel = viewModel.viewModels.value[indexPath.row]

let cell = configFeedCell(tableView: tableView, cellViewModel: cellViewModel, indexPath: indexPath)

// cell.saHorizontalSpace = (15, 15)

// if viewModel.isInfrontOfFeedSpacAble(indexPath: indexPath) {

// cell.saSeparaptorLineStyle = .bottom

// } else if cellViewModel as? FeedSpacAble != nil {

// cell.saSeparaptorLineStyle = .bottom

// } else {

// cell.saSeparaptorLineStyle = .none

// }

return cell

圖片加載優化

主要使用charles進行抓包，看項目有沒有加載比較大的圖片，咱們項目首頁的三張圖片的資訊使用的是大圖，一張圖片長達4M,因此我改爲小圖了

禁止tableView預估高度

由於tableView會根據estimatedRowHeight*行數來計算contentSize，而且在滑動時進行修正，因此會發生抖動，因此能夠經過如下代碼，禁用預估高度，由於iOS11之後預估高度的值不爲0，因此須要顯式賦值爲0

tableView.estimatedRowHeight = 0

tableView.estimatedSectionHeaderHeight = 0

tableView.estimatedSectionFooterHeight = 0

刪除無用數據處理邏輯

主要註釋了代碼中沒有用的數據處理邏輯

總結

以上其實只是針對咱們項目一些比較基本的優化的地方，固然還有不少地方能夠進行優化，例如將cell中view的佈局進行緩存，減小沒必要要的計算，還有將一些Label經過異步渲染的方式繪製在cell中，減小view的層級，將一部分渲染的工做放在子線程中，可是這樣會對咱們的項目改動過大，因此暫時沒有采用

PS: 最近加了一些iOS開發相關的QQ羣和微信羣，可是感受都比較水，裏面對於技術的討論比較少，因此本身建了一個iOS開發進階討論羣，歡迎對技術有熱情的同窗掃碼加入，加入之後你能夠獲得： 

1.技術方案的討論，會有在大廠工做的高級開發工程師儘量抽出時間給你們解答問題  

2.每週按期會寫一些文章，而且轉發到羣裏，你們一塊兒討論，也鼓勵加入的同窗積極得寫技術文章，提高本身的技術 

3.若是有想進大廠的同窗，裏面的高級開發工程師也能夠給你們內推，而且針對性得給出一些面試建議 

羣已經滿100人了，想要加羣的小夥伴們能夠掃碼加這個微信，備註:「加羣+暱稱」，拉你進羣，謝謝了 ！