图片缓存

怎样设计一个图片缓存框架

图片管理者模块：内存缓存模块、磁盘缓存模块、网络图片下载模块
图片处理：图片解码、图片压缩/解压缩

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

以图片URL的单向Hash值作为key 来存储到存储框架中
然后根据key值来获取图片，首先在内存中进行查找，找不到再进行磁盘查找，如果仍然找不到，最后通过网络进行图片的下载
系统使用了多级缓存策略来提高查找的效率，节省流量

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

存储的size：队列方式存储图片，先进先出，根据使用情况存储10kb以下的 50个，100kb以下的20个，100kb以上的10个，根据图片的大小，开辟不同的存储空间
淘汰策略
1. LRU 最近最久未使用算法，如果30分钟是否使用过
  通过定时器来定时检查，或者通过提高检测频率，例如在图片进行读写时，前后台进行切换时，可以进行检测

磁盘设计上需要考虑的问题

磁盘的特点：磁盘空间很大，但是读写效率很低
存储方式的选择
① Documents：保存应用运行时生成的需要持久化的数据,iTunes会自动备份该目录。苹果建议将在应用程序中浏览到的文件数据保存在该目录下。
② tmp：临时文件目录，在程序重新运行的时候，和开机的时候，会清空tmp文件夹。
③ Library:
1. Caches：
  一般存储的是缓存文件，例如图片视频等，此目录下的文件不会再应用程序退出时删除。
  在手机备份的时候，iTunes不会备份该目录。
  例如音频,视频等文件存放其中
2. Preferences：
  保存应用程序的所有偏好设置iOS的Settings(设置)，我们不应该直接在这里创建文件，
  而是需要通过NSUserDefault这个类来访问应用程序的偏好设置。
  iTunes会自动备份该文件目录下的内容。
  比如说:是否允许访问图片,是否允许访问地理位置......
存储大小的选择（100MB）
淘汰策略的选择（先进先出淘汰策略，LRU定时检测策略）

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

图片请求最大并发量
请求超时策略
请求优先级

图片解码考虑的问题

应用策略模式对不同图片格式进行解码
在哪个阶段做图片的解码：① 磁盘读取后 ② 网络请求返回后
图片加载的工作流
概括来说，从磁盘中加载一张图片，并将它显示到屏幕上，主要工作流如下：
1. 假设我们使用 +imageWithContentsOfFile: 方法从磁盘中加载一张图片，这个时候的图片并没有解压缩；
2. 然后将生成的 UIImage 赋值给 UIImageView ；
3. 接着一个隐式的 CATransaction 捕获到了 UIImageView 图层树的变化；
4. 在主线程的下一个 run loop 到来时，Core Animation 提交了这个隐式的 transaction ，这个过程可能会对图片进行 copy 操作，而受图片是否字节对齐等因素的影响，这个 copy 操作可能会涉及以下部分或全部步骤：
a.分配内存缓冲区用于管理文件 IO 和解压缩操作；

b.将文件数据从磁盘读到内存中；

c.将压缩的图片数据解码成未压缩的位图形式，这是一个非常耗时的 CPU 操作；

d.最后 Core Animation 使用未压缩的位图数据渲染 UIImageView 的图层。
在上面的步骤中，我们提到了图片的解压缩是一个非常耗时的 CPU 操作，并且它默认是在主线程中执行的。那么当需要加载的图片比较多时，就会对我们应用的响应性造成严重的影响，尤其是在快速滑动的列表上，这个问题会表现得更加突出。
在将磁盘中的图片渲染到屏幕之前，必须先要得到图片的原始像素数据，才能执行后续的绘制操作，这就是为什么需要对图片解压缩的原因。

阅读时长统计

记录器

页面式记录器用户访问一个页面的时长
流式记录器访问新闻阅读时长记录
自定义记录器横条新闻播放有业务方控制

记录管理者模块

记录的缓存
磁盘缓存（来处理内存模块的记录丢失问题）
上传器，上传至server

为何会有不同类型的记录器，考虑点是什么

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

记录的数据会由于某种原因丢失，如何处理（降低丢失率）

定时写磁盘（例如每满30分钟，我们就对磁盘进行一个写入）
限定内存缓存条数（如10条），超过该条数，即写磁盘

记录上传器，关于延时上传的具体场景

前后台切换
从无网到有网的变化
通用的轻量接口捎带（可以忽略，前两种已经最佳）

长传时机是怎样把握的

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

复杂页面架构

MVVM框架思想

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

ReactNative的数据流思想

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

系统UIView更新机制的思想

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

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

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

客户端整体架构

业务之间的解耦通信方式

OpenURL
① 中间件提供方法，可以将url和block进行绑定，各组件都要首先调用注册方法，把自己的功能（block）和对应的url注册到中间件中，才能让其他组件通过url调用。
② 从移动端的角度来说，就是把URL映射到相应的类上，iOS中的路由不是仅仅做页面跳转的，只是用的最多的地方，主要是因为可以解耦页面跳转的逻辑，它可以中转的不仅仅是 Controller还可以是其它对象,比如 UIImage ...
依赖注入方式：简单的来说就是，业务A需要使用业务C里边的一些模块，但是，为了遵循低耦合原则，我们此时就需要一个中间层，让业务A通过中间层获取业务C的方法和成员变量，
在iOS使用时，让某一个业务方注册一个protocol，注册到中间层中，同时实现中间层的代理方法，来返回给中间层具体的一个实例对象
然后业务A在使用时，通过跟其他业务人员商量好的协议，再从中间层通过某一个方法获取遵从某个协议的实例然后在业务A中，把这个实例当作完全遵从这个协议的透明对象来使用，这样就解除了业务A和业务C之间的耦合，这个样称之为依赖注入