问题介绍
最近工作室非常忙,忙着招新,也忙着其他事情。(学习OkHttp、RxJava)很多东西都没有积累下来。 所以打算还是要坚持写文章。实际上OkHttp和RxJava最近理解又多了不少。 但是迫于时间不够,没有时间积累下来。
最近也要开始重构我们工作室的项目,里面的代码有点感人,所以很难下手。 所以还是需要谨慎开始,但最近在思考的是一个问题:
有一些接口是要登录之后才能获取数据的,不然会被返回500.(这里的接口设计严重有问题,但也没办法,也是遗留代码)。 所以Android需要在一段时间了进行轮询,不断向服务器重复请求某个接口,保持App用户在线,以便恢复的时候,还能正常请求数据。
这会导致什么后果?
1.Service造成不必要的内存开销,而且不能保证100%存活,而且增加耗电。
2.不断请求数据,会导致用户流量增加,而且也会增加耗电。
3.用户量增大,导致后台压力太大。
4……
简直可以无限吐槽,经过一番思考,我想出了以下方法。
可能的解决方案
1.修改后台代码
据了解,后台是有一个统一拦截器,用来判断这个用户是否登录。 所以我打算在请求头或者Cookie里面,带上我们的用户名和密码。(但是这样不安全,容易被拦截)
然后如果Session过期,则进行模拟登录,重新分配,然后再返回实际接口数据。
但和后台沟通了之后,发现好像他们后台没有直接操作Cookie的概念。(因为框架已