• RxSwift中提供了多种不同的错误处理操作符,它们可以在链式操作中相互组合以实现复杂的处理逻辑,下面先简单介绍一下RxSwift提供的错误处理操作,然后通过一些具体的例子来看看如何在实际项目中应用。这里不会详细...

    RxSwift中提供了多种不同的错误处理操作符,它们可以在链式操作中相互组合以实现复杂的处理逻辑,下面先简单介绍一下RxSwift提供的错误处理操作,然后通过一些具体的例子来看看如何在实际项目中应用。这里不会详细介绍RxSwift,阅读前需要对Rx的基础有一定了解。

    错误处理操作符

    throw

    Rx中许多操作符中的闭包签名都是带有throws修饰符的,比如说这是map方法的签名:

    func map<R>(_ transform: @escaping (E) throws -> R) -> Observable<R>
    复制代码

    我们可以在这样的操作中抛出错误,抛出的错误会沿着链式操作一步步向下传递,比如下面的代码:

    Observable.of(3, 2, 1) // 创建一个包含3个事件的Observable
        .map { (n) -> Int in
            if n < 2 {
                throw CustomError.tooSmall // 1. 抛出一个自定义的错误
            } else {
                return n * 2
            }
        }
    	.subscribe { event in
    		// 2. 这里会收到一个 CustomError.tooSmall 类型的error
        }
    	...
    复制代码

    当数字小于2时,在mapthrow一个自定义的错误类型,这个错误会被传递到下面的subscribe中。

    catchError

    RxSwift可以在链式操作中捕获错误,不管是Observable自己产生的错误还是用户throw的错误,都可以在catchError操作中进行处理,接着上面map的代码:

    Observable.of(3, 2, 1)
        .map { 
            ...
        }
        .catchError({ (error) -> Observable<Int> in
            if case CustomError.tooSmall = error {
                return .just(2) // 1. 在捕获到tooSmall错误后返回一个2
            }
            return .error(error) // 2. 其他错误不处理,继续沿着操作链传递
        })
        .subscribe { event in
    		// 3. 当发生tooSmall错误时这里会收到2,最终的结果是 3, 2, 2
        }
    	...
    复制代码

    这样的处理方式接近于语言本身的try…catch机制,使用起来十分方便。

    retry

    retry提供了出错重试的操作,在一个Observable后面加上retry,当这个Observable出错的时候订阅方不会收到.error事件,而是重新订阅这个Observable,这通常意味着这个Observable创建事件相关的操作都会重新执行一次,比如说这是一个网络请求相关的Observable,“重新订阅”会重发相关的网络请求:

    moyaProvider.rx.request(.customData)
        .retry() // 1. 当发生错误时重试请求
        .subscribe { 
        	// 2. 重试的过程对于订阅者来说是不可见的,请求成功后这里才会接收到事件
        }
    复制代码

    retry方法还可以带一个Int类型的参数,表示重试的最大次数。

    retryWhen

    retryWhen就是带条件的retry,可以在特定条件下才进行重试。retryWhen的方法签名比较特别,它的闭包中接受的参数不是一个简单的Error类型,而是一个Observable<Error>类型,使用方法如下:

    Observable.of(3, 2, 1)
        .map { 
            ...
        }
        // 1. retryWhen不关心返回的是什么类型,只关心事件本身,所以直接用Observable<()>即可
        .retryWhen({ (errorObservable) -> Observable<()> in
           	// 2. 用flatMap将其转换成其他类型的Observable
            return errorObservable.flatMap({ (error) -> Observable<()> in
                if case CustomError.tooSmall = error {
                    return .just(()) // 3. 返回一个next事件表示重试
                }
                return .error(error) // 4. 继续返回error表示不处理
            })
        })
    复制代码

    闭包返回的Observable可以是任意类型,因为retryWhen只关心Observable中的事件本身,不关心其中承载的数据类型,所以这里直接用一个空类型即可,如果需要重试的话就将一个带有.next事件的Observable返回。

    retryWhen这样设计的一个优点是在出错的时候可以将它重试的逻辑跟另外一个Observable事件流关联起来(后面我会演示一个例子)。但是在上面这样一个简单的场景中,使用起来未免过于麻烦了,这里可以做一个简单的封装,提供一个(Error) -> Bool类型的闭包来处理判断逻辑:

    extension ObservableType {
        public func retryWhen<Error: Swift.Error>(_ shouldRetry: @escaping (Error) -> Bool) -> Observable<E> {
            return self.retryWhen({ (errorObserver: Observable<Error>) -> Observable<()> in
                return errorObserver.flatMap({ (error) -> Observable<()> in
                    if shouldRetry(error) {
                        return .just(())
                    }
                    return .error(error)
                })
            })
        }
        
        public func retryWhen(_ shouldRetry: @escaping (Swift.Error) -> Bool) -> Observable<E> {
            return self.retryWhen({ (errorObserver: Observable<Swift.Error>) -> Observable<()> in
                return errorObserver.flatMap({ (error) -> Observable<()> in
                    if shouldRetry(error) {
                        return .just(())
                    }
                    return .error(error)
                })
            })
        }
    }
    复制代码

    将上面这段代码复制到你的项目中,之前的重试逻辑就变成了:

    ...
    .retryWhen({ (error) -> Bool in
        if case CustomError.tooSmall = error {
            return true
        }
        return false
    })
    ...
    复制代码

    这样看起来清楚多了,减轻了思维负担。

    实际应用

    Moya是Swift常用的一个网络库,它提供了Rx的接口,下面的例子以Moya作为网络库来演示,Moya的一个核心协议是TargetType,不了解Moya的朋友可以看看它的文档,基本使用就不再详细介绍了。下面来看两个常见的实际应用场景

    场景一:带交互的出错重试

    在很多时候,用户的操作失败时不能直接重试,而是要给一个,让用户来决定下一步的操作。例如有一个文件下载的请求,当下载失败的时候需要弹框来询问是否重试。也就是说在出错到重试之间存在一个**“中断”**,只有当用户做出选择之后操作链才会继续向下执行。

    解决方法是使用retryWhen,将参数中的的Observable<Error>与我们自己业务逻辑的Observable关联起来。

    首先,我们假定有这样一个确认框的控件,它的签名如下:

    class ConfirmView: UIView {
        /// 在视图中显示一个确认框,callback为点击的回调,点击确认回调true,点击取消回调false
        static func show(_ title: String, _ callback: (Bool) -> Void) {
            ...
        }
    }
    复制代码

    实际的项目中通常都会有很多封装好的控件类型,借助于RxSwift中所提供的扩展机制,只需要添加一个小小的扩展就可以与Rx的世界无缝对接起来:

    extension Reactive where Base: ConfirmView {
        // 1. 在扩展中定义一个show方法,不同的是没有callback参数,而是返回一个Observable<Bool>
    	static func show(_ title: String) -> Observable<Bool> {
            // 2. 创建一个Observable<Bool>
            return Observable<Bool>.create({ (observer) -> Disposable in
                // 3. 调用原始的show方法,并在回调中通过observer发送结果
                ConfirmView.show(title, { (confirm) in
                    observer.onNext(confirm)
                    observer.onCompleted()
                })
                return Disposables.create { 
                	// do some cleanup
                }
            })
        }
    }
    复制代码

    之后就可以通过ConfirmView.rx.show(xxx)的方式来调用这个方法了,这个方法会弹出一个选择框等待用户的选择,选择的结果通过Observable的事件来进行通知。之后我们使用flatMap将这个ObservableretryWhen中的Obverable<Error>关联起来:

    ...
    .retryWhen({ (errorO) -> Observable<()> in
        return errorO.flatMap({ (error) -> Observable<()> in
            if case CustomError.tooSmall = error {
                return ConfirmView.rx
                    .show("是否重试?")
                    .map {
                        if $0 { // 1. 如果选择了重试,则返回.next()表示重试
                            return ()
                        } else {
                            throw error // 2. 否则继续返回error将错误继续向下传递
                        }
                    }
            }
            return .error(error)
        })
    })
    .subscribe {
    	// 3. 如果上面选择了重试,这里不会接收到错误事件
    }
    ...
    复制代码

    类似的,将不同的操作封装成Observable这样简单的逻辑流,然后通过RxSwift提供的操作加以组合以实现更加复杂的逻辑,这也是Rx所提倡的函数式思想。

    场景二:401认证

    401错误是一种很常见应用场景,比如说在我们的应用中认证流程是这样的:当服务器需要重新认证用户登录信息时会返回一个401状态码,这时客户端将认证信息添加到请求头中并重发当前的请求,这一过程对上层的业务方应该是无感知的。

    这跟之前的例子有一些不同的地方:当出错时我们不能直接retry整个请求,而是要修改原始请求添加自定义的Header,最简单粗暴的方法是在检测到401错误时发送一个通知,外面收到通知之后将Header添加到请求头里:

    moyaProvider.request(target)
        .map({ (response) -> Response in
            if response.statusCode == 401 { // 将401转换成自定义的错误类型
                // 先发送通知,之后再retry
                NotificationCenter.default.post(name: .AddAuthHeader, object: nil)
                throw NetworkError.needAuth
            } else {
                return response
            }
        })
        .retry()
    复制代码

    这种做法其实并不好,因为Rx中强调的是事件流,原本应该是一个连贯的逻辑却被通知给打断了,当我们阅读到这里的时候还得停下来全局搜索通知的名字以查找响应的位置,这样不利于阅读,同时也违背了Rx的哲学。

    我这里所采用的做法是捕获到错误时不进行retry,而是返回一个新的网络请求。为了让这个新的网络请求与之前的逻辑无缝连接起来,首先需要定义一个代理TargetType:

    let ProxyProvider = NetworkProvider<ProxyTarget>()
    
    enum ProxyTarget {
        // 添加Header
        case addHeader(target: TargetType, headers: [String: String]) 
        // ...
    }
    
    extension ProxyTarget: TargetType {
    	var headers: [String: String]? {
            switch self {
            // 1. 将新增的Header添加到被代理的Target上
            case let .addHeader(target: target, headers: headers):
                return headers.merging(target.headers ?? [:], uniquingKeysWith: { (first, second) -> String in
                    return first
                })
            }
        }
        
        // 2. 不需要吹的地方直接返回被代理Target的属性
        var task: Task {
            switch self {
            case let .addHeader(target: target, headers: _):
                return target.task
            }
        }
        
        // ...
    }
    复制代码

    ProxyTarget并没有定义新的网络请求,而是用来代理另外一个TargetType,这里我们只定义了一个addHeader操作,用来修改请求的Header。

    最终的实现如下:

    provider.request(target)
        .map({ (response) -> Response in
            if response.statusCode == 401 { // 1. 将401转换成自定义的错误类型
                throw NetworkError.needAuth
            } else {
                return response
            }
        })
        .catchError({ (error) -> Single<Response> in
            if case NetworkError.needAuth(let response) = error{
                // 2. 捕获未认证的错误,添加认证头后再次重试
                let authHeader = ... // 计算认证头
                let target = ProxyTarget.addHeader(target: token, headers: authHeader)
                return ProxyProvider.rx.request(target, callbackQueue: callbackQueue)
            }
            return Single.error(error)
        })
        .subscribe {
            // 3. 认证的过程对于上层的业务方是无感知的
        }
    	...
    复制代码

    使用map将401转换成自定义的错误类型,之后在catchError中捕获这个错误,使用ProxyTarget加上认证头之后返回一个新的Observable,这样一来所有相关的逻辑都被集中在这一系列的链式调用中了。

    当然在实际项目中不仅仅是401这类错误,可能还会有许多其他业务相关的错误类型,将它们全都放在map中处理显然不是一个好主意,最好的办法是将这部分逻辑抽离出来放在Moya的Plugin中,这里就不再演示了。

    最后

    Rx中对于事件流的抽象十分强大,可以用来描述各种复杂的场景,这里仅仅从错误处理的方面列举了一些简单的例子,可以看到Rx的思想跟我们平常所写的代码有很大不同,思维上的转变才是理解Rx的关键。

    展开全文
  • 前言其实,这一篇的题目,我觉得应该是RxSwift对代理的封装,最后还是沿用官方Example的命名吧。效果说明图一 图二 图一是当App可以使用定位信息时,显示当前的经纬度。图二是当App被禁止使用定位信息时,显示的...

    前言

    其实,这一篇的题目,我觉得应该是RxSwift对代理的封装,最后还是沿用官方Example的命名吧。

    效果说明

    图一

    图二

    图一是当App可以使用定位信息时,显示当前的经纬度。

    图二是当App被禁止使用定位信息时,显示的提示信息

    代码解释

    比起上两个Example,这个Example复杂的多了。主要复杂在对Delegate的封装。

    如何使用RxSwift对Delegate的封装稍后再说,先看看封装后的使用。

    let service = GeolocationService.instance
            // 将是否允许使用定位的“Bool”绑定noGeolocationView.rx.isHidden
            service.authorized
            .drive(noGeolocationView.rx.isHidden)
            .addDisposableTo(disposeBag)
            // 将定位信息绑定在showLocationLabel.rx.coordinates
            service.location
            .drive(showLocationLabel.rx.coordinates)
            .addDisposableTo(disposeBag)

    1、对UILabel的扩展

    可以看到上面的例子,将CLLocationCoordinate2D的经纬度信息绑定在label上了。当想绑定的在视图信息越多,我们就需要对UILabel进行扩展。

    扩展方法如下:

    /*
    意思就是当Reactive的Base对象是UILabel时,增加一个类型为UIBindingObserver<Base, CLLocationCoordinate2D>的coordinates属性。
    */ 
    private extension Reactive where Base: UILabel {
        var coordinates: UIBindingObserver<Base, CLLocationCoordinate2D> {
            return UIBindingObserver(UIElement: base, binding: { (label, location) in
                label.text = "Lat: \(location.latitude)\nLon: \(location.longitude)"
            })
        }
    }

    在后面的block参数列表中,label的类型是泛型中的Base类型(例子是UILabel),location是泛型中的CLLocationCoordinate2D对象。因此,我们只要在block中对label和location对象做操作即可。

    2、封装CLLocationManagerDelegate

    2.1、创建CLLocationManagerDelegate的代理Proxy

    为了创建Proxy对象,我们需要继承DelegateProxy,并且遵守DelegateProxyType协议,该协议必须实现以下两个方法。

    /// 返回object的代理对象
        class func currentDelegateFor(_ object: AnyObject) -> AnyObject? {
            let locationManager: CLLocationManager = object as! CLLocationManager
            return locationManager.delegate
        }
    
        /// 设置objct代理对象
        class func setCurrentDelegate(_ delegate: AnyObject?, toObject object: AnyObject) {
            let locationManager: CLLocationManager = object as! CLLocationManager
            if let delegate = delegate {
                locationManager.delegate = (delegate as! CLLocationManagerDelegate)
            } else {
                locationManager.delegate = nil
            }
        }

    2.2、创建PublishSubject对象

    先来简单回顾一下概念:

    subject的概念

    Subject可以看做是一种代理和桥梁。它既是订阅者又是订阅源,这意味着它既可以订阅其他Observable对象,同时又可以对它的订阅者们发送事件。

    PublishSubject的概念

    当你订阅PublishSubject的时候,你只能接收到订阅他之后发生的事件

    因此为了能够成为代理的代理,我们需要监听代理的事件,并且能够让外部进行监听,所以我们创建了以下两个publishSubject对象

    internal lazy var didUpdateLocationsSubject = PublishSubject<[CLLocation]>()
        internal lazy var didFailWithErrorSubject = PublishSubject<Error>()

    将代理事件通过subject传递出去,记得调用_forwardToDelagate?.method方法,因为我们这里只是做了一层监听中转

    public func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
            _forwardToDelegate?.locationManager(manager, didUpdateLocations: locations)
            didUpdateLocationsSubject.onNext(locations)
        }
    
        public func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
            _forwardToDelegate?.locationManager(manager, didFailWithError: error)
            didFailWithErrorSubject.onNext(error)
        }

    代理和proxy之间的层级关系图:

          +-------------------------------------------+
          |                                           |                           
          | UIView subclass (UIScrollView)            |                           
          |                                           |
          +-----------+-------------------------------+                           
                      |                                                           
                      | Delegate                                                  
                      |                                                           
                      |                                                           
          +-----------v-------------------------------+                           
          |                                           |                           
          | Delegate proxy : DelegateProxyType        +-----+---->  Observable<T1>
          |                , UIScrollViewDelegate     |          |
          +-----------+-------------------------------+     +---->  Observable<T2>
                      |                                     |                     
                      |                                     +---->  Observable<T3>
                      |                                     |                     
                      | forwards events                     |
                      | to custom delegate                  |
                      |                                     v                     
          +-----------v-------------------------------+                           
          |                                           |                           
          | Custom delegate (UIScrollViewDelegate)    |                           
          |                                           |
          +-------------------------------------------+   

    2.3、对CLLocationManager做扩展

    将想被监听的属性,通过刚才创建Proxy传递出来,于是我们只需要创建对应的Observable。

    代码如下:

    extension Reactive where Base: CLLocationManager {
        /**
         Reactive wrapper for `delegate`.
    
         For more information take a look at `DelegateProxyType` protocol documentation.
         */
        public var delegate: DelegateProxy {
            return RxCLLocationManagerDelegateProxy.proxyForObject(base)
        }
    
        // MARK: Responding to Authorization Changes
    
        /**
         Reactive wrapper for `delegate` message.
         */
        public var didChangeAuthorizationStatus: Observable<CLAuthorizationStatus> {
            return delegate.methodInvoked(#selector(CLLocationManagerDelegate.locationManager(_:didChangeAuthorization:)))
                .map { a in
                    let number = try castOrThrow(NSNumber.self, a[1])
                    return CLAuthorizationStatus( rawValue: Int32(number.intValue)) ?? .notDetermined
            }
        }
    
        // MARK: Responding to Location Events
    
        /**
         Reactive wrapper for `delegate` message.
         */
        public var didUpdateLocations: Observable<[CLLocation]> {
            return (delegate as! RxCLLocationManagerDelegateProxy).didUpdateLocationsSubject.asObservable()
        }
    
        /**
         Reactive wrapper for `delegate` message.
         */
        public var didFailWithError: Observable<Error> {
            return (delegate as! RxCLLocationManagerDelegateProxy).didFailWithErrorSubject.asObservable()
        }
    }

    这里值得一提的是调后delegate.methodInvoked,会返回Observable<[Any]>,其中数组装的就是传递给selector的参数,所以后面的map的block中,a[1]代表的就是CLAuthorizationStatus枚举类型。

    此外,还定义了一个转类型的函数,转失败后,会发出Error

    fileprivate func castOrThrow<T>(_ resultType: T.Type, _ object: Any) throws -> T {
        guard let returnValue = object as? T else {
            throw RxCocoaError.castingError(object: object, targetType: resultType)
        }
    
        return returnValue
    }

    2.4、定义service层

    class GeolocationService {
    static let instance = GeolocationService()
    private (set) var authorized: Driver<Bool>
    private (set) var location: Driver<CLLocationCoordinate2D>
    
    private let locationManager = CLLocationManager()
    
    private init() {
    
        locationManager.distanceFilter = kCLDistanceFilterNone
        locationManager.desiredAccuracy = kCLLocationAccuracyBestForNavigation
    
        // deferred会为每一位订阅者observer创建一个新的可观察序列
        authorized = Observable.deferred { [weak locationManager] in
            let status = CLLocationManager.authorizationStatus()
            guard let locationManager = locationManager else {
                return Observable.just(status)
            }
            return locationManager
                .rx.didChangeAuthorizationStatus
                .startWith(status)
            }
            .asDriver(onErrorJustReturn: CLAuthorizationStatus.notDetermined)
            .map {
                switch $0 {
                case .authorizedAlways:
                    return true
                default:
                    return false
                }
        }
    
        location = locationManager.rx.didUpdateLocations
            .asDriver(onErrorJustReturn: [])
            .flatMap {
                return $0.last.map(Driver.just) ?? Driver.empty()
            }
            .map { $0.coordinate }
        locationManager.requestAlwaysAuthorization()
        locationManager.startUpdatingLocation()
    }
    }
    

    这里的service层就是将之前扩展的LocationManager再次封装。值得一提的是,这里的authorized是使用deferred创建的。

    deferred

    deferred会等到有订阅者的时候再通过工厂方法创建Observable对象,每个订阅者订阅的对象都是内容相同而完全独立的序列。

    因此,每次订阅authorized信息时,都会发送独立的序列,确保每次都会响应。

    总结

    该Example可以当作封装Delegate的介绍,因此可以总结一下封装流程如下:

    • 创建代理Proxy,需要继承继承DelegateProxy,并且遵守DelegateProxyType协议
    • 定义subject对象,即订阅者(订阅代理)又是订阅源(被外部订阅)

    之后的什么扩展,service层就看大家的需要而定制了,但是以上的两步是必须的。最后,有不正确的地方,欢迎指正~

    Demo地址

    https://github.com/maple1994/RxSwfitTest

    展开全文
  • RxSwift-deallocating探索

    2019-08-11 17:56:30
    RxSwift中deinit等价于dealloc,在上面两个序列被订阅时,那么当deinit调用时会触发上面两个序列发送信号。执行顺序:deallocating -> deinit -> deallocated。看一段代码: override func viewDidLoad() {...

    deallocating.png

    RxSwfit中,有两个特殊序列

    • deallocating序列
    • deallocated序列

    RxSwiftdeinit等价于dealloc,在上面两个序列被订阅时,那么当deinit调用时会触发上面两个序列发送信号。执行顺序:deallocating -> deinit -> deallocated。看一段代码:

    override func viewDidLoad() {
        _ = rx.deallocating.subscribe(onNext: { () in
            print("准备走了")
        })
        _ = rx.deallocated.subscribe(onNext: { () in
            print("已经走了")
        })
    }
    override func viewDidAppear(_ animated: Bool) {
        print("我来了")
    }
    deinit {
        print("\(self.classForCoder) 销毁")
    }
    

    打印如下:

    我来了
    准备走了
    SecondController 销毁
    已经走了
    

    从上面代码我们可以看出,RxSwiftdeinit(dealloc)动了手脚,通常通过黑魔法就能够达到该效果,在OC中我们经常使用runtime来交换方法,在方法内部处理我们需要做的事情。那么RxSwift是如何实现的呢?下面就看看源码都做了哪些事情。

    deallocating序列的创建

    extension Reactive where Base: AnyObject {
        public var deallocating: Observable<()> {
            return self.synchronized {
                do {
                    let proxy: DeallocatingProxy = try self.registerMessageInterceptor(deallocSelector)
                    return proxy.messageSent.asObservable()
                }
                catch let e {
                    return Observable.error(e)
                }
            }
        }
    }
    
    • deallocatingReactive的扩展方法,继承自AnyObject相当于OC中的NSObject
    • 使用同步锁来保证线程安全
    • 内部通过self.registerMessageInterceptor传入deallocSelector来初始化一个DeallocatingProxy对象
    • 通过messageSent获取一个ReplaySubject序列

    deallocSelector一看就是一个方法选择器。实现如下:

    private let deallocSelector = NSSelectorFromString("dealloc")
    
    • 使用NSSelectorFromString方法来获取dealloc选择器

    由此可以看出,RxSwift确实是在dealloc(即Swfit中的deinit)上做文章。这里只是初始化了proxy对象,具体消息如何传出来的,还要继续代码追踪。

    proxy对象的创建

    fileprivate func registerMessageInterceptor<T: MessageInterceptorSubject>(_ selector: Selector) throws -> T {
        let rxSelector = RX_selector(selector)
        let selectorReference = RX_reference_from_selector(rxSelector)
    
        let subject: T
        if let existingSubject = objc_getAssociatedObject(self.base, selectorReference) as? T {
            subject = existingSubject
        }
        else {
            subject = T()
            objc_setAssociatedObject(
                self.base,
                selectorReference,
                subject,
                .OBJC_ASSOCIATION_RETAIN_NONATOMIC
            )
        }
    
        if subject.isActive {
            return subject
        }
    
        var error: NSError?
        let targetImplementation = RX_ensure_observing(self.base, selector, &error)
        if targetImplementation == nil {
            throw error?.rxCocoaErrorForTarget(self.base) ?? RxCocoaError.unknown
        }
    
        subject.targetImplementation = targetImplementation!
    
        return subject
    }
    
    • selector外部传入的dealloc的方法选择器
    • RX_selector方法通过dealloc方法名构建了另外一个方法选择器
    SEL __nonnull RX_selector(SEL __nonnull selector) {
        NSString *selectorString = NSStringFromSelector(selector);
        return NSSelectorFromString([RX_PREFIX stringByAppendingString:selectorString]);
    }
    

    从上面以看出我们的代码进入到OC区了,使用OC的方法来满足需求。沿着我们想要的结果去找方法,前面提到dealloc可能被替换了,通过代码中的targetImplementation,感觉像是一个目标实现,进入代码看一下:

    IMP __nullable RX_ensure_observing(id __nonnull target, SEL __nonnull selector, NSErrorParam error) {
        __block IMP targetImplementation = nil;
        @synchronized(target) {
            @synchronized([target class]) {
                [[RXObjCRuntime instance] performLocked:^(RXObjCRuntime * __nonnull self) {
                    targetImplementation = [self ensurePrepared:target
                                                   forObserving:selector
                                                          error:error];
                }];
            }
        }
        return targetImplementation;
    }
    
    • 返回一个IMP函数指针
    • [RXObjCRuntime instance]实际上是一个NSObject的一个单例,内部采用互斥锁,向外部提供当前单例对象
    • ensurePrepared消息发送的入口点

    ensurePrepared函数

    搜索或直接cmd+点击定位代码:

    -(IMP __nullable)ensurePrepared:(id __nonnull)target forObserving:(SEL __nonnull)selector error:(NSErrorParam)error {
        Method instanceMethod = class_getInstanceMethod([target class], selector);
        if (instanceMethod == nil) {
            RX_THROW_ERROR([NSError errorWithDomain:RXObjCRuntimeErrorDomain
                                               code:RXObjCRuntimeErrorSelectorNotImplemented
                                           userInfo:nil], nil);
        }
    
        if (selector == @selector(class)
        ||  selector == @selector(forwardingTargetForSelector:)
        ||  selector == @selector(methodSignatureForSelector:)
        ||  selector == @selector(respondsToSelector:)) {
            RX_THROW_ERROR([NSError errorWithDomain:RXObjCRuntimeErrorDomain
                                               code:RXObjCRuntimeErrorObservingPerformanceSensitiveMessages
                                           userInfo:nil], nil);
        }
    
        // For `dealloc` message, original implementation will be swizzled.
        // This is a special case because observing `dealloc` message is performed when `observeWeakly` is used.
        //
        // Some toll free bridged classes don't handle `object_setClass` well and cause crashes.
        //
        // To make `deallocating` as robust as possible, original implementation will be replaced.
        if (selector == deallocSelector) {
            Class __nonnull deallocSwizzingTarget = [target class];
            IMP interceptorIMPForSelector = [self interceptorImplementationForSelector:selector forClass:deallocSwizzingTarget];
            if (interceptorIMPForSelector != nil) {
                return interceptorIMPForSelector;
            }
    
            if (![self swizzleDeallocating:deallocSwizzingTarget error:error]) {
                return nil;
            }
    
            interceptorIMPForSelector = [self interceptorImplementationForSelector:selector forClass:deallocSwizzingTarget];
            if (interceptorIMPForSelector != nil) {
                return interceptorIMPForSelector;
            }
        }
    }
    

    看到几个熟悉的身影:

    • class_getInstanceMethod获取当前界面对象的dealloc方法,来判断该类是否存在该方法,容错处理,对方法替换没关系
    • 再看看注释:替换原始的dealloc方法。好像是我们需要找的地方
    • deallocSwizzingTarget获取到要替换dealloc的目标类
    • swizzleDeallocating传入目标类准备替换deallocdeallocating

    swizzleDeallocating

    SWIZZLE_INFRASTRUCTURE_METHOD(
        void,
        swizzleDeallocating,
        ,
        deallocSelector,
        DEALLOCATING_BODY
    )
    

    该处是个函数宏定义,内部整理如下:

    #define SWIZZLE_INFRASTRUCTURE_METHOD(return_value, method_name, parameters, method_selector, body, ...)
    SWIZZLE_METHOD(return_value, -(BOOL)method_name:(Class __nonnull)class parameters error:(NSErrorParam)error
    {
        SEL selector = method_selector; , body, NO_BODY, __VA_ARGS__)
        
        
        // common base
        
    #define SWIZZLE_METHOD(return_value, method_prototype, body, invoked_body, ...)
        method_prototype
        __unused SEL rxSelector = RX_selector(selector);
        IMP (^newImplementationGenerator)(void) = ^() {
            __block IMP thisIMP = nil;
            id newImplementation = ^return_value(__unsafe_unretained id self DECLARE_ARGUMENTS(__VA_ARGS__)) {
                body(__VA_ARGS__)
                
                struct objc_super superInfo = {
                    .receiver = self,
                    .super_class = class_getSuperclass(class)
                };
                
                return_value (*msgSend)(struct objc_super *, SEL DECLARE_ARGUMENTS(__VA_ARGS__))
                = (__typeof__(msgSend))objc_msgSendSuper;
                @try {
                    return msgSend(&superInfo, selector ARGUMENTS(__VA_ARGS__));
                }
                @finally { invoked_body(__VA_ARGS__) }
            };
            
            thisIMP = imp_implementationWithBlock(newImplementation);
            return thisIMP;
        };
        
        IMP (^replacementImplementationGenerator)(IMP) = ^(IMP originalImplementation) {
            __block return_value (*originalImplementationTyped)(__unsafe_unretained id, SEL DECLARE_ARGUMENTS(__VA_ARGS__) )
            = (__typeof__(originalImplementationTyped))(originalImplementation);
            
            __block IMP thisIMP = nil;
            id implementationReplacement = ^return_value(__unsafe_unretained id self DECLARE_ARGUMENTS(__VA_ARGS__) ) {
                body(__VA_ARGS__)
                @try {
                    return originalImplementationTyped(self, selector ARGUMENTS(__VA_ARGS__));
                }
                @finally { invoked_body(__VA_ARGS__) }
            };
            
            thisIMP = imp_implementationWithBlock(implementationReplacement);
            return thisIMP;
        };
        
        return [self ensureSwizzledSelector:selector
                                    ofClass:class
                 newImplementationGenerator:newImplementationGenerator
         replacementImplementationGenerator:replacementImplementationGenerator
                                      error:error];
    }
    

    代码看上去很繁琐,将参数一一对比能够看到,内部实际是重新组合了一个方法,参数为当前界面对象的类deallocSwizzingTarget。内部实现了一个闭包并返回IMP函数指针:

    • replacementImplementationGenerator代码块保存原始dealloc的函数地址,并在内部调用
    • 在代码块中调用了imp_implementationWithBlock函数,获取代码块的函数指针

    下面先看一下imp_implementationWithBlock函数的作用。

    imp_implementationWithBlock

    该函数接收一个block将其拷贝到堆区,返回一个IMP函数指针,把block当做OC中类的方法实现来使用。举例如下,用block代替原有方法实现:

    -(void)myMethod{
        NSLog(@"我来了");
    }
    ……
    //1、创建block
    void (^myblock)(int val) = ^(int val){
        NSLog(@"myblock");
    };
    //2、获取block的IMP
    IMP myblockImp = imp_implementationWithBlock(myblock);
    //3、获取要替换的方法的IMP
    Method method = class_getInstanceMethod(self.class, @selector(myMethod));
    //4、替换函数指针,指向block
    method_setImplementation(method, myblockImp);
    //5、执行原始方法
    [self myMethod];
    

    打印:我来了

    使用该函数是为了用代码块来替换一个需要替换的方法。

    以上宏定义的函数最后调用了ensureSwizzledSelector方法,搜索查看代码:

    ensureSwizzledSelector

    -(BOOL)ensureSwizzledSelector:(SEL __nonnull)selector
                          ofClass:(Class __nonnull)class
       newImplementationGenerator:(IMP(^)(void))newImplementationGenerator
    replacementImplementationGenerator:(IMP (^)(IMP originalImplementation))replacementImplementationGenerator
                            error:(NSErrorParam)error {
        if ([self interceptorImplementationForSelector:selector forClass:class] != nil) {
            DLOG(@"Trying to register same intercept at least once, this sounds like a possible bug");
            return YES;
        }
    
    #if TRACE_RESOURCES
        atomic_fetch_add(&numberOInterceptedMethods, 1);
    #endif
        
        DLOG(@"Rx is swizzling `%@` for `%@`", NSStringFromSelector(selector), class);
    
        Method existingMethod = class_getInstanceMethod(class, selector);
        ALWAYS(existingMethod != nil, @"Method doesn't exist");
    
        const char *encoding = method_getTypeEncoding(existingMethod);
        ALWAYS(encoding != nil, @"Encoding is nil");
    
        IMP newImplementation = newImplementationGenerator();
    
        if (class_addMethod(class, selector, newImplementation, encoding)) {
            // new method added, job done
            [self registerInterceptedSelector:selector implementation:newImplementation forClass:class];
    
            return YES;
        }
    
        imp_removeBlock(newImplementation);
    
        // if add fails, that means that method already exists on targetClass
        Method existingMethodOnTargetClass = existingMethod;
    
        IMP originalImplementation = method_getImplementation(existingMethodOnTargetClass);
        ALWAYS(originalImplementation != nil, @"Method must exist.");
        IMP implementationReplacementIMP = replacementImplementationGenerator(originalImplementation);
        ALWAYS(implementationReplacementIMP != nil, @"Method must exist.");
        IMP originalImplementationAfterChange = method_setImplementation(existingMethodOnTargetClass, implementationReplacementIMP);
        ALWAYS(originalImplementation != nil, @"Method must exist.");
    
        // If method replacing failed, who knows what happened, better not trying again, otherwise program can get
        // corrupted.
        [self registerInterceptedSelector:selector implementation:implementationReplacementIMP forClass:class];
    
        // ¯\_(ツ)_/¯
        if (originalImplementationAfterChange != originalImplementation) {
            THREADING_HAZARD(class);
            return NO;
        }
    
        return YES;
    }
    
    • interceptorImplementationForSelector查看dealloc是否存在对应的函数,如果有往下走,开始对dealloc做替换
    • class_addMethod,既然dealloc存在对应的函数,添加必然失败,继续向下走
    • method_setImplementation,开始设置deallocIMP指向上面提到的代码块replacementImplementationGenerator

    在此处即替换了系统方法,当系统调用了dealloc时就会触发replacementImplementationGenerator中的block方法。

    IMP (^replacementImplementationGenerator)(IMP) = ^(IMP originalImplementation) {
        __block return_value (*originalImplementationTyped)(__unsafe_unretained id, SEL DECLARE_ARGUMENTS(__VA_ARGS__) )
        = (__typeof__(originalImplementationTyped))(originalImplementation);
        
        __block IMP thisIMP = nil;
        id implementationReplacement = ^return_value(__unsafe_unretained id self DECLARE_ARGUMENTS(__VA_ARGS__) ) {
            body(__VA_ARGS__)
            @try {
                return originalImplementationTyped(self, selector ARGUMENTS(__VA_ARGS__));
            }
            @finally { invoked_body(__VA_ARGS__) }
        };
        
        thisIMP = imp_implementationWithBlock(implementationReplacement);
        return thisIMP;
    };
    

    在以上代码中我可以看到一个body函数的调用,该处即是关键。

    body-DEALLOCATING_BODY

    搜索找到宏并整理如下:

    #define DEALLOCATING_BODY(...)
    id<RXDeallocatingObserver> observer = objc_getAssociatedObject(self, rxSelector);
    if (observer != nil && observer.targetImplementation == thisIMP) {
        [observer deallocating];
    }
    
    • rxSelector即是要替换的方法选择器即deallocating对应的选择器
    • observer序列在此处调用了deallocating,此时deallocating就被调用
    @objc func deallocating() {
        self.messageSent.on(.next(()))
    }
    deinit {
        self.messageSent.on(.completed)
    }
    
    • .commpleted结束序列,因此不需要在外部添加垃圾袋

    此处即是向订阅发送消息,这里前边文章都有代码追踪这里就不一一介绍了。deallocating调用后,上面有讲到,body调用后即调用代码块保存的原始dealloc函数:

    return originalImplementationTyped(self, selector ARGUMENTS(__VA_ARGS__));
    

    联系上面定义,可知originalImplementationTypeddealloc的原始函数,在此处调用了dealloc,由于代码比较繁琐,下面来证明一下该处就是触发dealloc的方法。我们可以将次闭包的参数换成viewDidAppear,在RxCocoa -> _RXObjeCRuntime.m中的ensureSwizzledSelector方法中替换:

    将如下:

    replacementImplementationGenerator(originalImplementation);
    

    替换为:

    IMP viewdidAppear = class_getMethodImplementation(class, @selector(viewDidAppear:));
        IMP implementationReplacementIMP = replacementImplementationGenerator(viewdidAppear);
    

    替换为视图出现时调用的方法,如果在掉用deallocating后,viewdidAppear被调用则能够证明上面所指之处就是我们触发dealloc的方法。

    替换前的打印:

    我来了
    准备走了
    SecondController 销毁
    已经走了
    

    替换后的打印:

    我来了
    准备走了
    我来了
    

    通过以上测试能够确定dealloc就是在代码块中调用的。注意在修改源码后要clean一下工程,否则缓存会影响执行结果。

    deallocated序列的创建

    下面看看deallocated序列是如何产生,又是如何在dealloc调用完成之后执行的。

    public var deallocated: Observable<Void> {
        return self.synchronized {
            if let deallocObservable = objc_getAssociatedObject(self.base, &deallocatedSubjectContext) as? DeallocObservable {
                return deallocObservable._subject
            }
    
            let deallocObservable = DeallocObservable()
    
            objc_setAssociatedObject(self.base, &deallocatedSubjectContext, deallocObservable, .OBJC_ASSOCIATION_RETAIN_NONATOMIC)
            return deallocObservable._subject
        }
    }
    
    • 关联了创建的序列,保证当前控制器内的序列对象只有一个

    DeallocObservable代码:

    fileprivate final class DeallocObservable {
        let _subject = ReplaySubject<Void>.create(bufferSize:1)
    
        init() {
        }
    
        deinit {
            self._subject.on(.next(()))
            self._subject.on(.completed)
        }
    }
    
    • 内部也初始化了一个ReplaySubject序列,用来发送消息
    • 在对象销毁时调用了.next和.completed,这里不难理解,发送一条消息,再发送一条完成消息终止序列,因此在外部创建序列不需要添加垃圾袋

    总结

    • RxSwift中提供了两个关于deallocdeinit)的序列,观察dealloc的调用,其中deallocating内部替换了原生的dealloc方法从而达到监听dealloc的调用
    • 这里并不是交换方法,而是在replacementImplementationGenerator代码块中先保留了dealloc的函数地址,再通过imp_implementationWithBlock设置deallocIMP,指向了replacementImplementationGenerator代码块
    • 调用dealloc方法就会调用了代码块,在代码块内部通过body函数调用了deallocating方法,之后执行代码块中保留的原dealloc函数
    展开全文
  • 本文内容目录: itemSelected的底层实现 实战 tableView.rx.itemSelected .subscribe(onNext: { indexPath in ...复制代码我们在使用RxSwift的时候经常会遇到这样的代码,类似的还有诸如itemD...
    本文内容目录:
    • itemSelected的底层实现
    • 实战
    tableView.rx.itemSelected
          .subscribe(onNext: { indexPath in
              // Todo
          })
          .disposed(by: disposeBag)
    复制代码

    我们在使用RxSwift的时候经常会遇到这样的代码,类似的还有诸如itemDeselecteditemMoveditemInserteditemDeleted等,它们都是对UITableView代理方法进行的一层Rx封装。这样做能让我们避免因直接使用代理而不得不去做一些繁杂的工作,比如我们得去遵守不同的代理并且要实现相应的代理方法等。

    而将代理方法进行Rx化,不仅会减少我们不必要的工作量,而且会使得代码的聚合度更高,更加符合函数式编程的规范。而在RxCocoa中我们也可以看到它为标准的Cocoa也同样做了大量的封装。

    那么我们如何为自己的代理方法添加Reactive扩展呢?

    我们先从tableView.rx.itemSelected的底层实现中探个究竟吧。

    一. itemSelected的底层实现:

    
    extension Reactive where Base: UITableView {
        // events
    
        /**
        Reactive wrapper for `delegate` message `tableView:didSelectRowAtIndexPath:`.
        */
        public var itemSelected: ControlEvent<IndexPath> {
            let source = self.delegate.methodInvoked(#selector(UITableViewDelegate.tableView(_:didSelectRowAt:)))
                .map { a in
                    return try castOrThrow(IndexPath.self, a[1])
                }
    
            return ControlEvent(events: source)
        }
    
    }
    复制代码
    这里我们可以猜测其实现的大致流程是: 通过self.delegate触发UITableViewDelegate.tableView(_:didDeselectRowAt:)方法(即通过代理调用代理的代理方法。有点拗口,后面再理解),并通过map函数把代理方法中的IndexPath参数包装成事件流传出,供外部订阅。

    再来看看其中类型:

    • self: Reactive<Base>extension Reactive where Base: UITableView,可以理解成为Base后面的UITableView添加Rx扩展。
    public struct Reactive<Base> {
        /// Base object to extend.
        public let base: Base
    
        /// Creates extensions with base object.
        ///
        /// - parameter base: Base object.
        public init(_ base: Base) {
            self.base = base
        }
    }
    复制代码
    • delegate: DelegateProxy 代理委托,即"代理的代理"。从这里可以回想一下上文的一句话"通过代理调用代理的代理方法",那么更为准确的说,"通过为"base"设计一个代理委托,当"base"的某个代理方法触发时,其代理委托会做出相应的响应"

    我们来瞧瞧UITableView的代理委托:

    /// 奇了怪了,该delegate怎么在UIScrollView的Reactive扩展里面。虽然UITableView继承自UIScrollView
    但UIScrollView的代理委托怎么就能响应UITableViewDelegate的方法了? 别着急,下文给出了答案。
    
    extension Reactive where Base: UIScrollView {
            /// Reactive wrapper for `delegate`.
            ///
            /// For more information take a look at `DelegateProxyType` protocol documentation.
            public var delegate: DelegateProxy {
                return RxScrollViewDelegateProxy.proxyForObject(base)
            }
    }
    复制代码

    那么是不是我们照葫芦画瓢地为自己的代理设计一个像这样的代理委托,就ok了呢?

    暂不过早的下定论,先来瞧瞧上面提到的 DelegateProxyType,其文档解释有点长,但每个单词都很重要,且看且珍惜。

    ..and because views that have delegates can be hierarchical

    UITableView : UIScrollView : UIView

    .. and corresponding delegates are also hierarchical

    UITableViewDelegate : UIScrollViewDelegate : NSObject

    .. and sometimes there can be only one proxy/delegate registered,
    every view has a corresponding delegate virtual factory method.
    复制代码

    这段话解释了上文提到的delegate写在UIScrollView的Reactive扩展的疑惑。因为view和它们的delegate的响应都可以被继承下来。

    这是DelegateProxyType里的流程图,那么这个图说明了什么呢?

    以UIScrollView为例,Delegate proxy是其代理委托,遵守DelegateProxyType与UIScrollViewDelegate,并能响应UIScrollViewDelegate的代理方法,这里我们可以为代理委托设计它所要响应的方法(即设计暴露给订阅者订阅的信号量)。(----代理转发机制)

    到此,一切瞬间变得清晰起来了有木有?照葫芦画瓢设计代理委托真的就ok呀!

    二. 实战

    下面试着做一个简单的demo来验证一下吧!

    我们首先来设计一个简(zhuo)单(lue)的使用场景:创建一个TouchView类继承自UIView并遵守TouchPointDelegate协议,下面是协议里面的一个代理方法,该代理方法的作用是返回所点击view上的point。

    @objc protocol TouchPointDelegate: NSObjectProtocol {
        @objc optional func touch(at point: CGPoint, in view: UIView)
    }
    复制代码

    我们现在要为上述的代理方法添加Rx扩展,即当我们要使用该代理方法时可以像这样优雅的编码:

    touchView.rx.touchPoint
                .subscribe(onNext: { point in
                    print(point)
                })
                .disposed(by: disposeBag)
    复制代码
    首先我们来设计TouchView的代理委托RxTouchViewDelegateProxy

    要设计DelegateProxy(代理委托),我们先来看一眼RxScrollViewDelegateProxy是如何定义的,且要遵守哪些协议。

    public class RxScrollViewDelegateProxy
    : DelegateProxy,
    UIScrollViewDelegate, 
    DelegateProxyType {}
    复制代码

    现在照葫芦画瓢, 定义代理委托RxTouchViewDelegateProxy并遵守相应的协议DelegateProxyDelegateProxyTypeTouchPointDelegate

    class RxTouchViewDelegateProxy
    : DelegateProxy, 
    DelegateProxyType, 
    TouchPointDelegate {}
    复制代码

    此时会报RxTouchViewDelegateProxy没有实现DelegateProxyType协议方法的警告。

    那么,我们该实现哪些协议方法呢?

    不知道您有没有仔细阅读DelegateProxyType,里面有两个方法的解释中都出现了该语句Each delegate property needs to have it's own type implementing "DelegateProxyType",我们尝试实现这两个方法。

    class RxTouchViewDelegateProxy: DelegateProxy, DelegateProxyType, TouchPointDelegate {
        static func currentDelegateFor(_ object: AnyObject) -> AnyObject? {
            let touchView: TouchView = castOrFatalError(object)
            return touchView.touchDelegate
        }
        
        static func setCurrentDelegate(_ delegate: AnyObject?, toObject object: AnyObject) {
            let touchView: TouchView = castOrFatalError(object)
            touchView.touchDelegate = castOptionalOrFatalError(delegate)
        }
    }
    复制代码

    哎!现在终于看不到烦人的小红点了。

    代理委托设计完成了,接下来就是为TouchView关联设计好的代理委托。同样的,可以先看一眼UIScrollView代理委托的关联。

    extension Reactive where Base: UIScrollView {
            public var delegate: DelegateProxy {
                return RxScrollViewDelegateProxy.proxyForObject(base)
            }
    }
    复制代码

    再次照葫芦画瓢。

    extension Reactive where Base: TouchView {
        var touchDelegate: DelegateProxy {
            /// RxTouchViewDelegateProxy.proxyForObject(AnyObject): 设置代理委托实例
            return RxTouchViewDelegateProxy.proxyForObject(base)
        }
    }
    复制代码

    最后,为代理委托设计它所要响应的方法(即暴露给订阅者订阅的信号量)

    extension Reactive where Base: TouchView {
        // events
        
        var touchPoint: ControlEvent<CGPoint> {
            let source: Observable<CGPoint> = self.touchDelegate.methodInvoked(#selector(TouchPointDelegate.touch(at:in:)))
                .map({ a in
                    return try castOrThrow(CGPoint.self, a[0])
                })
            return ControlEvent(events: source)
        }
    }
    复制代码

    因为swift编译器的bug,导致我们无法直接使用RxCocoa编写好的强转异常的处理函数,所以这里需要我们手动去拷贝这部分代码。当然啦,也可以使用可选形式的方式进行处理。如下。

        static func currentDelegateFor(_ object: AnyObject) -> AnyObject? {
            let touchView: TouchView = (object as? TouchView)!
            return touchView.touchDelegate
        }
        
        static func setCurrentDelegate(_ delegate: AnyObject?, toObject object: AnyObject) {
            let touchView: TouchView = (object as? TouchView)!
            touchView.touchDelegate = delegate as? TouchPointDelegate
        }
    复制代码

    到此我们已经成功为自定义的代理方法添加了Rx扩展。

    ⌘ + R BINGO!
    结语

    因水平有限,对Rx文档的解读难免有疏漏,请阅读本文的同时查看对应的文档内容,如有不当,请多多赐教,感谢您的阅读。

    本文demo: demo

    启发文: RxCocoa 源码解析--代理转发

    展开全文
  • RxSwift-中介者模式

    2019-08-13 14:39:47
    RxSwift中存在很多中介者来帮我们处理很多事情,如map来帮我们处理数据并转化为新的序列;filter来帮我们筛选数据并产生新序列;zip来帮助我们将多个序列合成为一个序列。这些内部复杂的实现不可能每次在用到时...

    proxy.png

    中介者模式,顾名思义,通过中介来连接买家和供应商,减少买家和供应商的联系成本。在RxSwift中存在很多中介者来帮我们处理很多事情,如map来帮我们处理数据并转化为新的序列;filter来帮我们筛选数据并产生新序列;zip来帮助我们将多个序列合成为一个序列。这些内部复杂的实现不可能每次在用到时重新实现一边,通过中介者达到一个很好的复用及管理。

    map

    Observable<Int>.of(1,2,3,4,5,6)
        .map{
            $0+10
        }
        .subscribe(onNext: { (val) in
            print(val)
        }).disposed(by: disposeBag)
    
    • 输出结果在原有序列元素的基础上+10
    • 输出结果为:11 12 13 14 15 16

    filter

    Observable<Int>.of(1,2,3,4,5)
        .filter {$0>4}
        .subscribe(onNext: { (val) in
            print(val)
        }).disposed(by: disposeBag)
    
    • filter中介者筛选条件,筛选数据
    • 输出结果为:5

    以上RxSwift操作符均是我们的中介者,下面我们来看一下定时器中介者的演化。

    普通实现

    实现一个定时器并打印:

    self.timer = Timer.init(timeInterval: 1, target: self, selector: #selector(timerFire), userInfo: nil, repeats: true)
    RunLoop.current.add(self.timer!, forMode: .common)
    
    @objc func timerFire() {
        print("timer")
    }
    
    deinit {
        print("\(self.classForCoder) 销毁")
    }
    

    运行打印,能够跑起来,到这很多人觉得,这不就行了吗,有定时器直接用就好。我们来检查一下,界面是否能够正常释放。这里说明当前页面是push进来的页面,点击返回即可。

    返回后发现我们的deinit并没有消失,那就说明当前页面出现了循环引用,那么此处循环引用肯定是在timerself之间的。

    • self持有timertimer持有当前self构成循环引用

    当然有人会想到,在deinit中给timer置空不就打破了吗,可以吗?当然不行,self不能释放就不会执行deinit。那如果在页面快消失的时候使定时器失效,并置空呢?如下:

    override func viewDidDisappear(_ animated: Bool) {
        self.timer?.invalidate()
        self.timer = nil
        print("viewDidDisappear")
    }
    

    打印:SecondController 销毁

    运行pushpop能够正常销毁,但此处会显着很刺眼,难道我们每一个定时器都要在这个地方处理吗。当然在iOS10系统中苹果提供了block,只需弱引用控制器即可。下面来感受一下(此处没有引用当前控制器):

    self.timer = Timer.init(timeInterval: 1, repeats: true, block: {(timer) in
        print("timer")
    })
    RunLoop.current.add(self.timer!, forMode: .common)
    

    打印:
    SecondController 销毁
    timer

    我们可以看到,当前控制器被销毁了,但是定时器好像并没有停止打印,因此这里定时器并没有销毁,其实定时器是被RunLoop所持有,为解决这一问题,我们还是需要像上面那样使定时器失效并置空才能解决。

    以上方法都不便于我们对定时器的管理,而我们理想中的定时器需要跟随引用者的释放而释放,我们只负责创建和处理定时器事件。那么我们就引入中介者,把timer的失效和置空交给中介者解决就行。

    中介者实现

    首先中介者要知道外界的方法选择器便于调用,再者为打破self->timer->self的循环引用,中介者内部对self做弱引用。声明属性如下:

    weak var target: NSObjectProtocol?
    var sel: Selector?
    var timer: Timer? = nil
    
    • 管理外界对象,外界选择器,及内部的timer定时器

    仿造Timer定时器方法,对外设置定时器方法接受外部调用对象即选择器:

    func hb_scheduledTimer(timeInterval ti: TimeInterval, target aTarget: Any, selector aSelector: Selector, userInfo: Any?, repeats yesOrNo: Bool){
        self.timer = Timer.init(timeInterval: ti, target: self, selector: #selector(hb_timerFire), userInfo: userInfo, repeats: yesOrNo)
        RunLoop.current.add(self.timer!, forMode: .common)
        //此处对外self是弱引用
        self.target = (aTarget as! NSObjectProtocol)
        self.sel = aSelector
    }
    
    • 内部定义定时器,设定target为当前中介者类
    • 设定定时器触发方法为中介者类的方法
    • 定时器加入到RunLoop
    • 保存外界目标对象及选择器

    重点在中介者定时器触发方法中:

    @objc fileprivate func hb_timerFire(){
        if self.target != nil{
            self.target!.perform(self.sel)
        }else{
            self.timer?.invalidate()
            self.timer = nil
        }
    }
    deinit {
        print("\(self.classForCoder) 走了 ")
    }
    
    • 有目标对象,通过perform调用目标对象的方法
    • 没有目标对象,即清除定时器,解除RunLoop对定时器的引用

    以上中介者已构建完成,下面调用测试一下:

    class SecondController: UIViewController{
        let proxy = TimerProxy()
    
        override func viewDidLoad() {
            super.viewDidLoad()
            self.view.backgroundColor = .white
            self.proxy.hb_scheduledTimer(timeInterval: 1, target: self, selector: #selector(timerFire), userInfo: nil, repeats: true)
        }
        @objc func timerFire() {
            print("timer")
        }
        deinit {
            print("\(self.classForCoder) 销毁")
        }
    }
    

    pushpop页面打印如下:

    timer
    timer
    SecondController 销毁
    TimerProxy 走了 
    
    • 所有对象均被销毁,由于中介者内部对当前self是弱引用,所以当前控制器能够正常销毁
    • 当前控制器销毁后,proxy内部弱引用对象target也会被销毁
    • proxy内部定时器执行判断target时,发现targetnil即释放了定时器
    • proxy不持有timertimer也不持有proxy,即proxy会被销毁

    RxSwift定时器

    let timer = Observable<Int>.interval(1, scheduler: MainScheduler.instance)
    timer.subscribe(onNext: { (time) in
        print(time)
    }).disposed(by: disposeBag)
    

    以上序列其实就是一个中介者,在RxSwift中管理了Timer对象,在当前对象销毁时清除垃圾袋并销毁定时器对象。

    以上就是中介者对象的作用,直接使用,不用再对项目中定时器做释放操作。中介者其实就是封装复杂繁琐的操作,和不便于管理的业务,简化操作流程,让开发变得更简洁更高效。

    展开全文
  • RxSwift 之官方文档

    2019-07-20 08:32:49
    RxSwift 官方文档结构 Introduction: Subjects Transforming Observables Filtering Observables Combining Observables Error Handing Operators Observable Utility Operators Conditional and Boolean...
  • RxSwift补充

    2019-06-11 17:43:36
    再实际开发中,项目接入rxSwift时,难免会遇到一些封装的代码实用了代理,代理 很明显不符合rxSwift的链式编程,于是,需要对已有的代理进行处理。 这里需要建立一个中间代理,每次触发delegate时,都会先触发中间...
  • DelegateProxy 由英文意思就看处理,委托代理,注意:该类的实现并不是安全的,目前只能用于主线程。 DelegateProxyType DelegateProxyType协议允许使用正常的代理和Rx可观察者序列视图,并且只有唯一的delegate/...
  • RxSwift--中介者模式

    2019-08-15 11:55:49
    文章目录一、中介者模式二、应用举例:解决循环引用问题 一、中介者模式   中介者模式定义了一个中介对象来封装一系列对象之间的交互关系,使各个对象只与中介对象交互,各个对象之间不需要显式地相互引用,降低...
  • 代理 是iOS 开发里面一个很重要的内容,在关键时刻可以发挥重要作用,实训中使用到的例子是:* 点击一个tableviewcell中的一个按钮,跳转到另一个页面 * 如果简单的话当然可以直接storyboard连接过去,但是如果想...
  • Alamofire的设计之道

    2017-06-03 19:00:51
    前言:Alamofire是一个由Swift编写的优雅的网络开发框架。大部分用Swift编写的iOS App的网络模块都是基于Alamofire的。作为Swift社区最活跃的几个项目之一,有许多开发者在不断的对其进行完善,所以学习这种优秀的...
  • Subject & Schedulers

    2017-12-28 22:09:44
    Subject & Schedulers ...A Subject is a sort of bridge or proxy that is available in some implementations of ReactiveX that acts both as an observer and as an Observable. Because it is an observer, it can
  • http://www.jianshu.com/p/fd5d193f3d36 问 http://www.jianshu.com/p/c687110e552c 答   4道过滤菜鸟的iOS面试题 1.struct和class的区别 2.介绍一下观察者模式 ...4.在一个app中间有一个but...
  • 第18月第2天 ios博客

    2019-07-06 15:44:37
    1. github https://githuber.cn/search?language=Objective-C https://www.jianshu.com/u/815d10a4bdce https://blog.csdn.net/hello_hwc https://blog.ibireme.com/2015/05/18/runloop/ ...
  • 去年,我在微博上发起了100天阅读博文的行动。具体就是,每天读一篇 iOS 开发相关的技术博文,并在微博上分享自己的读后感。对于在开发、工作、和面试中常见的问题,通过这段时间100篇博客的阅读,我产生了自己的...
  • iOS高级进发 OC源码下载地址 苹果开发文档 如何阅读苹果开发文档 GNUstep是GNU计划的项目之一,它将Cocoa的OC库重新开源实现了一遍 源码地址:... iOS底层 1、一个NSObject对象占用多少内存 ......
  • TimLiu-iOSgithub排名 https://github.com/trending,github搜索:https://github.com/searchObjective-C版本点击这里 欢迎加入QQ交流群: 594119878使用方法:根据目录关键字搜索,记得包含@,以保证搜索目录关键字...
  • 2020面试题汇总

    2020-06-04 08:49:57
    2020不平凡的一年,无论是关于本身,还是关于生活,都不是好过的,再加上自己的人生低谷,无以复加,人道中年,真的也是雪上加霜。慢慢人生之路,不知何去何从,可我们没法选择我们自己的局,不管手中的牌是好是坏,...
1 2
收藏数 22
精华内容 8
热门标签