一年前，当Casa刚写出这个系列的文章的时候，因为对整个系统框架还出于学习状态，开发也只是为做而做。因为之前总是在做外包项目，对一个产品，整个架构了解甚少。也是从前年开始，进入家真正的互联网产品公司，加深了对架构方面的理解。最近，因为公司要把本应该写两个app 的产品要合并成一个，所以，对于架构，框架的理解要更深一步的去了解。故重读关于架构方面的文章，并结合自己所做的app，做一个读书笔记。
原文地址：iOS应用架构谈 网络层设计方案
下面是对文章分节笔记和自己的见解：
前言：
网络请求部分，确实苹果封装的很好。在业界，AFNetworking确实已成为App的标配。我在第一家公司使用的就是AFNetworking 。而现在的除了图片上传阿里云使用的是苹果自带的网络请求（这部分是另外一个同事做的，我并没有去分析其代码，还是决定用一种请求即可）
正如所说，网络层在一个App中承载着API调用，用户操作日志记录，即时通讯等任务。网络层这一块的设计方案是千变万化，大家也都是各显神通展示各种技巧。文中说道，会提出自己观点，不中立。我个人觉得甚是中肯。所以也是在摸索中，去将文中的方案，尽可能的理解的最深最优化。
这篇文章分了三个方面来讲：
1.网络层跟业务对接部分的设计
2.网络层的安全机制实现
3.网络层的优化方案
网络层跟业务对接部分的设计
这本文Casa就这个分了三个问题来讨论怎么去设计
1.使用哪种交互模式跟业务层做对接？
说到交互模式，那就要讨论数据流向业务层的表现形式，这里又有两个问题
1.以什么方式将数据交付给业务层
2.交付什么样的数据给业务层
以什么方式将数据交付给业务层，仅限于我目前开发所见到的网络层采用的方式有：Delegate,Block,Notification。我更多的使用Block这种方式。当然各种差异区别还有原因，我倾向于使用简单的代码风格，所以会用block，但是至于到底哪个最好，还是要看具体的实际情况来定夺吧。
文中，给出的建议是以delegate为主，notification为辅。也罗列的原因：
1>尽可能减少跨层数据交流的可能，限制耦合
2>统一回调方法，便于调试和维护
3>在跟业务层对接的部分只采用一种对接手段限制灵活性，以此来交换应用的可维护性
事实上，网络层定义好以后，以上的方式，都可以对应上面的方法，只需要统一优化。当然Casa也详细对这些原因作了解释。也就是在网络层，要限制跨级使用，定制好规范。文中专门把block拉出来，说了他的使用弊端。对于block，可是使代码简洁。不过难追踪，难维护（加重点）确实不太好处理，但是也可以用打印方式来去看的，所以，我并不觉得这个是问题。不过指出block回延长相关对象生命周期，这点，有关效率部分，我无法反驳，确实，对于注重内存的，这个无法忍受。我是同意的。之后，他提出了block在离散型场景下不符合使用的规范。这个地方我还没有深入了解过，所以不予评论。算是一个学习点。不过在这里Casa也说出了关于为什么大多数公司使用的是block。
之后的关于统一回调方法中，文中列举了关于block的回调方法问题，并写出自己的建议，觉得是可以借鉴吸收的，这样优雅的代码方式，简直了。所以，接下来的如果代码重构，想尝试一下。
最后的总结我想在这里强调下：
综上，对于以什么方式将数据交付给业务层？这个问题的回答是这样：
尽可能通过Delegate的回调方式交付数据，这样可以避免不必要的跨层访问。当出现跨层访问的需求时（比如信号类型切换），通过Notification的方式交付数据。正常情况下应该是避免使用Block的。
交付什么样的数据给业务层
这个Casa提出了自己的见解，把众多app通用处理方式批了一顿。否定了将数据转变成对应的对象原型种种问题成本。然后提出自己的解决方案，添加了reformer这个对象用于封装数据转化的逻辑，这个对象是一个独立对象，事实上，它是作为Adaptor模式存在的。觉得是一个很好的处理方式。
数据采用NSDictionary加Const字符串key来表征，避免了使用对象来表征带来的迁移困难，同时不失去可读性，但是对于喜欢用点语法的人，对此，进行代码编写感觉有些不流畅，毕竟括号比点，点更常用。
之后着重讲解了离散型和集约型设计，给出建议网络上层使用离散型设计，下部分使用集约型设计。也提出应该合理利用继承机制。
其实以上应该是Casa花费了大量时间去思考来写的，下面的更多的是底层的通用处理方式了，当然一些优化，实际上在客户端，并不会感受那么深刻，所以总觉得有些仓促结尾了。不过还是按照上面的来发表下自己的看法。
网络层的安全机制
1.判断API的调用请求是来自于经过授权的APP
这里要考虑两点
1.确保API的调用者是来自你自己的APP，防止竞争对手爬你的API
2.如果你对外提供了需要注册才能使用的API平台，那么你需要有这个机制来识别是否是注册用户调用了你的API
解决方案：设计签名
这个也是大家在与服务端开发人员协商制定的。通用处理方式，就是密钥加密。这里没什么可讨论的。
2.保证传输数据的安全
这里目的在于：
1.防止中间人攻击，比如说运营商很喜欢往用户的Http请求里面塞广告...
2.SPDY依赖于HTTPS，而且是未来HTTP/2的基础，他们能够提高你APP在网络层整体的性能
解决方案：HTTPS
文中有提到使用SPDY是我未知领域，待研究。
网络层的优化方案
这个部分，是精益求精，就目前来说，个人感觉，应该对于网络影响不是特别大。也未涉事了解过，所以，大家还是看原文了。
