缓存系统的决策：什么数据要缓存？什么缓存数据要丢给业务？

App进入页面请求服务器，在数据返回之前，没什么给用户看，所以我们用一种缓存系统来保存上次请求的数据，这次进入的时候先把缓存数据绘制到UI上，让用户先看到整个页面布局和可能过时的数据，等网络数据返回后再刷新一遍页面，以此来提高用户体验。那么就带来两个问题：

1， 什么样的数据应该缓存起来？

2， 什么情况下应该把缓存数据丢给业务？什么情况下不可以？

总结一下：

1， 什么样的数据应该缓存起来？先说不应该缓存的数据，包括：

        a. 提交类的接口返回数据，缓存的目的是为了填充页面UI元素防止白页，提交类接口数据跟这个目的没关系，并且提交类接口数据实时性要求最高，不能容忍过时数据，如果缓存了，会导致严重错误。

        b. 分页列表数据的非第一页，不应该缓存，对照防止白页的这个目的，第二页以后的数据跟这个目的没关系；

        c. 接口请求失败返回的数据，一般是默认错误提示等；

        d. 接口请求成功但是解析失败的数据，这等于是脏数据；

        e. 接口请求成功并解析成功，但业务上属于失败的数据，比如被踢出了，账号异常了，这些肯定要触发统一的风控规则，用户下一次进入页面肯定不希望因为过时的踢出数据把自己踢下线；

        除了以上的case，请他的数据都可以缓存起来。

 

2， 什么情况下可以把缓存数据丢给业务？ 什么情况下不可以？

        a. 网络回来的数据，当然肯定不是缓存数据了，要无任何条件得丢给UI.

        b. 不符合上面1段落描述的数据，就是不该缓存的数据，但万一缓存系统给保存了，那么取出出来丢给业务之前，要再做一次判断，做个兜底，如果这个缓存数据本来不应该被缓存，此时就不要一错再错丢给业务了；

        c.  如果页面上已经渲染了数据，不是白页了，则缓存数据不应该丢给业务，这样做会多此一举并且导致UI多闪一次；