上回讲到(我是在讲武侠故事吗,笑哭), ViewController 的事件(或者我们更一般化地称为消息),分四层处理: View/API/Store/Route 。 View 这块,视图本身会由 ViewController 管理。而视图的数据处理则会单独扔给对应的 ViewModel 。
通过四个属性对象,把原来在 ViewController 里处理的代码扔到四个不同地方。自然地,相应的类型依赖也被引出到四个不同地方。
这样可以避免 ViewController 类型依赖太多、代码太多太复杂的问题。
如果这个属性对象使用指定类型来声明, ViewController 就必须引入四个类型的依赖。
有没有办法可以连这四个类型都不依赖?
通过协议对象 id<protocol>object 。
这样,我们只需要引入四个协议就可以了。可以在运行时更换任意遵守协议的对象来对 ViewController 的同一事件做不同的处理,这样就可以减少选择判断的代码。
那,协议对象的代理对象,在什么地方指定呢?
初始化 ViewController 的地方。我们还是会在一个地方引入 ViewController 、 ViewModel 、 APIHandle 、 StoreHandle 、 RouteHandle 的依赖,然后完成它们的初始化。
因为页面跳转的时候,我们总是要指定跳转目标页面而引入目标 ViewController 的依赖,并完成 ViewController 的初始化。
所以,我们把四个层次的依赖放到 RouteHandle 里完成。
经过和老婆多次反复讨论,目前我们大概已经确定确实要把事情往深做。然后就是怎么做的问题。
我老婆很早就想开始思考这个问题,被我一直压住。找方法容易的,方向不好定。
我在群里提了一个想法:我从 2013 年 10 月开始做 iOS 开发,到现在已经 22 个月。如果这 22 个月,我只看 Runtime ,其它一切资料都不看。按我的努力程度,即使我不敢说精通 Runtime ,起码我也绝对敢对外宣布我熟悉 Runtime ,我也肯定能随便拉个人就讲上三天三夜的 Runtime 。
而现在的事实是什么呢?
我除了知道“ Runtime 可以做一些类型、数据、属性的动态绑定”这句话以外,其它 Runtime 的一切皆无所知。注意,我只知道这句话。对这句话的具体内容也一无所知。
大家可以看到这里面因为选择所导致的问题:实力的巨大差异。
为什么会造成这么巨大的差距?
在我看来,深还是广,不是哪个更好的问题,是生和死的选择。
好了,方向确定,下面是怎么做的问题。
以 Runtime 为例。
一般大家都会觉得多少有点难度。但如果我说,我用 22 个月来熟悉它,不但很多人会开始觉得有可能,甚至会有不少人觉得太容易。
这里就有一个非常有趣的点:时间可以消灭一切困难。至少是一些我们常见的以为自己无能为力的困难。
比如,书,一天看 10 页当然难。如果是一周看 1 页,还难吗?有了开始的积累,后面要提速,还难吗?
时间之所以能消灭一切,关键在于“信息叠加”。
当你对大脑进行足够的“信息叠加”,大脑就会进化成适合处理这类信息的机器。
我儿子被公认为在“汽车”上有天赋。但,参与整个实验过程,我和老婆都非常清楚,这只是因为我们顺着他的兴趣疯狂地给他堆各种汽车信息导致的必然结果而已。
在大家看来是偶然、幸运的事情,我们可以通过“叠加信息”让它变成必然!
我看完了老罗 2 个小时的发布会。
我觉得,老罗越来越平静了。
这种因为在深入优化上积累而得到的“平静的自信”,非常可怕。
多少人想毁灭他,但却对他这种“找一个点,深入优化,再找下一个点”的无敌模式一点办法都没有。
“深入优化”,在你积累还不够多的时候,别人会觉得你非常可笑,天天吹牛逼,说自己优化了这个优化了那个,结果连个基本成品都看不到。
但是,当你的“深入优化”积累多了一点点的时候,那些自以为聪明的反你人士,就开始有点无可奈何,看来是压不死你了。
当你的“深入优化”越积越多之后,对手们就崩溃了,这怎么回事,什么时候强大到这样啦。
看看苹果就知道,对手也可以做个一样的金表,前提是,你也发明“苹果金”试试?我不是说你完全没有可能做到,而是这样做的成本,会让很多对手都不可能做出努力的决心。