iOS课程观看笔记(十)---架构/框架

架构和框架之所以运用到我们开发中，是为了解决什么问题？
模块化
分层
解耦
降低代码耦合度

图片缓存

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

多了一个图片的编码、解码

图片读写

图片通过什么方式进行读写，过程是怎样的？
图片的读写，以图片的URL的单向Hash值作为key

采用多级缓存，提高查找效率
如果没有内存的查找，直接从硬盘查找，则速度慢；而直接从网络下载，也是速度慢而且耗时且耗费流量

图片缓存中的内存设计

图片缓存中的内存设计上需要考虑哪些问题？

1. 存储Size
2. 淘汰策略

队列的形式存储，并根据已调研统计后的图片大小建立不同大小的存储空间

两方面：
图片大小
图片使用频率

LRU算法（最近最久未使用算法），根据算法查找哪些图片在30分钟之内是否使用过

什么时候执行LRU算法，有两种方法：
一种是定时检查，写一个定时器，在特定时间执行一次，比较low
一种是，在每次进行图片读写的时候，遍历一次图片。或者在前后台切换的时候遍历一次。也就是在某个触发点执行。

图片缓存中的磁盘设计

图片缓存中的磁盘设计需要考虑哪些问题？

对比内存，磁盘的特点是：空间大，读取效率低
需要考虑的问题主要有：

1. 存储方式
2. 大小限制（如100M）
3. 淘汰策略（如某一图片存储时间距今已超过7天）

图片缓存中的网络设计

图片缓存中的网络设计需要考虑哪些问题？

1. 图片请求的最大并发量
2. 请求超时策略
3. 请求优先级

图片缓存中的图片解码

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

jpg\png\gif图
应用策略模式，对不同图片的格式进行解码

什么是策略模式？策略模式解决了什么问题？有什么优势？注意点？

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

• 磁盘读取之后
• 网络请求返回之后

图片在显示之前，会在主线程进行解码操作。

在硬盘中的图片是未解码格式，在内存当中，将图片进行解码，这样会减少主线程的压力。
在网络请求返回后，可以先解码再显示。

图片缓存中的线程处理

SDWebImage可以下载多大的图片，可以缓存多少？

多大图片没有限制；
缓存大小maxCacheSize没有默认值，可以自己设置，设置大小的单位是byte。

有时间上的限制，其默认值是一周

图片的下载操作放在一个NSOperationQueue并发操作队列中，队列默认最大并发数是6

更多学习关于SDWebImage
iOS开发之SDWebImage原理

---

阅读时长统计

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

分为两大模块：
记录器和记录管理者
记录器有几种方式：
页面式：就是进入一个界面开始计时，出去这个界面停止计时，从而达到知道用户在某个界面停留多久

流式：比如微博或者今日头条，微博首页那么大，好多新闻，一个首页就够用了，所以只统计页面没有意义。需要统计流，看某个新闻花费了多少流。

自定义式

记录管理者分为：
内存
磁盘：当手机突然没点，那么统计的数据就没有了，因此，需要将数据存储在磁盘一份
上传器：将记录的数据上传到服务器。

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

基于不同类型的场景，提供关于记录的封装和适配。

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

存储在内存上的东西，可能会突然消失或被覆盖。
那么，我们如何降低丢失率，而不是每一条都不丢失。

• 定时写磁盘（比如每50min写入磁盘一次）
• 限定内存的缓存条数（比如10条），超过该条数，即写入磁盘

记录上传器

记录上传器有立即上传，和延时上传
如果有一条就立即上传，那么对资源消耗就特别大，性能低，也没有意义。
因此，我们采取延时上传。

延时上传
可以在缓存数量达到一定数量（比如50条），批量上传一次。
可以在固定时间（1分钟），不管有多少条，批量上传一次。

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

前后台切换
从无网到有网的状态变化
上传一次。

---

复杂页面构架

少

MVVM

RN数据流思想

任何一个子结点，没有权利更新自己
比如右下角的结点变化了，它要一步一步返回给根节点。
然后，从根节点自订向下遍历，更新需要更新的节点

也就是，从主动变成了被动

这就是RN数据思想流

PS：那么，根节点好忙啊。

---

客户端整体架构

问：你的app，整体架构是怎样的？

上层依赖下层
下层不能依赖上层

OpenURL ？？？