理解百度云推送的几个概念

之前我们android项目的IM功能和推送功能使用的是国内的环信，但是项目需要部署到欧洲，欧洲地区对个人隐私数据的保护非常严格，不允许我们将聊天等信息传到环信在国内的服务器上，所以不得不采用别的推送方案。后面经过研究，决定使用Amazon SNS移动消息推送服务。如果是中国，那我们就使用百度云推送解决方法；如果是国外环境，使用的是google GCM推送。

百度云推送文档写的很好，上手很容易，具体的API使用方式这里不做解释，主要介绍下几个概念。

首先是应用包名、app id、api key、secret key。

应用包名：对应我们android应用AndroidManifest.xml文件中的package。这个只是约定，不是强制的。应用包名可以随便更改，对推送功能是没有影响的。也就是说：如果我们android实际应用的包名，跟应用包名不一致，android手机一样可以接受到推送的消息。

app id：应用的标识，创建应用的时候由百度自动生成。在android端，我们可以通过PushMessageReceiver.onBind获得。不过app id一般没有什么实际用处。

api key：如果手机端想要接受某个应用(web端通过管理控制台创建的)的推送，那么使用的api key必需和应用一致。如果同一台手机上多个应用使用同一个apikey，只有最后一个初始化的应用能收到推送，所以要为每一个app使用一个唯一的apikey。

secret key：秘钥，java等服务端向百度推送服务器发送消息的时候，必需要设置secret key。这个值对于手机端来手，没有啥意义。

最后我们回到android手机端的userid、channelId、requestId的区别，这3个字段的获取跟appid是一样的。这几个字段都是百度自己按照一定算法生成的，不允许我们修改。

channelId：具有设备唯一性，不同的设备(ios/android)不同。

requestId：主要是用来定位bug的，每次与推送服务器间的请求交互，都会自动生成一个requestid。我们只需要在异常处理中，打印出requestid，如果出现什么解决不了的问题，把requestid和errorcode反馈给百度云推送就好了。他们会帮助我们定位问题。也就是说requestid就是为了方便，百度云推送定位问题，对我们使用者来说，没有什么太大意义。

userid：这个字段只有使用百度账户才有用，对于第三方账户来说没有用。设计这个字段的初衷就是为了让用户跨设备。比如同一个用户，既可以在手机A也可以在手机B上都登录，那么我们希望不管用户使用A手机还是B手机，都能够收到消息。因为手机A和B的channelID是不同的，如果使用channelid发送消息，那么必须要考虑用户在哪儿个手机上。经过我的测试，在没有使用百度账号的情况下，userid的值跟channelid和api key都有关系：不同的手机，userid不一样；同一个手机不同的api key，userid也不一样。所以这个字段没有什么用处，为了让用户跨设备，我们必须要自己建立这个逻辑关系。