1.APNS develop模式
2.APNS_Adhoc adhoc模式
3.SilentPush 静默推送
4.VOIP 推送以及(CallKit)

APNS有感触发:
测试环境,dev 证书, php 本地服务打印app请求.证书还是使用之前创建的证书.
1.模拟数据获取,通过app group进行跨进程通信.
2.模拟远程推送触发,app唤醒(无法唤醒app).
3.可以唤醒plugin,活跃时间为5s.
4.有时候会产生部分延迟,使用的原生的推送.
5.通过拿到apns的数据进行上报处理.



Voip无感触发:
测试环境,voip 证书, php 本地服务打印app请求.证书还是使用之前创建的证书.
1.模拟一小时触发一次,发现当触发达到最多9次会无法收到推送.
2.模拟进行数据请求,app无法请求接口,原来是CallKit不接入,app将会闪退.
3.模拟hook 闪退的方法进行runtime替换. 成功使app存活.
4.模拟推送消息到手机端,开启请求后台任务不断请求播放无声音频任务,可以使得死了的进程复活,并且在系统管理页面无法管理app的页面(看不到页面).
5.模拟周一推送,周二收到推送.(当达到被禁的临界点,24h后会重新开启,假设成立(在英文网站也是找到了有做类似调试的一个人,他的结论也是印证了这个可能)).


方案一:有感触发

plugin+app uploadData

由于plugin是app的附属插件不需要手动安装,安装app即存在:


1.app初始化的时候将数据存储到group里面(跨进程的通讯).
2.游戏触发的推送的充值数据通过apns发送到plugin,集成sdk进行数据的上报.
3.得看一下sdk是否含有用到app 的 shareInstance单例对象.如果用到还不好集成.(为了保证app在启动和后台都可以进行数据上报)
4.上报机制: app杀死的情况下无法唤醒app,只有5s的上传时间.
                    app处于后台可以定时(比如30s上传一次)

总结:具有可行性.
难度有两点集成sdk到plugin和app,两者都可以使用.不知道能不能兼容.还有一点就是的账号是要续费的,我们的企业账号也要更改描述文件.
缺点:就是推送的频繁的话,用户可能会禁止推送.



方案二:无感触发

Voip + 请求后台访问权限

1.处理数据均在app内进行,通过keychain Sharing进行跨进程的数据通信.
2.无论kill or lock screen ,都可以触发通知,只不过有时间限制.
3.原本触发的时间响应是30s.请求后台任务可以活着长时间的live.当app重新open,
   app和这个进程合并,继续进行使用.当kill事件触发,无法再次继续后台任务的执行.
   如果php后台无法响应collect数据,那么最短在24h后再次在后台触发即可.使得app响应.比如每天早上8点进行一次推送.
4.这种方式apns不需要携带数据.
5.最低触发5-7s.锁屏的情况下

总结:具有可行性
难度也有两点,集成无难度,一个是续费账号和换一个描述文件.还有就是这个24触发的机制.需要后台处理一下.当第二天无法收到上报的数据.进行管理继续推送(最多6次)

缺点:就是后台要进行推送管理,可能一次并未触发.
优点:保证app就算一天未开的情况下也能进行数据上报

问了一下友盟,腾讯云推送,极光的.他们只支持安卓的杀死唤醒(通过短信)

未锁屏的情况下:
1.远程推送后台唤醒30s,可以完成接口请求,可以从keychain读取数据.
2.远程推送plugin唤醒5s,可以定制音乐.
3.唤醒后的通知栏消息可以在接口完成请求的情况下进行自动清除.
4.对于定时一天或者某个时间段进行数据采集是可以的.
5.通知栏自动清除的时间限制是30s,消息显示的现在可以理解为30s内.当代码自动清除后可以使通知栏直接清空.
6.在得到推送时理解清空通知栏程序会迅速进入死亡无法执行接口请求.

锁屏的情况下:
Extension 响应5s 可以完成数据请求,数据需从推送信息获取.
APP如果也要集成的话,需要制作成私有公共仓库进行app和appex都能进行上报的共用SDK


Voip程序下唤醒一秒后持续不断请求后台进程播放无声音乐,可以使进程存活.并持续完成数据上报.