开发者社区 问答 正文

移动推送在应用中的调用绑定和解绑应用场景说明是在什么位置?



问题


使用场景:

  • 用户登录时绑定帐号、标签或别名,用户退出时进行解绑操作
  • 用户解绑后,后台通过账号、标签或者别名进行推送

问题:
  • 在用户退出期间,服务端通过账号、标签或别名进行推送,用户重新登录之后为什么收不到?
  • 如果推送时设置了离线推送,是不是就可以收到了?


问题原因

  • 账号、标签、别名功能是为了方便将推送系统与App的业务系统打通,方便用户通过业务系统账号进行推送。相关接口使用请参考:SDK API介绍
  • 当用户通过账号、标签、别名进行推送时,移动推送服务端会将相关账号、标签、别名转换成对应设备,然后创建推送任务,对绑定的设备进行推送
  • 当用户发出推送请求时,如果目标设备与推送时指定的账号、标签、别名不存在绑定关系,则此时服务端不会创建推送任务,也就不会推送。
  • 离线推送的使用场景是,当服务端创建推送任务后,发现目标设备离线,则会在设备重新上线后推送。所以并不适用于本场景


解决方案


如果希望当用户重新登录后即可收到相关推送消息可以参考以下方案:
  • 服务端记录用户退出登录期间的需要推送的推送信息
  • 待用户重新登录绑定账号、标签、别名后再进行推送

展开
收起
猫饭先生 2017-10-24 09:36:55 1809 分享 版权
阿里云 AI 助理回答

您的理解是正确的。在您描述的场景中,用户退出登录后与账号、标签或别名解绑,服务端在这期间通过这些标识进行的推送,由于没有绑定的设备,自然无法送达给用户。即使启用了离线推送功能,其作用是在设备离线时暂存消息,待设备上线后再推送给该设备,但它并不解决推送目标(即账号、标签、别名)与当前在线设备之间关联性的问题。

如果希望用户在重新登录后能够接收到他们错过的推送消息,确实需要采取额外的措施来保存和重发这些消息。基于您提供的解决方案思路,这里有一个细化的方案:

  1. 消息缓存机制:当用户退出登录且有推送请求时,服务端不应立即丢弃这些推送请求,而是应该将这些消息及对应的推送目标(账号、标签或别名)存储起来。这可以是一个简单的数据库记录或者更复杂的队列系统,确保消息的可靠存储。

  2. 登录状态监测与消息重发:当用户重新登录并再次绑定账号、标签或别名后,服务端应检查是否有为该用户缓存的未送达消息。可以通过监听登录事件触发这一检查过程,一旦发现有待推送的消息,立即根据用户当前的绑定信息创建新的推送任务,将之前缓存的消息发送到用户新登录的设备上。

  3. 消息时效性管理:在实现上述方案时,还需要考虑消息的时效性。对于某些即时性要求较高的消息,可能需要设置一个有效期,超过这个时间点则不再重发,以避免用户收到过期无用的信息。

  4. 用户识别与个性化处理:为了精确地匹配用户和他们的消息,确保每个用户的体验,服务端逻辑需要足够智能,能够准确识别不同的用户身份,并且在用户重新登录时快速响应,执行个性化的消息重发策略。

采用这样的方案,可以在用户重新登录后有效地补发他们在离线期间错过的推送通知,提升用户体验。同时,这也要求后端系统具备一定的消息管理和调度能力。阿里云提供了多种产品和服务,如消息队列MQ、函数计算FC等,可以帮助开发者轻松构建这类消息缓存与重发机制,提高系统的灵活性和可靠性。

有帮助
无帮助
AI 助理回答生成答案可能存在不准确,仅供参考
0 条回答
写回答
取消 提交回答