友盟推送

因为开发文档上面都很详细，或者请教下技术客服，所以那些常规的就不写上面，主要写一些遇到的坑。 1.不管是友盟Push还是分享 有两种集成jar库和远程compile依赖： api 'com.umeng.umsdk:common:2.1.0' //友盟分享 api 'com.umeng.umsdk:share-core:6.9.4' api 'com.umeng.umsdk:share-board:6.9.4' api 'com.umeng.umsdk:share-qq:6.9.4' api 'com.umeng.umsdk:share-wx:6.9.4' api 'com.umeng.umsdk:share-sina:6.9.4' api 'com.umeng.umsdk:share-alipay:6.9.4' //UM PushSDK必须依赖utdid库，所以需要加入对应依赖 api 'com.umeng.umsdk:utdid:1.1.5.3' api 'com.umeng.umsdk:push:6.0.1' 注意了：2020.1.10我集成的时候，问下客服才知道，此时的远程依赖不支持android10,解决办法就是使用本地jar依赖 这一点很重要，千万别集成半天，又从新弄。 2.在集成分享的时候，在集成QQ的时候，如果使用jar则按文档要求配置就行

一、功能描述 根据业务需求，对IOS APP定时推送消息，点击通知栏的推送内容，跳转到APP内指定界面。 二、准备工作 1. 参照友盟消息推送官方文档，获取 appkey 和 appMasterSecret： 官方文档链接： https://developer.umeng.com/docs/66632/detail/68343 我是在阅读此官方文档的基础上进行集成的，现针对文档上一些必要的干货和我踩过的坑和大家分享一下： 1). 必须获取 Appkey 和 App Master Secret，IOS和java后台可以用一套，我们是项目经理帮着申请的。 2). 关于“IP白名单”：不是必须设置，我在集成的时候没有管，都是默认状态。 3). Device Token：IOS小伙伴在用户登录的时候根据设备获取的，并发送给友盟，使用单播或者列播的时候才需要此字段，但这两种模式有一个bug，比如同一个设备，用两个不同的账号登录过app，两个账号对应的推送消息该设备都能接收到，不符合常理。所以、我开始和小伙伴用的这种方式，发现这个bug后果断放弃了。 4). Alias：根据别名的方式推送消息，每一个设备上接到的推送就是最后一个登录的账号应该收到的消息。我采用的是这一种。setAlias(alias, alias_type)，也是IOS小伙伴在登录的时候注册到友盟的

最近接友盟推送，文档超简单，本来就几分钟能完成的事情，结果断断续续搞了好几天，期间踩的坑，现在回想起来真的好可笑，完全可以避免的。不过在此也对友盟的客服以及技术点个赞，真的很耐心，尽管提交工单，他们提的意见也并不是太管用。 坑一：请勿在调用register方法时做进程判断处理（主进程和channel进程均需要调用register方法才能保证长连接的正确建立）。若未按文档要求初始化，则会导致App运行时，弹出toast提示。 友盟打开调试log文档 由于项目中某些第三方也会新开进程，所以第三方初始化的时候，都判断了进程。友盟推送不建议判断进程，打开调试就可以看到这个提示。 坑二：请确保Application Module的build.gradle文件中的applicationId与资源包名package一致（若不一致，请参考高级功能—自定义资源包名）。 这个原因就是导致我接收不到推送消息的原因。让其他同事运行接入了demo，然后他没过滤关键词，看到推送的时候其他是有log打印出来的。于是这提醒了我，我就去看了一下mainfest.xml中package确实是applicationId不一致。改了之后，终于可以接收到推送消息。 这个问题，其实完全可以避免的，友盟推送文档已经提示得挺明显的了。最近附上官方文档以及参考博客。 友盟推送官方文档 友盟推送 收不到通知栏消息LogCat有消息