13.1.架构&框架
问题一: 架构&框架是什么?
- 引入框架&架构,主要是为了实现
模块化
。 - 然后再做一个相应的
分层
。 - 目的就是为了
解耦
。 - 最终达到
降低代码重合度
的效果
13.2.图片缓存框架
问题一: 怎样设计一个图片缓存框架?
图片缓存框架设计图解- 首先我们这个图片管理缓存框架需要有一个管理者
Manager
用于管理或者说协调调度这个框架内部的各个模块。 - 接下来需要有个关于内存缓存的模块,然后有一个关于磁盘缓存的模块,如果图片需要网络获取,还需要一个网络获取图片的模块。
- 如果图片是经过压缩的,我们就需要配一个图片解码的管理者
Code Manager
,用于调度图片解码模块
和图片压缩/解压缩模块
。
问题二: 一般常用的图片库,图片通过什么方式进行读写,过程是怎么样的?
-
以图片 URL 的单向 Hash 值作为 Key。
图片在框架中的读取流程
问题三: 内存的设计上需要考虑哪些问题?
- 存储的 Size(不能无限大,容易造成内存压力过大)
- 淘汰策略(因为有 Size 的限制,所以在超过限制了,就要有对应的淘汰策略)
问题四: 磁盘设计要考虑哪些问题?
问题思路指引,相比于内存,磁盘的存储很大,但是读取效率比较低。基于这个我们可以尝试寻找答案。
- 存储方式的选择
- 大小限制(如 100MB)
- 淘汰策略(如某一图片存储时间距今已超过7 天)
问题五:网络设计要考虑哪些问题?
- 图片请求最大并发量(比如最大并发量 10)
- 请求超时策略(再次请求,失败两次就不请求)
- 请求优先级(有些重要的图片,优先请求,失败多次重试)
问题六:对于不同格式的图片,解码采用什么方式来做?
- 应用策略模式对不同图片格式进行解码。
问题七:什么是策略模式?
- 策略模式定义了一组算法,将它们逐个封装起来,并使得它们可以相互替换。策略可以让算法独立于使用它们的客户而变化。
问题八:在哪个阶段做图片解码处理?
- 磁盘读取后(从而保证存到内存中的是已经解码的,让主线程读取后直接使用,减轻主线程的负担)
- 网络请求返回后
13.3.阅读时长统计
问题一: 怎样设计一个阅读时长统计框架?
时长统计框架的总体设计- 页面式记录器,一般
push
的时候为开始时间,pop
的时候为结束时间。 - 流式记录器,比如微博这样 feed 流的页面,对其进行停留时长统计。
- 自定义式记录器,记录一些自定义,比如说横幅停留时间等等,可以增强框架的扩展性。
- 记录管理者负责管理 记录缓存 磁盘存储 上传器。
- 记录缓存是缓存记录器所记录的信息到内存。
- 磁盘存储是反正内存中的缓存丢失。
- 上传器是为了将记录的数据上传到服务器。
问题二: 为何要有不同类型的记录器,你的考虑是什么?
- 基于不同分类场景提供的关于记录的封装、适配。
问题三:记录的数据会由于某种原因丢失,你是怎么样处理的?
问题解答思路:问这个问题要考虑到,数据在内存中偶尔出现丢失,这是必定会出现的问题,并不是问你怎么让它一条都不丢失,而是怎么做到尽量少丢失。
- 定时写磁盘
- 限定内存缓存条数(如10 条),超过该条数,就写入磁盘。
- 定时上传到服务器
问题四:关于延时上传的具体场景有哪些?
问题解答思路:关于延时上传的对立面就是立即上传,可想而知如果我每次产生一条记录,立刻上传到服务器,这个无疑是降低了客户端的性能以及十分消耗用户的流量。
- 前后台切换的时候上传
- 从无网到有网上传
- 通用的轻量接口捎带一些数据
问题五:上传时机怎么把控的?
- 立刻上传
- 延时上传
- 定时上传
网友评论