UITableView性能提升和優(yōu)化(第3章)之二

接上一篇翻譯的內(nèi)容。

創(chuàng)新互聯(lián)建站長期為超過千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為黃陵企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計、網(wǎng)站制作，黃陵網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

再次運行測試

在重用cell之后，你可以再一次測試滾動性能。從表格3-3可以看出，在你正確重用cell之后，性能提升了一倍。

UITableView性能提升和優(yōu)化(第3章) 之二

表格 3-3 重用cell之后測試的結(jié)果

結(jié)果顯示你的做法是正確的；但是，現(xiàn)在的性能依然不夠好。你總是想讓性能上升至0.6666-0.0001左右；對于一個標(biāo)準的UITableViewCell這是一個正常的性能，就像在第一部分展示的那樣。所以下一部分將要學(xué)習(xí)如何重用p_w_picpaths，而不是每次調(diào)用的時候都創(chuàng)建一個新的p_w_picpath。

這就是你為什么要重用cell的原因。對于OS來說，創(chuàng)建和加載一個新的cell到內(nèi)存中，都是要花費時間和內(nèi)存資源的。這就是為什么tableview總是queue 一個cell進行重用，無論這個cell是否在屏幕之外。如果你重用cell，OS就不需要創(chuàng)建一個新的cell來顯示；它只需要獲取舊的cell，改變一些屬性，然后重新顯示這個cell。這個過程比OS創(chuàng)建一個新的cell要快的多。

重用圖片

顯示圖片的主要問題在于加載的時間，要么通過文件系統(tǒng)IO，要么通過網(wǎng)絡(luò)IO，都是非常耗時的。這個加載過程同樣會影響到滾動性能，當(dāng)iOS不能返回cell來渲染UI時。

由于這個原因，請參考ReuseImageViewController這個給工程。首先我解釋一下在這些例子中，我為什么沒有使用[UIImage p_w_picpathd:@""]。p_w_picpathNamed做了一項非常重要的工作：它會在內(nèi)存中緩存圖片，當(dāng)你再次訪問的時候會重用它。使用這個方法的問題是它只能從bundle中獲取文件 --- 換句話說，圖片只能和app的源代碼放在一起。通常，你必須調(diào)用方法[UIImage alloc] initWithContentsOfFile:@""]；或者[UIImage alloc] initWithData:data]]。調(diào)用這些方法，OS不會自動的在內(nèi)存中緩存圖片。

所以，我希望你通過一個小的dictionary在內(nèi)存中存儲圖片，來自己緩存圖片(請看第4章)。另外一個圖片處理非常重要的部分是多線程(請看第6章)。使用這個技術(shù)，你可以把耗時的的處理任務(wù)放到當(dāng)前線程之外。在我的當(dāng)前例子中，不會使用多線程，因為你必須立即了解很多新的概念。在本章結(jié)束的時候，你應(yīng)該自己做完這個練習(xí)。

這是在NSDictionary緩存圖片的主要代碼(請不要使用這種方式存儲圖片，因為它會導(dǎo)致內(nèi)存警告)。

// Code to store the p_w_picpath in the dictionary- (UIImage *)p_w_picpathWithName:(NSString *)name {

if ([self.p_w_picpathDictionary objectForKey:name]) {return [self.p_w_picpathDictionary objectForKey:name];

}

UIImage *p_w_picpath = [[UIImage alloc] initWithContentsOfFile:name];[self.p_w_picpathDictionary setObject:p_w_picpath forKey:name];
return p_w_picpath;

}

下面這個是提取最近一次圖片的主要代碼。

// Customize the appearance of table view cells.
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *CellIdentifier = @"CellIdentifier";

ReuseTableViewCell *cell = (ReuseTableViewCell *) [selfgetCellWithTableView:tableView cellIdentifier:CellIdentifier nibName:@"ReuseTableViewCell"];

NSString *avatarFile = [NSString stringWithFormat:@"a0"];
NSString *avatarName = [[NSBundle mainBundle] pathForResource:avatarFile ofType:@"jpeg"];

cell.avatar.p_w_picpath = [self p_w_picpathWithName:avatarName];

cell.userName.text = [NSString stringWithFormat:@"hi here: %d", indexPath.row];// Configure the cell.

return cell;
}

代碼更新之后，你再運行一下測試。從表格3-4來看，你得到了一個更好的結(jié)果?，F(xiàn)在的平均運行時間是0.002，fps的性能現(xiàn)在接近60。和之前的ReuseTableView相比，你得到了一個更好的性能。

UITableView性能提升和優(yōu)化(第3章) 之二

表格 3-4 在重用圖片之后的測試結(jié)果

好極了！fps現(xiàn)在幾乎是60了，預(yù)加載的時間也降低了。如果你的apps能夠達到這個水平，你不必再擔(dān)心滾動時的性能了；它非常的流暢。通常，對于一個正常的，簡單的里面包含很多subviews的UITableView來說，這已經(jīng)是一個非常好的性能了。這樣是非常好的，因為你不必在開始的時候就做很多工作。如果滾動的性能依然不好，你就必須使用一個更好但是更復(fù)雜的方式來達到同樣的性能。

正如在第1章和第2章提到的，你應(yīng)該總是小心謹慎，避免過度優(yōu)化。為了一個很小的性能優(yōu)化而浪費太多的時間是非常不值得的。因此從這點考慮，如果你的應(yīng)用依然存在滾動性能方面的問題，你應(yīng)該轉(zhuǎn)到第2個例子，它使用到了UITableViewCell的繪制技術(shù)。

減少預(yù)加載時間

通常，我會通過緩存來重用圖片，同時減少初始化的過程。當(dāng)OS需要為TableView渲染一個新的cell，會通過調(diào)用下面的方法來返回一個新的cell：

- (UITableViewCell *)tableView:(UITableView *)tableViewcellForRowAtIndexPath:(NSIndexPath *)indexPath {

// Initialize and return the Cell here

}

因此，如果你在這里阻塞了太長的時間，UserInterface渲染的過程就會被阻塞；它將不能做任何事情或顯示任何新的東西。這就是為什么用戶看到在某個地方滾動停止的原因。

為了使這個過程盡可能的快，你可以去除一些邏輯，延遲計算，通過重用來緩存數(shù)據(jù)和圖片。另外一個方法是通過首先使用默認的圖片和數(shù)據(jù)來重用cell。當(dāng)要獲取圖片或數(shù)據(jù)的時候，你可以使用多線程，然后稍后進行填充。從用戶的角度來看，這種方法將會使得滾動更加流程，加載圖片的速度更快。

第二個例子

當(dāng)你有很多subviews或使用老的設(shè)備，繪制一個自定義的cell能夠提升應(yīng)用程序的性能。對于iPhone4和以后的設(shè)備，有一個非常顯著的性能提升，因此你將會看到繪制自定義cell技術(shù)會有一個很大的不同。

在這個例子中，我會增加cells的復(fù)雜度，這是來自一個真實的應(yīng)用，每一個cell有10個subviews，包括圖片和文件。因此，你會看到很多真實的應(yīng)用(像Facebook，這是我們嘗試模擬的)，滾動性能會被復(fù)雜的subviews結(jié)構(gòu)嚴重影響到。我測試的應(yīng)用有一個類似圖 3-5這樣的一個用戶界面。

UITableView性能提升和優(yōu)化(第3章) 之二