IOS数据加载层架构设计

工作中做过网络数据加载的设计工作.作为该模块架构设计时考虑的一些方面:

• 网络请求的包装(AF)

• 数据解析(DataParser),需要对空值及错误处理

• 重试队列,对网络请求超时处理

• 对请求进行统一的加工

  • 根据域名,添加不同的公共参数,比如设备类型,OS版本,地理位置信息等. 调用方只关注业务所需参数.
  • 根据请求参数进行请求签名

• 日志

  • 了解使用方的调用情况,帮助定位错误,统计接口性能(比如排查响应时间过长的异常请求)等
  • 考虑到出问题的更多是缓存层之前的部分(比如参数错误,流程错误等), 日志过多干扰问题定位,所以未对缓存层使用日志.

• 缓存的读取及写入

  • 内存+硬盘 缓存方案可由调用方指定
  • 内存使用NSCache或LRU淘汰算法. 最终使用的NSCache,原因:
    • 代码简单
    • 自带线程安全
    • 性能:以单个普通APP的并发量查询操作,这里不会成为瓶颈点
    • 内存警告时能自动清理内存数据  

• 持久化写入

  • 通过对url md5生成近乎唯一的key,作为cache key和文件名

  • 写入temp目录,由系统自动清理

  • 先对业务方返回数据,再进行写入,并使用队列 + 子线程,避免占用主线程

  在设计缓存策略时, 没有使用URLCachePolicy的原因是,我们通过后端返回的数据字段来指定数据有效期,并且需要写入文件持久化存储. 另外需要提供给业务方更加定制化的数据回调策略.

  通过良好的内部封装,将可变部分抽取成配置参数,调用方只关注本业务API特定的必要参数, 不用关注实现细节

调用方法:

  dataloader_a *loader = new dataloader_a;

  loader.load_option = default/net_only/cache_first...; //设置数据加载策略

  loader.param1().param2()="";

  loader.start_with_succ{ process(response) } fail{...};

附架构图设计如下: