[swift] ReactiveCocoa vs RxSwift-장단점?

이것은 매우 좋은 질문입니다. 두 세계를 비교하는 것은 매우 어렵습니다. Rx는 Reactive Extensions가 C #, Java 또는 JS와 같은 다른 언어로 된 포트입니다.

Reactive Cocoa는 Functional Reactive Programming 에서 영감을 받았지만 지난 몇 개월 동안 Reactive Extensions 에서도 영감을 받았습니다 . 결과는 Rx와 일부 정보를 공유하지만 FRP에서 유래 한 이름을 가진 프레임 워크입니다.

가장 먼저 할 말은 개념 의 Conal 정의 에 따라 RAC와 RxSwift가 Functional Reactive Programming 구현 이 아니라는 것 입니다. 이 시점부터 모든 프레임 워크가 부작용과 몇 가지 다른 구성 요소를 처리하는 방식으로 모든 것을 줄일 수 있습니다.

커뮤니티와 메타 기술 에 대해 이야기 해 봅시다 .

• RAC는 Objective-C에서 진행중인 작업을 완전히 중단 한 후 3.0 릴리스 용 Swift (브리지 포함)로 이식 된 Objective-C에서 태어난 3 년 된 프로젝트입니다.
• RxSwift는 몇 달 전의 프로젝트이며 현재 커뮤니티에서 추진력이있는 것 같습니다. RxSwift에서 중요한 한 가지는 ReactiveX 조직 아래에 있으며 다른 모든 구현은 동일한 방식으로 작동한다는 것입니다. RxSwift를 처리하는 방법을 배우면 Rx.Net, RxJava 또는 RxJS를 사용하는 것이 간단한 작업이자 문제입니다. 언어 구문 나는 그것이 한 번만 배운 철학에 근거한다고 말할 수 있고 , 어디에나 적용 할 수 있습니다 .

이제 기술적 인 시간이다.

엔티티 생성 / 관찰

RAC 3.0 2 개 주 요소를 가지며, Signal그리고 SignalProducer, 첫 번째 이벤트가없이 가입자가 장착되지 않았거나 출판, 두번째는 필요한 start실제로 제조 신호 / 이벤트를 갖는 것. 이 디자인은 많은 개발자들에게 혼란의 원인이 된 지루한 뜨겁고 차가운 관측 가능 개념을 분리하기 위해 만들어졌습니다. 이것이 차이점을 부작용 관리 방법으로 줄일 수있는 이유 입니다.

RxSwift에서, Signal그리고 SignalProducer로 변환 Observable, 그것은 혼란 소리 수 있지만,이 두 기관은 실제로 수신 세계에서 같은 일이다. ObservableRxSwift에서 s를 사용 하는 디자인 은 뜨겁거나 차갑지 않은지를 고려하여 생성해야합니다. 불필요한 복잡한 것처럼 들릴 수 있지만 일단 작동 방식을 이해하면 가입 및 관찰 중에 뜨거운 / 차가운 / 따뜻한 부작용이 발생합니다. ) 길들일 수 있습니다.

두 세계에서 구독 개념은 기본적으로 동일하며, RAC가 도입 한 것과는 약간의 차이가 있으며 완료 이벤트가 전송되기 전에 interruptiona Signal가 폐기 될 때 의 이벤트 입니다. 두 가지 모두를 요약하면 다음과 같은 종류의 이벤트가 있습니다.

• Next, 새로운 수신 값을 계산하기 위해
• Error, 모든 관찰자를 구독 취소하여 오류를 계산하고 스트림을 완료합니다.
• Complete모든 관찰자를 구독 취소하여 스트림을 완료된 것으로 표시

또한 RAC는 올바르게 완료되거나 오류가 발생하기 전에 interrupteda Signal가 폐기 될 때 전송됩니다 .

수동 작성

RAC에서 Signal/ SignalProducer는 읽기 전용 엔터티이며 외부에서 관리 할 수 ​​없으며 ObservableRxSwift 와 동일 합니다. Signal/ SignalProducer를 쓰기 가능한 엔터티로 바꾸려면 이 pipe()기능을 사용하여 수동으로 제어되는 항목을 반환해야합니다. Rx 공간에서 이것은 다른 유형 Subject입니다.

읽기 / 쓰기 개념이 생소하게 들리면 Future/ 와의 훌륭한 비유가 Promise가능합니다. A는 Future같은 읽기 전용 자리 표시 자입니다 Signal/ SignalProducer그리고 Observable다른 한편으로는, Promise대한처럼 수동으로 성취 될 수있다 pipe()및 Subject.

스케줄러

이 엔터티는 동일한 개념으로 두 세계에서 거의 비슷하지만 RAC는 직렬 전용이며 RxSwift 기능은 동시 스케줄러도 있습니다.

구성

컴포지션은 리 액티브 프로그래밍의 핵심 기능입니다. 스트림 구성은 두 프레임 워크의 본질이며 RxSwift에서는 시퀀스 라고도 합니다 .

RxSwift의 모든 관찰 엔티티 유형입니다 ObservableType우리의 인스턴스 구성 있도록, Subject그리고 Observable여분의 걱정없이, 같은 연산자를.

RAC 공간에, Signal그리고 SignalProducer2 개의 다른 엔티티이며에 우리는이 lift에 SignalProducer의 인스턴스 생성되는 것을 구성 할 수 있도록 Signal. 두 엔터티에는 자체 연산자가 있으므로 혼합해야 할 경우 특정 연산자를 사용할 수 있는지 확인해야하며 다른 쪽에서는 고온 / 감기 관측 가능 항목을 잊어 버리십시오.

이 부분에 대해 Colin Eberhardt는 다음과 같이 훌륭하게 요약했습니다.

현재 API를 살펴보면 신호 작업은 주로 ‘다음’이벤트에 중점을 두어 다른 스레드에서 값을 변환, 건너 뛰기, 지연, 결합 및 관찰 할 수 있습니다. 신호 생성기 API는 대부분 flatMap, takeUntil 및 catch와 같은 작업을 통해 신호 수명주기 이벤트 (완료, 오류)와 관련이 있습니다.

특별한

RAC도의 개념을 갖는다 Action및 Property값이 변경되면 태스크를 수행하기 위해 값을 관찰 할 때, 후자는 흥미, 전자는 주로 사용자 상호 작용과 관련된, 컴퓨팅 부작용 유형이다. RxSwift에서는 Action로 다시 번역되며 Observable, 이는 RxCocoaiOS와 Mac 용 Rx 프리미티브의 통합에 잘 나와 있습니다. RAC 는 RxSwift에서 (또는 ) Property으로 번역 될 수 있습니다 .VariableBehaviourSubject

Property/ Variable가 우리가 명령형 세계를 반응성 프로그래밍의 선언적 특성에 연결해야하는 방식 이라는 것을 이해하는 것이 중요 하므로, 때로는 타사 라이브러리 또는 iOS / Mac 공간의 핵심 기능을 다룰 때 기본 구성 요소가됩니다.

결론

RAC와 RxSwift는 완전히 다른 2 마리의 짐승입니다. 전자는 코코아 공간에서 오랜 역사를 가지고 있으며 많은 공헌자 들이며, 후자는 상당히 어리지만 Java, JS 또는 .그물. 더 나은 결정은 선호에 있습니다. RAC는 핫 / 콜드 관측 가능 분리가 필수적이며 이것이 프레임 워크의 핵심 기능이라고 말합니다 .RxSwift는 통합이 분리보다 낫다고 다시 말하지만 부작용은 어떻게 관리 / 수행되는지에 관한 것입니다.

RAC 3.0은 중단 개념, 두 개체간에 연산자 분리 및 start신호 생성을 시작하는 것과 같은 일부 필수 동작을 도입하는 등 핫 / 콜드 관측 가능 항목 분리라는 주요 목표 위에 예기치 않은 복잡성을 야기한 것으로 보입니다 . 어떤 사람들에게는 이런 것들이 좋거나 살인자 기능 일 수도 있고, 어떤 사람들에게는 불필요하거나 위험 할 수도 있습니다. 기억해야 할 또 다른 점은 RAC는 경험이 풍부한 코코아 데브이다 만약 그렇다면, 당신은 가능한 한 코코아 규칙을 유지하기 위해 노력하고있다 한다 그것보다는 RxSwift와 작업에 더 편안한 느낌.

반면 RxSwift는 핫 / 콜드 옵저버 블과 같은 모든 단점뿐만 아니라 Reactive Extensions의 장점도 있습니다. RxJS, RxJava 또는 Rx.Net에서 RxSwift로 이동하는 것은 간단한 것입니다. 모든 개념은 동일하므로 재료를 찾는 것이 매우 흥미로울 수 있습니다. 현재 직면하고있는 동일한 문제 일 수도 있습니다 .RxJava 및 솔루션의 누군가가 해결했습니다. 플랫폼을 고려하여 다시 적용 할 수 있습니다.

어느 것을 선택해야하는지는 분명한 선호의 문제이며, 객관적인 관점에서 어느 것이 더 나은지 알 수는 없습니다. 유일한 방법은 Xcode를 실행하고 두 가지 모두를 시도하고 작업하기가 더 편한 것을 선택하는 것입니다. 소프트웨어 개발 단순화라는 동일한 목표를 달성하려는 두 가지 유사한 개념을 구현 한 것입니다.

---

답변