最近App工作接近尾声，还有几个接口没有完成，其中之一就是需要在某些事件发生的时候通知App的后台，继而由App后台通知App，比如“订单即将被关闭，请尽快付款”、“优惠券即将到期”这样的消息。因为这些消息最终是要在用户的App上出现的，一般的做法是以Push notification的形式出现，主流平台android和iOS都是在屏幕最上方出现一些提示，点击后可以进入App的某个地方。

既然这样我们就直接集成第三方平台发送相应的消息好了，不过App做得实在很遗憾，用户点击消息后总会进入到App的消息中心，再点击某条消息才能看到具体内容，这样做可能是比较快，但体验不太好，至少和现有的主流App做法都不太一样，像上个时代的做法。

以上是背景，基于此我们希望能够把App作为推送会员消息的渠道，因为短信渠道现在变得越来越不可用，仅限于发送验证码等transactional消息，其实以上说的消息都是transactional消息，区别于marketing消息，这些消息一般是由用户自主激活的或满足一定条件触发，最终是区别于用户的，一般不是群发性的，例如营销类信息就属于marketing。将用户的App作为消息推送渠道的前提是能够较准确地获取这个用户的App渠道是否可用，如果不可用还是得选择短信等。

对于不同手机平台使用的技术差不多，但机制不太一样，不过这是有原因的。例如iOS上的推送机制：设备连接APNs，商户后端推送消息给APNs，再由APNs推送到最终用户的设备上；但android在国内不大一样，由于某些特殊的原因，android的GCM服务（类似APNs）无法使用，继而诞生了很多第三方推送服务商，这些服务商一方面做android的推送，另一方面也接管了到APNs的这块，其实接管APNs这块也不错，因为向APNs推送也并不容易实现——socket长连接，二进制消息等都增加了用户的开发成本，对于一般规模的App开发，使用第三方消息服务商几乎是没得选。

iOS的推送：在成功推送到APNs时服务商得不到任何响应，也不保证给你送达，用户不在线可以给你保留一段时间等用户上线了再推送，但长时间不在线的话推送消息也会被删除。除非消息格式有错等语法性的错误会得到响应，再就是如果APNs发现用户设备上没有这个App（被用户删除或被用户禁用了推送）会将该设备的ID记录下来，服务商可以通过APNs提供的反馈接口得到这些信息，也就是说只有再次给App推送消息后才有可能知道这条渠道还是不是可用。

android的推送：目前第三方服务商的做法是做出SDK，让开发App的人集成到App中，这个App安装到系统中后会出现一个Push Service在运行，当然不知道他们哪里来的智慧，如果多个App都用了某一家提供商，并不会启动多个Push Service，一般是一两个，这一两个服务所有App，从而实现了他们所描绘的多App共享长连接很省电什么的。某个设备后台的Push Service会自动和服务商的后端连接，等有消息过来时这些Service会知道该送给哪个App，到了具体的App再由用户的代码处理。由于机制的作用，android的消息服务商是可以实时知道某条消息能不能推送到设备上的，但这毕竟是一个不太常用的功能，所以服务商们一般不会公开这种API，我们用的这家在邮件中才告诉我们是有类似的API，但是VIP级别的，详情需要联系商务部门了解。