uni-push是DCloud推出的、全端的、云端一体的统一推送服务。
push，指服务器主动向客户端发送消息的技术。无需客户端持续轮询服务器，即可获得即时数据。
轮询有很多弊端：1)客户端应用必须实时在线；2)手机端耗电严重；3)服务器负载高且浪费资源
提醒：web浏览器的webnotification其实是一个本地通知栏功能，浏览器厂商没有提供push通道。
当客户端在线时，push通过socket协议实现。当客户端离线时，服务器找不到客户端，开发者无法自己实现推送，只能依托手机操作系统、小程序底层提供的离线消息推送，调用指定的手机厂商或小程序厂商的服务器接口来发送消息。
所以一个push系统需要3部分协作：开发者的业务服务器+专业push服务器+开发者的客户端应用。
其主要流程是：
如果开发者把上述每个平台的客户端和服务器的SDK都对接一遍，还自己处理没有push服务的中小品牌手机，那过于困难了。所以业内有专业的推送服务厂商把各种手机厂商的通道封装成一套统一的API，如个推（属于上市公司每日互动）；同时这些三方专业推送厂商还提供了高速socket通道。当应用在线时，也可以直接通过socket下发消息。否则开发者需要写很多判断代码、搭建socket服务器、处理在线时和离线时各种差异。
DCloud与个推（A股上市公司每日互动）深度合作，为uni-app的开发者提供了比传统方案便利甚多的统一推送方案uni-push2，利用云端一体的优势，同时提供基于uniCloud的push服务器和基于uni-app的push客户端，两者高效协同，极大的简化了push的使用。
注：uni-push的服务器稳定性是由阿里云serverless、腾讯云serverless、个推来保障的，都是日活过亿的上市公司，无需顾虑稳定性。
如下图所示：首先开发者的uniCloud应用服务器向uni-push服务器发送push消息，然后
总结下uni-push提供的功能：
注意：app申请创建通知栏消息、web申请弹出通知，均会由操作系统或浏览器自动弹窗询问用户是否同意。小程序下需要手机用户主动发起订阅行为，才能送达消息。
uni-push即降低了开发成本，又提高了push送达率，还支持全平台，并且免费，是当前推送的最佳解决方案。
uni-push本身并不收费，实际使用中需要依赖uniCloud云服务，而uniCloud价格很实惠：
可见价格之低，几乎可以忽略不计。
即：最高(1*0.0133+3*0.015)/10000=0.00000583元/每次（注：给你的应用的所有注册用户群发消息算一次）
有了uni-push，开发者不应该再使用其他push方案了。但我们发现很多开发者有误解，导致还在错误使用其他推送。
按照国家法律要求，所有提供云服务的公司在用户使用云服务时都需要验证手机号。
关联服务空间说明：uni-push2.0需要开发者开通uniCloud。不管您的业务服务器是否使用uniCloud，但专业推送服务器在uniCloud上。
开通完成后，后续仍可以在这里修改以上信息。
开通App的完整流程较多，但开通web和小程序的流程比较简单，即开即用。可以快速将uni-app项目运行到浏览器或小程序体验。
仅APP端支持，当应用被用户关闭，或者运行到后台时，手机厂商为了省电或释放内存，会终止App后台联网。
消息将通过不会离线的手机厂商通道，下发到手机系统推送服务模块；
此时客户端会自动创建通知栏消息，展示在系统消息中心（如图所示）但客户端监听不到消息内容；当用户点击通知栏消息后，会将APP唤醒此时APP才能监听到消息内容。
当应用在线时，不会创建“通知栏消息”，此时客户端会立即监听到消息内容。
如果你希望当应用在线时，也通过“通知栏消息”来提醒用户；可以通过以下两种方式实现：
个推的客户端类型是仅根据使用的sdk类型来判断的，分为两类：
uni.getPushClientId({success(res){console.log(res);},fail(err){console.log(err)}})注意：此时由于运行的标准基座中，不包含uni-push模块，如果运行会报错，不用着急继续往下操作
在manifest.json中配置完之后，需要重新编译项目，即：点击如图重新运行按钮
uni-push在web和小程序端就是个websocket；各家小程序平台，均要求在小程序管理后台配置小程序应用的联网服务器域名，否则无法联网。
根据下表，在小程序管理后台设置socket合法域名。下表的域名均为个推自有域名，并非DCloud所属域名。
示例代码：
APP端真机运行注意:
而uni-push2.0，开发者无需关心证书、签名、服务器端文档，使用简单。云函数通过uni-push服务端sdk，即uni-cloud-push的API即可直接执行uni-push所有操作。
uni-push的服务端sdk的体积不小，没有内置在云函数中。在需要操作uni-push的云函数里，开发者需手动配置uni-cloud-push扩展库。（uniCloud扩展库，是uniCloud自带API中不常用且包体积较大的部分，被独立为扩展库，可以由开发者自行选择是否使用该扩展库）
下面是一个开启了uni-cloud-push扩展库的云函数的package.json示例，注意不可有注释，以下文件内容中的注释仅为说明，如果拷贝此文件，切记去除注释
{"name":"test","version":"1.0.0","description":"","main":"index.js","extensions":{"uni-cloud-push":{}//配置为此云函数开启uni-cloud-push扩展库，值为空对象留作后续追加参数，暂无内容},"author":""}注意：扩展库依赖3张opendb表：opendb-tempdata,opendb-device,uni-id-device。公测版uniCloud，执行扩展库会自动创建。如果你使用的是uniCloud正式版需要自己创建这3张表。
云函数中调用uni-cloud-push扩展库的sendMessage方法，向客户端推送消息
//简单的使用示例'usestrict';constuniPush=uniCloud.getPushManager({appId:"__UNI__XXXXXX"})//注意这里需要传入你的应用appId，用于指定接收消息的客户端exports.main=async(event,context)=>{returnawaituniPush.sendMessage({"push_clientid":"xxx",//填写上一步在uni-app客户端获取到的客户端推送标识push_clientid"title":"通知栏显示的标题","content":"通知栏显示的内容","payload":{"text":"体验一下uni-push2.0"}})};在云函数文件目录右键（或按快捷键ctrl+r）->运行-本地云函数，此时你的客户端将收到推送消息（应用关闭时为通知栏消息，在线时代码监听到推送消息）
如果按步骤操作完毕，此时你运行起来的uni-app客户端就会打印出“收到推送消息：xxxx”。如遇异常，可以重新运行一遍。
上一章，演示了基于“客户端推送标识”的消息推送，仅为方便理解和体验；在业务开发中，通常是指定消息的接收人，而不是某个设备。
注意
以上内置逻辑，在uni-id-pages下，会自动判断是否启用push模块自动执行；但uni-id-pages-x下，需手动在:/uni_modules/uni-id-pages-x/init.uts导入autoReportPushClientId模块。