1. 客户端断网，导致客户端和个推服务器之间长连接断掉，需要网络恢复后并且建立长连接时才能收到个推的透传，建立连接最快要2秒的时间。在网络时断时续的情况下要比http请求的响应慢的多。若出现网络通而不达的情况，90秒以后才能确定这种网络异常，而http请求一般在设置的超时的时间内就返回了超时的结果（http的超时的时间一般设置的是10秒或20米，默认时间是30秒）。
2. 个推服务器消息排队延迟。毕竟免费的个推是N多人用一个服务，传说6亿活跃用户就是用负载均衡调度的时间也不慢，更慢的是就给你的消息分配了处理服务器，那还要在这个服务器排很长的队，这就决定了它快不起来。当然管理这么巨大的消息队列也很艰巨。个推虽然做到了消息基本不漏发，但是它的代价也是超大的。这就造成了没有发送成功的需要重复多次发送和确认发送成功，让本来消息队列就超长的情况更糟糕，一般有新消息不断加入进来，又有发送失败的消息加入进来。这样就进一步增加了消息的延迟。并且这种消息发送失败不断循环发送的机制也造成了，它很容易遭到攻击，一旦个推服务器遭到攻击，会有更大量的消息步断涌入，造成消息的严重延迟。虽然个推做了这种恶意消息的自动检测机制，但是当发现后再处理也是需要时间的。上次由于个推的问题就造成，10分钟才绑定个推成功的情况，很多透传消息延迟好久。当然个推也有一个bundle Identifier每年2万元的付费服务，据说能够减少在第二个环节在分配到的服务器前排队的问题。但是调度的时间开销还是要负担的。个推客户说的一个付费的用户一个服务，具体如何也不太清楚，不过肯定不是一个用户一台电脑，而是像阿里云一样的域名服务器（它本来就叫云推送）。个推云推送的透传大多数的推送速度还是很快的，快过htttp请求的速度。显然很多app的用户互相踢出机制大都使用个推的透传或个推的远程推送（苹果APNS），发现帐户被在其它设备登录要比发http请求时发现更快和实时。对不稳定网络环境，晚上下班高峰使用云推送密集时间段，服务器被攻击时，消息延迟很严重。
3. 服务器和个推之间的网络异常，需要个推和服务器恢复时间，导致服务处理成功，但是消息却没有及时发送到服务器。
除了透传（常规长连接）另一个更大范围使用的远程推送。透传的好处是更及时，远程推送的好处是用户不启动应用也能被推送活动消息。
通过苹果的APNS（它是苹果服务器和开机的iphone建立的一个长连接，个推的远程推送最终也是通过APNS推送来实现），当然通过远程推送的消息速度比透传慢的多，好处是可以在用户不开启应用的情况下，可以给用户推广告信息，活动信息，大部分对实时要求不高的消息推送用的都是远程推送，几乎所有应用都开启了远程推送，并且大部分应用都是使用的是个推的远程推送，也有的是直接使用苹果APNS。苹果不支持透传。
若你的应用对个推很依赖，那么只能等个推绑定成功才能自动登录或登录了不幸的是，有时候个推绑定回来的消息很慢，那么职能等了，通常个推不能在2秒内绑成功，那么通常要等1分钟左右，少数异常情况要等3到10分钟。若登录时不等待个推绑定成功的小，若需要用到个推时，它不给你返回，那么你的业务可能异常（如你接个单，结果乘客立刻取消了订单，你个推还没建立好连接，那么你就要等它建立好才能收到了，那么你得到个推消息就及时了），若你等待它绑定成功再进入那么有几率进入漫长的登录等待过程。
个推是第三方做的，app是自己做的，你只能收这种消息，无法帮助他们处理各种异常，如：若发现网络异常或经常闪断是发送http请求来确认。所以要处理各种异常和确认，不绑定成功能够进入并且接单，收到实时推送消息，那么最好是不用个推，实现自己的长连接。
