国内的推送平台用了一圈，发现都不好用，国外的收费太高，准备自己搞个，还有机会吗？

推送平台貌似技术含量还挺高的，单机并发连接数上不去成本根本无法控制，也没法跟别人竞争。

@dndx 嗯，单机肯定不行，推送需要多主机分布式推送。

因为现在针对个人小开发者或者小团队的推送还很少，基本都是针对大公司或者二次开发，比如UMessage就是，但是如果独立开发想做个app，肯定不会还要自己去实现推送或者二次开发，现成的，简单好用就行了

我最近也在纠结推送的问题，最终用了腾讯的信鸽，因为量比较大，觉得还是企鹅的服务器比较靠谱

JPush 朋友反应高峰时段推送缓慢，所以没试。
友盟那个就是笑话，安卓版推送消息到了自动崩溃，以为是我程序问题，结果用他的 Demo 也崩溃，各种搜也搜不到。
个推没用过，不评论。
个人觉得信鸽靠谱，国内这些创业公司一旦倒闭了就蛋疼了，因为国内 Android 没法自动更新的问题，迁移不是很快能完成的。
腾讯的起码不会跑路，就算不做了也会给你时间迁移，而且腾讯服务器应该不会差了。

百度云推送口碑不错，没用过吗？

用腾讯的信鸽吧，腾讯的大部分手游也都是用信鸽的。

@typcn 是的，xg我用过，sdk集成不够简洁，有点麻烦。

比如，ios8以后做了推送解锁自定义行为，但是很多小app可能不会用到这个功能，那设备版本的判断还得写到代码里面，实际上是可以封装进sdk的。

赶脚百度的还挺好用的啊。只要有百度一家子的产品随便一个 几乎都能收到推送，成功率还是挺高的。

@bkmi 以前用过BAE，问题还挺多，感觉还没SAE好用，所以推送也就没什么信心了，对于百度搜索，一直都是，呵呵。。。能不用就尽量不用

@AssKicker 不难啊，安卓复制几个 jar，改改 xml ，加一行启用就完了。
iOS 把库拖进来，然后把照着他的 demo 复制过来需要的部分即可。
@bkmi 腾讯要是也这样共享通道就好了，装了qq啥的都能收到，立马火

@typcn 不是难，我的意思，不够简洁

这东西用
pomelo啊

偶push用它 杠杠的

除了iaas
少用这些云
看着便宜其实是当

@typcn 信鸽怎么收费？

推送不是你想写，想写就能写......
别人拿那么多钱，请那么多人来写，不是你想象中那么容易的

@ipconfiger 偶一个人写出来了
正在用 分布式＋nosql 无限扩展
哈哈

自己去实现多数除了自我感觉良好外，不见得实际效果会有YY的那么好。当然也不反对去do it。

@chris98276 信鸽感觉权限实在是太多了

看了眼信鸽的权限，默默转向了百度云

用过个推，在android平台上，收到透传消息后居然会强行弹我的activity，为此我把receiver里面的所有逻辑都注释了，还是如此。
客服只会回答你第一句话，表示他在线。
差评

百度云推的丢包率很高，长期使用不是好工具。
其实你需求小，随便找个框架搭建就行

利益相关：推送相关从业者
建议用信鸽或者百度云推送，体量比较大，比较规范
技术难度是有一点，所以不建议普通开发者折腾（花时间）

@userlogin 真没有什么高端的。也不用什么秘笈。不用妄自菲薄。

@ipconfiger
@userlogin
@Smartype

在开发了，自己用，也顺带造福坛友。。。年后发布

@Smartype 我没说有多高端不能去做，我只是想说自己去实现除了自己用来顺手外，未必就能比其他平台推送及时，稳定，把其他平台PK掉。自己的体验不代表大部分人的用户体验。LZ问还有机会吗，是想做平台，不是单纯自用。我希望我错了，可以看到你们做出比目前市面上都好的产品，造福广大开发者。

@AssKicker 我的意思是说集群中每台机器的并发连接。集群是肯定的，但是如果单机并发太低也是入不敷出。

AVOS 也就是learncloud

呵呵

@userlogin
网易的push也是pomelo
pomelo里代码贡献度偶能到前10名
偶一直写工业级的软件

哈哈

我用的信鸽ios版，感觉还不错，到达很准时。

@AssKicker 来分享一下设计哇

Linux上单机百万连接轻轻松松的，超过百万要改内核，另外内存要足够多。

推荐一下我米的
http://dev.xiaomi.com/doc/?page_id=1670

接口都是公开的，如果不考虑高并发，技术门槛也不高。
我们以前都是自己生写的，近来才用信鸽。

纸上得来终觉浅，绝知此事要躬行

@l12ab iOS推送和Android推送差别很大的。

@ipconfiger 做得差不多了我会上来分享架构设计的：）

我们基于mqtt，提供各个平台的双向消息通讯服务 http://yunba.io/

我们这边打算用Mqtt做，因为要内部网，所以公共平台都没法用了，

不知道对于一个to B的产品来说, 楼主所指的用户体验是哪一方面?
评价推送产品的好坏, 最重要的还是推送的到达率咯. 如果有机会的话, 可以小批量上线一个版本, 去测试各个推送的到达率.
我所知很多客户在选择我们的产品的时候, 多做过这样的测试评估.
而对于 大公司产品 = 靠谱, 真是一个错误的认知
利益相关:某推送平台的员工

@xiezefan 我主要指iOS，因为我是iOS DEV，集成的都是iOS App。
说下我说的体验不好的方面：（不针对具体产品吐槽了，虽然全部都用过，但是指名道姓有点砸场子的嫌疑）
1.页面体验不好，比如某号称最好的推送，界面跟大学生设计的一样，里面的统计也很奇怪，至少不是我想要的。
2.到达率我没有办法完全统计，至少在上线以后，有我自己的手机上面安装的正式版无法收到推送的情况。（iOS的推送比较特殊，需要通过APNS，所以理论上来说，能否到达还有一部分是开发者不可控）
3.推送真的很慢，可能免费用户的优先级比较低吧
4.很多都不支持emoji，可以自己copy文本，但是不能实时预览，这个很难吗？
5.很多推送都不能模拟预览，这个也不难吧？至少发推的时候还可以看个效果对吧
6.推送声音还要自己输入声音字符串，有没有搞错，比如app里面如果集成了N多音效，我想推送，还得一字不差的输入声音名字，直接下拉选择不好吗？
还有些细节，暂时就不一一列举了。

不可否认的时现在这些产品都还在不断改进，所以上面提到的某些功能可能在这个过程已经开始完善了有说错的地方还望指正。

@AssKicker

做公共云平台要求技术水平和资源很高的
不是阿狗阿猫能搞定的

看盛大云阿里云被骂成什么样子 一般人早羞愧得癌症了

@arachide 是的，公共云平台的要求是很高，所以我不打算做，没资源啊，只做推送

@arachide 厉害厉害

哪有运维直接上推送平台自己管理的，当然是自己做个后台，背后用jpush之类的东西推，用户和管理员感受不到jpush的存在才是正路啊。你直接让运维去jpush啊百度云推送啊什么的去管理推送不是扯淡么。用户分组，tag，alias都是在自己服务器上另外管但背后还是连到推送服务的才方便管理啊。
感觉没必要自己连推苹果都自己做了，一来浪费时间，二来以后并发多了事儿一堆。

@yellowV2ex 个人开发者和小团队不太可能做二次开发，上面说到的运维只是一个例子，比如产品狗看到技术名词也会头大

@AssKicker 简单回复下你的几个问题

1. 页面体验不好, 这个在于推送产品的核心竞争力在于推送到达率与各种智能推送相关的业务(如分区域推送, 分性别推送等). 对于创业公司来,做不了大而全, 就先做小而美吧.
2.apns有一个开发模式和一个生产模式, apns开发中收不到消息, 90%是没设置这个的原因吧.
3.推送慢不知道是指哪一个方面? 是指收到消息慢么? apns推送其实对于push平台来说只是做一个转发(当然push平台提供的更多是全平台统一的api接口和各种智能推送), 你收到消息慢可能和你本地的网络环境与apns服务器之前的通讯质量有关. (我们也有遇到过关于推送过快, 导致大批量用户收到推送后进入相关页面, 导致客户服务器承受不知的问题. 后来也有相应的api提供定速推送的功能.)
4.emoji表情, 这个有支持.
5.模拟预览, 这个有支持. 虽然我觉得不是很好用.
6.关于声音的问题, 额, 这个我觉得更多的是业务平台去解决的问题嘛? 不是推送平台应该做的事情咯.

@AssKicker 那我不太明白，难道你自己做推送连管理和推送底层都自己处理会比做一个壳子管推送要省事儿？苹果不说，就安卓的推送，你自己要多做多少东西，安卓的同事要增加多少工作量。。。

@yellowV2ex 嗯，所以不做android啊，一开始只做iOS


@xiezefan 谢谢回复
1. 小而美，对。
2.当然不是，我回复中刻意说了是正式版本，也就是证书是production
3.我觉得在整个环节中，推送通常的瓶颈在provider（假设APNS是理想环境，即使不理想也不是我们可控的环节），因为在推送队列管理，还有跟APNS的长连接上面，还有很多细节可能导致变慢
4.JPush，UMessage，XG，Getui，那个支持了啊？ 我都用过，我说的支持是指，类似聊天一下直接选择表情，图文混排预览
5.模拟预览UMessage的做得很烂，XG有吗？Getui不知道新版有没有
6.我觉得这个支持非常重要，你觉得输入好还是下拉选择好？

云里面
偶觉得IAAS SAAS都好用
IAAS是必须
SAAS迁移成本几乎没有

BAAS PAAS谨慎用
因为sdk迁移成本不低

@AssKicker 关于4,5,6 我大概明白你的问题咯, 你的问题大概在于现有的push平台都没提供一个交互良好的界面吧.

我刚才测试了下, JPush是支持emijo的. http://xiezefan.qiniudn.com/emijo_test.jpg 但在控制台中的确不能发送emijo, 就算复制进去都不行, 用原始编码也不可以. 我这是通过 推送API调用 推送的.

可能是因为一些Android设备对Emijo支持不是很好吧. 为了支持全平台, 在通用的推送页面中加入Emijo并不是一个很好的设计吧.(个人看法)

建议你自己可以实现一个Web Portal, 简单实现下自己的推送要求, 我所知的很多用户都是通过自己的管理后台调用推送api去进行推送. 这样可以做到更灵活, 像表情支持, 预览, 声音选择都可以通过自己的业务要求来实现.

其实我觉得, 为什么各大push平台都没提供很完善的推送交互界面, 可能更大的原因在于, 对于绝大多数用户来说, 这并不是主要需求并且很多时候他们希望把push管理这个功能集成到自己的管理后台.

@xiezefan 是的，就是这个问题，对于大多数企业用户而言，的确是这样的，他们的业务系统需要和推送整合，比如SNS或者即时聊天之类的，是不可能用人工去发推的。

这也就是问题的所在，个人用户，小开发者越来越多，他们的很多app，可能就几天，或者1，2个月做的，他们没有更多的精力去做二次开发或者搭建一个推送平台，也没意义。

所以我就想针对这些人，有没有这样一种可能性：）

@AssKicker

问题这些人也不愿意付钱啊
本来baas这种模式国内就很难赚钱
小商家免费额度用不了
大商家自己搞baas

偶估计目前国内这些baas全部亏损
最后还是靠卖数据隐私赚钱

@AssKicker 从企业的决策上, 一般小开发者发展为付费用户的可能性很低. 所以这类需求的优先级基本都是很低的(对于公司来说无可厚非,毕竟做这些的最终目的都是为了赚钱).

我倒是觉得, 如果有时间的话, 用python或者nodejs撸一个第三方管理portal来调用push推送倒是可以有. 到时候开源出来惠及广大小开发者们.

这些都是基于需求开发的, 在平时开发中, 我倒是经常写一些非常简陋的UI, 给客户端的同事简单测试下推送. 要如何抽象成广大开发者适用的, 这个没多少经验倒是不好说呀.

http://xiezefan.qiniudn.com/2015-02-13 13:47:38的屏幕截图.png

@arachide 是的，所以打算免费，但是未来可以考虑按量收费，比如：发10000条1毛，这样。如果你app赚钱了，我相信几块钱还是愿意掏的，我是愿意有人来给我提供这种服务，我给钱都可以。

@xiezefan 是的，你这个想法倒是提供了另外一个思路，谢谢，考虑下：）

@typcn
你好，我是友盟的工作人员，看到您反馈的:


"友盟那个就是笑话，安卓版推送消息到了自动崩溃，以为是我程序问题，结果用他的 Demo 也崩溃，各种搜也搜不到。"

-- 最好您能提供一下使用的SDK版本，是Android的还是iOS的，出问题的机型等描述信息，如果有错误日志，发给我们的客服人员或者客服邮箱当然最好(客服人员的联系方式以及客服邮箱在我们集成文档以及网站上都有标注)，便于我们排查问题。

-- 光是这样一句模糊的描述，对一个服务的评价是不客观的。 目前集成友盟推送服务的开发者已经非常多了，crash的问题很少有反馈，即使有反馈过，经过我们的技术支持同事排查，大部分情况下也是开发者集成有问题导致的。

@fisheryiyi ios无问题，安卓无限崩溃，只要推送消息一到，就能听见提示音的前0.1秒，然后程序 crash ，logcat 看到的是因为找不到图标而崩溃，但是用你们的 demo 一样崩溃，推送全部是默认配置。

小米的推送怎么样