推送之个推推送

50 阅读 0 评论 33 点赞

我是靠谱客的博主朴实冷风，最近开发中收集的这篇文章主要介绍推送之个推推送，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

做完推送这个需求已经很长时间了，一直以来也没时间来写写笔记及新得，做完这个需求收货还是颇多的

集成类似于个推这种第三方框架首先要对其官方的sdk熟悉一番，个推的官方文档写的着实详细呢，每个名词都有详细的解释，还有相关的示例代码，所以如果你也碰到了个推，请不要只是关注于集成文档，个推官网那些东西着实很受用。

在拿到需求初期，只是简单的被告知要用个推的sdk，于是乎，在做推送初期一直伏在个推官网上，首先来说说伏在个推官网时那些收获：

1，从苹果官方网站下载含有APNS的测试证书，双击安装到本地电脑上（详细步骤略了），并将此证书以p12的格式上传到其官网相应位置。

2，先从官网下载了官方版本的个推sdk，添加各种依赖库，在官网注册了个推的个人账号。

3，在工程的delegate.m文件中依据集成文档，该写的写好。

4，以上工作完成后，首先来验证下我的证书，在官网如下可以进行尝试性推送

或者可以通过一个叫做pushmebaby的第三方小软件测试。

5，1.在此开个小差，介绍下pushmebaby，这个软件是一个xcode工程，将你想测试的证书拉到工程中，注意pushmebaby的bundle中的证书名称要与pushmebaby代码中的证书名称一致。如果初次运行时，有个地方会报错，哪错把哪注释掉就行了。软件运气起来如下：

2.运行已经集成个推官网sdk的工程，如果sdk集成一切ok的话，会在控制台打印出Device Token，将此deviceToken粘贴到pushmebaby填写Device Token处（注意两点：一是这里填写的devicetoken是最原生的不要去掉中间的空格；二是运行deviceToken的电脑必须联网，因为APNS的推送的原理相信你懂得），然后点击下边的额Push按钮，将app退到后台或杀死，你会收到一条推送通知栏消息，内容即为pushmebaby的Payload中显示的数据。

pushmebaby推送消息成功，说明客户端从集成到证书一切是ok的，如果后台推的通知栏消息一直没有踪影的话，只能是他们后台的问题了。

当我把个推官网的sdk玩的差不多已经很溜的时候，个推工作人员有弄过来一个针对于俺们这个需求的sdk，ok，所有步骤再来一遍，一切水到渠成。

苹果的推送机制，说白了无非就是通知栏显示消息，但其弊端就是只是在app处于后台或杀死状态才能收到消息，app处于前台时无法收到；即使在后台收到APNS通知栏消息也无法对其存储操作。要想将苹果的APNS发挥到极致，ok，类似于个推的公司出现了，这样我们的app处于后台或杀死后，不仅能接受通知栏消息，app在前天运行时也可以接搜到消息，并且无论在哪种情况下，都可以对这些消息进行存储等等操作。

现在来详细说下个推的sdk：

一、

+ (GexinSdk *)createSdkWithAppId:(NSString *)appid appKey:(NSString *)appKey appSecret:(NSString *)appSecret appVersion:(NSString *)aAppVersiondelegate:(id<GexinSdkDelegate>)delegate error:(NSError **)error;

注册个推，这个不必多说。在didfinishlaunching与applicationDidBecomeActive都要调用此方法。

二、

- (void)GexinSdkDidRegisterClient:(NSString *)clientId；注册cid，这个方法个推的实例代码依葫芦画瓢即可，对于客户端意义不大，对个推后台意义重大

三、

- (void)GexinSdkDidReceivePayload:(NSString *)payloadId fromApplication:(NSString *)appId 这个就是个推通道接收消息的方法。

1，当app在前台运行时，接到消息会走此方法；2，当app在后台运行或者当app被杀死时，个推接到消息时，个推会将消息暂存在其服务器端，当app再次进入前台时，个推会将此保存在其服务器端的消息下发，客户端会通过此方法接收消息；消息的存储等可以在此方法内处理

四、别名绑定

- (void)bindAlias:(NSString *)alias;

- (void)unbindAlias:(NSString *)alias;

这两个方法放在一起说，分别是别名绑定和解除别名绑定，如果绑定别名后，个推后台在推送消息时可以安别名推送，这样就可以实现个推在推消息时，不仅能收到一般消息还可以收到只关于其账号的个人消息了，用户退出账号或用其他账号登录时就需要解除别名绑定。

个人认为最重要的就是以上几个个推的sdk方法了。

原生客户端的几个方法：

一、

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult result))completionHandler {}

用户在点击通知栏时才会走此方法，在这里可以对app的角标进行设置。例如进app后将角标全部归零等。在app角标归零设置时，直接进行设置为0不可用（

[UIApplication sharedApplication].applicationIconBadgeNumber = 0;）必须先将其赋值之后再将其置为0才好使，by the way 应用图标右上角的数字角标的控制是需要app哦、后台一起配合才能完成的。

二、

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {} 当app收到通知栏消息，通过app图标进入会走此方法，如果要处理应用角标时也需要在此做如上相同的处理。

曾经跳过得坑：

1，关于sm4解密：

自家app推送过来的消息是经过sm4加密的，所以在接收到消息展示时需要进行sm4解密。在推送项目初期及中期，并未做sm4加密，未加密前，everything is ok，通知栏点击正常无论app在后台在前台还是被杀死，接收消息都很正常，弹出该条信息所对应的详情页。加密之后每点击通知栏都会崩溃，挣扎了将近一天，发现是因为sm4秘钥的原因，在用户点击通知栏消息时，后台的sm4秘钥还未送到客户端，而点击通知栏就要展示详情，次详情的报文需要sm4解密，所以一顿乱奔啊，最终将此秘钥做了个存储，并每次都要进行比较，不一样则替掉，就这样一个super bug overcomed。

2，关于秘钥：

因为秘钥不是一成不变的，所以消息在存储时，每条消息都要存储一条与之对应的秘钥，每次从数据库里读取这条消息时都要用这条消息存储时对应的秘钥进行解密，如果秘钥不匹配，会崩溃的。

3，还是关于秘钥：

当接到个推通道的消息时，需要sm4解密时，一定要判断本地实时要退换和对比的sm4秘钥是否存在，如此时还未获取到sm4串，请return

4，关于详情页的展示：

当用户点击通知栏时，需要弹出对应内容的详情页。

开始是这么设计的，接到个推推送消息先进行存储数据库操作，然后才展示，这样做经常出现的问题是：应用经常停留在app首页，而未进入详情页面，但偶尔跳的却很顺畅，思来想去，转换了设计思路，先用获取到的数据进行展示，然后再将数据进行存储。ok 问题解决。

5，关于通知栏消息与个推通道消息的匹配：

当客户端接到n条通知栏消息时，客户只点击了其中一条，那我们如何知道客户点击的是哪条并将对应的详情页报文呈上展示给客户呢？我是这样设计的：让个推后台在推送通知栏消息时，让其在报文中添加了一个唯一的消息标识。当然，通过个推通道下发的消息中也会有一个唯一的消息标识。当用户点击了某条通知栏消息时，就将通知栏的消息标识与个推消息报文进行匹配，如此便可。

现在任然存在的问题：

当用户下载了本应用，登录后（绑定别名后），然后直接卸载应用，之后再重新下载此应用后，客户此次下载（还未进行登录以及绑定别名等操作时），按理说此时客户端收到上一个账户的通知栏消息是不合理的。

思路一：个人认为这个应该由app后台配合操作，即我需要把上一个客户的别名以及此设备的唯一标识发给后台，再我下一次重新下载时，便给后台发这两个参数，其中一个便是设备号（此操作只进行一次），如果后台之前存储的设备号与客户端发出的一致，app后台便要给个推后台发消息，让个推解绑此设备之前对应的别名账户，即停止推送。

思路二：手机内部有块存储区域即我们通常所称的钥匙串，在应用存在于手机上时，我们可以往此处存储用户别名，当app被卸载时，这些数据依旧存在，当下次再重新打包时，便从钥匙串中读取此别名，进行解绑。

思路二的方法，简单设计范围低，可是不是每次都好使，表示很郁闷，思路一，设计面太广，实施难度很大，暂未执行。

暂时总结于此，如有改变会继续更新，若有不足之处或已经解决以上问题者请留言，吾将不胜感激。