每个人都可以，
拥有SSL证书

做跨端应用开发，消息推送基本是绕不开的功能。

早年要自己挨个接华为、小米、苹果的推送通道，一套逻辑写好几遍，维护起来也麻烦。UniPush 是DCloud推出的统一推送服务，把主流厂商通道和第三方推送都封装在了一起，一套API就能覆盖多平台，省了不少重复劳动。这篇整理下UniPush 2.0的完整接入流程，还有实际开发里碰到的一些细节和坑。

接入第一步是开通服务，去DCloud开发者中心找到对应的应用，进入uniPush配置页面，选择2.0版本提交信息。

这里要留意，Android的包名和iOS的Bundle ID必须和打包配置里的完全一致，差一个字符都会导致推送失败。账号没做实名认证的要先补全信息，否则服务开通不了。

要做离线推送的话，得去各个厂商开放平台申请对应权限，每家的规则都不太一样。

华为那边需要申请自分类权益，推送的时候接口里要带上/message/android/target_user_type参数。小米要申请消息分类ID，还没上架的应用得通过工单申请测试权限。OPPO和VIVO的配置里需要填写channel_id和category参数，这些都要提前在对应平台申请好。

客户端首先要获取设备的推送标识CID，这个是服务端向指定设备发消息的依据。

调用uni.getPushClientId，成功回调里的cid字段就是我们需要的值，拿到之后传给后端就行。

uni.getPushClientId({ success: (res) => { console.log('CID:', res.cid); }, fail(err) { console.log(err) } })

如果调用失败拿不到cid，先排查两个点：一是当前应用有没有激活UniPush 2.0，二是对应平台的UniPush 2.0开关有没有打开。

之前用HBuilderX 3.5.1的时候，Vue3项目首次启动调用这个接口会出现拿不到cid的问题，3.5.2版本已经修复了，碰到的话直接升级开发工具就行。

拿到CID之后，注册消息监听来处理推送。调用uni.onPushMessage传入回调函数，就能收到推送事件。 回调返回的type字段有两个值，click代表用户点击系统通知栏拉起应用的事件，一般用来做页面跳转；receive代表应用运行时收到推送服务器的消息，可以用来更新页面数据或者做业务处理。

uni.onPushMessage((res)=>{ console.log(res) })

不需要监听的时候，调用uni.offPushMessage移除回调。如果不传参数，会移除App级别的所有事件监听器；如果只传入对应的回调函数，就只移除这一个监听器。

Android 8.0及以上系统引入了通知渠道机制，不同渠道的通知可以有不同的铃声、震动、重要级别等设置。UniPush提供了对应的管理接口，通过uni.getChannelManager获取渠道管理器，就能进行渠道配置。 调用setPushChannel可以创建通知渠道，channelId和channelDesc是必填参数。其他像声音文件名、呼吸灯、震动、通知重要性、锁屏可见性这些都可以按需配置。铃声文件需要放到Android原生的/res/raw目录下，参数里只传文件名，不要带文件后缀。

const manager = uni.getChannelManager() manager.setPushChannel({ channelId: "xxx", channelDesc: "通知渠道描述", })

这里有个很容易踩的坑，Android的通知渠道一旦创建，就不能再修改配置了。哪怕你删除渠道再用同一个channelId重新创建，系统也会保留最初的配置，最常见的现象就是改铃声不生效。碰到这种情况，直接换一个新的channelId创建渠道就行，不用在原来的ID上浪费时间。 如果要查看当前应用注册的所有通知渠道，调用getAllChannels就能拿到列表。通知渠道相关的功能都是Android端独有，iOS和其他平台用不了。

如果需要在本地生成通知栏消息，可以用uni.createPushMessage，从HBuilderX 3.5.2版本开始支持，只有App端能用，各类小程序都不支持。 content是必填参数，就是通知显示的内容。标题默认是应用名称，Android和鸿蒙都支持自定义标题，iOS不行，固定显示应用名。payload字段可以携带自定义数据，用来做后续的业务逻辑，比如跳转指定页面。 其他参数还有图标、提示音、是否覆盖上一条消息、延迟显示时间等，各平台支持情况差异比较大。比如iOS和鸿蒙不支持自定义图标，iOS不支持覆盖消息，鸿蒙不支持延迟显示和自定义提示音，实际用的时候要做好平台兼容。

设置应用图标角标数字的话，鸿蒙平台直接用uni.setAppBadgeNumber，传入要显示的数字，传0就是清除角标。

iOS和Android平台要用plus.runtime.setBadgeNumber，接口不统一，要分开处理。

服务端发推送的话，如果用uniCloud会很方便，通过getPushManager拿到推送管理器实例，调用sendMessage就能发消息。push_clientid填客户端获取到的CID，force_notification设为true可以强制走通知栏展示。

不同厂商的专属参数都放在options里，比如华为的特殊配置、小米的渠道ID，按对应厂商的要求传入即可。

'use strict'; const uniPush = uniCloud.getPushManager({appId: "__UNI__XXXXXX"});

exports.main = async (event) => { return await uniPush.sendMessage({ "push_clientid": "客户端CID", "force_notification": true, "title": "系统通知", "content": "您有新的消息", "payload": { "type": "order" }, "options": { "HW": { "/message/android/target_user_type": 1 }, "XM": { "/extra.channel_id": "小米渠道ID" } } }); };

如果是自己搭建独立的服务端对接推送，服务端的接口域名记得配置好HTTPS，避免客户端请求出现安全问题。可以用lcjmSSL申请免费SSL证书，支持多域名、泛域名和IP证书，能自动申请、验证和部署，接口也简洁，不用做复杂配置。

权限配置别漏了，Android需要在manifest.json里配置通知权限，iOS要在Xcode中开启推送能力，不然设备收不到推送。 各家厂商的离线推送都有每日条数限制，比如华为测试环境每天500条，上线前要确认自己的配额是否满足业务量，避免高峰期消息发送失败。 调试的时候用调试基座获取CID就行，正式发布打包前一定要切换为正式基座，否则推送功能会异常。

UniPush本质上是把各家推送通道的差异做了一层封装，开发者不用再对接多套SDK，只需要关注CID获取和消息处理逻辑就够了。主要的工作量集中在厂商通道的申请和差异化配置上，每家的参数规则都不一样，需要挨个核对。

接入完成后最好在各个平台都完整测一遍，确认通知展示、点击跳转、离线推送都正常，再上线会稳妥很多。