网络层

概要

1. 网络层跟业务对接部分的设计
2. 网络层的安全机制实现
3. 网络层的优化方案

当回调之后要做的任务在每次回调时都是一致的情况下，选择delegate，在回调之后要做的任务在每次回调时无法保证一致，选择block

1.使用哪种交互模式来跟业务层做对接？

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

（1）iOS开发领域有很多对象间数据的传递方式，我看到的大多数App在网络层所采用的方案主要集中于这三种：Delegate，Notification，Block。KVO和Target-Action我目前还没有看到有使用的。

• 尽可能减少跨层数据交流的可能，限制耦合
• 统一回调方法，便于调试和维护（block很难追踪，难以维护）
• 在跟业务层对接的部分只采用一种对接手段（在我这儿就是只采用delegate这一个手段）限制灵活性，以此来交换应用的可维护性

（2） 其实我们的理想情况是希望API的数据下发之后就能够直接被View所展示。首先要说的是，这种情况非常少。另外，这种做法使得View和API联系紧密，也是我们不希望发生的。

 

添加一个中间层， 独立对象 reformer专门来做数据处理和转换。

网络层的安全机制

判断API的调用请求是来自于经过授权的APP

使用这个机制的目的主要有两点：

1. 确保API的调用者是来自你自己的APP，防止竞争对手爬你的API
2. 如果你对外提供了需要注册才能使用的API平台，那么你需要有这个机制来识别是否是注册用户调用了你的API

解决方案：设计签名

1.服务端需要给你一个密钥，每次调用API时，你使用这个密钥再加上API名字和API请求参数算一个hash出来，然后请求的时候带上这个hash。服务端收到请求之后，按照同样的密钥同样的算法也算一个hash出来，然后跟请求带来的hash做一个比较，如果一致，那么就表示这个API的调用者确实是你的APP。

2.把自己的密钥通过一个可逆的加密算法加密后连着请求和加密之后的Hash一起送上去

保证传输数据的安全

防止中间人攻击，比如说运营商很喜欢往用户的Http请求里面塞广告（ Response Data里面加广告啥 ）

解决方案：HTTPS

网络层的优化方案

1. 针对链接建立环节的优化
2. 针对链接传输数据量的优化
3. 针对链接复用的优化

1.1 针对发起请求的优化手段

• 1.1.1 使用缓存手段减少请求的发起次数（商品详情，比如App皮肤等地方）

什么时候清理缓存？ 要么就是根据超时时间限制进行清理，要么就是根据缓存数据大小进行清理。

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

1. 下拉刷新时，在请求着陆之前用户不断执行下拉操作
2. 条件筛选这种，那就取消前面已经发送的请求
3. 类似用户操作日志的请求策略（当记录满30条日志再上传，启动时候上传）

原则：能不发请求的就尽量不发请求，必须要发请求时，能合并请求的就尽量合并请求。

效果：降低用户设备的耗电量，同时提升网络层的性能

1.2 & 1.3 针对DNS域名解析做的优化，以及建立链接的优化

    API请求在DNS解析阶段的耗时会很多。

    那么针对这个的优化方案就是，索性直接走IP请求，那不就绕过DNS服务的耗时了嘛

    选择最优IP 优化方案： 每天第一次启动读取API,保存到 本地一份IP列表，这些IP是所有提供API的服务器的IP，每次应用启动的时候，针对这个列表里的所有IP取ping延时时间，然后取延时时间最小的那个IP作为今后发起请求的IP地址