友盟消息推送注意事项
1)即使应用名称相同，Android版和iOS版仍是属于不同平台的两个应用，无法共用一个Appkey，需要分开注册。
2)APP收到通知后会展示在通知栏，开发者可以在【友盟+】后台指定用户点击通知后的操作，包括“打开应用”、“打开链接”、“打开指定页面（自身应用内的Activity）”、自定义行为（需自己实现方法，详见：高级功能-通知的展示及提醒-自定义通知打开动作）。
3)iOS 版与 Android 版在使用消息推送服务时的步骤相同，唯一不同是在创建应用产品时需要上传“开发者证书”以及“生产者证书”，并需要提供对应密码。
4)开发过程中，在Debug模式下可以使用Logcat看到对应的Device Token。
5)Umeng消息推送服务使用device_token标识接收消息的设备，alias可以理解为设备的别名。
6)提供Alias服务主要是方便开发者建立自有帐号系统到Umeng消息推送服务device_token的对应关系，当然也可以灵活使用。
7)使用alias需要sdk调用接口回传开发者指定的alias，alias_type以及设备device_token和应用appkey，服务端记录映射关系。(详见SDK集成指南 6.4)
8)开发者发送消息时指定type为customizedcast并填写目标设备的alias，alias_type，消息会发到指定设备。这其中，alias_type是必填的，可以理解为alias的分组或者渠道。对于alias_type需要注意：1. 同一个alias_type下，同一台设备多次回传alias，后一次alias会覆盖前一次alias。如果不想覆盖，请指定不同的alias_type2. 不同设备回传相同的alias和alias_type，alias和alias_type合在一起，对应所有回传的设备3. 每个app的alias_type最多不超过20个，Device Token为友盟生成的用于标识设备的id，长度为44位，不能定制和修改。同一台设备上每个应用对应的Device Token不一样。
9) 设备长连在线只和三个条件有关：1、网络环境稳定良好 2、pushservice运行3、push service连接上友盟服务器。
10) 你也可以通过 adb shell ps | grep com.umeng.message.example 这个指令查询到友盟push的进程.
11) 由于pushSDK在设计上采取了多路复用的技术方案，即设备上多个集成了友盟消息推送SDK的App会共用一条长连通道， push service会挂靠在某一个App上，此时长连service所挂靠的App称为“宿主”。可以通过推送后台的工具栏查看。
12)还有一处需要注意，如果分别下发了两条消息，却只收到了一条，先不要着急。因为同一台设备在1分钟内收到同一个应用的多条通知时，不会重复提醒，同时在通知栏里新的通知会替换掉旧的通知。
13)为防止开发者误发过多条推送，造成用户卸载，我们对发送次数和频率作出了如下限制。单播：没有次数限制。
广播：对于没有上线的App(友盟推送判断集成个数小于200台设备的APP默认为没上线)，没有限制。 对于已经上线的App，每天不超过3次，但是这个限制次数根据业务场景可以申请调大。申请调大请发送邮件至msg-support@umeng.com，格式请写APP名称，APP类别，appkey，申请调整次数及具体原因。我们收到邮件后会第一时间处理。
14)每分钟发送次数，对于单播目前没有限制。 对于任务(非单播)，每分钟不能超过5次。
15)Device_token是友盟消息推送服务对设备上App的唯一标识。与iOS平台不同的是，这个token不是对设备的标识，对设备的标识我们用的是umid(umeng id)和utdid(阿里巴巴集团统一的设备标识库)，因此我们可以把Device-token近似的理解为 “设备id + appkey”，其中设备id就是前面提到的umid/utdid。
16) 在自己项目的build.gradle里一定要配置applicationId，并且确认applicationId和manifest中的package保持一致。 17)Device_token 在什么情况下会变？有以下两种情况会导致设备的Device_token变化:1. 设备卸载过，又重新安装，token可能会变化（小概率）2. 设备没有
19)自定义消息不会显示在界面上，开发者可以通过重写处理自定义消息的函数来处理自定义消息，包括如何将自定义消息显示在界面上。
20)目前alias不推荐使用中文，可以使用数字和英文字母。 21)用户关闭推送应该是程序自己去实现的。 我们sdk提供了打开和关闭的函数，os是没有打开和关闭函数的。 ios系统统一负责消息推送管理，用户可以在设置－>通知中心 里面去设置。
23)如果程序完全启动过的话，只要您的手机启动了任何其他一款使用了我们友盟推送的app，都是可以相互触发并且受到消息的。
24)关于消息发送查询历史查询，有一列叫做“状态”，有“已送达”和“已取走”两个。 “已送达”表示是千真万确的送达设备了。“已取走”表示服务器下发到设备了，很可能由于网络原因消息丢失了。 “已送达”的情况下，消息没有收到，很可能是自身集成的错误。
25)Alias是和设备绑定的，友盟推送对设备的标识是device-token，也就是说，Alias与友盟device-token是绑定对应的。1.多个账号登陆同一台设备，具体还要细分为两种case:1、如果是同一个alias_type，那么以最后绑定的alias为准。举个例子: (alias_A, alias_type_A)先做了绑定，之后(alias_B, alias_type_A)后做了绑定，那么，如果这个时候给alias_A发消息，设备是不会收到消息的，因为在友盟推送后台device-token是和最后登陆的alias_B做绑定的。这个在实际业务场景中也成立，最后一个登录的账号才是这台设备当前真实的用户。2、如果不是同一个alias_type, 那么前后两个绑定的alias均生效。举个例子: (alias_A, alias_type_A)先做了绑定，之后是(alias_B, alias_type_B)做了绑定，那么不管是给alias_A发消息，还是给alias_B发消息，设备均能收到消息。因为alias_type变化之后，友盟推送后台确定不了这是同一个用户(eg: 同一个用户使用不同平台的账号登录)，还是不同的用户(不同的用户，使用不同的账号登录)，友盟只能简单的判定这两个不同alias_type的账号是两个不同的账号。这种场景是需要特别注意的，建议开发者在实际的集成过程中尽量避免这种使用场景。
26)同一个账号登录多台设备:这种情况处理起来就比较简单了，即一个alias和多个device-token做绑定。如果给这个alias发消息，我们会给所有和这个alias绑定的设备都去推送消息。
27)设备没有收到消息，可能存在多种原因:对于Android来说,最常见的原因就是设备长连接不在线了(长连接在线的含义是: 设备联网&后台的PushService存在&PushService与服务器端建立了长连接)，这种情况可以按照常见的步骤来排查。对于iOS来说，一般的原因都是APNs的两套开发环境搞错了，苹果严格区分开发环境(sandbox)和生产环境(prod)，在开发测试阶段，只能用开发环境测试, 只有App Store上线后，才可以用生产模式发消息，对应的API后台参数是: prod_mode.
28)”已送达“说明消息已经确实被下发。消息送达到设备后，设备返回给友盟推送服务器一个ack回执，告诉服务器端App已经收到消息，服务器才会把状态归档成”已送达”。
29)如果系统禁用了相互唤醒（MIUI等部分定制系统根本没有考虑到跨进程通信的需求就粗暴的把AIDL禁用了），则会导致App可能无法收到消息。(PUSH SDK 3.0已经解决)
30)使用消息推送之后，发现消息收到数少的原因:
31)设备device-token变化有两种最可能的情况: 一种是设备卸载过，又重新安装，token可能会变化； 另一种是设备没有SD卡，设备id变化导致的device-token变化。*