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, 并发数量还是有重要的意义的，它的主要意义就是控制连接数。> 这里多谢 CasaTaloyum 同学的勘误，我原本不知道2G, 3G, 等网络协议的限制。

2G网络下一次只能维持一个链接，3G是2个，4G和wifi是不限。这个是对应协议的限制。如果超过这个限制发出的请求，就会报超时。

除掉这个连接数的影响外，还有次要的影响就是带宽，下载数据是要流量的，如果同时并发了太多请求，每个连接都占用带宽，可能导致每个请求的时间均会延长，就好像你在迅雷同时下载10个文件，那么下载速度都慢了。不过考虑到现在的网速，这个场景一般都比较极限，在做一些特殊场景优化的时候或许可以考虑到。

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

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

pause & dependency

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

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

2. 安全性

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

数据加密和防篡改

如无特殊情况，数据加密就推荐用https就够了，好处就不一一列举了，现在各大互联网公司（如BAT）都在做“全站https”. 而且现在免费的SSL证书也非常好申请，几乎不要什么成本了。

要保证接口参数不被篡改，不会被第三方恶意攻击，就要对参数进行签名。记得以前在某国内知名电商，由于接口没有类似防护，一两个小时被人利用移动端的注册接口注册了80w+账号，惨不忍睹。而且签名密钥（其实不是密钥，就是个干扰串）不要写死，要动态下发。

https中间人

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

DNS防劫持

进一步的安全策略就可以考虑到DNS防劫持，原理比较简单，可以本地维护一个路由表，然后本地实现 NSURLProtocol 对host进行ip映射。如果你还不太了解NSURLProtocol，可以参考NSURLProtocol进行学习

3. 组件设计

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

回调方式

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

拦截器

request的部分可能会有些场景需要请求前和请求后的拦截器的设计，即AOP入口，在这样的拦截器接口中，我们就可以做一些事情如： 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
};

 
    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长连接了，长连接可以让你做很多事情，唯一的难题就是要处理好心跳包。

6. 其他

6.1 国际化

在做国际化的时候，需要向服务器提供用户的语言偏好，也就是需要设置 Accept-Language 字段，如下：


[request setValue:[NSString stringWithFormat:@"%@", [[NSLocale preferredLanguages] componentsJoinedByString:@", "]], forHTTPHeaderField:@"Accept-Language"];

即使你的服务器还不支持国际化，把这个属性放进去会让你在需要的时候用到，而不必更新客户端。AFNetworking已经实现了改逻辑。

小结

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

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