IOS应用架构思考一（网络层）

最近看到Casa Taloyum同学的关于IOS架构的文章，分享的概念和观点很值得一看，于是不禁心痒，也做些分享吧，我会从实际设计过程中需要思考的问题的角度着手来讲述，毕竟无论什么样的架构，什么样的设计都是要解决这些问题的。

今天就先讲讲网络层的需要思考的问题吧。

1.requestOperation的设计

我们都知道在客户端发送请求是需要成本的，那么设计异步的请求就是首要的问题。我们知道Cocoa提供了非常丰富和易于使用的异步api, 有NSOperationQueue, dispatch queue, NSThread等。那么如何选择呢，答案毫无疑问的必须是NSOperation。 不信你去看ASIHTTPRequest和AFNetworking. 好像这个理由不够充分是吧，而且很多人就是使用了这些框架，而不清楚它们到底为何优秀，那我就列举下一些它们的优点吧

首先举个反例吧：曾经有人问过我“为什么要用AFNetworking和ASI这样的框架呢，我直接dispatch到后台用类似dataWithURL:拉数据这样不是很简单？”。 那么这样的使用案例有2个很致命的缺陷：第一个就是无法cancel这个请求，第二个是占用了完整的一个线程。

可以cancel

请求可以cancel的需求的重要性不用说了吧，别说你没用过。使用NSOperation可以让你方便的设计cancel一个请求的方法。

线程

说道线程可能很多人对发送请求的时候线程有个很大的误解： 每个请求占用一个线程。其实不是的，无论同时并发多少个请求，AFNetworking和ASI都是只有一个线程在等待的。不信请看AFNetworking的实现：

+ (void)networkRequestThreadEntryPoint:(id __unused)object {

@autoreleasepool {

[[NSThread currentThread] setName:@"AFNetworking"];

NSRunLoop *runLoop = [NSRunLoop currentRunLoop];

[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

[runLoop run];

}

}

+ (NSThread *)networkRequestThread {

static NSThread *_networkRequestThread = nil;

static dispatch_once_t oncePredicate;

dispatch_once(&oncePredicate, ^{

_networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];

[_networkRequestThread start];

});

return _networkRequestThread;

}

- (void)start {

[self.lock lock];

if ([self isReady]) {

self.state = AFOperationExecutingState;

[self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];

}

[self.lock unlock];

}

从上面的代码中我们可以看到，AFNetworking在等待请求时其实只有个一个Thread, 然后在这个Thread上启动一个runLoop监听 NSURLConnection 的 NSMachPort 类型源。 start里面直接就跳到这个线程去执行了， 在加入NSOperationQueue时，顶多start方法执行的时候占用一个线程，然后真正的发送请求和等待都是在这个networkRequestThread里面进行的。

补充一下，上面的描述可能引起误会，已经有人问我这个疑问了。注意， 上面讲的networkRequestThread 并不是最终访问网络并拉取数据的线程。真正的下载数据是NSURLConnection统一调度的，networkRequestThread 只是启用了一个runLoop来监听NSURLConnection的回调事件。

了解上面两点后我们再看前面的例子，就会发现问题有多致命了。

如果同时并发了很多个请求，那就是实实在在的占用了n个线程了，而且请求不能cancel，对于这些被占用掉得大量资源就束手无策了。

线程安全，说道线程，肯定要有线程安全，相关的资源已经够多了，本文就不讲了。

并发数量限制

如果用NSOperationQueue来说明，就是maxConcurrentOperationCount, 最大并发数量。

可能有人指出了, 刚才不是讲请求都是在一个线程等待的吗，那并发数量岂不是没有太大意义？ NO, 并发数量还是有重要的意义的，它的意义就是带宽，下载数据是要流量的，如果同时并发了太多请求，可能导致每个请求的时间均会延长，就好像你在迅雷同时下载10个文件，那么下载速度都慢了。

当然maxConcurrentOperationCount也不能设置太小，太小了的话，如果个别的请求太慢，导致后面的任务就启动不起来了。

并发数量的考虑应该从上面两个点出发，因此如果有人再扯到线程上去，只能说走远了。

具体的数值定位其实不太好定位，要在上述两个考虑中寻找均衡点，具体情况具体分析，最好能有数据支撑得出最佳结果，给个我们使用的参考，我们一般设置为10.

pause & dependency

可暂停的，可添加依赖的，这些可能不常会用到，但是如果要设计网络层框架还是要考虑的，这也是要用NSOperation的原因之一。

本节内容说出了开源框架在operation的设计上的一些优点，因此也推荐这部分直接使用AFNetworking之类的框架，因为优秀的开源组件总有其优点，他们考虑了很多你甚至都没有意识到的问题，以前有是遇到过一些同学质疑AFNetworking,质疑arc, 质疑SDWebImage, 质疑Masonry等，当然不是说没有缺点，但是这些东西当你真正深入了解学习后我觉得才能做出正确的选择。

2. 安全性

很多IOS客户端开发者不注重安全性，当然也因为IOS系统已经做得很不错的原因，还有安全的主要工作是在后端，比如使用https啊，比如加签啊，那么前段的网络框架设计要注意哪些安全性的问题呢。

https中间人

https是非常安全的协议，可以参考我以前的博客RSA加密数字证书里面。但是可能还是会存在中间人攻击的问题，那么就需要打ssl钢钉，AFNetworking中的AFURLConnectionOperationSSLPinningMode就是可以设置ssl钢钉的，原理就是把证书或者公钥 打包到bundle中，发送请求的时候会与请求过来的证书比较，因此避免中间人发放的伪造证书可能。

3. 组件设计

无论你是用AFNetworking之类的开源组件还是自己封装的方式，一般我们都会封装下中间组件，一来可以降低业务代码和底层组件的耦合，二来方便拓展。那么设计这些组件的时候需要注意哪些呢？

回调方式

这部分选择不少，主要是能统一和方便，可能会考虑下面2个问题 1、是选择block回调方式，还是delegate, 还是target-action, 可以根据自己的喜好来设置，也可以兼容多种。 2、success和fail分开回调还是同一个方法回调。

拦截器

request的部分可能会有些场景需要请求前和请求后的拦截器的设计，在这样的拦截器接口中，我们就可以做一些事情如： 1、session过期后自动登录 2、需要登录的接口进入登录

统一cancel还是单独cancel

在一个页面中发送请求的时候，无疑会碰到一个问题，那就是“页面退出时请求要取消”。

我们最开始是如何做的呢，就像内存管理，谁启动，谁cancel, 即是单独cancel. 使用方式类似下面：

@interface AViewController: UIViewController {

HTTPRequest *_request;

}

@end

@implementation AViewController

- (void)dealloc {

[_request cancel];

}

- (void)sendRequest {

[_request cancel];

_request = [[HTTPRequest alloc] init];

[HttpClient sendRequest:_request];

}

@end

然后就觉得每个地方都要在dealloc里面写cancel，很麻烦，于是可能想要做个统一的cancel，类似封装个方法在父类里面调用：

@implementation BaseViewController

- (void)dealloc {

[HttpClient cancelRequestForDelegate:self];

}

@end

这样的话好像就更方便了，代码量也少了一些，调用的类也不用去管cancel了， 但是这样真的好么，虽然可能让你暂时方便了，但是这样的设计还是不紧凑，其实这个请求是否应该被取消应该是调用者的逻辑，这样就相当于一部分的逻辑放在父类里面，是有点坑的，第一种写法虽然可能麻烦写，但是就像内存管理，谁创建，谁负责销毁，这样的代码可读性和维护性更高些。不然如果遇到特殊的逻辑，可能要去动父类或底层。

说到这里就是建议上面代码中的request对象的封装就是Operation本身，这样其实就不需要再在viewController里面写很多isLoading, isLoaded的状态位了啊，NSOperation自带的。

4. 缓存

说道网络请求，就不能不提网络缓存，数据缓存是提升用户体验不可缺少的重要一环。而对于缓存可以讲的太多了，比如图片缓存可以单独开篇文章来讲了，这里就讲一下关于普通接口数据的缓存。一般我们对于缓存的方式有两种做法，一种是客户端写缓存实现和缓存逻辑，一种是遵循HTTP协议的缓存。

4.1 自己实现缓存逻辑

一般需要这种缓存的逻辑无非是考虑下面的需求：

1、接口返回的数据很少变动，不希望做重复请求 2、网络慢或者服务器等异常状况容灾。

自己实现也比较灵活，你可以写个数据库来缓存、也可以直接序列化存文件。但是缺点也比较明显，那就是缓存时间不好定义。

既然做了缓存，那么就会遇到这个问题，就是数据刷新了之后，缓存不更新怎么办。那么其实在你选择这种缓存实现之前就需要做权衡，是数据实时性重要，还是数据加载速度重要。想好这个问题才能确定是否要这样的缓存。

4.2 HTTP缓存

这种缓存方案是比较推荐的方案，HTTP协议已经定义了好了一套缓存方案，为什么不用呢。 而且苹果已经帮我们实现好了缓存的代码，NSURLCache，数据缓存在本地sqlite里。不过就是要和服务端同学一块推进。

可以缓存的接口，可以在返回的 responseHeaders 中添加 cache-control 和 Expires 来告诉前端是否可以缓存和缓存时间等。

而客户端可以通过设置 cachePolicy 来决定是否使用缓存

typedef NS_ENUM(NSUInteger, NSURLRequestCachePolicy){    NSURLRequestUseProtocolCachePolicy = 0,    NSURLRequestReloadIgnoringLocalCacheData = 1,    NSURLRequestReloadIgnoringLocalAndRemoteCacheData = 4, // Unimplemented    NSURLRequestReloadIgnoringCacheData = NSURLRequestReloadIgnoringLocalCacheData,    NSURLRequestReturnCacheDataElseLoad = 2,    NSURLRequestReturnCacheDataDontLoad = 3,    NSURLRequestReloadRevalidatingCacheData = 5, // Unimplemented};

考虑一种场景，你不能确定数据什么时候更新，可能随时刷新，也可能几天才更新，那么我们如何使用缓存呢。

可以使用 ETag/If-None-Match 或者 Last-Modified/If-Modified-Since。

两种方式原理差不多，就是在发送请求的 requestHeaders 中加入 If-None-Match 或者 If-Modified-Since 字段，和服务端数据进行比较是否有更新，有更新则返回body，没有的话就在responseHeaders中告知使用缓存。 两者中， ETag是比较hash， Last-Modified是比较最后更改时间。

ASIHTTPRequest实现了这种模式，如下：

if ([self cachePolicy] & (ASIAskServerIfModifiedWhenStaleCachePolicy|ASIAskServerIfModifiedCachePolicy)) {              NSDictionary *cachedHeaders = [[self downloadCache] cachedResponseHeadersForURL:[self url]];              if (cachedHeaders) {                  NSString *etag = [cachedHeaders objectForKey:@"Etag"];                  if (etag) {                      [[self requestHeaders] setObject:etag forKey:@"If-None-Match"];                  }                  NSString *lastModified = [cachedHeaders objectForKey:@"Last-Modified"];                  if (lastModified) {                      [[self requestHeaders] setObject:lastModified forKey:@"If-Modified-Since"];                  }              }          }

5. 服务器推

对于很多需要精细化体验的app来说，HTTP协议的模式已经不能够满足需求了， 比如支付宝可以随时随地的推活动。那么就需要服务器推的技术了。

5.1 SPDY 或 HTTP/2

spdy 和 HTTP2 协议都定义了关于服务端推送的协议，还有一些其他的相对于http的优良特性. 一些大公司应该都做了对于spdy的支持，ios中可以使用twitter开源的CocoaSPDY。 不过Google刚刚宣布了不再支持SPDY，以后都走HTTP/2了。

关于这些我还没有详细的学习，这里就不多讲了，以后多多学习。

5.2 长连接

另一种比较灵活和强大的方法服务器推送的方案就是TCP长连接了，长连接可以让你做很多事情，唯一的难题就是要处理好心跳包。

小结

就写到这里吧，后面想到了再补充，欢迎讨论和指正。

==============题外话=================

有一个读者 想知 AFNetwork 的2次封装

常年转载别人的文章，实力有限，简单说下

2次封装是为了

1. API 管理

每个业务块都会创建并封装所有的请求

AFNetwork-》AFNetwork(2次封装)-》A,B,C,D 各个模块api 封装类

2.个性化的 ，域名设置 请求头部，参数，返回处理

AFNetwork(2次封装)

可以统一设置请求头部 "text/html", @"text/json", @"text/plain"

超时时间

固定不变的参数- 设计api的时候版本，token 之类的基本上固定的 此处 封装，发起请求的时候直接用

错误码，错误相应处理 ，本人此次做了针对每个 api请求失败统计

3.队列管理

根据业务 可以针对每一个请求队列进行管理

例子：应用刚打开-请求已经发送-用户手机获取到了地理位置信息（打算 重新发送请求）-取消第一次已经发出的请求-发出请求

这样会避免数据覆盖等问题

4.其他 参数封装的共同行为，接口管理，业务处理的共同行为

这些都是业务决定的

====================题外话结束===========

如果大家有自己的封装心得 可以一起交流哈