大家好,又见面了,我是你们的朋友全栈君。
一、传统APP架构下的信息传送
APP主动向服务器请求数据,服务器被动的提供数据。
步骤如下:
然而,如果此时服务器又有了新的新闻,在用户没有主动刷新的情况下,服务器是不会主动推送给用户的。
推送解决了这个困境,它让服务器主动连接APP,通知APP有了新的新闻,可以再请求。收到推送的APP(即使已关闭)又去服务器请求最新的新闻,用户就能看到了。
二、实现推送的方法
实现一个推送系统需要服务器端和终端的配合。
方法一:轮询
即不停地向服务器发送请求(既然不知道什么时候会发生,那就一遍一遍的问吧)。
缺点:手机消耗电量、流量大;服务器也要处理大量的请求,压力大。
方法二:APP和服务器建立长时间连接通道
通过这个通道,APP可以向服务器请求数据,服务器也可以向APP发送数据。
android系统中,如果APP被关闭,APP可以启动一个后台服务来维持通道继续运行。(ios的解决方法见下)
如何维护这个长时间连接的通道?
APP会每隔段时间向服务器报告自己还活着,服务器收到后,即可知道这个通道可以继续使用。(代价是增加电量消耗)
如果手机中装了多个带有推送功能的APP,如何解决多个通道的问题?
android解决方案:GCM(系统提供)、开发各自的专用通道(国内方法)
Android系统提供的 GCM 只能在 Android2.2 以上才能使用,3.0 以下必须要安装 Googleplay 并登陆了 Google 账号才能支持。而国内发行的手机大多是阉割掉了 google 服务的。
因此,对于 Android 系统来说,各家 app 只能开发自己的专用长连接通道了。然而这时候他们遇到了 app 的天敌:管家和卫士们。前文说了,app 想要及时收到服务器推送的消息,关键在于自己与服务器的长连接通道不被关闭,也就是自己的后台服务可以一直在后台运行,而管家和卫士们的一键清理功能就是专治这种 “毒瘤” 的。道高一尺魔高一丈,app 在与管家和斗士们的长期斗争中,总结了一系列躲避被清理掉的方法,什么定时自启能力、什么相互唤醒、什么前台进程等等。
IOS解决方案:APNS
ios开通了一条系统级别的长连接通道,通道的一端是手机的所有APP,另一端是苹果的服务器。
APP的服务器如果有消息需要推送,先把消息发送到苹果服务器上,再利用苹果的服务器通过长连接通道发送到用户手机,最后通知具体的APP。这样,即使安装了100款APP,也只需要向一条通道里发送推送。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/137324.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...