1

我有一個帶有5個選項卡的標籤欄控制器。每個選項卡都有一個表視圖控制器。其中兩個是NSFetchedResultsControllers。NSFetchedResultsController性能問題

每當用戶點擊表格視圖中的項目時,該項目首先被保存到歷史記錄中,然後被搜索並顯示。其中一個NSFetchedResultsControllers顯示按日期排序的已查看項目的歷史記錄。

當沒有這些NSFetchedResultsControllers已經懶洋洋地實例化,性能優良:

13:41:50.485 Saving to history… 
13:41:50.487 CoreData: sql: BEGIN EXCLUSIVE 
13:41:50.490 CoreData: sql: UPDATE ZSLBOOK SET ZDATEADDEDTOHISTORY = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? 
13:41:50.495 CoreData: sql: COMMIT 
13:41:50.511 Saved 

但負責顯示歷史NSFetchedResultsControllers被實例化後,速度得到顯着降低,服用一到兩秒(加上渲染下一個視圖),所以應用程序似乎掛起。

13:42:08.750 Saving to history… 
13:42:08.752 Will change 
13:42:08.753 Object changed 
13:42:09.579 Did change 
13:42:09.594 CoreData: sql: BEGIN EXCLUSIVE 
13:42:09.596 CoreData: sql: UPDATE ZSLBOOK SET ZCOVERIMAGE = ?, ZDATEADDEDTOHISTORY = ?, Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? 
13:42:09.619 CoreData: sql: COMMIT 
13:42:09.637 Saved 

只是讓你知道發生了什麼事情,這是我的更新歷史碼:

- (void)addToHistory 
{ 
    NSLog(@"Saving to history…"); 
    self.book.dateAddedToHistory = [NSDate date]; 
    NSError *error; 
    [self.managedObjectContext save:&error]; 
    NSLog(@"Saved"); 
} 

日誌消息稱爲在這些方法:

controllerWillChangeContent ("Will change") 
controller:didChangeObject ("Object changed") 
controllerDidChangeContent ("Did change") 

的NSFetchedResultsController是標準實施。即使我只有幾行(5-10),表現仍然很緩慢。核心數據是好的(從日誌中可以看到速度非常快),我將批量大小設置爲20,具有索引等。所以問題出在NSFetchedResultsController的某處。

其中一種可能性是將TVC的提取結果控制器委託設置爲零。但是,然後很難管理更新,選擇行並滾動到最後的位置(因爲您需要重新加載數據)。

你有什麼想法可能會導致這個問題?我不相信這個表現是正常的,因爲一個有bazillion行的表被加載並在瞬間顯示。

+0

你有沒有在儀器下運行這個程序,看看在哪裏花費時間?通常它在processChanges通知方法上。 – jrturton 2013-03-27 13:56:31

+0

是的,那是真的,大部分時間都花在postNotificationName:object:userInfo上。它似乎是在後臺重繪和動畫表格。這個子進程花費的時間最多: - [UIView(Hierarchy)layoutBelowIfNeeded]。 – Jonge 2013-03-27 14:22:44

回答

0

通過使用免費的Sensible TableView框架,您完全可以避免使用NSFetchedResultsController。該框架將自動獲取您的數據並將其顯示在表視圖上,包括生成所有詳細視圖UI和關係視圖。根據我的經驗,這比以前使用NSFetchedResultsController更有效率。