iOS OC架构与编程思想

iOS架构之网络层设计方案

2017-06-13  本文已影响284人  M_慕宸

前言：

之前看了Casa大神的架构设计文章，醍醐灌顶，一直想开个系列文章记录一下（这次就做个小小搬运工，别打脸），公司项目实在太忙，最近稍好些，就开始着手做这件事，这个系列共以下几篇：
１. 搭建优质的App框架
２. view层的组织和调用方案（常用架构模式-ＭＶＣ、ＭＶＣＳ、ＭＶＶＭ）
３. 网络层设计方案
４. 数据持久化设计方案及动态部署
５. 组件化方案

网络层在一个App中承载了API调用，用户操作日志记录，甚至是即时通讯等任务。
这篇文章就主要会讲这些方面：

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

一、网络层跟业务对接部分的设计

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

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

这里其实有两个问题：

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

1.1 以什么方式将数据交付给业务层？
iOS开发领域有很多对象间数据的传递方式，我看到的大多数App在网络层所采用的方案主要集中于这三种：Delegate，Notification，Block。KVO和Target-Action我目前还没有看到有使用的。
然而在我这边，我的意见是以Delegate为主，Notification为辅。原因如下：

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

什么叫跨层数据交流？就是某一层（或模块）跟另外的与之没有直接对接关系的层（或模块）产生了数据交换。为什么这种情况不好？严格来说应该是大部分情况都不好，有的时候跨层数据交流确实也是一种需求。之所以说不好的地方在于，它会导致代码混乱，破坏模块的封装性。我们在做分层架构的目的其中之一就在于下层对上层有一次抽象，让上层可以不必关心下层细节而执行自己的业务。
所以，如果下层细节被跨层暴露，一方面你很容易因此失去邻层对这个暴露细节的保护；另一方面，你又不可能不去处理这个细节，所以处理细节的相关代码就会散落各地，最终难以维护。

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

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

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

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

2）为什么尽量不要用block

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

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

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

1.2 交付什么样的数据给业务层？

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

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

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

先定义一个protocol：

@protocol ReformerProtocol <NSObject>
- (NSDictionary)reformDataWithManager:(APIManager *)manager;
@end


在Controller里是这样：

@property (nonatomic, strong) id<ReformerProtocol> XXXReformer;
@property (nonatomic, strong) id<ReformerProtocol> YYYReformer;

#pragma mark - APIManagerDelegate
- (void)apiManagerDidSuccess:(APIManager *)manager
{
    NSDictionary *reformedXXXData = [manager fetchDataWithReformer:self.XXXReformer];
    [self.XXXView configWithData:reformedXXXData];

    NSDictionary *reformedYYYData = [manager fetchDataWithReformer:self.YYYReformer];
    [self.YYYView configWithData:reformedYYYData];
}


在APIManager里面，fetchDataWithReformer是这样：
- (NSDictionary)fetchDataWithReformer:(id<ReformerProtocol>)reformer
{
    if (reformer == nil) {
        return self.rawData;
    } else {
        return [reformer reformDataWithManager:self];
    }
}

reformer本质上就是一个符合某个protocol的对象，在controller需要从api manager中获得数据的时候，顺便把reformer传进去，于是就能获得经过reformer重新洗过的数据，然后就可以直接使用了。

更抽象地说，reformer其实是对数据转化逻辑的一个封装。在controller从manager中取数据之后，并且把数据交给view之前，这期间或多或少都是要做一次数据转化的，有的时候不同的view，对应的转化逻辑还不一样，但是展示的数据是一样的。而且往往这一部分代码都非常复杂，且跟业务强相关，直接上代码，将来就会很难维护。所以我们可以考虑采用不同的reformer封装不同的转化逻辑，然后让controller根据需要选择一个合适的reformer装上，就像洗澡的莲蓬头，需要什么样的水流（数据的表现形式）就换什么样的头，然而水（数据）都是一样的。这种做法能够大大提高代码的可维护性，以及减少ViewController的体积。

总结一下，reformer事实上是把转化的代码封装之后再从主体业务中拆分了出来，拆分出来之后不光降低了原有业务的复杂度，更重要的是，它提高了数据交付的灵活性。另外，由于Controller负责调度Manager和View，因此它是知道Manager和View之间的关系的，Controller知道了这个关系之后，就有了充要条件来为不同的View选择不同的Reformer，并用这个Reformer去改造Mananger的数据，然后ViewController获得了经过reformer处理过的数据之后，就可以直接交付给view去使用。Controller因此得到瘦身，负责业务数据转化的这部分代码也不用写在Controller里面，提高了可维护性。

所以reformer机制能够带来以下好处：

  1. 绕开了API数据原型的转换，避免了相关成本。

  2. 在处理单View对多API，以及在单API对多View的情况时，reformer提供了非常优雅的手段来响应这种需求，隔离了转化逻辑和主体业务逻辑，避免了维护灾难。

  3. 转化逻辑集中，且将转化次数转为只有一次。使用数据原型的转化逻辑至少有两次，第一次是把JSON映射成对应的原型，第二次是把原型转变成能被View处理的数据。reformer一步到位。另外，转化逻辑在reformer里面，将来如果API数据有变，就只要去找到对应reformer然后改掉就好了。

  4. Controller因此可以省去非常多的代码，降低了代码复杂度，同时提高了灵活性，任何时候切换reformer而不必切换业务逻辑就可以应对不同View对数据的需要。

  5. 业务数据和业务有了适当的隔离。这么做的话，将来如果业务逻辑有修改，换一个reformer就好了。如果其他业务也有相同的数据转化逻辑，其他业务直接拿这个reformer就可以用了，不用重写。另外，如果controller有修改（比如UI交互方式改变），可以放心换controller，完全不用担心业务数据的处理。

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

1.3 集约型API调用方式和离散型API调用方式的选择？
集约型API调用其实就是所有API的调用只有一个类，然后这个类接收API名字，API参数，以及回调着陆点（可以是target-action，或者block，或者delegate等各种模式的着陆点）作为参数。然后执行类似startRequest这样的方法，它就会去根据这些参数起飞去调用API了，然后获得API数据之后再根据指定的着陆点去着陆。比如这样：

集约型API调用方式：

[APIRequest startRequestWithApiName:@"itemList.v1" params:params success:@selector(success:) fail:@selector(fail:) target:self];

离散型API调用是这样的，一个API对应于一个APIManager，然后这个APIManager只需要提供参数就能起飞，API名字、着陆方式都已经集成入APIManager中。比如这样：

离散型API调用方式：

@property (nonatomic, strong) ItemListAPIManager *itemListAPIManager;

// getter
- (ItemListAPIManager *)itemListAPIManager
{
    if (_itemListAPIManager == nil) {
        _itemListAPIManager = [[ItemListAPIManager alloc] init];
        _itemListAPIManager.delegate = self;
    }

    return _itemListAPIManager;
}

// 使用的时候就这么写：
[self.itemListAPIManager loadDataWithParams:params];

集约型API调用和离散型API调用这两者实现方案不是互斥的，单看下层，大家都是集约型。因为发起一个API请求之后，除去业务相关的部分（比如参数和API名字等），剩下的都是要统一处理的：加密，URL拼接，API请求的起飞和着陆，这些处理如果不用集约化的方式来实现，作者非癫即痴。然而对于整个网络层来说，尤其是业务方使用的那部分，我倾向于提供离散型的API调用方式，并不建议在业务层的代码直接使用集约型的API调用方式。原因如下：

前者的业务场景举个例子就是刷新页面的请求，刷新详情，刷新列表等。后者的业务场景举个例子是列表多维度筛选，比如你先筛选了商品类型，然后筛选了价格区间。当然，后者的情况不一定每次筛选都要调用API，我们先假设这种筛选每次都必须要通过调用API才能获得数据。

如果是离散型的API调用，在编写不同的APIManager时候就可以针对不同的API设置不同的起飞策略，在实际使用的时候，就可以不必关心起飞策略了，因为APIMananger里面已经写好了。

综上，关于集约型的API调用和离散型的API调用，我倾向于这样：对外提供一个BaseAPIManager来给业务方做派生，在BaseManager里面采用集约化的手段组装请求，放飞请求，然而业务方调用API的时候，则是以离散的API调用方式来调用。如果你的App只提供了集约化的方式，而没有离散方式的通道，那么我建议你再封装一层，便于业务方使用离散的API调用方式来放飞请求。

网络层与业务层对接部分的小总结

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

二、网络层的安全机制

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

解决方案：设计签名
要达到第一个目的其实很简单，服务端需要给你一个密钥，每次调用API时，你使用这个密钥再加上API名字和API请求参数算一个hash出来，然后请求的时候带上这个hash。服务端收到请求之后，按照同样的密钥同样的算法也算一个hash出来，然后跟请求带来的hash做一个比较，如果一致，那么就表示这个API的调用者确实是你的APP。为了不让别人也获取到这个密钥，你最好不要把这个密钥存储在本地，直接写死在代码里面就好了。另外适当增加一下求Hash的算法的复杂度，那就是各种Hash算法（比如MD5）加点盐，再回炉跑一次Hash啥的。这样就能解决第一个目的了：确保你的API是来自于你自己的App。

一般情况下大部分公司不会出现需要满足第二种情况的需求，除非公司开发了自己的API平台给第三方使用。这个需求跟上面的需求有一点不同：符合授权的API请求者不只是一个。所以在这种情况下，需要的安全机制会更加复杂一点。

这里有一个较容易实现的方案：客户端调用API的时候，把自己的密钥通过一个可逆的加密算法加密后连着请求和加密之后的Hash一起送上去。当然，这个可逆的加密算法肯定是放在在调用API的SDK里面，编译好的。然后服务端拿到加密后的密钥和加密的Hash之后，解码得到原始密钥，然后再用它去算Hash，最后再进行比对。

2、保证传输数据的安全
  1. 防止中间人攻击，比如说运营商很喜欢往用户的Http请求里面塞广告...
  2. SPDY依赖于HTTPS，而且是未来HTTP/2的基础，他们能够提高你APP在网络层整体的性能。
    解决方案：HTTPS

三、网络层的优化方案

网络层的优化手段主要从以下三方面考虑：

  1. 针对链接建立环节的优化
  2. 针对链接传输数据量的优化
  3. 针对链接复用的优化
    这三方面是所有优化手段的内容，各种五花八门的优化手段基本上都不会逃脱这三方面，下面我就会分别针对这三方面讲一下各自对应的优化手段。
1、针对链接建立环节的优化

在API发起请求建立链接的环节，大致会分这些步骤：

  1. 发起请求
  2. DNS域名解析得到IP
  3. 根据IP进行三次握手（HTTPS四次握手），链接建立成功
    其实第三步的优化手段跟第二步的优化手段是一致的，我会在讲第二步的时候一起讲掉。

1.1 针对发起请求的优化手段
其实要解决的问题就是网络层该不该为此API调用发起请求。

小总结
针对建立连接这部分的优化就是这样的原则：能不发请求的就尽量不发请求，必须要发请求时，能合并请求的就尽量合并请求。然而，任何优化手段都是有前提的，而且也不能保证对所有需求都能起作用，有些API请求就是不符合这些优化手段前提的，那就老老实实发请求吧。不过这类API请求所占比例一般不大，大部分的请求都或多或少符合优化条件，所以针对发送请求的优化手段还是值得做的。

1.2 & 1.3 针对DNS域名解析做的优化，以及建立链接的优化
API请求在DNS解析阶段的耗时会很多，那么针对这个的优化方案就是，索性直接走IP请求，那不就绕过DNS服务的耗时了嘛。

另外一个，就是上面提到的建立链接时候的第三步，国内的网络环境分北网通南电信（当然实际情况更复杂，这里随便说说），不同服务商之间的连接，延时是很大的，我们需要想办法让用户在最适合他的IP上给他提供服务，那么就针对我们绕过DNS服务的手段有一个额外要求：尽可能不要让用户使用对他来说很慢的IP。

所以综上所述，方案就应该是这样：本地有一份IP列表，这些IP是所有提供API的服务器的IP，每次应用启动的时候，针对这个列表里的所有IP取ping延时时间，然后取延时时间最小的那个IP作为今后发起请求的IP地址。

我们一般都是在应用启动的时候获得本地列表中所有IP的ping值，然后通过NSURLProtocol的手段将URL中的HOST修改为我们找到的最快的IP。另外，这个本地IP列表也会需要通过一个API来维护，一般是每天第一次启动的时候读一次API，然后更新到本地。
如果你还不熟悉NSURLProtocol应该怎么玩，看完官方文档和这篇文章以及这个Demo之后，你肯定就会了，其实很简单的。另外，刚才提到那篇文章的作者(mattt)还写了这个基于NSURLProtocol的工具，相当好用，是可以直接拿来集成到项目中的。
不用NSURLProtocol的话，用其他手段也可以做到这一点，但那些手段未免又比较愚蠢。

2、针对链接传输数据量的优化

这个很好理解，传输的数据少了，那么自然速度就上去了。这里没什么花样可以讲的，就是压缩呗

3、针对链接复用的优化

建立链接本身是属于比较消耗资源的操作，耗电耗时。SPDY自带链接复用以及数据压缩的功能，所以服务端支持SPDY的时候，App直接挂SPDY就可以了。如果服务端不支持SPDY，也可以使用PipeLine，苹果原生自带这个功能。
一般来说业界内普遍的认识是SPDY优于PipeLine，然后即便如此，SPDY能够带来的网络层效率提升其实也没有文献上的图表那么明显，但还是有性能提升的。还有另外一种比较笨的链接复用的方法，就是维护一个队列，然后将队列里的请求压缩成一个请求发出去，之所以会存在滞留在队列中的请求，是因为在上一个请求还在外面飘的时候。这种做法最终的效果表面上看跟链接复用差别不大，但并不是真正的链接复用，只能说是请求合并。
还是说回来，我建议最好是用SPDY，SPDY和pipeline虽然都属于链接复用的范畴，但是pipeline并不是真正意义上的链接复用，SPDY的链接复用相对pipeline而言更为彻底。SPDY目前也有现成的客户端SDK可以使用，一个是twitter的CocoaSPDY，另一个是Voxer/iSPDY，这两个库都很活跃，大家可以挑合适的采用。
不过目前业界趋势是倾向于使用HTTP/2.0来代替SPDY

总结

第一部分主要讲了网络层应当如何跟业务层进行数据交互，进行数据交互时采用怎样的数据格式，以及设计时代码结构上的一些问题，诸如继承的处理，回调的处理，交互方式的选择，reformer的设计，保持数据可读性等等等等，主要偏重于设计（这可是艺术活，哈哈哈）。

第二部分讲了网络安全上，客户端要做的两点。当然，从网络安全的角度上讲，服务端也要做很多很多事情，客户端要做的一些边角细节的事情也还会有很多，比如做一些代码混淆，尽可能避免代码中明文展示key。不过大头主要就是这两个，而且也都是需要服务端同学去配合的。主要偏重于介绍。（主要是也没啥好实践的，google一下教程照着来就好了）。

第三部分讲了优化，优化的所有方面都已经列出来了，如果业界再有七七八八的别的手段，也基本逃离不出本文的范围。这里有些优化手段是需要服务端同学配合的，有些不需要，大家看各自情况来决定。主要偏重于实践。

iOS应用架构谈 网络层设计方案

上一篇下一篇

猜你喜欢

热点阅读