【学习资料】这些 iOS 面试基础题目，你都深入了解吗？
发布时间：2016年01月24日 18:00分 来源：博为峰教育网采编 关键词：iOS面试 | 上一篇 | 下一篇 |
第二步：数据的同步操作
多 context 同步最简单的方案如下：
NS Managed Object Context 在执行保存操作后会发出 NS Managed Object Context Did Save Notification ，包含了 context 所有的变化信息，包括新增的、更新的以及删除的对象的信息 ； 而 merge Changes From Context Did Save Notification( _ notification) 方法则用于合并其他 context 中发生的变化。
如果 context 并未观察其他 context 的 NS Managed Object Context Did Save Notification通知 ，且保存时，persistent store 已经被其他 context 更改过，那么很可能存在差异，此时同步就有了以下几种选择：选择保存context中的版本或者使用 persistent store 的版本替换context的版本，又或是将两者的版本融合。这种同步方式由 NS Managed Object Context 的 merge Policy属性决定。
1.NS Error Merge Policy
默认策略，有冲突时保存失败，persistent store 和 context 都维持原样，并返回错误信息，是唯一反馈错误信息的合并策略。
2.NS Merge By Property Store Trump Merge Policy
当persistent store 和context 里的版本有冲突，persistent store 里的版本有优先权， context 里使用 persistent store 里的版本替换，但是 context 里没有冲突的变化则不会受到影响。
3.NS Merge By Property Object Trump Merge Policy
与上面相反，context 里的版本有优先权，persistent store 里使用 context 里的版本替换，但是 persistent store 里没有冲突的变化不受影响。
4.NS Overwrite Merge Policy
用 context 里的版本强制覆盖 persistent store 里的版本。
5.NS Rollback Merge Policy
放弃 context 中的所有变化并使用 persistent store 中的版本进行替换。
同步是件很复杂的事情， 实际上还是需要根据实际需要来选择同步方案。上面两种方案中第一种概念简单实现容易，第二种比较复杂相对危险，需要谨慎选择同步策略。还有一点需要注意，如果需要跨线程使用 managed object，那么不要直接在其他 context 里使用该 managed object，而应该通过该对象的 objectID 将该对象 fetch 到 context 里。
最后，搞定大量数据
多线程和同步问题解决，最后的难点：大量数据。大量数据意味着需要我们关注内存占用和性能，写代码时需要记得以下规则：
1.尽可能缓存需要的数据，不相关的数据保持 faults状态；
2.fetch 时尽可能精准，少引入不相关的数据；
3.构建多context 时尽量将同类 managed object 集中，最大限度减少合并需求；
4.提升操作效率，对Asynchronous Fetch, Batch Update，Batch Delete等新特性尽可能利用。
多线程编程
在 iOS 编程中，这几种情况下需要处理多线程：
I 事件必须在主线程里进行，其他的可以放在后台进行 ；而进行一些耗时长或阻塞线程的任务，最后放进后台线程里进行。iOS 的多线程技术有这么几种：线程，GCD 和 NSOperationQueue。线程这种技术比较复杂，而多线程编程向来是「 复杂必死」 ，推荐尽可能使用后二者，但线程有个后二者没有的优势：能够精确保证任务执行的时间。GCD 全称是 Grand Central Dispatch, 是 libdispatch 这个库的外部代号，基于 C 的底层来实现；而NSOperationQueue，通称操作队列，是基于 GCD 实现的。GCD 能做的 NSOperationQueue 基本上都能做，而且还有些 GCD 中不易实现的特性，如挂起、取消任务，虽然在 iOS 8 中，GCD 也提供了取消任务的功能，但在 GCD 中任务的挂起和取消都有较大的局限性；虽然大多数情况下应该使用抽象级别更高的 API，也就是 NSOperationQueue，但处理一般的后台任务我偏爱 GCD，主要是 GCD 搭配 Blcok 使用简单，非常方便。如何选择，下面两个链接对此问题的讨论值得一看：
●StackOverflow: NS Operation vs. Grand Central Dispatch
●Blog: When to use NSOperation vs. GCD
另外，还推荐这些文章：objc 的并发编程专题《Concurrent Programming》 及中文翻译版本；雷纯锋的博客《iOS 并发编程之 Operation Queues》 ；NS Hipster 的《NS Operation》。
设计模式
评价 Delegate, Notification, KVO 几种设计模式的优缺
大家可能会觉得这个问题是个好问题，与其比较这几个设计模式的优缺点，不如谈它们各自的特点比较好，因为它们是为了解决某类问题才设计出来的，有各自适合的使用场景。另外，给个 iOS 中设计模式的介绍：iOS Design Patterns。
为什么出题目都喜欢把这三个设计模式拿来对比呢？Notification 和 KVO都是用于协助对象间的通信：某个对象监听某个事件的发生，当某个事件发生时，该对象会得到通知然后做出响应。这几句话大概是以前看过的书本上说的。如果你以前没接触过设计模式，第一次学习时总是能够看到事件、响应这类模糊的词汇，看得你云里雾里。但 delegate ，应该说没有监听的功能，而是当事件发生或时机到了，要求 delegate 对象做点什么。刚开始学习 OC 的时候，一本书中将 delegate比喻为助手，当初可能不怎么理解，事后就会觉得这个比喻十分恰当。虽然delegate 模式在 OC 中随处可见，在UIViewController 类中广泛存在，但在开发 FaceAlbum 的过程中只遇到过一次自定义 protocol/delegate 的情况 ，后来还是用 KVO 取代了。相对于 Notification 和 KVO 模式，使用 delegate 模式你会明确知道对象的 delegate 能干什么，因为要成为 某个对象的delegate，该对象得遵守指定的 protocol，protocol 指定了 delegate 对象需要实现的方法。
Notification和 KVO两者都需要监听事件的对象去注册，delegate则需要 delegate 对象遵守指定的 protocol；Notification 中监听者向一个单例对象NSNotificationCenter注册，NSNotificationCenter类似一个广播中心，接受任何对象的注册，后者则向要监听的对象注册，一对一，这两者都不需要对象之间有联系，而 delegate 则需要通信的对象通过变量联系；NS Notification模式里监听的对象与被监听的对象通信是通过 NS Notification Center 这个中介，而KVO 里，不能说两者是直接通信的，我没有了解过过 KVO 是如何实现通信的，从表面上看两者就那么心灵感应一般，这是系统替我们实现的，而delegate， 由于通过变量连接，直接向 delegate 发送消息即可，在这点上，NSNotification不需要通信双方知道对方，而后两者则不然；在响应事件时，NSNotification和 KVO 模式里都是在注册时指定响应方法，而 delegate 则在 protocol 里预定义了响应方法。
说了这么多，不直观。说个实际场景，比如在 UI Collection View 里选择cell的时候，希望 title 能够跟踪选中 cell 的数量。这里用NS Notification 和 KVO 都能实现，但是我更喜欢 KVO，感觉更优雅，因为使用NSNotification模式的话，选中一个cell 的时候要在选择的方法里手动发布通知，而 KVO，只要对观察的属性实现KVO兼容的方法就可以了； 而 delegate ，自己做自己的 delegate 。而面对一些系统里的事件，比如键盘的出现与消失，图片库的变化，使用NS Notification 更加自然，因为 KVO 限于对对象属性的跟踪。
以上这些 iOS 面试基础题目，作为iOS开发者的你么都深入了解吗？
