第十二章 架构和框架

目的

  • 实现模块化
  • 分层
  • 解耦

图片缓存

图片缓存框架设计方案？

图片缓存时内存设计上需要考虑的问题

  • 内存存储的size

    • 10kb的图片开辟的内存空间 50 张
    • 100kb图片的 20 张
    • 100kb 以上的 10 张
      通过队列的方式存储，先进先出的方式淘汰

  • 淘汰策略

    • 以队列先进先出的方式淘汰
    • 已LRU 算法 (如 30 min 之内是否使用过)

磁盘设计考虑的问题

  • 存储方式
  • 大小限制
  • 淘汰策略(超过 7 天)

网络部分的设计需要考虑的问题

  • 图片请求最大并发量
  • 请求超时策略，一旦超时了，可以重试，如果重试2次失败，是否还下载
  • 请求优先级，下载或者缓存的图片是否紧急需要

图片通过什么方式进行读写，过程是怎样的？

  • 以图片的url 的单向哈希值作为key 存储
  • 读取过程

图片解码

  • 对于不同格式的图片，解码采用什么方式来做？

    • 应用策略模式对于不同图片格式进行解码

  • 在那个阶段做图片解码处理？

    • 再磁盘读取后未解码或者网络请求返回后，解码后再放到内存中，可以减轻主线程的压力，解码在主线程中

线程处理

阅读时长统计

怎样设计一个时长统计框架？

为何要有不同类型的记录器，处于什么考虑？

基于不同分类场景提供的关于记录的封装、适配

记录的数据由于程序杀死或者断电，关机等丢失，你是怎样处理的？

  • 定时写磁盘
  • 限定内存缓存条数，超过该条数就写如磁盘

记录器上传 中延时上传的具体场景有哪些？上传时机如何把握？

上传时机

  • 立刻上传
  • 延时上传
  • 定时上传

延时上传场景

统计结果立即上传会重复调用接口导致资源浪费

  • 前后台切换
  • 从无网到有网的变化时
  • 通过其他的接口捎带着上传

复杂页面的架构

MVVM 框架思想

RN 的数据流思想

任何一个子节点是没有权力做自己的变化更新的，它必须把这个消息传递给根结点，根结点通过自顶向下的遍历查找需要更新的节点

系统UIView 更新机制的思想

AsyncDisplayKit 关于预排版的设计思想

客户端整体架构

需要独立于APP 的通用层
通用的业务层
中间层
业务层

业务之间的解耦通信方式

  • OpenURL
  • 依赖注入方式， 在中间层通过代理 的方式实现业务A 和业务B之间的通信