最佳实践

客户端注册

客户端在用户登录到应用服务器之后，绑定用户ID，应用服务器给此用户推送消息时使用用户ID推送，服务端开发者无需关注接收用户的pushToken。(建议服务端存储pushToken，某些业务场景需要对指定设备推送)

构建消息

在服务端构建消息对象中必要属性只有payload，在最佳实践中payload的值是让客户端直接可显示的内容，是让人类直接能读懂的语言字符串，不要把它设置为JSON字符串虽然不会报错（例如，发送图片消息，这里不要赋值为图片的URL，可以赋值为“[图片]”，图片相关信息可以放到属性extra），如果构建消息对象只赋值这一个属性也是能够发送成功的，但这不是最佳的。实际应用场景中发送消息会存在一个发送者，可能是系统发送的，也可能是人发送，无论是什么都可以用fromId去指代。消息应该存在一个消息类型type(不赋值默认1)。当然msgId作为消息唯一标示也是必须的，如果开发者不赋值，UPush会自动生成一个对toId(接收者)唯一的消息ID。

消息推送

服务端使用用户ID推送，绑定用户ID的各个平台都将收到消息，使用用户ID订阅群组，给群组推送消息，绑定群成员用户ID的各个平台也将收到消息，fromId(发送者)发送消息时，它的其他平台也将同步他发送的消息。

相关设置

推送消息相关设置，设置通知类型，别名和头像，这些应该在推送消息前被设置好，UPush根据消息中fromId和目标用户ID取得相关设置并装载到消息中，而服务端开发者只需关注消息本身的构建即可。客户端开发人员接收到消息直接渲染到UI无需查找选渲染属性。例如：

1. 用户注册时填写昵称，头像，请求发送到应用服务器，注册成功后，调用setPortraitForUser，之后推送消息fromId是此用户时，UPush会把昵称和头像作为消息画像装载到消息中推送给目标用户的客户端。
2. 用户A把用户B聊天设置为NO_MESSAGE，请求发送到应用服务器，在应用服务器处理完成后，调用setNotifyTypeForFromId，之后用户A给用B发送消息，服务端开发者构建好消息即可，UPush会自动把通知类型装载到消息中。

请开发者者灵活使用这些设置API，去体验自动装载带来的便捷。

通知栏消息

按照以上，当接收消息的是手机端时，UPush会自动把消息装载成手机通知栏消息，无论是Android的哪个厂商或者是IOS，服务端开发者只需专注于消息本身，专注于业务实现，把消息推送交给UPush。