怎样设计一个图片缓存框架(基本框架)

• Manager
• 内存缓存
• 磁盘缓存
• 网络下载
• CodeManager
  • 图片解码
  • 图片压缩/解压缩

图片缓存框架.png

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

• 以图片URL的单向Hash值作为key 来存储到存储框架中

  • 为什么要使用内存为了提高系统的查找效率所以才要设置多级缓存，节省流量

    
    图片缓存的过程.png

内存的设计上需要考虑哪些问题

• 存储size
  • 队列方式存储图片，先进先出

  • 根据使用情况存储10kb以下的 50个，100kb以下的20个，100kb以上的10个

    
    根据使用情况来设置size的大小.png

• 淘汰策略
  • 先进先出的淘汰策略
  • LRU 最近最久未使用算法， 如果30分钟是否使用过
    • 定时检查，优化：每次进行读写的时，前后台切换也可以去检查
  • 通过缓存大小清除

磁盘设计

• 存储方式的选择
• 大小限制(如100MB)
• 淘汰策略（距今超过7天）

网络设计

• 图片请求最大并发量
• 请求超时策略
  • 重试机制
  • 请求优先级

图片解码

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

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

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

磁盘读取之后网络请求后进行图片解码。

图片缓存过程？

图片缓存工作流程线程交互.png

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

• 记录管理者
  • 记录缓存模块
    • 内存缓存在程序崩溃的时候怼是怎么办，
    • 磁盘来处理异常场景
    • 上传器 本地时长数据上传给server
  • 流式
• 记录器 (记录的数据交给记录管理者进行管理)
  • 页面式记录器 用户访问一个页面的时长
  • 流式记录器 访问新闻阅读时长记录
  • 自定义记录器 横条新闻播放有业务方控制

阅读时长统计.png

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

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

记录的缓存*存储

记录的数据由于某些原因丢失，你怎么处理？

• 定时写磁盘，每次满足多少条就存储磁盘

关于延时上传的具体场景有哪些？

• 每满多少条上传
• 前后台切换
• 无网到有网的变化

上传时机是怎么样把控的？

• 立即上传
• 延迟上传
• 定时上传

复杂页面架构总结

MVVM框架思想

• View对MVVM有一个强引用，ViewModel作为view的成员变量，ViewModel可以通过block形式把输出结果回传给使用方，或者是RAC响应式编程方来把对应的输出回传给这个视图
  • View包含ViewController
• ViewModel对model有一个强引用，或者是成员变量，model可以用block或者代理会传给Viewmodel

MVVM架构图.png

ReactNative的数据流思想

首先会反向回到根节点，通过自顶向下遍历查找对应打了脏标记的节点，然后去更新对应的视图
任何一个子孙节点是没法做自己的变化更新的。他必须把这个变化消息传递给根节点， 根节点自顶向下的顺序去遍历子孙节点，
从主动行为编程被动行为。

RN数据流思想.png

系统UIView更新机制的思想

微博正文页，反向更新机制，实际上就是模拟了系统的UIView更新机制的思想，
UIView更新机制，就是UIView的绘制流程，调用UIView的setneedsplay只是给对应视图打了一个脏标记，而它真正绘制的时候是在RunLoop将要结束时才进行的实际绘制。view通过反向查找到对应的ViewModel然后变更对应的业务数据，打脏标记，然后在下次reload之前去反向更新从新走一遍RN的数据流来驱动UI的变化，借鉴了系统UIView更新机制的思想

或者是借鉴了AsyncDisplayKit的预排版思想

FaceBook的开源框架AsyncDisplayKit关于预排版的设计思想

预排版，也是解决了性能方面的问题，也是性能优化的一种

客户端整体架构面试问题

如何自己设计客户端的整体架构

• 独立于App的通用层
  • 时长统计、崩溃统计、网络的第三方库
• 通用的业务层
  • 自定义的当下公司业务相关的控件
• 中间层 协调解耦
• 业务A、业务B、业务C、业务D 中间层就是为了解耦这些业务

完全单独拿出来一个业务A就能直接运用

业务之间的解耦通信方式

• OpenURL
• 依赖注入方式

依赖注入

业务A需要使用业务C的一些某些模块，业务C、业务A不产生依赖就可以解耦，那么可以使用中间层，业务A通过中间层获取业务C的方法和成员变量
iOS使用的时候， 让某一个业务方注册一个protocol，注册到中间层当中，同时实现中间层的代理方法，来返回给中间层具体的一个实例对象
然后业务A在使用的时候，通过跟其他业务开发人员商量好的协议，再从中间层中通过某一个方法
获取遵从某个协议的实例然后在业务A当中，把这个实例当作完全遵从这个协议的透明对象来使用，这样就接触了业务A和业务C的耦合称之为依赖注入

总结

图片缓存设计

阅读时长统计

时长统计数据丢失率

复杂页面架构

客户端整体架构

上层可以依赖下层 下层不能依赖上层

业务解耦
OpenUrl
依赖注入