溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
接上一篇翻譯的內(nèi)容。
再次運行測試
在重用cell之后，你可以再一次測試滾動性能。從表格3-3可以看出，在你正確重用cell之后，性能提升了一倍。
表格 3-3 重用cell之后測試的結果
結果顯示你的做法是正確的；但是，現(xiàn)在的性能依然不夠好。你總是想讓性能上升至0.6666-0.0001左右；對于一個標準的UITableViewCell這是一個正常的性能，就像在第一部分展示的那樣。所以下一部分將要學習如何重用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)絡IO，都是非常耗時的。這個加載過程同樣會影響到滾動性能，當iOS不能返回cell來渲染UI時。
由于這個原因，請參考ReuseImageViewController這個給工程。首先我解釋一下在這些例子中，我為什么沒有使用[UIImage p_w_picpathd:@""]。p_w_picpathNamed做了一項非常重要的工作：它會在內(nèi)存中緩存圖片，當你再次訪問的時候會重用它。使用這個方法的問題是它只能從bundle中獲取文件 --- 換句話說，圖片只能和app的源代碼放在一起。通常，你必須調(diào)用方法[UIImage alloc] initWithContentsOfFile:@""]；或者[UIImage alloc] initWithData:data]]。調(diào)用這些方法，OS不會自動的在內(nèi)存中緩存圖片。
所以，我希望你通過一個小的dictionary在內(nèi)存中存儲圖片，來自己緩存圖片(請看第4章)。另外一個圖片處理非常重要的部分是多線程(請看第6章)。使用這個技術，你可以把耗時的的處理任務放到當前線程之外。在我的當前例子中，不會使用多線程，因為你必須立即了解很多新的概念。在本章結束的時候，你應該自己做完這個練習。
這是在NSDictionary緩存圖片的主要代碼(請不要使用這種方式存儲圖片，因為它會導致內(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來看，你得到了一個更好的結果?，F(xiàn)在的平均運行時間是0.002，fps的性能現(xiàn)在接近60。和之前的ReuseTableView相比，你得到了一個更好的性能。
表格 3-4 在重用圖片之后的測試結果
好極了！fps現(xiàn)在幾乎是60了，預加載的時間也降低了。如果你的apps能夠達到這個水平，你不必再擔心滾動時的性能了；它非常的流暢。通常，對于一個正常的，簡單的里面包含很多subviews的UITableView來說，這已經(jīng)是一個非常好的性能了。這樣是非常好的，因為你不必在開始的時候就做很多工作。如果滾動的性能依然不好，你就必須使用一個更好但是更復雜的方式來達到同樣的性能。
正如在第1章和第2章提到的，你應該總是小心謹慎，避免過度優(yōu)化。為了一個很小的性能優(yōu)化而浪費太多的時間是非常不值得的。因此從這點考慮，如果你的應用依然存在滾動性能方面的問題，你應該轉到第2個例子，它使用到了UITableViewCell的繪制技術。
減少預加載時間
通常，我會通過緩存來重用圖片，同時減少初始化的過程。當OS需要為TableView渲染一個新的cell，會通過調(diào)用下面的方法來返回一個新的cell：
- (UITableViewCell *)tableView:(UITableView *)tableViewcellForRowAtIndexPath:(NSIndexPath *)indexPath {
// Initialize and return the Cell here
}
因此，如果你在這里阻塞了太長的時間，UserInterface渲染的過程就會被阻塞；它將不能做任何事情或顯示任何新的東西。這就是為什么用戶看到在某個地方滾動停止的原因。
為了使這個過程盡可能的快，你可以去除一些邏輯，延遲計算，通過重用來緩存數(shù)據(jù)和圖片。另外一個方法是通過首先使用默認的圖片和數(shù)據(jù)來重用cell。當要獲取圖片或數(shù)據(jù)的時候，你可以使用多線程，然后稍后進行填充。從用戶的角度來看，這種方法將會使得滾動更加流程，加載圖片的速度更快。
第二個例子
當你有很多subviews或使用老的設備，繪制一個自定義的cell能夠提升應用程序的性能。對于iPhone4和以后的設備，有一個非常顯著的性能提升，因此你將會看到繪制自定義cell技術會有一個很大的不同。
在這個例子中，我會增加cells的復雜度，這是來自一個真實的應用，每一個cell有10個subviews，包括圖片和文件。因此，你會看到很多真實的應用(像Facebook，這是我們嘗試模擬的)，滾動性能會被復雜的subviews結構嚴重影響到。我測試的應用有一個類似圖 3-5這樣的一個用戶界面。
圖 3-5 第二個應用例子
每一個cell包含一個頭像，用戶名，郵件的圖片，標題和內(nèi)容。它同時也顯示了應用發(fā)送郵件的時間。測試結果圖表格3-5。
表格3-6顯示了運行自定義繪制代碼的結果
從表格3-5和3-6可以看出，使用自定義繪制代碼能夠顯著的提升渲染性能。在使用復雜的subview這點上，這個性能已經(jīng)足夠好了，你不必需要其他的優(yōu)化了。
對于沒有優(yōu)化的cell，它將會創(chuàng)建很多的components和subviews。請查看圖3-5，確保你理解了這個問題。
暫時翻譯到這里，有時間繼續(xù)！
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內(nèi)容。
