RAC 5.0 相比於 4.0 有了巨大的變化，不僅是受 swift 3.0 大升級的影響，RAC 對自身項目結構的也進行了大幅度的調整。這個調整就是將 RAC 拆分為四個庫：ReactiveCocoa、ReactiveSwift、ReactiveObjC、ReactiveObjCBridge。

ReactiveCocoa

現在的 RAC 注意力主要集中在 Swift 和 UI 層上，將原來一個基於 RAC 面向 UI 層的擴展庫 Rex 合並進了 RAC 。

RAC 3 和 4 的主要精力在圍繞 Swift 重新打造一個響應式編程庫。因為這部分的核心 API 已經很成熟，所以現在將重心放在為 AppKit 和 UIKit 提供一些更好用的擴展上。

ReactiveSwift

原來 RAC 中只和 Swift 平台相關的核心代碼被單獨抽取成了一個新框架：ReactiveSwift 。

Swift 正在快速成長並且成長為一個跨平台的語言。把只和 Swift 相關的代碼抽取出來後，ReactiveSwift 就可以在其他平台上被使用，而不只是局限在 CocoaTouch 和 Cocoa 中。

ReactiveObjC

在 RAC 3 和 4 中，RAC 也包含了 RAC 2 中的 OC 代碼。現在這部分代碼被移到了 ReactiveObjC 。

這樣做的原因是因為兩個庫雖然有著一樣的核心編程范式，實際上卻是完全獨立的兩套 API 。實際的使用中，RAC 4 和 RAC 2 是完全不同的兩組用戶群，並且維護的團隊其實也是兩組。之前混在一個庫裡也增加了管理的復雜度。拆分出去後也可以更加自由的維護 ReactiveObjC 。

ReactiveObjCBridge

在把 Swift 和 OC 的庫拆分之後問題來了，並不是所有的庫都是純 OC 和 Swift 的。有相當大一部分項目處於 OC 遷移到 Swift 過程中，其中可能使用 Swift 調用了 RAC 2 中基於 OC 寫的 API。為了解決這部分用戶的問題，所以有了 ReactiveObjCBridge 。

在項目裡現在到底要引入哪些

如果你只是純 swift 項目，你繼續使用 ReactiveCocoa 。但是 RAC 依賴於 ReactiveSwift ，等於你引入了兩個庫。

如果你的項目是純 OC 項目，你需要使用的是 ReactiveObjC 。這個庫裡面包含原來 RAC 2 的全部代碼。

如果你的項目是 swift 和 OC 混編，你需要同時引用 ReactiveCocoa 和 ReactiveObjCBridge 。但是 ReactiveObjCBridge 依賴於 ReactiveObjC ，所以你就等於引入了 4 個庫。

API 重新命名????

這部分的給我的感覺就是會呼吸的痛。很多 API 需要重新找一遍，而且命名也變了。

一個方向是參照 RxSwift 采用了reactive 的命名空間。比如：

let appearing = view.reactive.trigger(for: #selector(viewWillAppear(_:)))

let producer = object.reactive.values(forKeyPath: #keyPath(key))

API 都放在了 reactive 後。不再是原先的 rac_xx 。

還有一部分與 UI 相關的屬性命名也改了，可能是受 rex 的影響。比如：

// 原來是 rac_text
viewModel.searchString <~ textField.reactive.textValues

button.reactive.pressed = CocoaAction(viewModel.commit)

還增加了生命周期 lifetime 的屬性。比如：

signal.take(during: object.reactive.lifetime)

當 object 被回收的時候信號也停止獲取 value 。

最後

讓我們一起笑著活下去????。

歡迎關注我的微博：@沒故事的卓同學

相關鏈接：RAC change log