一般情况下，从业务方从API中请求JSON数据时，一般都会经过以下三步：

1
2

--------1------------2----------
原始数据 -> JSON/字典  -> Model

当然，大部分情况下，原始数据就是JSON，所以第一步基本上只是对接受数据的一个类型转换。一般在网络层中，由组件方提供1步骤，而业务方往往在网络组件的回调中提供步骤2。简单的转换逻辑明了了，接下来就可以试下用Moya实现步骤1，ObjectMapper实现步骤2。

在结合RxSwift+Moya+ObjectMapper三者之后，常规JSON数据的获取与解析变得更加精简。以近期编写的一个V2ex API为例，获取个人信息接口如下：

1
2
3
4
5
6
7

func fetchMemberInfo(_ username: String? = V2exAppContext.shared.currentUsername,
                     _ id: Int? = nil) -> Observable<V2exMember> {
    return V2exProvider
        .request(.ShowMembers(username: username, id: id))
        .mapObject()
        .shareReplay(1)
}

嗯，没错，最终的调用就是这么简单明了！

create a disposable resource that has the same lifespan as the Observable，即创建一个和Observable具有相同生命周期的disposable资源。

这是ReactiveX对于Using的描述。

可以看出，当一个ObserverA订阅Using返回的Observable时，Using会使用调用者传入的Resource工厂方法[resourceFactory]创建对应的资源，并且使用Observable工厂方法[observableFactory]创建ObserverA实际上想要订阅的Observable。当ObserverA终止时，对应的Resource也会被释放[dispose]。

在RxSwift中，订阅者都会返回一个Disposable（默认是Disposables），以便使用者可以在后续的操作中，取消此次订阅。

使用者可以调用dispose方法来进行取消订阅：

1
2
3
4
5
6
7

let disposables = Observable
    .just(1)
    .delay(2, scheduler: MainScheduler.instance)
    .subscribe { event in
        print(event)
    }
disposables.dispose()

关于手动取消订阅后，对应的subscribe回调会不会调用，官方的手册是这么说的：

• 当scheduler是串行调度器，并且使用者在此调度器上调用了dispose，那么回调就不会执行［MainScheduler是在主线程/UI线程的串行调度器］
• 其他情况都不能保证回调的执行与否［并行情况下，执行顺序无法保证］

和ReactiveCocoa的实现类似，RxSwift也是通过不停地订阅上游的Observable来实现数据的流动。

Rx操作大体分为两种：

• 创建: create、just、of、from等
• 处理: map、flatMap、do等

接下来通过下面的操作来简单分析下代码执行过程：

1
2
3
4
5

let _ = Observable.just(1)
    .map { $0 }
    .subscribe(onNext: {
    print($0)
})

1、Xcode8日志及Pod的Swift3.0问题

2、UITextFiled使用UITextAlignmentRight输入空格光标不实时跟进

3、解决使用UIAlertController时，Attempt to present vc whose view is not in the window hierarchy! 问题

4、单例在 Unit Test 中不唯一问题

说到图片浏览器，项目中比较常用的成熟框架有Objective-C版本的MWPhotoBrowser，IDMPhotoBrowser或者Swift版本的SKPhotoBrowser。

从核心功能来看，MWPhotoBrowser，IDMPhotoBrowser这两个框架，都很好地实现了对本地资源、相册资源、网络资源的获取与显示。并且很好地封装了网络和相册的获取方式，在我看来，这是他的优势，但同时，高度的集成也催生了一些不足。

这样做的优势不言而喻，调用者只需要很少的几行代码，就可以集成一个图片浏览器框架，省时省力。以MWPhotoBrowser为例，在不设置额外属性的情况下，只需要下面两行代码就可以创建：

1
2

MWPhotoBrowser *browser = [[MWPhotoBrowser alloc] initWithPhotos:self.photos];
[self.navigationController pushViewController:browser animated:YES];

使用者只要关注如何提供MWPhotoBrowser所要展示资源就可以了，不需要做额外的操作，非常地简洁方便。

关于不足，由于MWPhotoBrowser内部实现了获取网络图片功能，在追求内部实现尽量精简的前提下，不可避免地要依赖加载图片的第三方库(SDWebImage)。如果原来项目并没有使用SDWebImage，而是用YYWebImage或者Kingfisher，那么使用MWPhotoBrowser便会引入冗余的框架，从而让项目额外增加了一种图片缓存机制，不利于内存以及磁盘使用率的优化。

对于相册资源的访问，MWPhotoBrowser内部也实现了通过PHAsset或者ALAsset获取相片的功能。不过一般来说，项目会有自己的一套相册选择器，进而会有相应的相册资源获取策略。所以以个人观点来看，如何获取相册资源，应该由使用者告知，而不是在框架内部自己实现一套，这样更加符合DRY。

接下来，我会针对上面的不足，实现一套兼容本地资源、相册资源、网络资源的简易图片选择器。

本文章对应的所有代码在仓库TBVImageBrowser中。

iOS8之后，苹果推出了PhotoKit，让开发者在处理相册相关的业务时，可以更加得心应手。github上的开发者针对PhotoKit做了一层很优秀的封装CTAssetsPickerController，如果只需要支持iOS8+，那么可定制程度非常高的CTAssetsPickerController是个不错的选择。

但是由于现有的业务还是需要支持iOS7，所以并不能完全舍弃使用AssetsLibrary的方式来访问相册。因此也就需要自己封装一套兼容iOS7的相册管理器。

本文涉及代码：TBVAssetsPicker

1、dispatch_after及NSTimer造成对象无法释放

2、宏定义##与#

3、Swift实现原子属性

4、Xcode图像化调试错误

5、UITabBarController调用viewDidLoad的时机

YYModel是由ibireme开发的一套小而精美的模型转换框架，采用分类的形式，无需继承框架的某个基类就可以方便地完成模型的转换，且内部做了自动类型转换和安全处理，可以有效地防止因模型类型和后台给的数据类型不一样而产生的崩溃问题。

近些天抽空拜读了一下其源码，果然是思维严谨，考虑的一些细节也很到位，让人自叹弗如。虽然作者说这个框架是花了两个周末的时间完成的，但是其代码质量还是非常让人惊艳的，值得仔细阅读。

MQTT全称Message Queue Telemetry Transport，是一个针对轻量级的发布/订阅式消息传输场景的协议，同时也是被推崇的物联网传输协议。MQTT详细的介绍文章可以从官方网站获得，所以这里就不进行详细的展开了，而是针对这些天的使用经历与感受做一番纪录。

MQTT开源的iOS客户端有以下几种：

1
2
3
4

|MQTTKit  |Marquette|Moscapsule|Musqueteer|MQTT-Client|MqttSDK|CocoaMQTT|
|---------|---------|----------|----------|-----------|-------|---------|
|Obj-C    |Obj-C    |Swift     |Obj-C     |Obj-C      |Obj-C  |Swift    |
|Mosquitto|Mosquitto|Mosquitto |Mosquitto |native     |native |native   |

以上开源库我只看过部分MQTTKit、MQTT-Client、CocoaMQTT的开源代码，总体来说MQTT-Client支持的功能更多全面一些。如果只是对协议本身进行学习不考虑功能的话，可以阅读CocoaMQTT，也可以阅读我重写的SwiftMQTT，因为代码量相对前面两个库少了很多。

而MQTT的broker一般选择Mosquitto，Mosquitto是一个由C编写的集客户端和服务端为一体的开源项目，所以相对来说风格较为友好，可以无障碍地阅读并调试源码（开源地址）。可以看到，以上客户端开源库中的前四种就是基于Mosquitto的一层封装。