KVO 的争论

说起KVO，真是有一段颇为曲折的经历，彼时应公司要求自修iOS，做了两年后，种种原因另谋高就，第一份面试题里面就有一题什么是KVC？KVO，有啥区别有啥联系？当时就懵了...KVO？KVC？iOS里面有这玩意么？我做了两年，app无数，上线的都好几款，咋不知道这个东西？难道是C语言基础...

题是肯定没有做出来，所以晚上回家就查了查，一查吓一跳原来除了notification，delegate，oc还给我们提供了这么方便的东西...我竟然不知道...当时心里那个惭愧啊...

后来在新公司开始做项目，自然而然就想到了这个东西...search一下，用起来超简单3个方法，add，remove，invoked（当然，和notification不同不可以custom），查了几个示例代码，大部分都写着[self.map addObserver:self ......], 仿照一下，写完了一用不错，方便快捷...话说项目很快进入了中期，开始大量的测试，突然发现有比较异常的内容溢出伴随各种诡异的crash，不明就里，各种测试，最后在别人的帮助下发现是由于KVO的remove写的有问题，导致发生了obj被release掉KVO却没有移除的情况，批评过后建议不要用KVO，全部换成delegate...当时就觉得这玩意确实不好用，因为之前也没用过，程序好好的，也没这么多事...

话说一晃又是两年，前段时间和另一个partner合作，此时自己对KVO乃至其他几种设计模式已经了然于胸，当时信手拈来，可是程序写完后对方提出说觉得KVO用的有问题，问之，曰：”KVO should not be used on itself own property, it doesn't make any sence“...汗之余，开始深切思考...why？？？于是又深入了解下这个看起来非常不错的工具。

KVO，简单讲就是Key-Value Observer. 基于KVC的观察者模式...之所以是基于KVC可能是iOS其实是通过运行时解析的原理实现的KVO，再深入就不知道啦...所以还是从实现和架构上解释这个东西。

KVO 的优点主要是可以做到完全解耦，当然观察者模式就是为这个而生的，另外就是可以对非自己管理的对象进行观察，比如框架类属性的观察，缺点也比较明显，首先不允许自定义回掉方法，所有回调逻辑都要写在唯一的方法，如果你在同一个controller里面分别给不同的target设置了不同观察者，依然得写在这一个方法里，所以不得不写一堆看起来argly的if else...另外context参数几乎没有用，唯一的作用是区分super和self...另外remove的时候没办法判断当前观察者是否还观察着object，导致逻辑错误容易访问未知内容crash...（虽然可以通过try catch解决，但是肯定有效率的影响）

So...咋一看，弊大于利啊...为什么还要用呢,不用行不行呢？不用肯定行，但是未必好，用也可以用但不可以滥用...这都是废话，对了关于这个问题还想到之前看到网上的一个文档，文档是用来描述MVC in iOS的，其中的图例里明确在View和Controller之间用KVO连接做完全逻辑解耦...

那到底用不用呢，在实际使用过程中我就遇到过一次我觉得不得不用，不能不用的情况，那就是一次针对UICollectionView的修改我想要实现让UICollectionView拥有plain模式UITableView的section上推效果，怎么做？我需要针对scrollview的offset进行一些操作...不用kvo？你怎么玩？一秒钟变化无数次，每次变化都要跟着变化写在相应的delegate里面肯定是可以的，但是系统的那些控件会这么干么？都在scrollview did scroll里面写一大堆逻辑？why？我们有KVO，完全可以优雅的解决这个问题好么，对offset 价格观察者跟着变不就完了，逻辑多简单！所以我对KVO有了一些感受，虽然还不完善，但是我想要写出来，帮我自己缕一缕...

就KVO的设计初衷来看，更多的应该是希望用这个东西实现一个简单的机制去刷新UI，这种刷新既包括数据的绑定刷新，又包括在UI上实现某些特殊的逻辑，自动是无差别的触发通知，手动就是由你自己来决定是否使用通知，还得到一种说法，KVO影响效率...查了好多资料，没查到，也不知道是不是真的...

KVO 还可以键值依赖，就是说可以让加上observer的属性仍然依赖于自己属性的变化，这个功能强化了KVO的对象特性，使关注的value不仅是值更可以是对象。

写了一大堆，但是对于何时合适使用KVO还是不够清晰，所以以后再来追加。