友盟推送集成的常见问题

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u013823101/article/details/53540968

友盟消息推送注意事项
SDK集成:http://dev.umeng.com/push/android/integration
常见问题:http://bbs.umeng.com/thread-5911-1-1.html
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. 设备没有SD卡,设备id变化导致的device-token变化。详细可参考: http://bbs.umeng.com/thread-11061-1-1.html
18)集成配置文件的权限说明:http://bbs.umeng.com/thread-9660-1-1.html
19)自定义消息不会显示在界面上,开发者可以通过重写处理自定义消息的函数来处理自定义消息,包括如何将自定义消息显示在界面上。
20)目前alias不推荐使用中文,可以使用数字和英文字母。
21)用户关闭推送应该是程序自己去实现的。 我们sdk提供了打开和关闭的函数,具体看这里http://dev.umeng.com/message/android/integration-guide;ios是没有打开和关闭函数的。 ios系统统一负责消息推送管理,用户可以在设置->通知中心 里面去设置。
22)错误代码定位原因: http://bbs.umeng.com/thread-12350-1-1.html
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)使用消息推送之后,发现消息收到数少的原因:
http://bbs.umeng.com/forum.php?mod=viewthread&tid=15857&page=1&extra=#pid33016
31)设备device-token变化有两种最可能的情况: 一种是设备卸载过,又重新安装,token可能会变化; 另一种是设备没有SD卡,设备id变化导致的device-token变化。*

没有更多推荐了,返回首页