其实你也说了，增删是有变化的，除非你们有完整的通知机制能告知Android端数据改变了，如若不是，你还是有必要在需要数据的场景下请求

如果后端能配合

1、使用MQTT，消息推送。后端在进行人员修改的时候把事件推送到客户端，客户端同步删除。

2、在接口中，人员id，额外返回一个时间戳，代表了最后更新时间， 这个时间戳存到数据库。里，如果本地时间和接口时间一致，代表本地数据就是最新的，不用更新。否则就调接口更新数据。

如果后端不配合

1、

step first 用户数据缓存到本地，第二次正常调取本地数据，正常显示

step second 在第二次调取数据的同时异步调接口，查数据，对比本地数据是否需要更新

step third 如果判断需要更新，定义接口，把数据推送给UI界面刷新，同时异步存储数据

虽然不能真的做到实时，但是一定程度上的实时了。

2、

要来代码，自己改后端代码，不就是个用户信息缓存吗，后端这点活都不愿意干。

用Java写的话，可以去了解一下flatMap和map函数的用法，retrofit结合rxjava的flatMap函数可以将一个请求的结果作为下一次的请求的参数，用来解决链式请求问题很方便，具体可以看看https://juejin.cn/post/6844903464330330125；kotlin+协程写的话会更加简洁。

其实你已经写好了

Sp 更适合吧 简单轻量 你可以搜索一下SharedPreferences

如果频繁更换的话 按道理就不能做缓存了哦 还是得实时请求