2017年又开始了，回想2016年，还是感觉自己做的不够好，原因也是各方面，不多说了。
现状
大家都知道，app的网络层是很重要的，AF 虽然已经帮我们封装了 AFHttpSessionManager ，但实际在开发中，因为业务的要求变得复杂，所以用起来变得越来越麻烦，而且代码耦合、重用也不好，这也是为何很多人要自己再进行封装的原因。毕竟满足自身业务需要的轮子，才是好轮子。
分析
怎么进行网络层的设计？我是参考了Casa大神是思路。不过，app本来很简单，接口少，那集约型设计就够了，维护起来应该不至于要骂娘。而如果接口多起来，我还是会偏向于离散型，毕竟，维护成本提高相比类爆炸，个人偏向于让项目更好维护，而且离散型设计，拓展性更好一些，谁知道会有什么新奇葩需求过来😳。
为了分析网络层，我将网络层分成了四个主要连续步骤：
- 生成request
- request起飞
- response落地
- 数据交付
在每一层中，我们都可以将工作更细化，并且加入各种状态的监控，我通过思维导图做了一些基本分析，如下：
网络层结构分析
图片是xmind导出的，这里有原xmind文件
简单说一下：
1、request生成需要各种参数，主要包括业务参数和http请求参数。
2、生成一个请求之后，通过AF让请求起飞，在请求起飞前，我们可以根据参数判断是起飞还是直接进入请求失败，而且起飞时候，如果这个请求起飞任务还在队列中，那么我们还有机会取消这个起飞任务，而如果已经上天了，那么取消任务，只是将这个task标记为 being canceled（正在被取消）,
/* -cancel returns immediately, but marks a task as being canceled.
The task will signal -URLSession:task:didCompleteWithError: with an
error value of { NSURLErrorDomain, NSURLErrorCancelled }. In some
cases, the task may signal other work before it acknowledges the
cancelation. -cancel may be sent to a task that has been suspended.
*/
- (void)cancel;
3、response落地一方面可能需要统一response的格式，这个需要自定义，另一方面，对于请求成功，业务错误的response，一并归到请求失败中，并给予不通的错误类型。
4、业务数据应该是没有必要转成model的，所以通过一个reform 将原始的response转换成UI需要的，这个Casa在文章中有说明。另一个方面就是将response的key，使用专门的头文件替代，并且用extern修饰，这样Xcode就有智能提示
总结
这些思路大多是借鉴Casa大神的，我只是根据自己的理解做了分析。一个架构的形成肯定是由简入繁，所以我才将网络层分成四部分，先确定基本的骨架，然后再丰富皮肉。解决问题就应该用这种思路吧，我也算是给自己上了一课。
