前言
谁能不爱 KVO 呢，一处修改，处处得知，多么优雅的模式啊！等等 Notification 模式也可以啊，咳咳，Notification 模式下还得发布一个通知。两者的优劣对比是一个很常见的笔试题，但我不觉得这样的题目是个好题目，大部分情况下两者能互换，但两者各有更适合的使用场景，这里暂不讨论了。
关于 KVO 推荐这些文章，篇篇精华。老实说，有了这几篇文章后以目前我的水准写不出有价值的啥新东西了，至此本文沦为总结 Tips 的水文，话说这么说，本文总结了些别人踩过和自己踩过的坑，还算有点用，对于在 Swift 里使用 KVO 还是具备一定指导性的：
- 官方文档：Key-Value Observing Programming Guide
- NSHipster: Key-Value Observing, Matt 大神的总结和看法
- Glow 技术团队：如何自己动手实现 KVO
第3篇手动实现 KVO 这篇文章我看得很吃力，希望再过一段时间，能把这篇文章彻底消化。以下是正文：
KVO in Swift
官方文档中给出了在 Swift 中使用 KVO 的例子：Using Swift with Cocoa and Objective-C: KVO Observing
class MyObjectToObserve: NSObject {
dynamic var myDate = NSDate()
func updateDate() {
myDate = NSDate()
}
}
private var myContext = 0
class MyObserver: NSObject {
var objectToObserve = MyObjectToObserve()
override init() {
super.init()
objectToObserve.addObserver(self, forKeyPath: "myDate", options: .New, context: &myContext)
}
override func observeValueForKeyPath(keyPath: String?, ofObject object: AnyObject?, change: [NSObject : AnyObject]?, context: UnsafeMutablePointer<Void>) {
if context == &myContext {
if let newValue = change?[NSKeyValueChangeNewKey] {
print("Date changed: \(newValue)")
}
} else {
super.observeValueForKeyPath(keyPath, ofObject: object, change: change, context: context)
}
}
deinit {
objectToObserve.removeObserver(self, forKeyPath: "myDate", context: &myContext)
}
}
总结如下：
1.在 Swift 中使用 KVO 的前提条件：1.观察者和被观察者都必须是 NSObject 的子类；2.观察的属性需要使用 @dynamic 关键字修饰。这与在 OC 中几乎没有多少门槛相比，确实麻烦了许多。
- 条件1：观察者和被观察者都必须是 NSObject 的子类，因为 OC 中KVO的实现基于 KVC 和 runtime 机制，只有是 NSObject 的子类才能利用这些特性，具体的实现细节可参考官方文档：KVO Implementation Details。另外，这也意味着 Swift 中强大的 Struct，Enum 以及泛型都与 KVO 无缘了。等等，Struct, Enum 这些值类型用处大吗？喵大的书里指出Swift的内建数据类型 String, Array, Dictionary, Set 和各种数字类型都是值类型带来的省却堆内存管理的好处，但我一直体会不深。
- 条件2：要观察的属性使用 @dynamic 修饰，表示该属性的存取都由 runtime 在运行时来决定，由于 Swift 基于效率的考量默认禁止了动态派发机制，因此要加上该修饰符来开启动态派发；除此之外，在 NSObject 子类中几乎没有属性默认是使用 @dynamic 修饰（该关键字最常见场景是在 Core Data 里，NSManagedObject 子类的属性都是 dynamic 的），所以若想对某个属性进行观察，还必须在当前的子类中 override 该属性，override 时，采用 super 的实现即可。
2.在 OC 中要观察的属性通常可分为三类：attributes, to-one relationships, to-many relationships。对于前两者而言，观察这两类属性，在 Swift 中除了要遵守第一条的规则外，与在 OC 中无异。OC 中实例变量和属性是两种东西，后者通过KVC 方法来访问前者并可以触发 KVO，在 Swift 将实例变量和属性这两种概念合并了，直接改变属性或是通过 KVC 方法都可以触发 KVO。
但对于to-many relationships，通常我们需要更加细致的信息，比如希望在添加、删除或是替换了成员时也能得到 KVO 通知，在 OC 中我们需要通过实现Collection Accessor Patterns for To-Many Properties 并使用对应的方法才能触发对应的 KVO。但在 Swift 中，这些方法都无法触发 KVO，你在实现这些方法时 Xcode 也没有提示，基本上很多方法你会有 Swift 不支持的错觉，当然就不吐槽 Xcode 对 Swift 的糟糕支持了。看起来似乎没办法了，直到我搜到了这个回答 Key-Value Observe in Swift not showing insertions and removals in arrays，该答案的回答者在回答的两天前也问过类似的问题Key-Value Observing To-Many Relationships in Swift，后来他找到了方法。对于 NSMutableArray, NSMutableSet 一类的属性，在 Swift 中，需要通过以下 KVC 方法来获取观察属性的集合代理(collection proxy)，通过该代理，直接使用常规的添加、删除和替换方法就能触发 KVO，这正是我们需要的结果。
- mutableArrayValueForKey:
- mutableArrayValueForKeyPath:
- mutableSetValueForKey:
- mutableSetValueForKeyPath:
- mutableOrderedSetValueForKey:
- mutableOrderedSetValueForKeyPath:
3.KVO 中的其他特征，如属性依赖(Registering Dependent Keys)，自动/手动通知，在 Swift 中都是支持的，已经验证过。
属性观察器
Swift 中可以为属性设置属性观察器，可以说是内建的 KVO 观察，只不过只限于对自身属性的观察。看起来像这个样子：
class StepCounter {
var totalSteps: Int = 0 {
willSet(newTotalSteps) {
print("About to set totalSteps to \(newTotalSteps)")
}
didSet {
if totalSteps > oldValue {
print("Added \(totalSteps - oldValue) steps")
}
}
}
}
属性观察器只在在初始化完成后触发，而且不限于 NSObject 的子类，Swift 中所有的 Class, Struct, Enum 都可以使用。
Swift 内建的 Array, Dictionary, Set 等都是值类型，对其内容的修改包括添加，删除，替换元素也会触发属性观察器。这很好理解，Array, Dictionary, Set 等值类型更改内容后，会复制新的内容给变量，变量指向的地址不同了。对于对应的 OC 版本的类型，这类操作并不会触发属性观察器。但是在上面的第2条里面的 KVC 方法获得的集合代理在更改内容时会触发属性观察器。具体是什么导致了触发，我还不太明白，因为不了解背后的实现机制，老实说我还不知道用什么手段来进行分析，望指教。
非 NSObject 子类的 KVO
前面提到，在 Swift 中使用 KVO 需要观察者和被观察者都是 NSOject 的子类才行，一直以来，Cocoa 中的 KVO API 都被广泛吐槽太难用，但是借助 Swift 的闭包和泛型也可以实现更优雅的 KVO 模式。
- Colin Eberhardt: Swift KVO Alternatives
- Key Value Observing (KVO) with Swift Closures
- 第三方的 Swift KVO库：Observable-Swift
以上的文章和库我暂时还看不懂，再等段时间来理解。
PS: 刚才还在微博上看见有人翻译了 UIStackView 的官方文档求转发，老实说，为啥要翻译这种级别的文档，有价值吗？曾经，我在某博客找到某个问题的解决方案，顺道看看博客上的内容，有一系列的 Core Animation 文档翻译，收藏了下以待日后学习。后来我看他的一系列翻译，两篇过后质量就很低了，严重影响理解。前不久学习 Swift 也看了国内组织翻译的文档，看了一半还是回来看英文文档。文档这东西还是老老实实看官方文档就好了，虽然有时候官方文档也不咋地，但至少对于所解释的东西是非常直接的。翻译这件事不好做，要得翻译者本身对该技术的理解和写作能力都不错才行。
