1. 使用缓存有以下优点：使用缓存可以降低服务器的压力，更快速的响应用户的请求，提升用户体验。
1. 对于很长时间都不会有变化的接口来说，可以设置一个时效性，在时效性之内使用缓存，当然这个时效性要通知到客服及Cloud人员，以便支持用户需求。localOrRemote
2. 对于一些场景可以支持先显示缓存再加载远端，远端返回后覆盖缓存，比如点击微信朋友圈就是先显示的缓存然后去发起请求。localThenRemote
3. 对于一些场景可以支持先加载远端，远端失败才显示缓存。（总体来说返回用户失败不如返回缓存用户更友好）remoteThenLocal
4. 对于一些有很高时效性的场景可以不使用缓存，直接加载远端数据。remote
2. 对于服务器修改了一个字段，客户端有缓存一直显示的缓存没有加载服务器修改后的数据，这种怎么处理呢？
1. 客户端可以设置一个网络层统一的缓存过期时长，并告诉Cloud，这是我们设置的时长，让Cloud明白客户端只有在这个时长后才会生效。
2. 如果Cloud不想等这个时长可以在APP设置页面手动APP清理缓存数据，并且这是合理的，服务器手动修改了字段想要打破客户端的缓存机制直接加载最新的那就是需要手动清理缓存。
3. 客户端可以只做App生命周期内的缓存，比如只做内存缓存、或也做磁盘缓存但在启动时进行清理。
3. 缓存应该怎么做？
1. 缓存的枚举值定义为：
2. 通常所说的三级缓存是指内存缓存、磁盘缓存、云端缓存，而云端缓存需要依赖云端开发人员去做，客户端能独立做的有内存缓存、磁盘缓存。
3. 缓存的Key使用encoded requestURL、method、parameters拼成一个字符串去MD5为key来存缓存。
1. Json转Model是一个通用的需求，网络层直接做了转Model的操作，业务调用就可以使用更少的代码来实现网络请求，所以有必要在网络层做转Model的操作。
2. 苹果系统提供的Decodable方式有很多缺点：
1. 当需要自定义变量名称时，需要写出所有的CodingKeys，例如下面例子只是userID的key不同却需要把nonce、id、state、name、location全部列出来。
2. 当服务端某个字段没有返回，客户端又没有声明为可选类型时，会导致解析Model失败。
3. 给struct里的let常量设置默认值将会很麻烦，其中一种做法是重写init(from decoder: Decoder)方法。
3. HandyJSON对比苹果系统具有以下优点：
1. 当需要自定义变量名称时，只需要写需要自定义的变量，其他变量不需要写。
2. 继承自HandyJSON协议后，其属性强制要求声明为可选类型或赋初值。不存在解析不声明为可选类型解析失败的问题。
3. 给struct里的let常量设置默认值只需要初始化设置即可。
4. HandyJSON demo
应该支持DEBUG模式下的Log打印，打印以一个完整的请求为单位，request等待response返回再统一打印，打印以火箭