Core Data 在近两代系统 iOS 8 和9中得到了大幅强化，解决了以往性能和批量操作的痛点，主要有以下几个新特性：
1.Batch Refresh
2.Batch Update
3.Batch Deletion
4.Asynchronous Fetch
不过，这几个新功能的共同特点是：特么都没文档！！！

Core Data 复习小图：

Core Data Stack

NSPersistentStoreRequest 及其衍生类

NSManagedObjectContext.executeRequest:error

批量刷新 Batch Refresh

context.refreshAllObjects()

这个功能姗姗来迟，直到今天的 iOS 9 才到来，在以往要刷新 NSManagedObjectContext 里的所有对象是很不方便的，特别是 iOS 8 里添加了 Batch Update 后，这个功能简直是迫在眉睫了。这个功能的作用就是我们想象的那样：
1.刷新在 context 里注册的所有对象的数据，与 Persistent Store 同步;
2.没有发生变化的对象将会进入 faults 状态，降低内存占用；
3.保留尚未保存的变化；
4.关系引用保持有效。

批量更新 Batch Update

BigNerdRanch 出品的使用指南：New in Core Data and iOS 8: Batch Updating。

批量更新在速度方面有很大提升，内存占用也比传统方案少很多。示例代码将所有未读的邮件标记为已读，直接在 Persistetn Store 层面操作，性能非常好。副作用是：1.更新后不会主动刷新 context；2.更新不会运行有效性验证；3.自己处理冲突。

let batchUpdateRequest = NSBatchUpdateRequest.init(entityName: "Mail")
batchUpdateRequest.predicate = NSPredicate(format: "read == %@", false)
//propertiesToUpdate 使用 property 为 key，任何 NSExpression 作为值，这点非常强大。
batchUpdateRequest.propertiesToUpdate = ["read": true]
batchUpdateRequest.resultType = .UpdatedObjectIDsResultType

context.performBlock(){
    do{
        let batchUpdateResult = try context.executeRequest(batchUpdateRequest) as! NSBatchUpdateResult
        if #available(iOS 9, *){
           context.refreshAllObjects()
        }else{
            let updatedIDs = batchUpdateResult.result as! [NSManagedObjectID]
            for objectID in updatedIDs{
                if let updatedObject = context.objectRegisteredForID(objectID){
                    context.refreshObject(updatedObject, mergeChanges: true)
                }
            }
        }
    } catch {
            //Error Handle
    }
}

NSBatchUpdateRequest需要配置的属性如下：
1.entityName: 指定 entity，用作初始化
2.predicate：用于筛选
3.propertiesToUpdate：更新的键值对
4.resultType：有三种类型，指定返回值类型。
NSStatusOnlyResultType：默认值，表示操作状态，成功或失败
NSUpdatedObjectsCountResultType：返回被更新的数量
NSUpdatedObjectIDsResultType：返回含有更新对象的 ObjectID 的数组

批量删除 Batch Deletion

批量删除与上面的批量更新非常类似，也是直接在 Persistent Store 里操作。有两种初始化方式，一种是对NSFetchRequest的封装，另一种是指定要删除对象的 ObjectID。示例代码删除所有垃圾邮件：

if #available(iOS 9.0, *) {
    //init with FetchRequest
    let fetchRequest = NSFetchRequest.init(entityName: "Mail")
    fetchRequest.predicate = NSPredicate(format: "isSpam == %@", true)
    let batchDeleteRequest = NSBatchDeleteRequest.init(fetchRequest: fetchRequest)
        
    //Or init with ObjectIDs
    let deleteIDs: [NSManagedObjectID] = ...
    let batchDeleteRequest = NSBatchDeleteRequest.init(objectIDs: deleteIDs)
        
    context.performBlock(){
        do{
            try context.executeRequest(batchDeleteRequest)
            context.refreshAllObjects()
        }catch{
           //Error Handle
        }
    }       
}else{
    // Fallback on earlier versions
    Sample from stack-overflow:(http://stackoverflow.com/questions/1383598/core-data-quickest-way-to-delete-all-instances-of-an-entity/1383645#1383645)
}

NSBatchDeleteRequest的 resultType 有三种值：
1.NSBatchDeleteResultTypeStatusOnly：默认值，不返回任何值
2.NSBatchDeleteResultTypeObjectIDs：返回含有被删除对象 ObjectID 的数组
3.NSBatchDeleteResultTypeCount：返回被删除的数量
批量删除的副作用和批量更新很类似：1.删除后不更新 context，不会发出通知，因此需要手动刷新；2.不会运行有效性验证(主要是一些关系的约束)。

异步获取 Asynchronous Fetch

BigNerdRanch 出品的使用指南: New in Core Data and iOS 8: Asynchronous Fetching。这个特性不能算作批量操作的内容，但作为一个有用的特性，还是记录下。

Managed Object Context 的 fetch 是同步操作，虽然我们可以使用多 context 来解决阻塞主线程的问题，但 fetch 时依然会阻塞后台进程，相对而言，异步获取就解决了这个问题。NSAsynchronousFetchRequest类在 iOS 8 中推出，但是无论是文档还是在 SDK 里的头文件里都找不到，同级别的类至少还能在 SDK 的头文件里找到，不知为何。

NSAsynchronousFetchRequest依然是对NSFetchRequest的封装，由于是异步的，所以搭配了 completionBlock 用于 fetch 完成时执行特定操作。基于异步的定位，Asynchronous Fetch 还配置了显示 fetch 进度和取消 fetch 的功能。但是，但是，所有的中间类都找不到文档和相关信息，可以说这个特性相当的不友好，如果不是特别需要异步特性，还是别用了吧。

异步请求用法