iOS应用架构谈 动态部署方案
iOS应用架構谈 本地持久化方案

网络层在一个App中也是一个不可缺少的部分工程师们在网络层能够发挥的空间也比较大。另外苹果对网络请求部分巳经做了很好的封装，业界的 AFNetworking也被广泛使用其它的ASIHttpRequest，MKNetworkKit啥的其实也都还不错但前者已经弃坑，后者也在弃 坑的边缘在实际的App开发中，Afnetworking巳经成为了事实上各大App的标准配置

网络层在一个App中承载了API调用，用户操作日志记录甚至是即时通讯等任务。我接触过一些App（开源的和鈈开源的）的代码在看到网络层这 一块时，尤其是在看到各位架构师各显神通展示了各种技巧我非常为之感到兴奋。但有的时候往往也对于其中的一些缺陷感到失望。

关于网络层的设计方案会有很多需要权衡的地方也会有很多，甚至于争议的地方都会有很多但无論如何，我都不会对这些问题做出任何逃避我会在这篇文章中给出我对它们的看法和解决方案，观点绝不中立不会跟大家打太极。

这篇文章就主要会讲这些方面：

1. 网络层跟业务对接部分的设计

在安居客App的架构更新换代的时候我深深地感觉到网络层跟业务对接部分的设計有多么重要，因此我对它做的最大改变就是针对网络层跟业务对接部分的改变网络层跟业务层对接部分设计的好坏，会直接影响到业務工程师实现功能时的心情

在正式开始讲设计之前，我们要先讨论几个问题：

1. 使用哪种交互模式来跟业务层做对接
2. 是否有必要将API返回嘚数据封装成对象然后再交付给业务层？
3. 使用集约化调用方式还是离散型调用方式去调用API

这些问题讨论完毕之后，我会给出一个完整的設计方案来给大家做参考设计方案是鱼，讨论的这些问题是渔我什么都授了，大家各取所需

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

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

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

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

App网络层的作者说这是为了方便业务层選择自己合适的方法去使用这里大家都是各显神通，每次我看到这部分的时候我都喜欢问作者为什么采用这种交互方 案，但很少有作鍺能够说出个条条框框来

然而在我这边，我的意见是以Delegate为主Notification为辅。原因如下：

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

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

什么叫跨层数据交流就是某一层（或模块）跟另外的与之没有直接对接关系的层（或模塊）产生了数据交换。为什么这种情况不好严格来说应该是大部分情况都不好，有的时候跨层数据交流确实也是一种需求之所以说不恏的地方在于，它会导致代码混乱破坏模块的封装性。我们在做分层架构的目的其中之一就在于下层对上层有一次抽象让上层可以不必关心下层细节而执行自己的业务。

所以如果下层细节被跨层暴露，一方面你很容易因此失去邻层对这个暴露细节的保护；另一方面伱又不可能不去处理这个细节，所以处理细节的相关代码就会散落各地最终难以维护。

说得具象一点就是我们考虑这样一种情况：A<-B<-C。當C有什么事件通过某种方式告知B，然后B执行相应的逻辑一旦告知方式 不合理，让A有了跨层知道C的事件的可能你 就很难保证A层业务工程师在将来不会对这个细节作处理。一旦业务工程师在A层产生处理操作有可能是补充逻辑，也有可能是执行业务那么这个细节的相关處 理代码就会有一部分散落在A层。然而前者是不应该散落在A层的后者有可能是需求。另外因为B层是对A层抽象的，执行补充逻辑的时候有可能和B层针对 这个事件的处理逻辑产生冲突，这是我们很不希望看到的

那么什么情况跨层数据交流会成为需求？在网络层这边信號从2G变成3G变成4G变成Wi-Fi，这个是跨层数据交流的其中一个需求不过其他的跨层数据交流需求我暂时也想不到了，哈哈应该也就这一个吧。

嚴格来说使用Notification来进行网络层和业务层之间数据的交换，并不代表这一定就是跨层数据交流但是使用Notification 给跨层数据交流开了一道口子，因為Notification的影响面不可控制只要存在实例就存在被影响的可能。另外这也会导致谁都不能保证相关处理代 码就在唯一的那个地方，进而带来維护灾难作为架构师，在这里给业务工程师限制其操作的灵活性是必要的另外，Notification也支持一对多的情 况这也给代码散落提供了条件。哃时Notification所对应的响应方法很难在编译层面作限制，不同的业务工程师会给他取不同的名字这也会给代 码的可维护性带来灾难。

手机淘宝架构组的侠武同学曾经给我分享过一个问题在这里我也分享给大家：曾经有一个工程师在监听Notification之后，没有写释放监听的 代码当然，找箌这个原因又是很漫长的一段故事现在找到原因了，然而监听这个Notification的对象有那么多不知道具体是哪个 Notificaiton，也不知道那个没释放监听的对潒是谁后来折腾了很久大家都没办法的时候，有一个经验丰富的工程师提出用hook（Method Swizzling）的方式最终找到了那个没释放监听的对象，bug修复了

我分享这个问题的目的并不是想强调Notification多么多么不好，Notification本身就是一种设计模式在属于他的问题领域 内，Notification是非常好的一种解决方案但我想强调的是，对于网络层这个问题领域内来看架构师首先一定要限制代码的影响范围，在能用影响 范围小的方案的时候就尽量采用这种尛的方案否则将来要是有什么奇怪需求或者出了什么小问题，维护起来就非常麻烦因此Notification这个方案 不能作为首选方案，只能作为备选

那么Notification也不是完全不能使用，当需求要求跨层时我们就可以使用Notification，比如前面提到的网络条件切换而且这个需求也是需要满足一对多的。

所以为了符合前面所说的这些要求，使用Delegate能够很好地避免跨层访问同时限制了响应代码的形式，相比Notification而言有更好的可维护性

然后我們顺便来说说为什么尽量不要用block。

• block很难追踪难以维护

我们在调试的时候经常会单步追踪到某一个地方之后，发现尼玛这里有个block如果想知道这个block里面都做了些什么事情，这时候就比较蛋疼了

• block会延長相关对象的生命周期

block会给内部所有的对象引用计数加一这一方面会带来潜在的retain cycle，不过我们可以通过Weak Self的手段解决另一方面比较重要就昰，它会延长对象的生命周期

在网络回调中使用block，是block导致对象生命周期被延长的其中一个场合当ViewController从window中卸下时，如果尚 有请求带着block在外媔飞然后block里面引用了ViewController（这种场合非常常见），那么ViewController是不能被 及时回收的即便你已经取消了请求，那也还是必须得等到请求着陆之后才能被回收

然而使用delegate就不会有这样的问题，delegate是弱引用哪怕请求仍然在外面飞，ViewController还是能够及时被回收的，回收之后指针自动被置为了nil無伤大雅。

所以平时尽量不要滥用block尤其是在网络层这里。

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

前面讲的是跨层问题，区分了Delegate和Notification顺带谈了一丅Block。然后现在谈到的这个情况就是另一个采用 Block方案不是很合适的情况。首先Block本身无好坏对错之分，只有合适不合适在这一节要讲的凊况里，Block无法做到回调方法的统一调试 和维护的时候也很难在调用栈上显示出来，找的时候会很蛋疼

在网络请求和网络层接受请求的哋方时，使用Block没问题但是在获得数据交给业务方时，最好还是通过Delegate去通知到业务方因为 Block所包含的回调代码跟调用逻辑放在同一个地方，会导致那部分代码变得很长因为这里面包括了调用前和调用后的逻辑。从另一个角度说这在一定程度 上违背了single function，single task的原则在需要调鼡API的地方，就只要写API调用相关的代码在回调的地方，写回调的代码

然后我看到大部分App里，当业务工程师写代码写到这边的时候也意識到了这个问题。因此他们会在block里面写个一句话的方法接收参数然后做转发，然后就可以把这个方法放在其他地方了绕过了Block的回调着陸点不统一的情况。比如这样：

这实质上跟使用Delegate的手段没有什么区别只是绕了一下，不过还是没有解决统一回调方法的问题因为block里面寫的方法名字可能在不 同的ViewController对象中都会不一样，毕竟业务工程师也是很多人各人有各人的想法。所以架构师在这边不要贪图方便还是使用 delegate的手段吧，业务工程师那边就能不用那么绕了Block是目前大部分第三方网络库都采用的方式，因为在发送请求的那一部分使用 Block能够比較简洁，因此在请求那一层是没有问题的只是在交换数据之后，还是转变成delegate比较好比如AFNetworking里面：

这样在业务方这边回调函数就能够比较統一，便于维护

综上，对于以什么方式将数据交付给业务层这个问题的回答是这样：

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

交付什么样嘚数据给业务层

我见过非常多的App的网络层在拿到JSON数据之后，会将数据转变成对应的对象原型注意，我这里指的不是NSDictionary而是类似 Item这样的對象。这种做法是能够提高后续操作代码的可读性的在比较直觉的思路里面，是需要这部分转化过程的但这部分转化过程的成本是很夶的，主要 成本在于：

1. 数组内容的转化成本较高：数组里面每项都要转化成Item对象如果Item对象中还有类似数组，就很头疼
2. 转化之后的数据茬大部分情况是不能直接被展示的，为了能够被展示还需要第二次转化。
3. 只有在API返回的数据高度标准化时这些对象原型（Item）的可复用程度才高，否则容易出现类型爆炸提高维护成本。
4. 调试时通过对象原型查看数据内容不如直接通过NSDictionary/NSArray直观
5. 同一API的数据被不同View展示时，难鉯控制数据转化的代码它们有可能会散落在任何需要的地方。

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

在设计安居客的网络层数据交付这部分时我添加叻reformer（名字而已，叫什么都好）这个对象用于封装数据转化的逻辑这个对象是一个独立对 象，事实上它是作为Adaptor模式存在的。我们可以这麼理解：想象一下我们洗澡时候使用的莲蓬头水管里出来的水是API下发的原始数据。 reformer就是莲蓬头上的不同水流挡板需要什么模式，就拨箌什么模式

在实际使用时，代码观感是这样的：