最近弄了下推送,在测试时遇到了些问题,在此整理汇总了些推送测试相关的方案,并添加了一些补充信息。下方链接是相关文章,感谢各位作者的分享。
周村ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联公司的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:028-86922220(备注:SSL证书合作)期待与您的合作!
debug包和build切换为release直接在手机上跑生成的device token都是开发token。release打包后注册生成的token是生产的。
向证书制作者要推送证书的 p12文件。 双击输入密码。在钥匙串中找到如下。
证书有下方密钥,没有的话证书不可用。
将p12上传的三方平台并填写密码即可。测试推送在这些推送平台填写 设备token等信息即可。
给中台p12文件和密码,协商好消息格式、提供对应环境的token,由中台触发即可。
注意证书分为三种。测试(sanbox)、生产、 测试和生产合并。
如果发送成功,核对 token、证书、中台链接苹果服务器息的地址。是否为统一环境。(苹果的推送服务器也是区分测试和生产的,域名不同,下方脚本中可以看到)
在Xcode11.4之后,模拟器也支持推送测试
具体格式根据你们的产品要求,接入极光或者个推的可以在控制台发一条推送打印出具体格式内容查看,将文件保存后缀为apns,待会要用到
a、查看已启动模拟器
会看到类似下面信息,如果没有请先启动模拟器
b、运行项目在模拟器上后执行相应命令simctl push device [bundle identifier] (json file | -)
示例如下
将第一步创建的json文件内容稍加修改,具体就是添加了"Simulator Target Bundle": "com.app.test"你项目的包名
然后直接拖动文件到模拟器上,出现绿色➕后松手,这样也可以进行推送测试
参考苹果官方文档
Sending Push Notifications Using Command-Line Tools
u;/u
1、在终端新建 shell 文件,这里命名为 push-remote-notification
2、编辑 shell 脚本,这里需要 der 和 pem 证书,如果已经有了 p12 证书,可以通过 openssl 进行转换
运行 shell 脚本
真实脚本事例:
a、p12转der需要先转为pem格式,再从pem转到der格式
openssl pkcs12 -in disPush.p12 -out disPush.pem -nodes
b、pem转der
openssl x509 -outform der -in certificate.pem -out certificate.der
Smart push
git地址:
如果报错
SSL端点域名不能被设置 -25300
Keychain中不能找到证书 -25300
说明钥匙串中没有密钥,要新的p12文件并双击
不推荐,所以不例举,网站风险无法判断。
u;/u 证书转换
u;/u 证书转换
u;/u 证书转换
u;/u
u;/u
u;/u 脚本
u;/u
u;/u 脚本
u;/u 模拟器
导语:
由于移动设备内存、CPU、电量的局限性,iOS 不允许 APP 的进程常驻后台(事实上可以申请后台运行一段时间,最长约 10 分钟),这样当用户主动杀掉 APP,或者 APP 进入后台超过约定时长时,就意味着该 APP 进程的结束。这在很大程度上保障了前台 APP 的流畅性,也延长了手机的使用时长,获得了较好的用户体验。但是这也意味着,服务器无法主动和用户交互(如推送实时消息等)。为了解决这个限制,苹果推出了 APNs,允许设备和服务器分别与苹果的推送通知服务器保持长连接状态。
iOS 的通知分为本地通知和远程通知。本地通知是由本地应用触发的,一般是基于时间的一种通知形式,如闹钟、待办事件等的提醒。远程通知是由开发商通过自己的服务器推送的一种通知形式,而 APNs 就是远程通知功能的核心。
关于远程推送,记住以下两点就够了:
这里就很清楚了,其实 APNs 的本质就是 服务器和客户端之间的中介 。当服务器需要给客户端推送消息时,先将消息发送给苹果服务器,再由苹果服务器找到对应设备推送下去。
那为什么还要走中介,不直接发送呢?因为这样做一个设备(即所有 APP )只需要和苹果的服务器建立一条长连接,而不需要每个 APP 都和服务器建立一条长连接。
可能有些人还是不太明白 APNs 的意义,觉得也只是将多个长连接变成了统一的一个长连接而已,有必要那么做吗?
很有必要!
我们来看下 Android 的推送现状就明白了。
Android 事实上也有类似于 APNs 的一套用于推送的服务,简称 GCM,即 Google Cloud Messaging。但由于 GCM 需要谷歌服务器的支持,在国内由于「墙」的原因基本不能使用。这下就热闹了,国内出现了一大堆第三方推送服务商,如华为推送、小米推送、极光推送等。APP 通过集成这些推送服务来实现推送功能,而这些推送服务为了保持自己的长连接不被杀死,采用了各种保活、唤醒手段,这也是 Android 手机使用不流畅的真凶。之前也有看到「 工信部要求国内安卓统一消息推送标准 」的新闻,工信部都这么重视,可见统一推送的意义非凡。
想要了解具体区别,可以参考这篇文章 「 国内 90%以上的 iOS 开发者,对 APNs 的认识都是错的 」。
不言而喻,当然是尽早升级 HTTP/2 协议了。
参考:
(完)
1.APNS的推送机制
首先我们看一下苹果官方给出的对ios推送机制的解释。如下图
Provider就是我们自己程序的后台服务器,APNS是Apple Push Notification Service的缩写,也就是苹果的推送服务器。
上图可以分为三个阶段:
APNS推送通知的详细工作流程
下面这张图是说明APNS推送通知的详细工作流程:
根据图片我们可以概括一下:
1. 什么是远程消息推送?
3. 实现消息推送的步骤
总结下大致流程
1.设备打开某个App后,会生成唯一的 一个token ,并把这个token上传给我们自己的服务器,我们的服务器有了token,就可以向我们的app推送通知了,这个是前提。但是这个通知并不能直接推送给我们的设备,而是要推送给苹果的服务器。
2.我们的服务器会将token和推送的内容,一起推送给苹果的服务器。
3.苹果服务器会根据token定位到设备,将push推送给设备。
4.设备拿到这个push,就会知道是哪个app。然后就可以将这个通知推送到具体的app。
推送的实现方式:
想要收到推送消息 ,就必须要有后台服务器(下面的1、2)往 苹果的APNs的服务器发请求。
1、公司自己开发后台服务器程序
2、 采用第三方的后台服务程序,比如:百度云推送、极光推送、友盟推送
ios消息推送原理主要分为以下几步:
1、由 App 向 iOS 设备发送一个注册通知,用户需要同意系统发送推送;
2、iOS 向 APNs 远程推送服务器发送 App 的 Bundle Id 和设备的 UDID;
3、APNs 根据设备的 UDID 和 App 的 Bundle Id 生成 deviceToken 再发回给 App;
4、App 再将 deviceToken 发送给远程推送服务器(自己的服务器), 由服务器保存在数据库中。
5、当自己的服务器想发送推送时,在远程推送服务器中输入要发送的消息并选择发给哪些用户的deviceToken,由远程推送服务器发送给 APNs。
6、APNs 根据 deviceToken 发送给对应的用户。
想要了解更多ios消息推送原理可以到深圳极光了解一下。深圳市和讯华谷信息技术有限公司于2011年成立,是中国领先的开发者服务提供商,专注于为开发者提供稳定高效的消息推送、一键认证以及流量变现等服务,助力开发者的运营、增长与变现。
很多应用都会实现推送功能,我们可以集成第三方框架实现推送功能,
比如:JPush推送:
个推:
下面来说说收到推送消息的逻辑处理
一、收到推送消息有三种情况:
1、应用未启动(默认显示在通知栏,或者锁屏时显示在锁屏页面)
2、应用在后台挂起(默认显示在通知栏,或者锁屏时显示在锁屏页面)
3、应用在前台(默认不显示)
二、点击推送消息有两种情况:1、应用未启动 - 启动这个时候如论是点击推送消息打开应用还是点击icon打开应用都会调用以下方法(具体的可以根据 userInfo 进行判断):(只有重新打开APP和后台杀死后在打开APP才会走下面的方法)
2、应用在后台 - 应用在前台应用在后台挂起时点击推送消息和应用在前台时收到推送消息,都会调用以下方法:
ios 7 以上会调用下面这个方法
ios 10 会调用 下面的方法
应用在后台挂起时默认是不调用该方法的,如果你需要接收到推送消息还没点击推送就调用该方法,可以让服务器发给APNS时在aps 字典中加入:
aps = {
content-available = 1;
}
首先根据APP的状态进行判断 这里当APP在前台显示的时候根据需求我们没有消息进行处理
第一步:发送通知
第二步:添加观察者
第三步:进行页面的跳转,这地方有一个重点是如何获取的当前页面的然后才能够实现跳转
在此给View写了一个分类方法
第四步:实现跳转到目的controller
售后响应及时
7×24小时客服热线数据备份
更安全、更高效、更稳定价格公道精准
项目经理精准报价不弄虚作假合作无风险
重合同讲信誉,无效全额退款