一.简单介绍
所以构建一个优秀的APP,缓存是非常重要的一个环节。
二.处理方案
这样以此类推，内存中的数据和缓存的数据保持一致。
当用户又一次下拉刷新界面时，会出现两种情况：
第一种情况比較简单。数据变动小于一页。说明刷新返回的数据加上缓存的数据就能够构建出用户的所有数据，所以此时仅仅须要合并刷新返回的最新数据和缓存的数据，将反复的数据去掉就可以。
另外一种情况比較复杂。数据变动大于一页，说明刷新返回数据和缓存数据之间还遗漏了部分的数据，那怎样去同步这部分的数据呢？
简单的方案是，假设出现这样的情况，则重构缓存。重构缓存的意思就是删除旧的缓存信息又一次加入建立缓存。这个方法的长处就是实现简单不easy出错，当然缺点就是假设频繁的重构缓存则失去了缓存的意义。
真正的解决中间数据获取的问题。能够通过新建暂时的数组的方式。将当前在内存中的数据放入暂时的变量中，然后把刷新返回的数据增加内存中，当用户触发载入很多其它事件时，推断最新返回的数据是不是和暂时变量中的数据有重合，有重合说明中间的遗漏数据已经获取完成，则将暂时变量的数据合并到内存中就可以。当然内存中的操作都须要同步到缓存中。
若用户网络不通的情况下直接展示缓存数据。
三.问题
- 载入很多其它时。传入分页的page和size，当用户数据频繁的更新时。会出现冗余的数据，比方第一页的最后两条可能就是第二页的前两条。
- 同步问题，在有些业务中，数据大部分是不变的，可是有些数据是会变化的，比方在微博中，微博内容不会变化，可是转发条数，评论数是在变化的。假设只展示缓存中的数据会出现和server端不同步的问题
- 缓存没有一个清理功能。随着时间的增长，总会出现内存溢出的情况
解决：
问题1：获取数据时分页中增加sinceID和maxID。用以来控制最大和最小的数据ID。这样就能防止冗余的反复数据
问题2：对于频繁的小数据块（如阅读数。分享数）能够制定同步协议，更新这些小数据块时无需更新总体的数据
问题3：内存的增长能够通过限制缓存的条数来控制，当缓存条数超过限制后。为用户重构缓存（大数据块的更新也能够通过定时重构缓存来实现）
异常处理：
网络异常--显示缓存数据
内存溢出--限制缓存条数
转载于:
一.简单介绍
所以构建一个优秀的APP,缓存是非常重要的一个环节。
二.处理方案
这样以此类推，内存中的数据和缓存的数据保持一致。
当用户又一次下拉刷新界面时，会出现两种情况：
第一种情况比較简单。数据变动小于一页。说明刷新返回的数据加上缓存的数据就能够构建出用户的所有数据，所以此时仅仅须要合并刷新返回的最新数据和缓存的数据，将反复的数据去掉就可以。
另外一种情况比較复杂。数据变动大于一页，说明刷新返回数据和缓存数据之间还遗漏了部分的数据，那怎样去同步这部分的数据呢？
简单的方案是，假设出现这样的情况，则重构缓存。重构缓存的意思就是删除旧的缓存信息又一次加入建立缓存。这个方法的长处就是实现简单不easy出错，当然缺点就是假设频繁的重构缓存则失去了缓存的意义。
真正的解决中间数据获取的问题。能够通过新建暂时的数组的方式。将当前在内存中的数据放入暂时的变量中，然后把刷新返回的数据增加内存中，当用户触发载入很多其它事件时，推断最新返回的数据是不是和暂时变量中的数据有重合，有重合说明中间的遗漏数据已经获取完成，则将暂时变量的数据合并到内存中就可以。当然内存中的操作都须要同步到缓存中。
若用户网络不通的情况下直接展示缓存数据。
三.问题
- 载入很多其它时。传入分页的page和size，当用户数据频繁的更新时。会出现冗余的数据，比方第一页的最后两条可能就是第二页的前两条。
- 同步问题，在有些业务中，数据大部分是不变的，可是有些数据是会变化的，比方在微博中，微博内容不会变化，可是转发条数，评论数是在变化的。假设只展示缓存中的数据会出现和server端不同步的问题
- 缓存没有一个清理功能。随着时间的增长，总会出现内存溢出的情况
解决：
问题1：获取数据时分页中增加sinceID和maxID。用以来控制最大和最小的数据ID。这样就能防止冗余的反复数据
问题2：对于频繁的小数据块（如阅读数。分享数）能够制定同步协议，更新这些小数据块时无需更新总体的数据
问题3：内存的增长能够通过限制缓存的条数来控制，当缓存条数超过限制后。为用户重构缓存（大数据块的更新也能够通过定时重构缓存来实现）
异常处理：
网络异常--显示缓存数据
内存溢出--限制缓存条数
