一.网络层跟业务对接部分的设计
二.网络层的安全机制实现
三.网络层的优化方案
一.网络层跟业务对接部分的设计
1.使用哪种交互模式来跟业务层做对接？
2.是否有必要将API返回的数据封装成对象然后再交付给业务层?
3.使用集约化调用方式还是离散型调用方式去调用API?
1.使用哪种交互模式来跟业务层做对接?
(1) 以什么方式将数据交付给业务层？
(2) 交付什么样的数据给业务层？
(1) 以什么方式将数据交付给业务层
大多数App在网络层所采用的方案主要集中于三种：
Delegate
Notification
Block
（KVO，Target-Action很少使用）
以Delegate为主，Notification为辅
尽可能减少跨曾数据交流的可能
统一回调方法，便于调试和维护
在跟业务层对接的部分只采用一种对接手段（可只采用Delegate）限制灵活性，以此来交换应用的可维护性
跨层数据交流，会导致代码混乱，破坏模块的封装性
Notification — —不同工程师起不同名字，不便于维护
（notification与delegate的选择：
notification：一对多时
delegate：避免跨层范文，限制相应代码的形式）
Block — — 很难追踪，难以维护；延长相关对象的生命周期，使得内部所有的对象引用计数加一，不能及时回收
（block与delegate的选择：
delegate：当回调之后要做的任务在每次回调时都一致；
Block：在回调之后要做的任务在每次回调时无法保持一致）
尽可能通过Delegate的回调方式交付数据，这样可以避免不必要的跨层访问。当出现跨层访问的需求时（比如信号类型切换），通过Notification的方式交付数据。正常情况下应该是避免使用Block的
(2) 交付什么样的数据给业务层
将数据转变成对象交付成本很大：
1.数组内容的转化成本较高：数组里面每项都要都要转化成item对象，
2.转化之后的数据在大部分情况是不能直接被展示的，为了能够被展示，还需要第二次转化。
3.只有在API返回的数据高度标准化时，致谢对象原型的可复用成都才高，否则容易出现类型爆炸，提高维护成本。
4.调试时通过对象原型查看数据内容不如直接通过NSDictionary/NSArray直观。
5.同一API的数据被不同View展示时，难以控制数据转化的代码，他们有可能会散落在任何需要的地方。
对于业务层而言，由Controller根据View和APIManager之间的关系，选择合适的reformer将VIew可以直接使用的数据（甚至reformer可以用来直接生成view）转化好之后交付给View。对于网络层而言，只需要保持住原始数据即可，不需要主动转化成数据原型。然后数据采用NSDictionary加Const字符串key来表征，避免了使用对象来表征带来的迁移困难，同时不失去可读性。
集约型API调用方式和离散型API调用方式的选择？
对外提供一个BaseAPIManager来给业务方做派生，在BaseManager里面采用集约化的手段组装请求，然而也无妨调用API的时候，则是以离散的API调用方式来调用。如果你的App只提供了集约化的方式，而没有离散方式的同道，那么我建议再封装一层，便于业务方使用离散的API调用方式来放飞请求。
使用delegate来做数据对接，仅在必要时采用Notification来做跨层访问
交付NSDictionary给业务层，使用Const字符串作为Key来保持可读性
提供reformer机制来处理网络层反馈的数据，这个机制很重要，好处极多
网络层上部分使用离散型设计，下部分使用集约型设计
设计合理的继承机制，让派生出来的APIManager受到限制，避免混乱
二.网络层的安全机制
1.判断API的调用请求是否来自于经过授权的APP
确保API的调用者是来自你自己的APP，防止竞争对手爬你的API
如果你对外提供了需要注册才能使用的API平台，那么你需要有这个机制来识别是否是注册用户调用了你的API
解决方案：设计签名
2.保证传输数据的安全
防止中间人共计，比如说运营商给你很喜欢往用户的Http请求里面塞广告
SPDY依赖于HTTPS，而且是未来HTTP/2的基础，他们能够提高你APP在网络层整体的而性能
解决方案：HTTPS
三.网络层的优化方案
1.针对链接建立环节的优化
2.针对链接传输数据量的优化
3.针对链接复用的优化
1.针对链接建立环节的优化
（1）发起请求
（2）DNS域名解析得到IP
（3）根据IP进行三次（HTTPS四次）握手，链接建立成功
（1）针对发起请求的优化手段
要解决的问题就是网络层该不该为此API调用发起请求
（一）使用缓存手段减少请求的发起次数
一般把API名字和参数拼成字符串取MD5作为key存储对应返回的数据。
什么时候清理缓存：根据超时时间限制进行清理
根据缓存数据大小清理
（二）使用策略来减少请求的发起次数
针对重复请求的发起和取消：下拉刷新时，在请求着陆之前，后面的重复操作可不白发送。条件筛选时，取消前面已经发送的请求。
用户操作日志的请求策略：本地记录用户的操作记录，当记录满30跳的时候发起一次请求。
（2&3）针对DNS域名解析做的优化，以及建立连接的优化
解决方案：本地有一份IP列表，这些IP是所有提供API的服务器的IP，每次应用启动的时候，针对这个列表里的所有IP取ping延时时间，然后取延时时间最小的那个IP作为今后发起请求的IP地址。应用启动的时候获得本地列表中所有IP的ping值，然后通过NSURLProtocol的手段将URL中的HOST修改为我们找到的最快的IP。另外，这个本地IP列表也会需要通过一个API来维护，一般是每天第一次启动的时候读一次API，然后更新到本地。
2.针对链接传输数据量的优化
解决方案：压缩
3.针对链接复用的优化
解决方案：SPDY自带链接复用以及数据压缩的功能，所以服务端支持SPDY的时候，App直接挂SPDY就可以了。如果服务端不支持SPDY，也可以使用PipeLine，苹果原生自带这个功能。
