前言
網(wǎng)上看了很久，沒發(fā)現(xiàn)有比我這篇更詳細(xì)的孕荠。
如果學(xué)到或者查到 NSFetchedResultsController，我猜50%大概你已經(jīng)了解到了CoreData到底是有多么強(qiáng)大攻谁，Apple 設(shè)計(jì)了 CoreData 這么一整套這么完美的持久化框架稚伍，在減少代碼量的同時(shí)，也極大程度上提高運(yùn)行效率戚宦。
在我們的日常開發(fā)過程中个曙，使用 Core Data 的時(shí)候經(jīng)常經(jīng)常會(huì)跟 TableView 打交道，為了更好的使得兩者合作更加緊密受楼，Apple 設(shè)計(jì)了 NSFetchedResultsController垦搬。
NSFetchedResultsController 并不是 ViewController 的子類，它僅僅是一個(gè) Controller艳汽，沒有視圖沒有界面猴贰。
為了介紹它的偉大，舉個(gè)例子你有 1000 條數(shù)據(jù)河狐，1000個(gè) Cell 來展示你的那些數(shù)據(jù)米绕。如果你刪除或者更新了一條數(shù)據(jù)，在數(shù)據(jù)庫中就要執(zhí)行相應(yīng)操作馋艺，這個(gè)時(shí)候通過 NSFetchedResultsController 的 Delegate栅干，會(huì)自動(dòng)去更新那一條數(shù)據(jù)的UI，而且不是整體更新捐祠，而是針對那一條數(shù)據(jù)進(jìn)行更新碱鳞，極大的優(yōu)化了執(zhí)行效率。
而這一切踱蛀，你“幾乎”什么都不用做窿给。
NSFetchedResultsController 的簡單用法：
假設(shè)你的類已經(jīng)加入了 CoreDataStack，如果沒有的話看這里
1星岗、數(shù)據(jù)展示
首先需要一個(gè) iVar：
var fetchRequestsController : NSFetchedResultsController!
然后在 ViewDidLoad 或者根據(jù)你項(xiàng)目自己的架構(gòu)或者封裝來初始化：
super.viewDidLoad()
let fetchRequest = NSFetchRequest(entityName: "Team")
//給 FetchRequest 加入排序填大，F(xiàn)etchResultsController 的 FetchRequest 至少需要一個(gè)排序戒洼，不可為空
let sortDesctiptor = NSSortDescriptor(key: "teamName", ascending: true)
fetchRequest.sortDescriptors = [sortDesctiptor]
//FetchResultsController 就像是 CoreData 和 TableView 之間的助手一樣俏橘，但是即便如此還是需要提供FetchRequest。
//初始化方法包含了四個(gè)參數(shù)圈浇，第一個(gè)就是 FetchRequest寥掐，第二個(gè)是上下文 Context靴寂，拿它來 executeFetchRequest，三四個(gè)參數(shù)是Optional召耘，后面會(huì)詳寫百炬。
fetchRequestsController = NSFetchedResultsController(fetchRequest: fetchRequest, managedObjectContext: coreDataStack.context, sectionNameKeyPath: nil, cacheName: nil)
do {
try fetchRequestsController.performFetch()
} catch let error as NSError {
print("Error: \(error.localizedDescription)")
}
ViewDidLoad 之后還需要在 DataSource 中做相應(yīng)配置：
extension ViewController: UITableViewDataSource {
//暫時(shí)先這么寫，后面的一部分回用到 Section count 的相關(guān)污它。
func numberOfSectionsInTableView
(tableView: UITableView) -> Int {
return fetchRequestsController.sections!.count
}
func tableView(tableView: UITableView,
numberOfRowsInSection section: Int) -> Int {
let sectionInfo = fetchRequestsController.sections![section]
return sectionInfo.numberOfObjects
}
func tableView(tableView: UITableView,
cellForRowAtIndexPath indexPath: NSIndexPath)
-> UITableViewCell {
let cell =
tableView.dequeueReusableCellWithIdentifier(
teamCellIdentifier, forIndexPath: indexPath)
as! TeamCell
configureCell(cell, indexPath: indexPath)
return cell
}
func configureCell(cell: TeamCell, indexPath: NSIndexPath) {
let team = fetchRequestsController.objectAtIndexPath(indexPath) as! Team
cell.flagImageView.image = UIImage(named: team.imageName!)
cell.teamLabel.text = team.teamName
cell.scoreLabel.text = "Wins: \(team.wins!)"
}
}
大概看一下 Cell 的 configureCell 方法就根據(jù)實(shí)際項(xiàng)目需求去寫剖踊。
另外我們發(fā)現(xiàn)一般的 FetchRequest 并不是不需要進(jìn)行排序的，但是這個(gè)必須要把 NSSortDescription 傳遞給 fetchRequest.sortDescriptors衫贬，至少需要一個(gè)排序德澈，不可為空。
2固惯、修改數(shù)據(jù)
常規(guī)的修改數(shù)據(jù)就是三步梆造，先拿到數(shù)據(jù)，然后做修改葬毫，然后提交Change镇辉，跟SVN管理代碼一個(gè)邏輯：
extension ViewController: UITableViewDelegate {
func tableView(tableView: UITableView,
didSelectRowAtIndexPath indexPath: NSIndexPath) {
//常規(guī)的修改數(shù)據(jù)就是三步，先拿到數(shù)據(jù)贴捡，然后做修改忽肛，然后提交Change，跟SVN管理代碼一個(gè)邏輯：
let team = fetchRequestsController.objectAtIndexPath(indexPath) as! Team
let wins = team.wins!.integerValue
team.wins = NSNumber(integer: wins+1)
//創(chuàng)建 FRC 的時(shí)候是不是用 coreDataStack.context 創(chuàng)建的嘛烂斋，所以保存還是使用 coreDataStack.context 的這個(gè)方法麻裁。
coreDataStack.saveContext()
tableView.reloadData()
}
}
其實(shí) NSFetchedResultsController 不僅僅便利了查詢數(shù)據(jù)的便捷，這里因?yàn)樗〕鰜淼?Object 也和之前一樣都是 ManagedObject源祈，所以存數(shù)據(jù)也就跟以前一樣煎源。
這里最后使用了 tableView.reloadData() 來強(qiáng)制 UI 刷新。
3香缺、Section分組顯示 -- 初始化的時(shí)候的一個(gè)參數(shù)
在 NSFetchedResultsController 的初始化方法里的第三個(gè)參數(shù)手销，sectionNameKeyPath: 使用它，可以說明按照一個(gè)具體的 KeyPath 指向的屬性可以對 FetchResults 進(jìn)行分組图张。
//初始化方法包含了四個(gè)參數(shù)锋拖，第一個(gè)就是 FetchRequest，第二個(gè)是上下文 Context祸轮，拿它來 executeFetchRequest兽埃，三四個(gè)參數(shù)是Optional，后面會(huì)詳寫适袜。
fetchRequestsController = NSFetchedResultsController(fetchRequest: fetchRequest, managedObjectContext: coreDataStack.context, sectionNameKeyPath: nil, cacheName: nil)
keyPath 所指向的屬性的每一個(gè)結(jié)果值都會(huì)產(chǎn)生一個(gè)分組柄错，比如大家的這個(gè)屬性都一樣的話就是一個(gè) Section，多少種結(jié)果就是多少種 Section。
添加一下 tableView 的 DataSource 方法 titleForHeaderInSection:
func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
let sectionInfo = fetchRequestsController.sections![section]
return sectionInfo.name
}
但是做到這里還是不夠售貌，Section 來分配組的方法僅僅是根據(jù)數(shù)量给猾，也就是說它只是知道前3個(gè)是一組，然后后面4個(gè)是一組颂跨，后面2個(gè)是一組敢伸。也就是說你得自己去實(shí)現(xiàn)排序的邏輯。
然后之前的排序是按照首字母來進(jìn)行的恒削，現(xiàn)在得自己來實(shí)現(xiàn)根據(jù)屬性來排序池颈，這樣做，Section 的數(shù)量和 排序就能對應(yīng)钓丰，就可以實(shí)現(xiàn)根據(jù)特定屬性分組顯示了饶辙。
所以還得去之前聲明 NSSortDescriptor 的地方替換代碼：
把之前寫的下面的代碼：
//給 FetchRequest 加入排序，F(xiàn)etchResultsController 的 FetchRequest 至少需要一個(gè)排序斑粱，不可為空
let sortDesctiptor = NSSortDescriptor(key: "teamName", ascending: true)
fetchRequest.sortDescriptors = [sortDesctiptor]
替換為
let nameSort = NSSortDescriptor(key: "teamName", ascending: true)
let zoneSort = NSSortDescriptor(key: "qualifyingZone", ascending: true)
let scoreSort = NSSortDescriptor(key: "wins", ascending: false)
fetchRequest.sortDescriptors = [zoneSort, scoreSort, nameSort]
這里傳進(jìn)去的是一個(gè)數(shù)組弃揽，這個(gè)數(shù)組的順序就是排序規(guī)則的優(yōu)先級。還有上面的排序規(guī)則则北，ScoreSort 的 ascending 是 false矿微，代表著降序。
4尚揣、分組的優(yōu)化 -- 初始化的時(shí)候的最后一個(gè)參數(shù)
話說回來涌矢，這個(gè)分組并不是一個(gè)低功耗的算法，還是會(huì)把每一個(gè)元素都循環(huán)遍歷一遍快骗。
話再回來娜庇，如果你開發(fā)的程序是對你司2萬名員工的上下班打卡信息的展示，這樣海量數(shù)據(jù)的展示方篮，再用這種方法來進(jìn)行分組可能就會(huì)出現(xiàn)問題名秀。
還記不記得上面初始化 NSFetchedResultsController 的時(shí)候一共有四個(gè)參數(shù)，其實(shí)第四個(gè)的名字叫做 cacheName藕溅，緩存名匕得。你讓 NSFetchedResultsController 開啟在硬盤上的緩存，這個(gè)緩存跟 CoreData 中存儲(chǔ)這次展示數(shù)據(jù)的 PersistentStore 是完全分離開的巾表。
其實(shí)哦汁掠，已經(jīng)保存的 Cache 對 FetchRequest 的變動(dòng)非常敏感，比如EntityDescription集币、SortDescriptor 的變動(dòng)都會(huì)給你兩組完全不同的數(shù)據(jù)考阱，數(shù)據(jù)都不同了，cache當(dāng)然也完全不相同了鞠苟。避免這種情況產(chǎn)生乞榨，當(dāng)改變了FetchRequest的這些值秽之，使用方法 deleteCacheWithName: 去刪了Cache，或者用不同的CacheName姜凄。
所以打開緩存其實(shí)很簡單，把第四個(gè)參數(shù)nil趾访，換成具體的String就行了态秧，但是還是慎用。
NSFetchedResultsController 的作用并不針對效率扼鞋，所以更多跟效率有關(guān)的后面再研究申鱼。
5、監(jiān)聽
這部分的東西又是雙刃劍云头，用的好很厲害捐友，用不好就是自殘。
最牛逼的一個(gè)點(diǎn)兒溃槐，就是 NSFetchedResultsController 其實(shí)是可以監(jiān)聽結(jié)果集 resultsSet 的變動(dòng)匣砖，然后做一個(gè)通知，NSFetchedResultsControllerDelegate昏滴，使用這個(gè)Delegate猴鲫。
既然它能監(jiān)聽結(jié)果集的變動(dòng)，那意思就是它能監(jiān)聽任何一個(gè)谣殊，任何它能抓到的對象拂共，就是 fetchRequest 能到達(dá)的地方，它都能監(jiān)聽姻几。
除一種情況宜狐，多重 Context 指向同一個(gè)持久層的情況它應(yīng)該是監(jiān)聽不了的，畢竟 Context 的情急比它高蛇捌。
初始化的時(shí)候加代理：
fetchRequestsController.delegate = self
用到的類加extension：
extension ViewController: NSFetchedResultsControllerDelegate {
}
代理中三個(gè)方法介紹：
func controllerWillChangeContent(controller: NSFetchedResultsController);
func controller(controller: NSFetchedResultsController, didChangeObject anObject: AnyObject, atIndexPath indexPath: NSIndexPath?, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath?);
func controllerDidChangeContent(controller: NSFetchedResultsController);
第一個(gè)方法即將開始改變的時(shí)候抚恒。
第二個(gè)方法是要告訴你具體哪個(gè)對象要改變，具體要做什么改變络拌，增刪改還是重新排序柑爸，以及受影響的模塊是誰。這個(gè)方法緊緊連接著 tableView 和 CoreData.
第三個(gè)跟第一個(gè)類似盒音，結(jié)束的時(shí)候調(diào)用表鳍。
然后還有一個(gè)代理方法可能會(huì)用到，如果你的分組改邊了祥诽，你的Section進(jìn)行了改變：
func controller(controller: NSFetchedResultsController, didChangeSection sectionInfo: NSFetchedResultsSectionInfo, atIndex sectionIndex: Int, forChangeType type: NSFetchedResultsChangeType);
具體是什么時(shí)候調(diào)用第四個(gè)方法譬圣，比如你有四組數(shù)據(jù)，當(dāng)你添加或者刪除的時(shí)候雄坪，數(shù)據(jù)變成了五組數(shù)據(jù)或者三組數(shù)據(jù)厘熟，那么這個(gè)方法就會(huì)被調(diào)用。
6、插入數(shù)據(jù)
插入數(shù)據(jù)其實(shí)很簡單绳姨，因?yàn)榍懊娴谖妩c(diǎn)已經(jīng)實(shí)現(xiàn)了登澜，所以插入數(shù)據(jù)只需要一個(gè)方法：
let newEntity = NSEntityDescription.insertNewObjectForEntityForName("YourEntity", inManagedObjectContext: self.coreDataStack.context) as! YourEntity
self.coreDataStack.saveContext()
因?yàn)楸O(jiān)聽一直存在，所以UI上的數(shù)據(jù)實(shí)時(shí)更新飘庄，這就是 NSFetchedResultsController 的強(qiáng)大之處脑蠕。
