手机端解决被迫下线的方案

手机端被迫下线实现方案

方案一(现用,具体看嘀嗒应用源码):

后台:定义一个字段(useid),登陆时把这个字段返回给用户,

前台:在BacrActivity里定义一个线程,每个十秒请求一次,请求到返回的数值跟本地比较,不一样是直接跳到登陆界面,从而实现异地登录被迫下线功能.

注意事项:第一次不匹配,被迫下线后前台已存的页面要清空,应用到activity管理

优点:实现简单,后台修改简单,前台只需一个线程就ok

缺点:每十秒请求一次数据,当用户群小时还行,当用户群多时,服务器压力大.同时每十秒刷新也给用户带来了不必要的流量浪费.

应用场景:应用要求不太严格,用户量少的客户端.

 

 

方案二: 利用广播接收器,当A用户登陆一个ID1后,B用户再登陆ID1后,利用推送消息机制,服务器给A发一个消息,A接收到广播后,执行下线操作.

具体实现过程:(利用到推送服务)

后台: 当一个ID已经登录,再次登录时,通过服务器向第一个登录的用户发送消息,

前台:集成第三方推送(百度.信鸽,极光),通过自定义广播接收器,首先把本个应用推送默认为不可设置且为默认接收,当接受广播消息进行验证字段或标签来执行是否下线,如果是直接提示用户”该账号应经在其他地方登陆,请重新登陆!”

注意事项:清楚推送服务的类型,避免造成不必要的麻烦.前台应用自定义广播接收器,且设置为不可屏蔽.被迫下线及时清空Activity.

缺点:因为不同的第三方推送有不同的服务器类型,一种是用户关闭推送消息,是关闭服务器,不在推送消息,一种是关闭后只是不在提示,但依据能接收,所以用第三方推送时要了解清楚.一旦屏蔽消息无法接收后,就不能实现被迫下线功能.

优点:对服务器压力小,对用户来说,减少请求次数,减少不必要的流量和电量浪费.

应用场景:使用人数多,需要推送机制服务的客户端