李忠：ReactiveCocoa底层的完成是对照庞大的，在功能上的确会有必定的影响。一个复杂的[signalsubscribeNext:^(idx){}]就会有形成很深的callbackstack(近40次的挪用)，比拟纯KVO不到10次的挪用，速率上慢了最少1个数目级。不外只管云云，只需subscribe的次数不要过量，功能上仍是能够承受的。
在事务呼应上，RAC比KVO慢了也许5倍，不外成绩不年夜，在iPhone5上测了下，也就1ms多一点，尽年夜多半的利用场景都不会有成绩。
在开辟MacApp时，可使用CocoaBindings，但iOS却不撑持，大概也是出于功能上的思索。既然RAC的功能不如间接利用原生的高，另有需要用它么？我以为仍是有的，功能是我们选择框架的一个参考要素，但不是决意性的要素。开辟者在充足懂得RAC的情形下，RAC能够进步开辟效力并匡助开辟者编写更容易保护的代码，这两点就值得我们往研讨、利用它。
李忠：iOS开辟UI界面次要有3种体例，手写UI代码、利用xibs来构造UI、利用StoryBoard来构造xibs，3种体例各有优弱点。
以是三种体例各有好坏，而利用RAC其实不会强迫你利用代码往构建UI，仍然能够用xib/StoryBoard，它改动的是编程形式，对UI的影响实在不年夜。别的RAC还供应了一套UIKitExtension，良多必要Delegate/Target-Action的UI，能够间接利用RAC的办法，这也带来了很年夜的便当。
- 手写UI代码(也是我今朝接纳的体例)既然xib能够做的事变，代码都能够做到，并且xib做不了的事变，代码也能够做到，那为何不间接用代码来写呢。良多人忧虑开辟效力上会是一个很年夜的成绩，我以为也许会慢一点，但成绩不年夜，特别是分离了如许的UIViewHelper以后。另有就是触及到多人开辟时，能够削减抵触，特别是每一个人卖力各自的模块，基础不会呈现这个情形。
- 利用xibs来构造UI这也是很多开辟者接纳的形式，跟手写UI比拟，最年夜的优点是直不雅且高效。Xcode4的xib文件布局庞大且痴肥，很简单发生抵触，不外幸亏Xcode5对它举行了很年夜的改善，布局加倍复杂且易读。不外因为UI既能够在xib里调剂，也能够在代码里调剂，乃至是代码的分歧中央举行调剂，调试和保护都简单呈现成绩。
- 利用StoryBoard优点很分明：十分直不雅。一共有几个页面，每一个页面是做甚么的，页面之间怎样联系关系都能够看得很分明。成绩也很年夜：多人合作，很简单呈现抵触，要频仍地办理抵触仍是挺影响效力的。固然假如只是一团体开辟，那就没有成绩了。
李忠：比如有一座屋子，屋子的仆人每一年城市对内里的家具做一些调剂，如灯胆从白炽灯酿成节能灯，洗衣机从半主动酿成了全主动等等，也会新添置一些工具，如为了更爽地看天下杯，买了个投影仪，或为了更便利地扫除房间，买了个iRobot等等。
这座屋子就仿佛Cocoa，对家具的调剂就比如新的API，新的工具比如新的工具。而RAC其实不会对现有的家具形成影响，它改动的只是墙体的布局，让它更安定。
以AutoLayout为例，它能够完成界面的绝对结构，好比[NSLayoutConstraintconstraintsWithVisualFormat:options:metrics:views:]，RAC其实不会搅扰这一历程。但AutoLayout的一个特性：形貌View之间的干系，而不是静态的往盘算，是挺切合RAC的理念的，以是RAC也能够用来做这件事变。好比有两个View：parentView和childView，假设当parentView的bounds改动时，childView也要随着改动，就能够这么做：
[RACObserve(parentView,layer.bounds)subscribeNext:^(idbounds){childView.frame=CGRectInset(bounds,5,5);}];
RAC的开辟者以为如许可行，因而就有了ReactiveCocoaLayout，以是是不是有需要基于RAC举行自界说扩大，必要看是不是切合RAC的理念。
李忠：先来讲说坏处吧，RAC最年夜的成绩在于它跟一般的编程形式太纷歧样了，就像第一次穿上滑冰鞋，良多人城市以为不习气，然后各类摔交，由于不克不及再用“走路”的形式往理论了。以是进修本钱是个很年夜的应战。
其次RAC没有被年夜范围采取，很少有人分享BestPractices，或相干的文章，这时候“冒然”地用到项目里，假如影响了开辟效力怎样办？项目不克不及准期托付怎样办？其他团队成员不敷熟习怎样办？碰到成绩找不到办理计划怎样办？这些都是要思索的要素，以是假如要利用，必需对它有相称水平的懂得，因而潜伏的风险也是个年夜成绩。
有一天同事Dismory说他已用RAC开辟了一个App，而且感到很不错，因而就决意在开辟花瓣时用一下。由于我们是模块化开辟，每一个人会分到多个模块，以是也其实不请求每一个人都利用RAC，能够依照本人最熟习的体例往写，这也进一步下降了风险。
之前没有效RAC写过一个完全的项目，天然会碰到很多成绩。最年夜的成绩是：怎样用RAC的理念往思索？由于不敷熟习，以是代码常常两不像，既不像RAC，也不像Cocoa。因而我就入手下手翻issues列表，看RAC作者写的App和各种文章，渐渐地有点getthepoint了，写起来也随手了。也会跟团队成员分享履历，会商碰到的成绩。开辟效力的提拔，代码庞大度下降这两点就是最年夜的优点。
李忠：因为ObjectiveC言语本身的限定，也影响到了RAC的一些特征，好比没法依据一个Signal得知它的sendNextvalue的范例，这是很不便利的，要末揣度它的范例，要末往看接口申明，假如没有申明，那只能看源码。而Swift的Generic特征恰好能够填补这点。
除此以外，由于Swift没有KVO，而RAC又是基于KVO完成的，以是假如要用Swift来重写，底层的修改仍是挺年夜的。不外看起来他们正盘算这么做。
这就会带来一些成绩，假如项目是用ObjectiveC写的，那末就没法挪用Swift的Generic办法，大概其他Swift具有的特征。别的今朝Swift言语还没有到不乱版，接口和利用上也存在变化的大概。
我以为他们应当是认同Swift，且信任它会在未来成为主力开辟言语，以是不如一次性地撑持到位。假如仍是利用OC，那末能够用RAC2，假如利用Swift，那末就能够用RAC3。
RAC3自创了.NET的Rx头脑，经由过程Observer/Observable/Enumerator/Enumerable这4个基本类来完成push/pulldrivenstreams，架构上也更明晰了，利用Swift来完成这些特征应当也没甚么成绩。至于难度么，Justtrustthegithubguys。
李忠：比拟于其他的框架，ReactiveCocoa的进修曲线加倍峻峭，也就意味着必要花更多的工夫。假如对Cocoa的计划形式、理念和经常使用Framework都已很熟习，也做过了几个成熟的App，那末能够往更深切地懂得下，好比怎样用RAC的体例往办理Cococa编程碰到的成绩，怎样写出更RAC的代码等等。
有两种办法能够写出bug-free的代码。1)利用那些让bug更少的手艺2)用本人熟习的手艺。假如对第一点吃禁绝，那末只利用第二点也没甚么成绩。
不倡议老手间接利用RAC往开辟程序，假如能做到这点，已不是老手了，最少有不错的编程基本。假如只是本人做SideProject还行，触及到多人互助，压服他人利用也是个困难，究竟RAC不敷popular，且有着不成控的风险，并且未来他人来保护代码也会是个成绩。
Cocoa编程另有良多的应战，这些不是学会了RAC就可以办理的，关于年夜多半人我仍是倡议先看看，不必急着就在项目里利用，等RAC3.0出来后再思索也不迟。
| 欢迎光临 仓酷云 (http://ckuyun.com/) | Powered by Discuz! X3.2 |