第十三篇：Objective-C 知识回顾架构框架之一

本篇大纲内容

13.1.架构&框架

问题一： 架构&框架是什么？

• 引入框架&架构，主要是为了实现 模块化。
• 然后再做一个相应的 分层。
• 目的就是为了 解耦。
• 最终达到 降低代码重合度 的效果

13.2.图片缓存框架

问题一： 怎样设计一个图片缓存框架？

图片缓存框架设计图解

• 首先我们这个图片管理缓存框架需要有一个管理者Manager用于管理或者说协调调度这个框架内部的各个模块。
• 接下来需要有个关于内存缓存的模块，然后有一个关于磁盘缓存的模块，如果图片需要网络获取，还需要一个网络获取图片的模块。
• 如果图片是经过压缩的，我们就需要配一个图片解码的管理者 Code Manager，用于调度 图片解码模块 和 图片压缩/解压缩模块。

问题二： 一般常用的图片库，图片通过什么方式进行读写，过程是怎么样的？

• 以图片 URL 的单向 Hash 值作为 Key。

  
  
  

  图片在框架中的读取流程

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

• 存储的 Size（不能无限大，容易造成内存压力过大）
• 淘汰策略（因为有 Size 的限制，所以在超过限制了，就要有对应的淘汰策略）

存储的 Size 在数据结构上的设计（重要）

淘汰策略一：利用队列的先进先出方式进行淘汰

淘汰策略一：通过 LRU 算法进行淘汰，定时检测不推荐，耗时费力

问题四： 磁盘设计要考虑哪些问题？

问题思路指引，相比于内存，磁盘的存储很大，但是读取效率比较低。基于这个我们可以尝试寻找答案。

• 存储方式的选择
• 大小限制（如 100MB）
• 淘汰策略（如某一图片存储时间距今已超过7 天）

问题五：网络设计要考虑哪些问题？

• 图片请求最大并发量（比如最大并发量 10）
• 请求超时策略（再次请求，失败两次就不请求）
• 请求优先级（有些重要的图片，优先请求，失败多次重试）

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

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

问题七：什么是策略模式？

• 策略模式定义了一组算法，将它们逐个封装起来，并使得它们可以相互替换。策略可以让算法独立于使用它们的客户而变化。

问题八：在哪个阶段做图片解码处理？

• 磁盘读取后（从而保证存到内存中的是已经解码的，让主线程读取后直接使用，减轻主线程的负担）
• 网络请求返回后

13.3.阅读时长统计

问题一： 怎样设计一个阅读时长统计框架？

时长统计框架的总体设计

• 页面式记录器，一般push的时候为开始时间，pop 的时候为结束时间。
• 流式记录器，比如微博这样 feed 流的页面，对其进行停留时长统计。
• 自定义式记录器，记录一些自定义，比如说横幅停留时间等等，可以增强框架的扩展性。
• 记录管理者负责管理 记录缓存 磁盘存储 上传器。
• 记录缓存是缓存记录器所记录的信息到内存。
• 磁盘存储是反正内存中的缓存丢失。
• 上传器是为了将记录的数据上传到服务器。

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

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

问题三：记录的数据会由于某种原因丢失，你是怎么样处理的？

问题解答思路：问这个问题要考虑到，数据在内存中偶尔出现丢失，这是必定会出现的问题，并不是问你怎么让它一条都不丢失，而是怎么做到尽量少丢失。

• 定时写磁盘
• 限定内存缓存条数（如10 条），超过该条数，就写入磁盘。
• 定时上传到服务器

问题四：关于延时上传的具体场景有哪些？

问题解答思路：关于延时上传的对立面就是立即上传，可想而知如果我每次产生一条记录，立刻上传到服务器，这个无疑是降低了客户端的性能以及十分消耗用户的流量。

• 前后台切换的时候上传
• 从无网到有网上传
• 通用的轻量接口捎带一些数据

问题五：上传时机怎么把控的？

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