泊学看来的，记录一下，忘了回来翻一下，理论不好记，让代码说明一切

扩展CoreLocation

实话说，搞清楚RxCocoa处理UIKit delegate的机制略显复杂。简单来说，就是它设置了一个delegate proxy，这个proxy可以替我们从原生delegate获取数据，然后变成Observables供我们使用。而我们要做的，就是自己为CLLocationManager定义一个这样的proxy，然后注册到RxCocoa就行了。这个过程要比理解这个机制的细节，简单多了。大体上说，分成三步。

首先，在Extensions group中，添加一个CLLocationManager+Rx.swift文件，这也是符合RxCocoa命名约定的做法；

其次，我们要告诉RxCocoa，CLLocationManager是一个有delegate的类型，这是让它遵从HasDelegate实现的。HasDelegate是RxCocoa定义的一个protocol，它有两个约束，一个是Delegate，表示原生delegate的类型，这里，当然就是CLLocationManagerDelegate：

extension CLLocationManager: HasDelegate {
    public typealias Delegate = CLLocationManagerDelegate
}

另一个是delegate对象，我们稍后再说。

第三，我们就要实现CLLocationManagerDelegate的proxy了。先来看它的声明：

class CLLocationManagerDelegateProxy:
    DelegateProxyType,
    CLLocationManagerDelegate,
    DelegateProxy<CLLocationManager, CLLocationManagerDelegate>

这里：

DelegateProxyType是RxCocoa定义的protocol，它约束了RxCocoa中，delegate proxy的接口；
而DelegateProxy<CLLocationManager, CLLocationManagerDelegate>可以理解为是遵从DelegateProxyType的一份标准实现，这份实现需要两个泛型参数，分别是类型自身和与这个类型搭配工作的原生Delegate类型；
最后，作为CLLocationManager的delegate proxy，我们当然得让它也遵从CLLocationManagerDelegate；
理解了这个声明之后，实现它就容易多了，首先是它的属性和init方法，无非就是创建一个CLLocationManager对象，并传递我们期望的CLLocationManager的delegate proxy类型：

class CLLocationManagerDelegateProxy:
    DelegateProxyType,
    CLLocationManagerDelegate,
    DelegateProxy<CLLocationManager, CLLocationManagerDelegate>, {
    weak private(set) var locationManager: CLLocationManager?

    init(locationManager: ParentObject) {
        self.locationManager = locationManager
        super.init(parentObject: locationManager,
            delegateProxy: CLLocationManagerDelegateProxy.self)
    }
}

完成后，唯一需要我们实现的一个DelegateProxyType方法是registerKnownImplementations。它用于向RxCocoa注册我们自定义的DelegateProxyType：

static func registerKnownImplementations() {
    self.register {
        CLLocationManagerDelegateProxy(locationManager: $0)
    }
}

至此，RxCocoa中的delegate proxy机制理论上就有能力可以转发CLLocationManagerDelegate的方法了。但我们还没法使用它，而这就是我们接下来要完成的部分。

最后，给CLLocationManager对象添加rx扩展。这里，我们稍微多做一点功课，先来了解下rx这个“名字空间”是怎么来的。

在workpaces中，打开Pods/RxSwift/Reactive.swift，在这里，先是两个类型的定义：

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
    }
}

/// A type that has reactive extensions.
public protocol ReactiveCompatible {
    /// Extended type
    associatedtype CompatibleType

    /// Reactive extensions.
    static var rx: Reactive<CompatibleType>.Type { get set }

    /// Reactive extensions.
    var rx: Reactive<CompatibleType> { get set }
}

其中，Reactive<Base>可以理解为一个具备响应式能力的类，它的泛型参数Base表示要进行响应式扩展的原始类。例如：Reactive<UITextField>表示一个具备响应式能力的输入框。接下来，ReactiveCompatible为所有支持响应式扩展的类型定义了“名字空间”rx，静态版的rx表示类型自身，而类对象属性版的rx则表示一个具体的类对象。

接下来，RxCocoa为ReactiveCompatible提供了一个默认的实现：

extension ReactiveCompatible {
    /// Reactive extensions.
    public static var rx: Reactive<Self>.Type {
        get {
            return Reactive<Self>.self
        }
        set {
            // this enables using Reactive to "mutate" base type
        }
    }

    /// Reactive extensions.
    public var rx: Reactive<Self> {
        get {
            return Reactive(self)
        }
        set {
            // this enables using Reactive to "mutate" base object
        }
    }
}

可以看到，这个实现正是我们刚才描述过的两个版本rx的功能。然后，在这个文件最后，我们可以发现下面的代码：

import class Foundation.NSObject

/// Extend NSObject with `rx` proxy.
extension NSObject: ReactiveCompatible { }

看到这里，一切就都真相大白了。实际上，所有NSObject的派生类在RxCocoa都已经自带了两个版本的rx属性。我们无需做任何额外的事情。唯一要做的，就是让“对象版本”的rx可以访问一开始我们设计的didUpdateLocations方法就好了。

有了这个思路之后，我们继续添加下面的代码：

extension Reactive where Base: CLLocationManager {
    var delegate: CLLocationManagerDelegateProxy {
        return CLLocationManagerDelegateProxy.proxy(for: base)
    }
}

由于我们一开始，让CLLocationManager遵从了HasDelegate，因此在这里，我们要定义另外一个约束delegate，它表示用于“代理请求”的对象，而这个对象，当然就是我们自己创建的CLLocationManagerDelegateProxy。唯一需要注意的，就是绝对不要手工调用init方法创建proxy delegate对象，而始终要通过proxy方法返回，记住这点就好了。

定义好delegate之后，我们继续在extension Reactive中实现希望的方法：

extension Reactive where Base: CLLocationManager {
    ///...

    var didUpdateLocations: Observable<[CLLocation]> {
        let sel = #selector
            CLLocationManagerDelegate.locationManager(_:didUpdateLocations:))

        return delegate.methodInvoked(sel).map {
            parameters in parameters[1] as! [CLLocation]
        }
    }
}

可以看到，形式上，我们只是通过delegate调用了原生的didUpdateLocations。这里，methodInvoked会返回一个Observable<[Any]>，其中[Any]表示原生的delegate方法带有的所有参数，因此，parameters[1]就表示之前我们使用的[CLLocation]。为了方便在代码中使用，我们对这个Observable进行了一次map。

完整代码如下： 整理了一下

import UIKit
import RxSwift
import RxCocoa
import CoreLocation

extension CLLocationManager: HasDelegate {
    public typealias Delegate = CLLocationManagerDelegate
}

class CLLocationManagerDelegateProxy:
    DelegateProxy<CLLocationManager, CLLocationManagerDelegate>,
    DelegateProxyType,
    CLLocationManagerDelegate {
    weak private(set) var locationManager: CLLocationManager?
    
    init(locationManager: ParentObject) {
        self.locationManager = locationManager
        super.init(parentObject: locationManager, delegateProxy: CLLocationManagerDelegateProxy.self)
    }
    
    static func registerKnownImplementations() {
        self.register { CLLocationManagerDelegateProxy(locationManager: $0) }
    }
}

extension Reactive where Base: CLLocationManager {
    var delegate: CLLocationManagerDelegateProxy {
        return CLLocationManagerDelegateProxy.proxy(for: base)
    }
    
    var didUpdateLocations: Observable<[CLLocation]> {
        let sel = #selector(CLLocationManagerDelegate.locationManager(_:didUpdateLocations:))
        
        return delegate.methodInvoked(sel).map {
            parameters in parameters[1] as! [CLLocation]
        }
    }
}