美文网首页
关于网络层的架构

关于网络层的架构

作者: FongG | 来源:发表于2017-08-08 11:57 被阅读0次

    读了Casa Taloyum老师的关于iOS应用架构谈 网络层设计方案这一篇文章后收获颇多,这里自己做一个思想上的整理。

    主要需要考虑的几个方面

    1.  网络层和业务层的如何进行数据的交互
    2.  如何提升网络请求的安全性
    3.  如何优化网络请求
    

    一、 网络层和业务层的如何进行数据的交互

    1.1 选择集约型api请求,还是离散型api请求?

    1.1.1 两者的区别

    集约型api,就是将所有的api请求都归于一个apiManager去调配;而离散型则是根据不同的业务模块,将对应的api请求各自创建apiManager进行管理。实际上离散型api就相对于对集约型api的分类,他的上一层就是一个总的apiManager作为父类。
    
    补充一下其实我自己的理解,集约型一般是通过类方法的方式请求api,而离散型是通过实例方法完成。后者更容易针对一个task任务的起飞降落进行管控。(ps:我觉得这才是重点)
    

    1.12 选择哪一种?

    离散型api。
    1. 离散型api可以更方便地管理task任务的请求起飞和请求着陆。
    2. AOP的处理方便。ios中主要体现在Method Swizzing
    3. 离散型api可以根据需求增加api调用的灵活性。比如不需要进行page的管理,直接调用nextPage。
    
    

    1.2 传递的数据是否需要Model化处理

    不需要,直接传递json转化后的数据即可(字典或者数组)。
    CT老师的想法是view即便拿到了数据也不转化成model,直接用一个转化器Reformer去对数组/字典筛选展示的数据。具体要不要这样操作,我觉得可以看看到底性能上有多少提升。
    但如果没什么区别,我觉得就没必要了。比较久可读性和开发效率来讲model会更高。
    
    原文中对数组的描述,说了5个点,我觉得可以总结为一下3点:
    1.  减少不可复用的item对象(这个可以接受)
    2.  数据的使用需要二次转化。(不确定性能会差多少)
    3. 同意api数据被不同view展示时,难以控制数据转化的代码,他们可能会在任何地方。(这个难以理解)
    
    

    1.3 通过什么方式来传递数据

    网络层常用的3种数据传值方法:Notification、Delegate、Bolck。
    先说结果:如果是跨层访问,如网络状态的切换,建议采用Notification(一般也只有这个会这样操作)。其他的只能上一层或下一层交互的,使用Delegate完成,不建议使用Block
    
    下面说说block和delegate的问题
    1. 使用方便性
    block方便,但delegate也不差。
    
    2. 可读性
    block只能向上看,而不能向下看(查看哪些地方调用了该block)。
    
    3. 对生命周期的影响
    block会对捕捉的对象引用计数器+1,这样会造成内存泄露(这个可以用weak解决)。但造成的问题是,blcok会延长对象的生命周期。
    比如说在一个控制器中请求一个api,该api的block中访问了self,在请求没有着陆之前,该控制器的内存就无法被释放。(当然你可以说主动调用task cancle来解决,那我没话说)
    
    

    二、提升网络请求的安全性

    主要考虑2点:

    1. 服务器如何辨别请求该api的客户端是被认可的客户端(防止对手爬api)
    一般可以通过签名的方式实现:
    服务器提供一个密钥,调用api时通过api名和参数和密钥拼接成一个参数一起发给服务器,服务器获取到了之后进过校对,判定是否来自认可的客户端。
    
    
    1. 客户端请求api时,如果保证传输数据的安全(运营商很喜欢往http请求中塞广告)
    HTTPS
    这货比http慢很多。
    http耗时 = TCP3次握手
    https耗时 = TCP3次握手 + SSL握手
    

    三、网络优化

    api发起请求是通过3个步骤
    1. 发起请求
    2. DNS域名解析获取ip
    3. 根据http3次握手(https4次),连接建立
    
    1.1 针对发起请求的优化
    
    如果一个api对应的数据实效性够长,可以把api名、参数拼接成一个字符串然后取MD5为key,存储对应的数据。以后请求api可以先从本地获取。api的请求可以先检索本地数据。
    PS:这里需要有一个本地数据的清理策略,可以根据数据的存储量或者存储时间来清理。
    
    1.2 对重复请求的撤销
    如果在上一个请求还没有结束的着陆的情况下,又发起了一个相同的请求,可以撤销后面的请求。
    
    2.1 域名解析api耗时的问题
    直接采用ip访问api
    
    3.1 针对ip的优化
    通过URLProtocol的优化,将Host转化为可获取到的速度最快的ip
    

    相关文章

      网友评论

          本文标题:关于网络层的架构

          本文链接:https://www.haomeiwen.com/subject/wuoelxtx.html