iOS开发-App网络层的思考

App开发基本离不开网络请求,网络层应该怎么去搭建才能更方便使用、更专注于业务逻辑?

自个儿琢磨了一段时间,也参考了一些博客和开源框架,于是有了以下的网络层架构图。主要包含2大块,缓存层和网络请求层。

StructureFlow.png

缓存层

大部分App都会针对某些接口设计缓存。
一方面是为了在无网络或网络请求失败的时候有数据展示,而不是空白一片,这样用户体验会更好;
另一方面是为了节省资源,如果本身接口的数据更新不频繁的,没必要每次都去发起网络请求去服务器取数据,只需读缓存就可以了,例如省市区数据。

针对以上问题,我想不如每个接口都设计2个缓存配置项,一个用于配置是否需要缓存数据,另一个配置缓存过期时间。
在缓存有效时间内发起的网络请求,底层不会真正发起网络请求,只是去读取缓存数据然后返回结果。
如果缓存过期时间配置是永久有效的,则先读取缓存数据,然后发起网络请求,会回调2次。这种配置主要是为了在无网络或者是网络请求失败的时候有数据展示。

在框架中,我使用了开源库 SPTPersistentCache, 它是LRU缓存设计,可以设置缓存数据有效时间和缓存自动回收。

网络请求层

这是核心层,里面包含网络监测、JSON数据转化和缓存处理。
每一次请求都会先检查网络是否连接,如果无网络,直接返回错误。
如果网络请求失败,例如网络超时或者是服务器错误,则会返回错误。
当网络请求成功并有数据返回时,会判断当前请求是否有设置缓存,如果有则会先把数据缓存起来,然后回调成功结果。

网络请求是封装开源框架 AFNetwoking,请求参数是以NSDictionary 格式传入,返回的则是JSON数据。

我觉得请求参数以字典的形式很不方便,写起来麻烦,维护起来也麻烦,如果某个接口参数变了,需要找到那个网络发起的位置,然后修改字典的key。
针对以上问题,我利用开源框架 MJExtension,把每个接口的参数以数据Bean的形式管理,一个接口对应一个Bean。发起网络请求的时候只需传入这个Bean的实例,网络层会在里面转成字典形式,然后发起请求。

另外一个是网络返回的JSON数据,如果我们每次都需要在业务层对返回的JSON数据进行转化,这样重复代码很多,写起来也不方便。
针对此问题,我在网络层里面把返回的JSON数据利用框架 MJExtension 转成数据Bean,然后返回给业务层,这样业务层拿到就可以用了,方便。

总结

总的来说,就是把数据的处理合并在一起,在业务层直接拿就可以了。

以上是我对网络层的一些思考,不足之处,还请多多指教。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 135,001评论 19 139
  • iOS网络架构讨论梳理整理中。。。 其实如果没有APIManager这一层是没法使用delegate的,毕竟多个单...
    yhtang阅读 5,277评论 1 23
  • 1.稀缺是一个基本事实,我们把经济学建立在“稀缺”的前提上,稀缺不是假设,而是事实。 2.产生稀缺的原因:1)你想...
    怡辛缘静静阅读 403评论 1 2
  • 人真是一种奇怪的季节性动物,一到炎炎夏日时,总爱来些冰镇的饮料和西瓜。每一样都恨不得都刚从冰箱里拿出来,透着沁人的...
    味博士阅读 1,092评论 7 10
  • 昨天又错过了交稿的时间,才7号啊,已有两次未交稿的经历,只有一次机会了,下决心好歹再烂的文即使拼凑也一定要按时交稿...
    吾乡阅读 270评论 1 0