API的安全机制
主要存在两个漏洞：
1. 是因为缺少对调⽤者进⾏安全验证的⽅式
保证API的调⽤者是经过⾃⼰授权的App, 采⽤设计签名的⽅式. 对每个客户端，Android、iOS、WeChat，分别分配⼀个AppKey和AppSecret
客户端调用API -> ⽣成⼀个签名字符串(将AppKey加⼊请求参数列表，并将AppSecret和所有参数⼀起，根据某种签名算法生成) -> 请求带上签名字符串
服务端收到请求 -> 根据请求中的AppKey查询相应的AppSecret，按照同样的签名算法，也⽣成⼀个签名字符串 -> 当服务端⽣成的签名和请求带过来的签名⼀致的时候，那就表示这个请求的调⽤者是经过⾃⼰授权的，证明这个请求是安全的
注意：
1. 每个端都有⼀个Key，也⽅便不同端的标识和统计。
2. 为了防⽌AppSecret被别⼈获取，这个AppSecret⼀般写死在代码⾥⾯。
3. 签名算法也需要有⼀定的复杂度，不能轻易被别⼈破解，最好是采⽤⾃⼰规定的⼀套签名算法，⽽不是采⽤外部公开的签名算法。
4. 在参数列表中再加⼊⼀个时间戳，还可以防⽌部分重放攻击
2. 是因为数据传输不够安全， 采⽤HTTPS
HTTPS因为添加了SSL安全协议，⾃动对请求数据进⾏了压缩加密，在⼀定程序可以防⽌监听、防⽌劫持、防⽌重发，主要就是防⽌中间⼈攻击
MVP架构
业务层向数据层请求数据；
数据层检查缓存中有没有请求需要的数据；
如果有缓存数据，则直接返回缓存数据；
如果没有缓存数据，则从⽹络API获取数据，并将数据加⼊缓存，然后返回数据
一般用于GET 查询数据缓存 ，Post 一般不用
调⽤频率⾼、最新的数据 NSCache + CoreData + plist
调⽤频率低、最新的数据 CoreData + plist
1. net目录 网络请求， AFNetworking + 对外的功能 协议HttpResponseHandle
get 方法 + 是否缓存的标识
post方法
网络判断 Wi-Fi 或4g或无网
HttpResponseHandle 协议
成功回调 + 缓存数据(有缓存 返回{缓存key: url, 请求参数}， 没有缓存 返回nil)
失败回调
2. coreData 目录 CoreData缓存
CoreDataUse CoreData的基本使用
StudentUse 遵守CoreDataCacheProtocol 缓存协议的，具体的CoreData存储 某个HomeModel数据模型的应用
3. cache 目录 数据缓存
ZTCache 具体的缓存方式
plist 存储 开始缓存的时间（判断缓存是否过期）和 已缓存的page（
coreData：缓存过 更新操作， 没有缓存 添加操作
NSCache: 初始化有默认值填充（@(0)）, 只有更新操作
）
1. 缓存模式 ：没有缓存 或 频率高 NSCache + CoreData 或 频率低 CoreData
2. 构造函数 传一个遵守CoreDataCacheProtocol协议的对象
3. 储存数据
4. 获取数据
CoreDataCacheProtocol 协议， 数据操作 page 基本单元，1页存10条数据
添加数据：添加具体的实现（StudentUse） 对应的数据，是以page为基本单元
查找数据：查找具体的实现（StudentUse） 对应的数据
更新数据：更新具体的实现（StudentUse） 对应的数据
删除数据 ：删除具体的实现（StudentUse） 对应的数据
4. presenter目录 业务层
1. 具备网络数据的 属性， HttpClient 并遵守网络响应协议
2. 添加视图层HomeViewProtocol 代理，把得到数据往上传递
3. 获取数据的方法， 可以做缓存。添加 ZTCache 缓存对象和 HttpClient 网络请求对象
5. HomeViewProtocol 协议
视图 要实现的协议，可以得到成功返回数据 或 失败返回数据
6. model 目录 数据的模型，JSONModel 实现的
7. viewController 遵守HomeViewProtocol 协议
具备业务层 HomePresenter属性
签订HomeViewProtocol代理 为viewController
HomePresenter属性 发起数据请求， 通过实现HomeViewProtocol 协议，获取数据
环境分离
不同环境有不同的App
