前提条件：如果一共有12条数据，每次请求加载10条，滑动到底部时自动加载更多
问题触发：如果用户删除了4条数据，这时候RecyclerView滑动到了底部触发了加载第二页的逻辑，但这时候只有8条数据只有一页了，请求第二页的数据为空，于是底部显示“没有更多数据了”，但现在列表只展示了6条（删了4条），其实还有2条数据没有请求到没有展示出来。
问题引申：
1、如果用户每次删除文件都刷新列表(等同于下拉刷新)，这样体验不好，每次都重新回到顶部。
2、假如用户一直上拉加载到了99页，然后随机删除某些页的一条或多条数据，如何保证page和数据的准确性?
解决方案一：假如用户一直上拉加载到了99页，然后滑回去删除了第50页的某条数据，这时候请求第100页的第一条数据填充到数据末尾，这时候前99页的数据也是完整的。需要注意的点是删除的时候先请求数据，因为为了防止删除最后一条数据引起上拉加载更多而引起二种数据同时处理混乱的情况。
解决方案二：假如用户一直上拉加载到了99页，然后滑回去删除了第50页的某条数据，这时候保存第0页-第49页的数据，然后重新请求第50页的数据addAll到保存的第0页-第49页的数据上，用这个数据加载列表。因为第50页的数据变了，所以之前的第50页-第99页的数据都没用了，用户继续上拉加载新的第51页、第52页......
这种方案相对比较容易实现，但也有个问题是：用户之前看到的条目可能会偏移，比如看到了第50页的第9条，然后删除第50页的第9条，这时候第50页的数据全部删除，并重新加载第50页，这时候用户看到的第一条是第50页的第一条，而不是原来的第50页的第9条。
解决方案三：先请后端老哥吃顿饭。传统的请求都是传page和page_size，比如第一页请求10条，就是page=1|page_size=10，如果改成按数据索引返回就可以完美解决这个问题。因为前端不管怎么删，条目的索引跟后台都是同步的，比如请求了第一页的10条数据并删了前8条，那第9条的数据在前端和后端的索引就都变成了0，如果请求第二页的数据就应该从索引2开始（第一页剩余的二条数据是索引0和索引1），即请求索引2到11的数据，这样就可以根据索引拿到准确的第二页的数据了。这样操作非常简单，只用管集合的长度（对应条目索引），同时删除时不需要重新请求对应页的数据，只需要正常的上拉加载即可。
暂时只想到这三种方案，欢迎交流！
