建了一個面試題解答的項目，大家可以看一看，希望大家?guī)兔o一個star，謝謝了！?

項目地址：https://github.com/NotFound9/interviewGuide?

在使用過程中發(fā)現(xiàn)，我們App的首頁在快速滑動時會出現(xiàn)掉幀，以及在上拉加載更多時會抖動，因為首頁模塊是以前的同事寫的，很多代碼已不適應(yīng)當(dāng)前的需求，所以產(chǎn)生了優(yōu)化的想法，優(yōu)化主要分為以下幾個方面：

1.緩存cell高度（發(fā)現(xiàn)了一種計算Label高度的新方法）

2.優(yōu)化cellForRow方法

3.圖片加載優(yōu)化

4.禁止tableView預(yù)估高度

5.刪除無用數(shù)據(jù)處理邏輯

緩存cell高度

在Feed流中，UITableViewCell的高度通常是變化的，需要根據(jù)返回的數(shù)據(jù)中的cell類型以及l(fā)abel的文字長度來計算高度，而在UITableView中func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell

是一個高頻調(diào)用的方法，為了減少CPU的計算，盡可能減少掉幀，所以需要將高度進(jìn)行緩存，在我們的項目中，首頁的數(shù)據(jù)是這樣一個操作流程后臺返回的JSON->FeedListModel->FeedsModel->各種cell的ViewModel(例如小圖片的cell對應(yīng)的model-SmallImageCellViewModel，大圖片的cell對應(yīng)的-BigImageCellViewModel)FeedListModel主要是包含了一些頁碼信息和FeedsModel數(shù)組FeedsModel儲存著后臺返回的cell所需的信息BigImageCellViewModel是cell對FeedsModel進(jìn)行處理后得到cell所需的信息

優(yōu)化以前，我們的高度是通過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屬性，所以一開始我也是把計算屬性改成存儲屬性了，但是還是很耗時（后來才發(fā)現(xiàn)是因為高度是存在BigImageCellViewModel中的，而每次數(shù)據(jù)更新后，由于業(yè)務(wù)需要會對當(dāng)前的列表數(shù)據(jù)重新遍歷處理，生成新的BigImageCellViewModel，新的BigImageCellViewModel的高度自然是每次需要計算），在使用instruments分析時發(fā)現(xiàn)，在加載數(shù)據(jù)時，1s內(nèi)有20%的時候是用于計算每個cell的高度，因為計算cell高度時需要根據(jù)model.title確定cell中的標(biāo)題Label顯示幾行，從而確定Label的高度，進(jìn)而算出cell的高度，而計算Label高度一般都是使用這個方法，

@available(iOS 7.0, *)

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

因為即便是同一個字符串，字體大小一樣，字體不同時，高度會不一定一樣，這個方法會根據(jù)字符串和對應(yīng)字體進(jìn)行繪制計算后得到的高度，而且這個操作是在主線程進(jìn)行的，所以會導(dǎo)致掉幀，然后我就網(wǎng)上查閱資料怎么優(yōu)化這個方法，網(wǎng)上這方面的資料比較少因為這個方法的耗時本身是可接受范圍以內(nèi)的，只是我們的height沒有真正緩存上導(dǎo)致這個方法測試時特別耗時，這種思路是思路一在子線程中調(diào)用這個方法，然后對height進(jìn)行賦值，類似于這樣：

思路一 異步計算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賦一個概率最大的值，然后通過異步計算后，得到一個準(zhǔn)確值，再給height賦值上，但是在實際測試中發(fā)現(xiàn)，大部分cell取的是我們預(yù)設(shè)的高度默認(rèn)值，這樣在下次reloadData時，cell的高度會取算出來的值，然后會導(dǎo)致tableView的contentSize變化，視圖抖動然后我就自己思考，其實我們的標(biāo)題并不復(fù)雜，大部分是中文，其他是數(shù)字，標(biāo)點符號，字母，然后我就測試了一下在UIFont.boldSystemFont(ofSize: 16)下，中文，數(shù)字，標(biāo)點符號，字母的大小，然后測試發(fā)現(xiàn)中文 15pt 數(shù)字是8pt左右，主要的一些標(biāo)點符號16pt 小寫字母大概8pt，大寫自貿(mào)銀11pt，就想能不能通過對標(biāo)題字符串進(jìn)行遍歷，判斷字符的類型來計算標(biāo)題的總寬度，之后再將總寬度除以標(biāo)題的最大寬度得到行數(shù)，然后計算得出cell高度，代碼如下：

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

-(CGFloat)calculateTotalWidthInBold16 {

?? CGFloat totalWidth = 0;

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

? ? ?? unichar character? = [self characterAtIndex:i];

? ? ?? //中 占15pt 數(shù)字 占7 英文 a 8.2 A 10.1 B 10.6 ， ? 16.6pt

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

? ? ? ? ?? totalWidth += 8;

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

? ? ? ? ?? totalWidth += 10;

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

? ? ? ? ?? totalWidth += 12;

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

? ? ? ? ?? totalWidth += 17;

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

? ? ? ? ?? totalWidth += 15;

? ? ?? } else {

? ? ? ? ?? totalWidth += 15;

? ? ?? }

?? }

?? return totalWidth + 5;

}

在不緩存高度的情況下，這個方法能夠很快得計算出高度，讓tableview達(dá)到平均55幀以上的幀率，但是缺點是需要對使用的字體下進(jìn)行測試，在UIFont.boldSystemFont(ofSize: 16)字體下，中文是固定的15pt，但是數(shù)字，小寫字母，大寫字母的長度不是固定的，所以如果需要做到非常準(zhǔn)確，需要對每個數(shù)字，字母在這個字體下的長度進(jìn)行測試。

在緩存高度的情況下，與boundingRect方法相比，這個方法也能夠提高計算速度，只是收益不那么明顯

優(yōu)化cellForRow方法

因為tableView的cellForRow方法也是一個調(diào)用頻率特別高的方法，所以應(yīng)該避免在cellForRow對cell進(jìn)行約束修改，frame變化等操作，? ??

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

主要是把這部分代碼注釋掉了，這部分操作主要是為了隱藏最后一個cell的分割線，但是我們是預(yù)加載的，其實很少能看到最后一個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

圖片加載優(yōu)化

主要使用charles進(jìn)行抓包，看項目有沒有加載比較大的圖片，我們項目首頁的三張圖片的資訊使用的是大圖，一張圖片長達(dá)4M,所以我改成小圖了

禁止tableView預(yù)估高度

因為tableView會根據(jù)estimatedRowHeight*行數(shù)來計算contentSize，并且在滑動時進(jìn)行修正，所以會發(fā)生抖動，所以可以通過以下代碼，禁用預(yù)估高度，因為iOS11以后預(yù)估高度的值不為0，所以需要顯式賦值為0? ?

? ? ? ?tableView.estimatedRowHeight = 0

? ? ?? tableView.estimatedSectionHeaderHeight = 0

? ? ?? tableView.estimatedSectionFooterHeight = 0

刪除無用數(shù)據(jù)處理邏輯

主要注釋了代碼中沒有用的數(shù)據(jù)處理邏輯

總結(jié)

以上其實只是針對我們項目一些比較基本的優(yōu)化的地方，當(dāng)然還有很多地方可以進(jìn)行優(yōu)化，例如將cell中view的布局進(jìn)行緩存，減少不必要的計算，還有將一些Label通過異步渲染的方式繪制在cell中，減少view的層級，將一部分渲染的工作放在子線程中，但是這樣會對我們的項目改動過大，所以暫時沒有采用