开发过程中引入框架与架构，是为了解决什么问题？
- 模块化
- 分层
- 解耦
- 降低代码重合度
图片缓存框架
怎样设计一个图片缓存框架？(多级缓存)
图片缓存架构.png
图片通过什么方式进行读写，过程是怎样的？
- 以图片URL的单项Hash值作为Key
图片读取流程.png
内存的设计上需要考虑哪些问题？
存储的Size
淘汰策略
存储的Size
存储大小.png
淘汰策略
- 以队列先进先出的方式淘汰
队列淘汰.png
- LRU算法(如30分钟之内是否使用过-最近最久未使用算法)
淘汰策略.png
磁盘设计
磁盘设计需要考虑哪些问题？
- 存储方式
- 大小限制(如100MB)
- 磁盘的淘汰策略(如某一图片存储时间距今已经超过7天)
网络设计
网络部分的设计需要考虑哪些问题？
- 图片请求最大并发量
- 请求超时策略
- 请求优先级
图片解码
对于不同格式的图片，解码采用什么方式来做？
- 应用策略模式对不同图片格式进行解码
在哪个阶段做图片解码处理
- 磁盘读取后
- 网络请求返回后
线程处理
图片缓存时序图.png
阅读时长统计
怎样设计一个时长统计框架？
时长统计框架.png
记录器
为何要有不同类型的记录器，你的考虑是什么？
- 基于不同分类场景提供的关于记录的封装、适配
记录的缓存和存储
记录的数据会由于某种原因丢失，你是怎样处理的？(降低丢失率)
- 定时写磁盘
- 限定内存缓存条数(如10条)，超过该条数，即写磁盘
记录上传器
客户端如果每出现一条就上传，是很浪费流量和性能的，所以会采取延时上传的策略。
关于延时上传的具体场景有哪些？
- 前后台切换
- 从无网到有网的变化
- 通用轻量接口捎带(这个可能会出现耦合)
上传时机是怎样把控的？
- 立刻上传
- 延时上传
- 定时上传
复杂页面架构
微博APP的正文页
- 整体架构
- 数据流
- 反向更新
整体架构
微博架构.png
视图层(View & ViewController)
View：
- 控件初始化
- 设置数据
- 交互事件代理
ViewController:
- 视图创建、组合
- 协调逻辑
- 事件回调处理
业务逻辑层(ViewModel)
- 业务逻辑处理(预排版)
- 数据增删改查封装者
- 线程安全处理
数据层(Engine & Model)
- 网络请求
- 数据解析
- 增删改查
- 本地处理逻辑(对Server的适配)
数据流
数据流.png
数据及数据关系
- 网络数据
- 一级评论
- 二级评论
- 转评赞
- 广告、推荐等其他数据
- 业务数据
id dataint type
- UI数据
- imageObj
- LabelObj
- frame
- value
数据与数据之间的关系.png
反向更新
反向更新.png
view以代理的方式找到ViewController，再根据ViewController对ViewModel的强引用，找到对应的ViewModel。然后根据UI数据对业务数据的弱引用，由ViewController找到对应的业务数据，并在对应的业务数据上打下脏标记。之后再由查找到的ViewModel进行数据流的重新驱动。由业务数据经由ViewModel标记为脏数据的重新处理，生成一个新的UI数据，然后交由ViewController，在下一次刷新视图之前做一个数据的变化，这样在刷新之后就可以看到由于数据的变化导致的视图改变。
复杂页面架构总结
- MVVM框架思想
- ReactNative的数据流思想
- 系统UIView更新机制的思想
- FaceBook的开源框架AsyncDisplayKit关于预排版的设计思想
MVVM
MVVM.png
RN数据流思想
RN数据流.png
任何一个子节点或者子孙节点是没有权利做变化更新的，必须要把更新的消息传递给根节点，然后由根节点来去自顶向下的方式去询问哪些需要更新，然后去跟新具体的视图。
客户端整体架构
客户端整体架构.png
业务之间的解耦通信方式
- openURL
- 依赖注入
依赖注入
依赖注入.png
面试总结
图片缓存怎么设计
阅读时长统计怎么设计
复杂页面架构怎么设计
客户端整体架构设计分层
