iOS网络层的组织方案

1.以什么方式将数据交付给业务层

以什么方式将数据交付给业务层首先要知道iOS中数据交互的几种方式。

大多数系统在网络层架构时采用的对象间传数据的方式都是这三种： delegate、block、通知。作者这里推荐使用delegate，并给出了他的理由。

尽可能减少跨层数据交流的可能，限制耦合

统一回调方法，便于调试和维护

在跟业务层对接的部分只采用一种对接手段（在我这儿就是只采用delegate这一个手段）限制灵活性，以此来交换应用的可维护性

什么是跨层数据交流？

举个例子，比如说A->B->C,C有什么事，会直接告诉B，但是如果告知方式不合理，被A知道了，处理A层的工程师就会对这个事件进行处理，那么这个细节的处理代码就会有一部分被放在了A层。

为什么尽量不要使用NSNotification?

NSNotification的代码影响比较大，Notification支持一对多的情况，这也给代码散落提供了条件。同时，Notification所对应的响应方法很难在编译层面作限制，不同的业务工程师会给他取不同的名字，这也会给代码的可维护性带来灾难。

比如说有一个人在写代码的时候，没有写释放监听的代码，那么这个时候有很多对象监听了同一个Notification，不知道具体是哪个对象没有释放。

为什么不要使用block？

2.网络层的安全机制

确保API的调用请求来自经过授权的app，经授权的app就是你自己的app或者是你对外提供了需要注册才能使用的API平台，那么注册的用户就是经过授权的app。

保证传输数据的安全，主要是防止运营商向http请求里加广告。解决方案：使用https。目前使用HTTPS的主要目的在于防止运营商往你的Response Data里面加广告啥的（中间人攻击），面对的威胁范围更广。

xcode7.0以后只支持https请求，不支持http请求。

Https和Http请求的区别：

Https需要ca申请证书，一般免费的证书很少，都需要交费。

Http协议是超文本传输协议，信息通过明文传输，Https是具有安全性的ssl加密传输协议。

Http和Https的连接方式完全不同，实用的端口号也不同。

Http的连接很简单是无状态的，Https是由Http＋ssl构建的可进行加密传输身份认证的网络协议，更加安全。

https请求数据的过程：

客户端向服务器请求数据，服务器响应以后不会马上发送数据给客户端而是发送一个受保护区域和安全证书给客户端，如果客户端信任服务器，安装了安全证书。发送对称密钥给服务器服务器接收到密钥，就会在客户端和服务器之间建立保护区，这个时候服务器通过保护区把数据发送给客户端。四次握手。

iOS里发送https请求：

在iOS里发送https请求需要使用NSURLSession,实现代理方法didReceiveChallenge。有些网站在https请求的时候会询问要不要安装这个证书，这个时候就要实现didReceiveChallenge方法，手动安装证书。有些网站在访问的时候强制安装了证书，这个时候就不需要用代理方法去手动安装证书。

用AFN发送https请求：

AFN

补充：关于数据安全

仅仅用POST请求发送数据不能解决数据完全的问题。

所以，在网络上发送数据的时候不允许传输用 户隐私数据的明文，在本地不允许保存用户隐私数据的明文。只有用户输入数据的那一刻是明文，在网络传输和数据库里存储的都是密文。

3.网络层的优化

针对网络层的优化，作者主要介绍了三个方面的内容：

针对链接建立环节的优化

针对链接传输数据量的优化

针对链接复用的优化

4.针对链接建立环节的优化

4.1使用缓存减少请求的发起次数

对于大部分API调用请求来说，有些API请求所带来的数据的时效性是比较长的，比如商品详情，比如App皮肤等。那么我们就可以针对这些数据做本地缓存，这样下次请求这些数据的时候就可以不必再发起新的请求。

关于这里有一个缓存策略的问题需要讨论：什么时候清理缓存？要么就是根据超时时间限制进行清理，要么就是根据缓存数据大小进行清理。这个策略的选择要根据具体App的操作日志来决定。

当然，有些时效性非常短的API数据，就不能使用这个方法了，比如用户的资金数据，那就需要每次都调用了。

4.2 使用策略来减少请求的发起次数

这个主要是针对重复的请求，针对重复请求的发起和取消有相应的策略进行优化。

针对重复的请求，后面重复发送的api都可以取消。如果是条件筛选这种，那就取消前面已经发送的请求。虽然很有可能这个请求已经被执行了，那么取消所带来的性能提升就基本没有了。但如果这个请求还在队列中待执行的话，那么对应的这次链接就可以省掉了。

另外一种情况就是请求策略：类似用户操作日志的请求策略。用户操作日志这种东西是默默发送的，用户不需要操纵，因此不需要用户每次执行一个操作都发送操作日志。可以把用户的操作日志缓存起来，达到一定数量的时候一次性发送给服务器。

4.3针对DNS域名解析做的优化

其实在整个DNS链路上也是有DNS缓存的，理论上也是能够提高速度的。这个链路上的DNS缓存在PC用户上效果明显，因为PC用户的DNS链路相对稳定，信号源不会变来变去。但是在移动设备的用户这边，链路上的DNS缓存所带来的性能提升就不太明显了。因为移动设备的实际使用场景比较复杂，网络信号源会经常变换，信号源每变换一次，对应的DNS解析链路就会变换一次，那么原链路上的DNS缓存就不起作用了。

5.针对链接传输数据量的优化

传输的数据量少了传输的速度自然就会提高，所以要想办法压缩数据。

6. 针对链接复用的优化

建立链接本身是属于比较消耗资源的操作，耗电耗时。SPDY自带链接复用以及数据压缩的功能，所以服务端支持SPDY的时候，App直接挂SPDY就可以了。如果服务端不支持SPDY，也可以使用PipeLine，苹果原生自带这个功能。