根据上篇的讲解，我们可以知道长连接是目前实现Push的最好的方法。我们现在考虑下要自己实现Push服务的成本。
注意，与通常Http服务器的差别：通常Http服务器需要支持的同时连接数是基于活跃用户的峰值；而长连接服务器需要支持的同时连接数是总的用户数。
对于中小型企业来讲，一个App的总用户数大概是百万级
千万级，那么服务器需要支持的同时连接数就是百万级
千万级。
一个服务器能支持的同时连接数上限到底有多少，我没有经验。但是我想要支持同时连接数达到百万级~千万级的成本应该是不低的，不管是资金成本还是技术成本，大多数中小型企业负担起来应该是很吃力的。
所以，对于中小企业来说，使用推送平台是个明智的选择。推送平台会是一个很大的市场，这也是各个大小公司都推出推送平台的原因。
APNS(Apple Push Notification Service) 是苹果提供的推送通知服务。
iOS的App是不允许后台长时间运行的，所以App自己实现Push是不可能的，能且只能使用APNS服务。
事实上APNS服务还是很稳定的，并且APNS的好处是在iOS设备上，只需要一个后台服务，也就是只要保持一个长连接，可以满足所有App的推送需求。
iOS7.0以前的推送，只能推送通知，就是会弹出的通知，iOS7.0开始，支持静默推送，收到推送以后App可以在后台运行一小段代码。
目前各大推送平台支持iOS消息推送的，实际上，最终还是通过APNS去实现的，但是对一些不具备服务端的App，还是很有用处的。
Google Cloud Messaging 是Google提供的推送通知服务。我没有用过，国内业界使用这个的也比较少，主要有两个缺点：
服务稳定性。众所周知google的服务在国内经常被封，所以GCM在国内的表现无法让人抱有很高的期望。
Android碎片化。这一个原因更加重要，Android的碎片化也是众所周知的，各大厂商的实现也是奇奇怪怪，对Google自带服务阉割也比较严重，GCM在这些手机上会有什么样的表现，也让人无法期待。
由于Android比较开放，可以后台运行以及做各种奇奇怪怪的事情，所以目前国内外有很多公司都在针对Android做Push服务。
下面分析下国内的各大平台。
本文写于2014.7.31，所以这部分的分析和评价请注意时效性
目前国内做了推送的平台有：小米、百度、华为、极光、个推、AVOS、友盟等等。
百度 是我们的App《周末去哪儿》正在用的，不忍直视。到达率不行，接口老化，sdk老化，技术支持基本没有，统计数据看不到，后台用起来跟屎一样难受，ios7.0以后支持了静默推送，百度Push也没有跟进支持， 感觉百度自己也已经放弃这一块了，至少没有好好打理。总之没有用的不要用，已经用的赶紧换。我们正打算把这玩意儿换掉。
华为 自夸的很好，但是没用过，也没仔细研究过，总感觉不太想用，业内也没有听说过使用的典型案例，好像还要收费的，所以就不看了。
友盟 做统计起家，现在也开始推出推送平台了。友盟的统计确实做的很好；但是总觉得友盟的技术不是很NB的那种，而且友盟统计以外的功能总觉得差了那么一点；而且毕竟做的比较晚，觉得在技术上不会比其他平台更有优势，所以不打算用。
极光和个推 这两家是属于老牌专业级的Push服务提供商了功能到达率方面应该是没什么问题，并且两家都有很多成功案例，其中不乏一些耳熟能详的App。但是感觉极光的B格更高一些，具体看文档和Server SDK，嗯嗯，纯属一种感觉。另外这两家都是收费的，但是有时候有优惠，比如极光目前有个“两个500万”的活动（为避免广告嫌疑，不多说了）。极光的售前售后也比较积极，个推倒是没接触过。
另外比较另类的一点是极光貌似还支持winPhone。
这两家另外一个问题就是都是小公司，所以不知道会不会突然夭折，这是我个人的一点担忧，我倒是觉得不太重要。
总之如果愿意花钱、需要专业服务的，我认为这两家是值得考虑的。
以下两个是我最近亲测过的，这里详细讲一下
小米 手机行业的大公司，小米能入围基于以下几点考虑：
大公司，而且是手机行业的。
小米手机持有量在国内很高，根据我们App的统计，小米和三星的比例最高。
小米对权限做了一些限制，三星在这方面比较尊重原生Android，基本没有做改动，小米自己的服务在自己的手机上针对权限应该会有一些特殊处理吧。
小米的技术支持很给力，我在使用的时候遇到问题，联系了小米的人，对方直接建立了一个9个人的QQ群组，里面包括了Push服务各方面的负责人。
当然小米也有一些缺点：
后台易用性不够，导航不够清晰，操作不够简洁。
文档不够好
最重要的一点：接口不够好，这点我要好好吐槽一下，现在提供服务接口，都讲究用个REST的形式，小米这个完全很奇怪啊。给了个POST请求，结果所有的参数都是作为query去操作的，完全没有content。用query就意味着所有的参数都要querify，不能友好的使用json，要考虑urlencode，总之麻烦一堆，具体有些什么麻烦，等下面讲完了AVOS之后再说。
AVOS NB技术型公司，B格高，高大上。这家公司的主要业务是AVOSCloud，也就是云服务，看了下文档，挺牛的。小米的缺点在这里都成了优点，下面做一下对比。
小米iOS和Android需要分别申请一个App，有两套appkey，写服务端的时候也要注意区分一下；AVOS只需要注册一个App，在发送的时候，使用参数区分iOS或Android，这也是大多数平台的做法，所以小米这里又略显不足。
两者都是用了https，安全性比较高；appkey都是放在head中进行认证的。
AVOS也是使用post请求，但是参数是以json格式放在content中发送的。这样有两个好处：一，参数形式很清晰，多层次的参数使用json格式可以很好的组织在一起；二、自定义的参数也可以很方便的加进去。而小米如前面所说，使用的时query形式，所有的参数都是在一个层次的，没有组织结构，比较难理解，而要加自己的参数也很麻烦，小米提供了一种extra.xxx的参数，还有数量限制，没法实现json那样的层次，很麻烦。
在实际测试过程中，两者在iOS的到达率上基本没有差别，差别主要在Android上，特别是小米的手机上。经常会出现的情况是，当App退到后台后，小米的通知都能弹出，但是AVOS发出的通知无法弹出，等到重新打开App时，累计的通知会同时弹出。
我们使用Push，通常有两种作用
通知，在通知栏弹出。
消息，静默推送，由App决定如何处理消息。
基于以上，我考虑使用多平台的方案：
通知：如果多个平台同时发送，则手机会弹出多条通知来，所以可以随机选择一个平台发送，或者挑一个觉得到达率比较高的平台进行发送。
如果是静默推送，则使用多个平台同时发送，每个消息带一个递增的id，客户端记录处理过的消息的id值，并且根据id进行判断，只处理大于记录下的id值的消息，这样可以防止重复处理。
提供了一个demo，包括一个Nodejs的PushServer，还有一个ios和android的demo程序。支持小米和AVOS两个平台。