iOS应用架构谈应用架构谈--网络层设计方案网络层设计方案
编者按：iOS客户端应用架构看似简单，但实际上要考虑的事情不少。本文作者将以系列文章的形式来讨论iOS应用架构中的
种种问题，本文是其中的第三篇，主要讲网络层设计以及安全机制和优化方案。
前言
网络层在一个App中也是一个不可缺少的部分，工程师们在网络层能够发挥的空间也比较大。另外，苹果对网络请求部分已经
做了很好的封装，业界的AFNetworking也被广泛使用。其它的ASIHttpRequest，MKNetworkKit啥的其实也都还不错，但前者
已经弃坑，后者也在弃坑的边缘。在实际的App开发中，Afnetworking已经成为了事实上各大App的标准配置。
网络层在一个App中承载了API调用，用户操作日志记录，甚至是即时通讯等任务。我接触过一些App（开源的和不开源的）
的代码，在看到网络层这一块时，尤其是在看到各位架构师各显神通展示了各种技巧，我非常为之感到兴奋。但有的时候，往
往也对于其中的一些缺陷感到失望。
关于网络层的设计方案会有很多，需要权衡的地方也会有很多，甚至于争议的地方都会有很多。但无论如何，我都不会对这些
问题做出任何逃避，我会在这篇文章中给出我对它们的看法和解决方案，观点绝不中立，不会跟大家打太极。
这篇文章就主要会讲这些方面：
网络层跟业务对接部分的设计
网络层的安全机制实现
网络层的优化方案
网络层跟业务对接部分的设计
在安居客App的架构更新换代的时候，我深深地感觉到网络层跟业务对接部分的设计有多么重要，因此我对它做的最大改变就
是针对网络层跟业务对接部分的改变。网络层跟业务层对接部分设计的好坏，会直接影响到业务工程师实现功能时的心情。
在正式开始讲设计之前，我们要先讨论几个问题：
使用哪种交互模式来跟业务层做对接？
是否有必要将API返回的数据封装成对象然后再交付给业务层？
使用集约化调用方式还是离散型调用方式去调用API？
这些问题讨论完毕之后，我会给出一个完整的设计方案来给大家做参考，设计方案是鱼，讨论的这些问题是渔，我什么都授
了，大家各取所需。
使用哪种交互模式来跟业务层做对接？
这里其实有两个问题：一，以什么方式将数据交付给业务层？二，交付什么样的数据给业务层？
以什么方式将数据交付给业务层？
iOS开发领域有很多对象间数据的传递方式，我看到的大多数App在网络层所采用的方案主要集中于这三种：
Delegate，Notification，Block。KVO和Target-Action我目前还没有看到有使用的。
目前我知道边锋主要是采用的block，大智慧主要采用的是Notification，安居客早期以Block为主，后面改成了以Delegate为
主，阿里没发现有通过Notification来做数据传递的地方（可能有），Delegate、Block以及target-action都有，阿里iOS App网
络层的作者说这是为了方便业务层选择自己合适的方法去使用。这里大家都是各显神通，每次我看到这部分的时候，我都喜欢
问作者为什么采用这种交互方案，但很少有作者能够说出个条条框框来。
然而在我这边，我的意见是以Delegate为主，Notification为辅。原因如下：
尽可能减少跨层数据交流的可能，限制耦合
统一回调方法，便于调试和维护
在跟业务层对接的部分只采用一种对接手段（在我这儿就是只采用delegate这一个手段）限制灵活性，以此来交换应用的可维
护性
尽可能减少跨层数据交流的可能，限制耦合
什么叫跨层数据交流？就是某一层（或模块）跟另外的与之没有直接对接关系的层（或模块）产生了数据交换。为什么这种情
况不好？严格来说应该是大部分情况都不好，有的时候跨层数据交流确实也是一种需求。之所以说不好的地方在于，它会导致
代码混乱，破坏模块的封装性。我们在做分层架构的目的其中之一就在于下层对上层有一次抽象，让上层可以不必关心下层细
节而执行自己的业务。
剩余11页未读，继续阅读
资源评论
