“iOS应用架构谈 网络层设计方案”笔记

新浪微博：love_in_sky

2017年7月25日最新文章。

一、在和业务层对接的时候，采用delegate。
使用Notification等于给跨层数据交换开了一个口子，除了不可控之外，还有命名不统一的缺点。在网络层这边，信号从2G变成3G变成4G变成Wi-Fi，这个是跨层数据交流的其中一个需求，可以使用Notification。
使用block，追踪不好追踪，而且延长对象的生命周期。

block和delegate乍看上去在作用上是很相似，但是关于它们的选型有一条严格的规范：当回调之后要做的任务在每次回调时都是一致的情况下，选择delegate，在回调之后要做的任务在每次回调时无法保证一致，选择block。

然后还介绍了集约API和离散API，单看下层，大家都是集约型。因为发起一个API请求之后，除去业务相关的部分（比如参数和API名字等），剩下的都是要统一处理的：加密，URL拼接，API请求的起飞和着陆。
对外提供一个BaseAPIManager来给业务方做派生，在BaseManager里面采用集约化的手段组装请求，放飞请求，然而业务方调用API的时候，则是以离散的API调用方式来调用。如果你的App只提供了集约化的方式，而没有离散方式的通道，那么我建议你再封装一层，便于业务方使用离散的API调用方式来放飞请求。

在网络请求和网络层接受请求的地方时，使用Block没问题。但是在获得数据交给业务方时，最好还是通过Delegate去通知到业务方。因为Block所包含的回调代码跟调用逻辑放在同一个地方，会导致那部分代码变得很长，因为这里面包括了调用前和调用后的逻辑。

总结：尽可能通过Delegate的回调方式交付数据，这样可以避免不必要的跨层访问。当出现跨层访问的需求时（比如信号类型切换），通过Notification的方式交付数据。正常情况下应该是避免使用Block的。

二、交付数据时，就不要再转一层model了。直接使用NSDictionary/NSArray直观。使用key方式提高非表征数据（NSDictionary/NSArray）的可读性。

使用reformer机制，适配器模式。

网络请求回来的data数据一定要经过处理，这样当这个数据被多次使用到时，就不需要每次都进行转化。但不需要转成数据模型。

对于业务层而言，由Controller根据View和APIManager之间的关系，选择合适的reformer将View可以直接使用的数据（甚至reformer可以用来直接生成view）转化好之后交付给View。对于网络层而言，只需要保持住原始数据即可，不需要主动转化成数据原型。然后数据采用NSDictionary加Const字符串key来表征，避免了使用对象来表征带来的迁移困难，同时不失去可读性。

1.使用delegate来做数据对接，仅在必要时采用Notification来做跨层访问
2.交付NSDictionary给业务层，使用Const字符串作为Key来保持可读性
3.提供reformer机制来处理网络层反馈的数据，这个机制很重要，好处极多
4.网络层上部分使用离散型设计，下部分使用集约型设计
5.设计合理的继承机制，让派生出来的APIManager受到限制，避免混乱

三、网络层的安全机制
针对链接建立环节的优化
能不发请求的就尽量不发请求，必须要发请求时，能合并请求的就尽量合并请求。然而，任何优化手段都是有前提的，而且也不能保证对所有需求都能起作用，有些API请求就是不符合这些优化手段前提的，那就老老实实发请求吧。不过这类API请求所占比例一般不大，大部分的请求都或多或少符合优化条件，所以针对发送请求的优化手段还是值得做的。

DNS域名解析做的优化
本地有一份IP列表，这些IP是所有提供API的服务器的IP，每次应用启动的时候，针对这个列表里的所有IP取ping延时时间，然后取延时时间最小的那个IP作为今后发起请求的IP地址。

建立连接的优化
我们一般都是在应用启动的时候获得本地列表中所有IP的ping值，然后通过NSURLProtocol的手段将URL中的HOST修改为我们找到的最快的IP。另外，这个本地IP列表也会需要通过一个API来维护，一般是每天第一次启动的时候读一次API，然后更新到本地。

针对链接传输数据量的优化
就是压缩呗。各种压缩。

链路复用
我建议最好是用SPDY，SPDY和pipeline虽然都属于链接复用的范畴，但是pipeline并不是真正意义上的链接复用，SPDY的链接复用相对pipeline而言更为彻底。