在正常的项目开发中，使用第三方友盟、极光等推送的场景居多，这些三方平台对接的其实还是苹果自身的推送服务，在这些服务的基础上做了一些特殊的优化，并且整合了安卓平台。
如果是国外应用，或者客户能使用Google play 服务，推荐使用firebase 集成，这个平台不仅支持安卓和iOS，flutter端也有官方的plugin，不用自己去写桥接方法了。
下面从几个方面介绍推送服务搭建过程中的一些坑点。
1、推送证书
推送证书iOS分为两类，一种是 P12 证书、一种 P8 证书。
P12 证书是与环境、应用深度绑定的证书，需要与应用的bundleId配合使用?？梢杂辛教?，一套沙盒环境（测试环境），一套正式环境，在后端对应的服务地址是不一样。证书需要每年更新一次，会有过期时间。
P8 证书是苹果最近这几年优化后的证书，每个账户可以申请一个，申请后账号下所用应用都可以使用，不需要为新增的应用额外添加推送证书，并且长期有效，不需要每年更新，这种方式确实对开发及管理者都是很友好的。
推荐使用P8，这种后期维护的成本基本没有。
2、DeviceToken
1·token绑定
这边有个小坑，DeviceToken原生获取的时候只有用户允许了通知权限才会触发DeviceToken获取的代理方法，所以刚进入应用的时候可能拿不到DeviceToken，但是我们的一般接口设计的时候可能将DeviceToken与登录接口关联起来，那这边就会有个小bug,万一用户第一次安装App并且打开App的时候没有允许通知，然后登陆了App后又想起来要允许通知，又跑去设置——通知里去把通知权限打开，那么这里就会错过一个用户绑定DeviceToken的机会，所以一般需要一个单独接口来更新token，当然可以将登录接口那边的token绑定逻辑去掉，不去其实问题也不大，反正绑定肯定是需要用户登录完成后才能进行的。
这里你可能会问为啥第三方的推送没这个问题，这里以最常用的极光推送来举例，极光提供一个获取RegisterID的方法，但这个不是DeviceToken，DeviceToken是需要调用苹果自有代理获取的，这两个不是一个东西，极光貌似还有个tagID,那个没有用过，好像是标签ID，是用来给用户分组，便于给特定标签的用户推送的。在使用极光推送的时候，自有后台对接的主要是RegisterID，而App将DeviceToken利用极光的App SDK 丢给极光，在极光推送管理平台上也是用RegisterID模拟推送，所以给我们的假象就是极光用RegisterID在推送。笔者这边大胆猜测一下，其实极光RegisterID可是极光生成的设备与应用的唯一码，一旦获取到DeviceToken，再将RegisterID和DeviceToke绑定起来，就可以完美躲避DeviceToke获取的时机，这只是我的假设。
所以，DeviceToken的绑定只放在登录接口是不完美的。
如何是允许多设备登录，那维护的成本貌似有点高，还好做即时通讯基本都是单点登录。
2·token获取
DeviceToken貌似返回有两种格式，具体的好像要看系统版本，这个网上能百度到，这种应该貌似是13以上的获取方式
#include <arpa/inet.h>
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken
{
if (![deviceToken isKindOfClass:[NSData class]]) return;
const unsigned *tokenBytes = (const unsigned *)[deviceToken bytes];
NSString *hexToken = [NSString stringWithFormat:@"%08x%08x%08x%08x%08x%08x%08x%08x",
ntohl(tokenBytes[0]), ntohl(tokenBytes[1]), ntohl(tokenBytes[2]),
ntohl(tokenBytes[3]), ntohl(tokenBytes[4]), ntohl(tokenBytes[5]),
ntohl(tokenBytes[6]), ntohl(tokenBytes[7])];
NSLog(@"deviceToken:%@",hexToken);
}
还有一种是比较常用的
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
NSString *token = [[deviceToken description] stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"<>"]];
NSLog(@"deviceToken=%@", deviceToken);
}
3·token解绑
清token的逻辑一般放在退出登录接口。
若是App 是https业务接口，一般App都有一些异常直接跳转登录页的情况，那这个时候用户可能会登录一个不是之前登录的账号，那这样等于一个token绑了两个用户，发推送就会有些异常情况。
如果要彻底点，直接绑定的时候看有没有其他用户绑这个token，如果其他用户绑的要把其他绑定的解绑了再和当前用户进行绑定。
3、推送发送时机
正常https貌似没什么需要注意的，有需要就可以发。
如果是websocket的话可能需要注意一点，不知道微信QQ这类如何设计的，反正我们这边设计是将调用推送接口的机会降到最低了。
1、心跳包收不到，相当于用户离线，这时候有消息需要发推送
2、增加App进入后台和回到前台状态的信令或接口高数后端服务，只在进入后台收到消息的情况下发送推送
4、角标
iOS这边一直是角标和推送是一套内容体系，安卓的貌似是两回事，每次和安卓沟通的时候安卓都说不是一个需求，实在不太懂安卓。
角标这个其实极光做的很不错的，它内部应该是一套角标逻辑体系的，居然能耦合+1的这种设置法，在iOS原生推送里，badge就只能是integer数值，这种+1的方式大大减轻了开发的维护成本。
但现在要抛开三方，自己实现的话，恐怕后台就必须维护这个角标数值了。
大体逻辑是这样：
1、服务端将角标数与用户关联，发送推送的时候需要将角标数+1，设置到推送内容里，并且更新到表内，这样下次推送和这个逻辑一样
2、服务端需要给前端提供一个可以更新角标数的接口，让App更新角标数。
这样就能保证App业务上的未读数量和下次推送角标数的准确性。
你可能能会问即时通信那边怎么做的，即时通信应用是有消息缓存的，前后台逻辑和上面的大体一致，只是App端多了一个汇总所有未读消息数的逻辑，在App退至后台可以将未读数告诉后台。
5、推送内容
在即时通信应用里，信令是很重要的东西，所以推送的扩展内容会把信令带进去，这样，用户点击推送的时候就知道该处理什么样的逻辑了。
比如音视频通话的推送，虽然用户刚登陆账号，可以从离线消息里面拿到音视频的消息，但是离线消息只是为了会话列表展示数据所用，真正需要进行的通话还是要从推送里去获取，可能来了四五个通话，而用户真正想处理的是第一个通话，而不是最后发起的那个。
通过扩展内容，可以拿到建立通话的基本信息。
所以，一切业务需要的不需要展示的信息都可以放到拓展字段里。
结语
上面是针对项目的一些总结，如果写的不对的或疑问的地方欢迎大家批评指正，或者有需要补充的内容也欢迎大家私信我。
