你正在使用的浏览器版本过低，将不能正常浏览和使用知乎。&p& 自己的一篇博客，对IM服务器的简单架构思路。&/p&&br&&p&&b& IM系统架构设计之浅见&/b&&/p&&p&背景：除去大名鼎鼎的QQ这款即时聊天工具，还有许多细分行业的IM，比如淘宝阿里旺旺、网易泡泡、YY语音......。恰巧公司产品也要开发一款基于我们自己行业的类IM系统，很有幸我担当了这个产品的架构师，核心代码编写、实现者。下面我近年来从技术上我对IM系统（即时消息的传输，不包括语音，视频，文件的传输）的理解和设计分享出来，浅薄之见，望大家别见笑，欢迎给出批评意见。&/p&&b&一.网络传输协议的选择&/b&&p&目前我知晓的所有IM系统传输即时消息无外乎使用UDP、TCP、基于TCP的http这几种协议中的一种或几种。比如QQ主要采用UDP协议，MSN主要采用TCP协议，而且他们也都支持HTTP协议的代理模式。更多资料，请参加这篇文章&a href=&///?target=http%3A///maowang1991/p/3572327.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&《一些常用软件的网络端口协议分类介绍》&i class=&icon-external&&&/i&&/a&。&/p&&p&我们该如何选择呢？&/p&&ul&&li&&p&UDP协议实时性更好，但是如何处理安全可靠的传输并且处理不同客户端之间的消息交互是个难题，实现起来过于复杂；&/p&&/li&&li&&p&HTTP协议属于扩展支持，我们在产品的初始阶段可以不用支持；&/p&&/li&&li&&p&那就非TCP协议莫属了，要考虑的同样也有很多，特别是如果有海量用户的需求。如何保证单机服务器高并发量，如何做到灵活，扩展的架构。&/p&&/li&&/ul&&blockquote&&p&Tips: &a href=&/question/& class=&internal&&QQ 为什么采用 UDP 协议，而不采用 TCP 协议实现？&/a&&/p&&/blockquote&&b&二.应该选择什么格式的数据协议&/b&&p&二进制格式？文本格式？这个话题转到我的这篇文章&a href=&///?target=http%3A//yaocoder./210& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&《网络传输数据格式的选择》&i class=&icon-external&&&/i&&/a&，从我们当前的需求和产品周期上我觉得选择JSON形式的数据协议是最好的。&/p&&b&三.架构设计&/b&&p&首先我们来提炼一下一个IM系统的主要需求，包括账号，关系链，在线状态显示，消息交互......。&/p&&p&&strong&架构考量&/strong&：&/p&&ul&&li&&p&由于采用可靠传输协议TCP，考虑到负载问题（短连接实现账号、关系链相关业务，长连接实现上线、信息推送）；&/p&&/li&&li&&p&后台架构的灵活性、可扩展性，支持分布式部署——把网络层、业务逻辑层、数据层分离，网络层和业务层支持负载均衡策略、数据层支持分布式存储；&/p&&/li&&li&&p&客户端SDK的易用性：把网络层、数据层分离、业务逻辑层分离；&/p&&/li&&/ul&&p&&strong&后台架构简化图&/strong&&/p&&img src=&/1715bbba938b427c10aea_b.jpg& data-rawwidth=&1188& data-rawheight=&840& class=&origin_image zh-lightbox-thumb& width=&1188& data-original=&/1715bbba938b427c10aea_r.jpg&&&br&&p&&strong&架构示意图&/strong&&/p&&img src=&/1c06d4ecfe1d3ddacd63d29_b.jpg& data-rawwidth=&1188& data-rawheight=&840& class=&origin_image zh-lightbox-thumb& width=&1188& data-original=&/1c06d4ecfe1d3ddacd63d29_r.jpg&&&br&&p&&strong&架构细化图&/strong&&/p&&img src=&/9655fefaa5b6b2ebc4bd61cc06f0d55b_b.jpg& data-rawwidth=&1188& data-rawheight=&840& class=&origin_image zh-lightbox-thumb& width=&1188& data-original=&/9655fefaa5b6b2ebc4bd61cc06f0d55b_r.jpg&&&br&&p&&strong&说明&/strong&&/p&&ul&&li&&p&从&架构细化图&中可以看出对于上线服务由于建立的是TCP长连接，对于单台服务器往往由于硬件资源、系统资源、网络资源的限制无法做到海量用户的同时在线，所以设计为根据服务器负载支持多服务器上线，同时由于多服务器上线造成了对整个系统交互（不同的客户端的交互，协作部门应用服务和客户的交互）的分割，引入消息转发服务器作为粘合点。另外对于多服务器上线造成的统一账户信息（在线状态，消息）数据的分割，引入统一的数据层（内存存储层：session、状态信息存储、消息队列存储；数据库：账号信息存储）做到业务和数据的分离，也就做到了支持分布式部署。参见我的这篇文章&a href=&///?target=http%3A//yaocoder./1638& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&《构建高性能服务的考量》&i class=&icon-external&&&/i&&/a&&/p&&/li&&li&&p&对于部分业务服务：做到网络层、业务层、数据层的完全分离。首先对于TCP短连接来说不会如长连接那般消耗资源，即使后期遇到海量的并发访问请求依然可以从容的通过负载均衡策略和数据分布式部署策略进行解决。参见我的这篇文章&a href=&///?target=http%3A//yaocoder./4280& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&《服务端架构中的“网关服务器”》&i class=&icon-external&&&/i&&/a&&/p&&/li&&/ul&&p&&strong&服务端平台及技术选型&/strong&&/p&&ul&&li&&p&系统开发平台： CentOS——Linux发行版的一种，稳定可靠、可定制优化、支持丰富；&/p&&/li&&li&&p&网络支撑层： libevent——减小开发成本，增强稳定性；&/p&&/li&&li&&p&缓存存储层： Redis——支持丰富的存储结构，支持分布式存储；&/p&&/li&&li&&p&数据库： MySQL——最适合互联网的数据库，免授权、高效稳定、可控性高；&/p&&/li&&li&&p&开发语言： C/C++；&/p&&/li&&/ul&&p&&strong&部分热点问题考量&/strong&&/p&&ul&&li&&p&系统性能考量：&/p&&ul&&li&&p&编码角度：采用高效的网络模型，线程模型，I/O处理模型，合理的数据库设计和操作语句的优化；&/p&&/li&&li&&p&垂直扩展：通过提高单服务器的硬件资源或者网络资源来提高性能；&/p&&/li&&li&&p&水平扩展：通过合理的架构设计和运维方面的负载均衡策略将负载分担，有效提高性能；后期甚至可以考虑加入数据缓存层，突破IO瓶颈；&/p&&/li&&/ul&&/li&&li&&p&系统的高可用性：（防止单点故障）&/p&&ul&&li&&p&在架构设计时做到业务处理和数据的分离，从而依赖分布式的部署使得在单点故障时能保证系统可用。&/p&&/li&&li&&p&对于关键独立节点可以采用双机热备技术进行切换。&/p&&/li&&li&&p&数据库数据的安全性可以通过磁盘阵列的冗余配置和主备数据库来解决。&/p&&/li&&/ul&&/li&&li&&p&Tips: 如果要支持web IM，请阅读&a href=&///?target=http%3A//yaocoder./4501& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&《Web推送技术研究》&i class=&icon-external&&&/i&&/a&&br&&/p&&/li&&/ul&&p&&strong&主要学习资料：&/strong& 请自行google。&/p&&ul&&li&&p&《1.4亿在线背后的故事》；&/p&&/li&&li&&p&《BasicDB的架构演变》；&/p&&/li&&li&&p&《微信之道－至简》；&/p&&/li&&/ul&
自己的一篇博客，对IM服务器的简单架构思路。
IM系统架构设计之浅见背景：除去大名鼎鼎的QQ这款即时聊天工具，还有许多细分行业的IM，比如淘宝阿里旺旺、网易泡泡、YY语音......。恰巧公司产品也要开发一款基于我们自己行业的类IM系统，很有幸我担当了这个…
我是融云的 CTO，LeanCloud 是一家令人敬仰的公司，我个人也是 LeanCloud 的粉丝。&br&LeanCloud 和融云在即时通讯服务方面主要的不同在于：LeanCloud 提供的是一个更加抽象的实时通讯服务，可以非常灵活的实现各种功能场景，这是最大的优势；而融云对即时通讯功能做了非常高级的封装，可以说完全是面向即时通讯业务的，而且提供了开箱即用的界面组件，无疑大大降低了开发成本和门槛。&br&成本角度，融云无论用户量多大，全部是免费的，一些增值服务才付费。&br&以 40 万日活计算，融云成本为零；LeanCloud 是 1.2 万元/月，环信是 2 万元/月。
我是融云的 CTO，LeanCloud 是一家令人敬仰的公司，我个人也是 LeanCloud 的粉丝。 LeanCloud 和融云在即时通讯服务方面主要的不同在于：LeanCloud 提供的是一个更加抽象的实时通讯服务，可以非常灵活的实现各种功能场景，这是最大的优势；而融云对即时通讯…
LS有同学说扣扣邮箱不能推送，其实……不是酱紫的！&br&刚才用扣扣邮箱发送文件后仍然没有反应，几分钟kindle设备的绑定邮箱收到邮件，内容：&br&&blockquote&亲爱的客户，&br&&br&发件人 XXXXXXXXXX 曾尝试向您的 Kindle 发送文档。由于XXXXXX不在您的 Kindle 获批准的电子邮件列表中，因此该发件人向您发送的任何文档均无法传送至您的 Kindle。&br&&br&要批准此发件人的电子邮件地址：&br&1. 访问管理您的内容和设备页面。&br&2. 登录亚马逊帐户。&br&3. 进入“管理您的内容和设备”下的“个人文档设置”。&br&4. 在“获批准的个人文档电子邮件列表”下，点击“添加一个已获得批准的电子邮件地址”。&br&5. 输入要审批的电子邮件地址，然后选择“添加地址”。&br&6. 通知发件人重新发送文档。&br&&br&请注意，此通知您只会收到一次。此后，您将仅收到从获批准的电子邮件地址发送的文档。&br&&br&要了解更多有关传输个人文档到您 Kindle 的信息，请访问我们的帮助页面&br&&a href=&///?target=https%3A///gp/r.html%3FC%3DMNZYG5K7A6RJ%26K%3DA19BXTJ1DE8XRE%26R%3DUON2LJEVM9Q3%26T%3DC%26U%3Dhttp%3A///Kindledocuments/%3Fref_%253Dpe_A%3DDGAA5M2VIXS9UPRFZ153EONN02UA%26H%3DMWDN516QNXGSDIFHMC6NIOVL3JAA%26ref_%3Dpe_729420& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/Kindledocuments/&i class=&icon-external&&&/i&&/a&&br&&br&此致，&br&亚马逊 Kindle 支持&br&&br&请注意：本电子邮件的地址仅用于发送通知，不能接收邮件。请勿回复此邮件。&br&&br&&a href=&///?target=https%3A///gp/r.html%3FC%3DMNZYG5K7A6RJ%26K%3DA19BXTJ1DE8XRE%26R%3DUON2LJEVM9Q3%26T%3DC%26U%3Dhttp%3A///kindle/%3Fref_%253Dpe_A%3DERVOB6MUWBB6PWXGIPAWHKJR13UA%26H%3DS3FRA0HVGS8MAOGTWULZVTICOEQA%26ref_%3Dpe_729420& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&进一步了解亚马逊 Kindle&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=https%3A///gp/r.html%3FC%3DMNZYG5K7A6RJ%26K%3DA19BXTJ1DE8XRE%26R%3DUON2LJEVM9Q3%26T%3DC%26U%3Dhttp%3A///kindlestore/%3Fref_%253Dpe_A%3DFLVIAD7GAOHJ81F1JAUXF16HHOYA%26H%3DALSUUCFAMU2JSLJOLLCN1HYCGD0A%26ref_%3Dpe_729420& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&查看 Kindle 商店&i class=&icon-external&&&/i&&/a&&br&&br&若您对 Kindle 还有疑问，请访问&a href=&///?target=https%3A///gp/r.html%3FC%3DMNZYG5K7A6RJ%26K%3DA19BXTJ1DE8XRE%26R%3DUON2LJEVM9Q3%26T%3DC%26U%3Dhttp%3A///kindlesupport/%3Fref_%253Dpe_A%3DEUGOLJON7RGNB3UJA7ASAEABDSCA%26H%3DGR4F18QWMJEW7ZMHLVRBIQOQGRCA%26ref_%3Dpe_729420& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&亚马逊 Kindle 帮助&i class=&icon-external&&&/i&&/a&页面&br&该“帮助”页面将为您提供常见问题的答案，并提供亚马逊 Kindle 专员链接。&br&要联系亚马逊 Kindle 客户服务，只需在“帮助”页面上单击“联系我们”框中的按钮，即可通过电子邮件或手机获取帮助。 &br&&br&在 Kindle 上阅读您的个人文档从未如此便捷。要了解更多关于“Send to Kindle”（发送至 Kindle）的信息，请访问&a href=&///?target=https%3A///gp/r.html%3FC%3DMNZYG5K7A6RJ%26K%3DA19BXTJ1DE8XRE%26R%3DUON2LJEVM9Q3%26T%3DC%26U%3Dhttp%3A///sendtokindle%26A%3DQGTQGM4O367UKMBKMR8VSNA1IYSA%26H%3DHEAHJQ7IRKX6DCB1CMSGGAHXVAOA& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/sendtokindle&i class=&icon-external&&&/i&&/a&&/blockquote&所以非常简单……只需要按照邮件点开 管理您的内容和设备 页面，找到 设置-个人文档设置：&br&&img src=&/f1ed7f294ffd10bbc58b8fd63a6db439_b.png& data-rawwidth=&1315& data-rawheight=&295& class=&origin_image zh-lightbox-thumb& width=&1315& data-original=&/f1ed7f294ffd10bbc58b8fd63a6db439_r.png&&&img src=&/4de35c098f72f6be47dffe7f_b.png& data-rawwidth=&1325& data-rawheight=&235& class=&origin_image zh-lightbox-thumb& width=&1325& data-original=&/4de35c098f72f6be47dffe7f_r.png&&至此重新发送，大功告成！&br&————————————————————————————&br&但是，如何查收发送的文档到底有没有发送成功？&br&一下为扣扣邮箱的投递情况，但是kindle刷新N次仍然没有任何新添加书籍。&br&&img src=&/ab98b5cc71fb2a7100aefd6_b.png& data-rawwidth=&858& data-rawheight=&105& class=&origin_image zh-lightbox-thumb& width=&858& data-original=&/ab98b5cc71fb2a7100aefd6_r.png&&我就想登陆这个&a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&去看看。。结果我错了，这个地址根本都不存在立即404了。。其实，接收方只是个亚马逊的云盘，登陆就可能看到是否已经收到文件，非常方便！&br&&a href=&///?target=https%3A///clouddrive/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&亚马逊:登录&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=https%3A///clouddrive/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://www.&/span&&span class=&visible&&/clouddrive/&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&&br&&img src=&/c8adc2bc64ce5f3afa46ead_b.png& data-rawwidth=&1364& data-rawheight=&575& class=&origin_image zh-lightbox-thumb& width=&1364& data-original=&/c8adc2bc64ce5f3afa46ead_r.png&&能打开这个网页也可以选择 + 添加文件，比邮箱方便的多！&br&爽乎？&br&吐槽下，kindle从云端下载真的好慢。
LS有同学说扣扣邮箱不能推送，其实……不是酱紫的！ 刚才用扣扣邮箱发送文件后仍然没有反应，几分钟kindle设备的绑定邮箱收到邮件，内容： 亲爱的客户， 发件人 XXXXXXXXXX 曾尝试向您的 Kindle 发送文档。由于XXXXXX不在您的 Kindle 获批准的电子邮件列表…
刚好对 LeanCloud、融云、环信 都有了解。&br&&br&首先，技术是都差不多的，都做了一样的事情，开发者用了哪一家，就用户层面上来说感受都一个样。&br&&br&然后，与其他两个专注 “ IM 云服务” 的提供商相比， LeanCloud 除了 即时通讯，还有 统计分析、消息推送、数据存储等功能。这对移动开发者来说很方便，我们仅需要 LeanCloud + 一个 社会化分享 提供商 就可以做完所有的事情。&br&&br&当然，还有一个原因是：产品气质。&br&&br&没错。我是被 LeanCloud 的气质折服的，关于它的气质，举个栗子：&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&LeanCloud 开放资源&i class=&icon-external&&&/i&&/a&
刚好对 LeanCloud、融云、环信 都有了解。 首先，技术是都差不多的，都做了一样的事情，开发者用了哪一家，就用户层面上来说感受都一个样。 然后，与其他两个专注 “ IM 云服务” 的提供商相比， LeanCloud 除了 即时通讯，还有 统计分析、消息推送、数据存…
推荐题主了解下MQTT 和 XMPP协议。 网络上有很多开源的实现方案。 &br&上述两个协议都是移动端消息推送协议， 刚好毕业设计与实习是做相关的东西， 所以做了点技术调研，分享给题主。 &br&&br&看问题题主应该是想要实现移动端的即时通信。&br&首先，大概把系统分为以下两个模块。&br&1.消息推送模块&br&&a href=&///?target=http%3A//2.IM& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&2.IM&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&的业务模块&br&&br&&b&关于消息推送模块&/b&&br&如果题主的需要是公司的项目的话吗，我建议消息推送模块使用第三方推送，国内的第三方推送平台已经很成熟，诸如 &a href=&///?target=https%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&JPush极光推送&i class=&icon-external&&&/i&&/a&， &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&腾讯信鸽推送&i class=&icon-external&&&/i&&/a&，&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&个推-安卓Android推送_IOS推送&i class=&icon-external&&&/i&&/a&&br&&br&如果你是纯粹个人项目想实现一个简单的推送系统的话，建议你可以参考一下 &a href=&///?target=http%3A//tt.mogu.io/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&蘑菇街TeamTalk&i class=&icon-external&&&/i&&/a&&br&大旨是要解决几个问题（我只简单了解下， 实际开发中还有很多难题需要解决）：&br&&ul&&li&客户端如何持续保持与服务端的长连接。&br&&/li&&ul&&li&也就是心跳机制，在WIFI,2G,3G,4G环境下的心跳间隔， 额外触发心跳的机制（切换网络环境，擦入电源线，切换基站？）&/li&&li&心跳机制是主要影响app耗电的一个问题&/li&&li&Android上的定时机制，AlarmManager和Timer的区别&/li&&/ul&&li&服务端缓存离线客户端的消息机制&/li&&ul&&li&客户端难免有时会离线，登出， 服务端应该如何缓存客户端的信息， 缓存多少等等。&/li&&/ul&&li&服务器宕机后，重新启动后大量客户端同时连接客户端的解决方案， &b&雪崩效应&/b&&/li&&/ul&还有N多问题，记录在笔记中还未总结，以后用空补上。&br&&br&&b&关于IM的业务模块&/b&&br&这点没什么好说的， 纯粹的业务逻辑， 消息的接收与展示。&br&因为我也是刚刚开始， 计划中大致把该模块分为 &b&聊天逻辑模块&/b&，&b&好友关系模块&/b&，&b& 历史消息模块&/b&&br&， 其中聊天模块的相对独立的模块， 作为整个系统的核心， 其他好友关系模块与历史消息模块都是非必须可插拔的。 模块间基于接口编程。 &br&&br&对于客户端而已，服务端是透明的，也就是客户端A给客户端B发送信息， 首先是客户端A通过HTTP请求像把消息发送给服务端，服务端通过Push，将消息原封不动地推送给客户端B。 服务端纯粹的一个转发通道。而客户端间以一套双方已经约定的协议来解析接收到的消息并处理。&br&&br&以上的项目的架构只是简单构思下， 具体实现的合理性还有待讨论。 其实网上已经完整的IM解决方案，上述的TeamTalk， 还有&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&环信即时通讯云&i class=&icon-external&&&/i&&/a&， &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&容联云通讯&i class=&icon-external&&&/i&&/a&， AVOS等 . 题主可以根据自己的需要选择解决方案&br&&br&&br&最后分享下一篇关于各种Android消息解决方案的分类总结。&br&&blockquote&本文主旨在于，对目前Android平台上最主流的几种消息推送方案进行分析和对比，比较客观地反映出这些推送方案的优缺点，帮助大家选择最合适的实施方案。&br&&br&&strong&方案1、&/strong&使用GCM服务（Google Cloud Messaging）&br&简介：Google推出的云消息服务，即第二代的G2DM。&br&优点：Google提供的服务、原生、简单，无需实现和部署服务端。&br&缺点：Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。&br&&br&&strong&方案2、&/strong&使用XMPP协议（Openfire + Spark + Smack）&br&简介：基于XML协议的通讯协议，前身是Jabber，目前已由IETF国际标准化组织完成了标准化工作。&br&优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。&br&缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。&br&&br&&strong&方案3、&/strong&使用MQTT协议（更多信息见：&a href=&///?target=http%3A//mqtt.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&MQTT: MQ Telemetry Transport&i class=&icon-external&&&/i&&/a&）&br&简介：轻量级的、基于代理的“发布/订阅”模式的消息传输协议。&br&优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域（参考：&a href=&///?target=http%3A//mqtt.org/software& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Software - runtimes, APIs and libraries for MQTT&i class=&icon-external&&&/i&&/a&），且已有C++版的服务端组件rsmb。&br&缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。&br&&br&&strong&方案4、&/strong&使用HTTP轮循方式&br&简介：定时向HTTP服务端接口（Web Service API）获取最新消息。&br&优点：实现简单、可控性强，部署硬件成本低。&br&缺点：实时性差。&/blockquote&
推荐题主了解下MQTT 和 XMPP协议。 网络上有很多开源的实现方案。 上述两个协议都是移动端消息推送协议， 刚好毕业设计与实习是做相关的东西， 所以做了点技术调研，分享给题主。 看问题题主应该是想要实现移动端的即时通信。 首先，大概把系统分为以下两个…
我来答一个，从实际客户角度看，你去看他们官网最下面，合作伙伴or案例的介绍&br&&br&腾讯信鸽肯定不行，没人用，你看他自己主页的合作伙伴，是腾讯分析和腾讯云，没其他第三方了，腾讯自己的业务，为何没微信？&br&然后百度，&a class=& wrap external& href=&///?target=http%3A///cloud/push& target=&_blank& rel=&nofollow noreferrer&&云推送 - 百度开放云平台&i class=&icon-external&&&/i&&/a& ，案例，百科，gif，365日历，其他没了。。。&br&从客户认可度角度看，上面两家都比较弱&br&然后看个推和极光，两者官网上宣传的案例客户都较多，从客户的重量级角度看，个推比极光强，不是一个重量级的（新浪微博，唱吧，pptv，天天动听 ）vs （凤凰网，珍爱，爱卡，东方航空）&br&&br&从官方自己宣传的资料看，以客户阵营投票，个推认可度较高
我来答一个，从实际客户角度看，你去看他们官网最下面，合作伙伴or案例的介绍 腾讯信鸽肯定不行，没人用，你看他自己主页的合作伙伴，是腾讯分析和腾讯云，没其他第三方了，腾讯自己的业务，为何没微信？ 然后百度， ，案例，百科，…
明明旁边有桥，非要摸着石头过河。
明明旁边有桥，非要摸着石头过河。
技术原理基本上就楼主所说的三种：&br&&ol&&li&Pull&/li&&li&SMS&/li&&li&Persistent TCP/IP&/li&&/ol&&br&Pull和SMS方式的缺点是显而易见的，Pull会加重服务器负担，过快消耗移动设备的电力；SMS费用较高，时效性也没有优势，而且很难在全球范围内推广。比较靠谱的方案是TCP/IP长连接。我可以说说Android上Push Notification的实现原理。&br&&br&Android从2.2版之后推出了一个新的东西：C2DM(Android Cloud to Device Messaging Framework)，其实就是Android上的Push Notification机制。使用C2DM，第三方应用程序可以搭建自己的服务器，配合Google的C2DM Server实现消息的即时通知。&br&&br&C2DM其实使用的也是TCP/IP长连接，所不同的是它运行在系统级别，从而避免了被操作系统杀死使整个Push机制失效的悲剧（第三方应用程序当然可以不使用C2DM自己实现Push机制，但一旦系统内存较低，程序被操作系统杀死后你就歇菜了）。另外，由于所有的第三方Push数据都必须走Google的C2DM Server，所以在实现上只需保持一个TCP/IP长连接，所有的Push数据都通过这个连接传送，从而节省了很多电力开销。&br&&br&关于C2DM的更多信息，请参考：&br&Android Cloud to Device Messaging Framework - Google Projects for Android&br&&a href=&///?target=http%3A///intl/zh-CN/android/c2dm/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/intl/zh&/span&&span class=&invisible&&-CN/android/c2dm/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
技术原理基本上就楼主所说的三种： PullSMSPersistent TCP/IP Pull和SMS方式的缺点是显而易见的，Pull会加重服务器负担，过快消耗移动设备的电力；SMS费用较高，时效性也没有优势，而且很难在全球范围内推广。比较靠谱的方案是TCP/IP长连接。我可以说说Andr…
&b&Maka&/b&&br&&b&优点：&/b&功能很简单，非常容易上手，交互做的很不错，自动完美适配，体验很不错&br&&b&缺点&/b&：唯一感觉遗憾的是太慢了，简直要卡死的节奏，并且图片质量还想有压缩，不是特别的清晰。&br&&b&vxplo&/b&&br&&b&优点&/b&：打开速度非常快，并且图片很清晰，可以自己设定各种功能，效果也很多，比较强大&br&&b&缺点：&/b&有点小复杂，不是傻瓜式，还得看教程啊看教程啊，看了半天，才研究明白一点简单的，我不会承认是我笨的~~&br&&b&初页：（&/b&App Store上线的一个app&b&）&/b&&br&&b&优点：&/b&比较简单，有现成的模板，直接更换图片、文字即可，&br&&b&缺点：&/b&太模板化，文字颜色不能改，文字不能删，必须中规中矩的，如果背景图片木有选好，会发生白图白字，看不见啊啊啊~~只能换模板
Maka 优点：功能很简单，非常容易上手，交互做的很不错，自动完美适配，体验很不错 缺点：唯一感觉遗憾的是太慢了，简直要卡死的节奏，并且图片质量还想有压缩，不是特别的清晰。 vxplo 优点：打开速度非常快，并且图片很清晰，可以自己设定各种功能，效果…
先不提4.0之前必须登录google账户才能用，gcm容易撞墙，容易被rom删掉。到达率50%还是80%还是90%又如何？不是100%就没法用。即使是100%的android手机都有，偶尔墙一下也受不了，G。F。W的行为你是未知的，没必要赌这个。同时维护两套消息推送机制也很麻烦，只选一个必然要自己搞，有人提到的WHATSAPP、LINE、Gmail等等，这些app国内没多少人用，用这些东西的人应该也很少用被深度定制了的系统。纯国内大厂的app有谁用gcm？没必要针对微信吐槽腾讯如何如何。&br&&br&另外，gcm的网络机制不是很适合国内的网络。之前有人写过一篇文章讲为何微信导致移动的基站负载变高之类的。大概是说移动的数据通信会把长时间不传数据的长连接关掉，避免这个的办法就是降低心跳间隔，gcm的默认心跳间隔不清楚是多少，但绝对比微信自己的长。导致gcm的连接容易被断掉从而收消息有延迟。我之前用android上的gtalk感触很大，用固定宽带的wifi聊天，收到消息很及时，换数据流量上网，经常会出现一两分钟没收到消息然后一下收到好几条的情况。&br&&br&耗电量和即时性确实是个折衷的东西，你可能认为微信晚一分钟收到消息但省电1%挺好，但未必所有人都这么认为。
先不提4.0之前必须登录google账户才能用，gcm容易撞墙，容易被rom删掉。到达率50%还是80%还是90%又如何？不是100%就没法用。即使是100%的android手机都有，偶尔墙一下也受不了，G。F。W的行为你是未知的，没必要赌这个。同时维护两套消息推送机制也很麻烦，…
这不是 Android 和 iOS 或者 PC 的推送机制的区别，是新浪在各个客户端上不同的设计机制的区别。&br&&br&iOS 不允许 app 后台常驻进程，因此 app 只能选择通过 Apple 的 APNs 进程推送，这种推送是需要 app 的服务端主动发起对 Apple 服务器的连接，发送 Json 数据给 Apple 再由 Apple 的服务器通过与设备的长连接向设备推送。因为需要服务端主动发起，因此服务端需要一个 pub/sub 系统或者一个守护进程定时向微博数据库请求通知数据，然后发给 Apple 推送给设备。新浪的后台设计我们无从得知，这种几十秒的延时八成是由后台的架构造成的，因为新浪的通知量是非常大的，而 Apple 的通知应该是有频率限制的(短时间内大量请求可能会被拒绝服务)，不可能为每一条新浪通知发起一个 Apple push 通知，所以后台一个守护进程每隔几十秒取一次通知然后整合成一条 push 通知的可能性比较大，你看到的这几十秒的延时很有可能就是因为这个间隔。&br&&br&Android 允许 app 在后台常驻进程，我用 Android 微博客户端的时候也看到了它的服务进程了，因此推测微博 Android app 是直接通过后台进程 long polling 来获取通知，因为这种 long polling 是直接向微博的数据库获取通知数据，因此不会有像上面 iOS 通知机制一样的限制。虽然 Android 也有和 iOS 一样的系统级推送机制 C2DM，但是真正在用的 app 不多，因为常驻进程的诱惑太大了，可以的话大家都会倾向于常驻进程直接请求自己的服务器而不是通过 Google C2DM 来进行推送。&br&&br&我没用过微博的 PC 客户端，因此不发表意见。但是我猜测 PC 客户端和 &a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& web 版的机制是一样的，每隔几十秒的时间向 &a href=&///?target=http%3A//rm./remind/unread_count.json%3Ftarget%3Dapi& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&rm./remind&/span&&span class=&invisible&&/unread_count.json?target=api&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a& 这个 API 请求通知数据，因为也是客户端主动请求而不是 long polling，所以你看到的几十秒延时应该也是由客户端的请求间隔引起的。&a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& web 的通知机制你可以通过 firebug 看到。
这不是 Android 和 iOS 或者 PC 的推送机制的区别，是新浪在各个客户端上不同的设计机制的区别。 iOS 不允许 app 后台常驻进程，因此 app 只能选择通过 Apple 的 APNs 进程推送，这种推送是需要 app 的服务端主动发起对 Apple 服务器的连接，发送 Json 数据…
&b&Push的主要功能是用来激活用户，提升用户活跃率，&/b&&u&&b&但没有节制的滥用又会打扰用户，造成卸载。&/b&&/u&那么如何规避这个问题呢？我结合我们公司的实例来谈谈（可能涉及到公司的利益，具体什么类型的app我就不说了）。&br&&br&&b&我们通过用户的特征对用户进行了分类，并且针对不同类型的用户push不同的内容：&/b&&br&&br&&b&1、新注册用户：&/b&我们会有一个自动push，就是在注册一周内，在注册后1、2、3、5、7天的晚上8点自动推送给他一个关于产品使用技巧的（这个是系统自动发的，无需运营人员操作）&br&&br&&b&2、注册之后，一直没有内容的用户：&/b&这类用户缺少内容，我们推送促使他产生内容的信息；&br&&br&&b&3、有内容，但不分享的用户：&/b&主要推送刺激他分享的内容信息；&br&&br&&b&4、有内容又产生分享行为的用户：&/b&主要是刺激产生新内容的内容信息；&br&&br&（我们根据用户的一些其它指标，一共做了大概8个分类，针对每个分类发布不同的内容消息）&br&&br&这样细分之后，每种用户收到的内容都是对自己有用的内容，这样打开率会比较高，同时也不会因为频繁收到push而造成干扰，最大化地提升活跃率的同时，又有效将卸载率降到最低。&br&&br&我们公司的push应该算是业内很人性化的！&br&&br&&blockquote&（运营、产品的朋友们可以加微信交流：hutengfeihaoshuai ）&/blockquote&
Push的主要功能是用来激活用户，提升用户活跃率，但没有节制的滥用又会打扰用户，造成卸载。那么如何规避这个问题呢？我结合我们公司的实例来谈谈（可能涉及到公司的利益，具体什么类型的app我就不说了）。 我们通过用户的特征对用户进行了分类，并且针对不…
谢邀。&br&&br&GCM服务是GMS的一部分。Android手机出厂的时候是否要装GMS取决于手机厂商和Google之间的协定。国行Android手机目前没有GMS是因为国内厂商尚未和Google达成这样的协定。&br&&br&这个协定本身和“Google回归中国”——其实确切的说，只是“Google Play入华”而已——基本是互不相关的。&br&&br&而国产APP不用GCM，客观原因就是绝大多数人的手机上就没有GMS，从而只能自己搞一套或者去用一些其他的服务。我认为这个情况几年内都不会有任何改变。
谢邀。 GCM服务是GMS的一部分。Android手机出厂的时候是否要装GMS取决于手机厂商和Google之间的协定。国行Android手机目前没有GMS是因为国内厂商尚未和Google达成这样的协定。 这个协定本身和“Google回归中国”——其实确切的说，只是“Google Play入华”…
基本逻辑是这样的，苹果发现如果程序都保持一个后台进程和网络连接的话，有几个坏处：&br&1、费电，后台进程浪费Cpu和内存&br&2、网络连接，浪费流量和费电&br&3、很多开发者写出来的代码不够优化，会带来很多问题&br&4、界面无法统一&br&5、开发者其实很难搭建可以支持大量用户的通知服务器（需要的性能很夸张）&br&&br&所以实际上苹果的做法是：&br&1、整个系统就一个后台的进程管理推动。&br&2、所有app都把自己的通知发到苹果的服务器
基本逻辑是这样的，苹果发现如果程序都保持一个后台进程和网络连接的话，有几个坏处： 1、费电，后台进程浪费Cpu和内存 2、网络连接，浪费流量和费电 3、很多开发者写出来的代码不够优化，会带来很多问题 4、界面无法统一 5、开发者其实很难搭建可以支持大…
&b&即刻的产品有4个特点：&/b&&br&&br&1.内容都是抓取别人的，而没有UGC的内容；&br&2.内容的获取需用户主动订阅，而不是被动（智能）推荐；&br&3.订阅源是通过官方精选的，而不是个人操控的；&br&4.订阅源的颗粒度非常细，而不是很宽泛的。&br&&br&这四个特点让即刻不同于以智能推荐为主要内容分发机制的今日头条和一点资讯，不同于个人推荐为主要内容分发机制的读读日报 ，不同于以UGC内容为主的知乎专栏和简书，也不同于只能【订阅】而不能【发现】的传统RSS阅读器。&br&&br&&b&我并不喜欢所谓的信息智能推荐产品：&/b&&br&&br&1.这类产品并不是很智能，如果推荐的3条信息里面有1条是我并不感兴趣的话，这对于我来就是一种负担。&br&&br&2.这类产品对信息的控制很弱，所谓的推荐，无论智能与否都是让你被动地接受信息，即使你能通过关掉或者标注为不感兴趣的方式，让这类产品更懂你，但都做不到让你随心所欲的控制接受哪些信息。&br&&br&3.这类产品是违背部分人性的，人性分为本我、自我和超我，本我更倾向于消遣、娱乐，大家都喜欢看段子、动图和小视频，但超我则是喜欢能够通过资讯阅读来获取知识和提高自己，但智能推荐的产品总是给你推荐那些轻松、有趣能吸引眼球的信息，所以就我个人而言，以前看完某头条就很自责，觉得又浪费了很多时间。&br&&br&4.从社会价值上来讲，总是接受那些自己认同和感兴趣的信息对人的成长是不利的，人需要通过接受多元化的信息、不同的观点来认识这个真实的社会。&br&&br&&b&接下来，想推测下即刻未来的方向：&/b&&br&&br&1.更加突出人的角色，加强用户互动，增强用户粘性，沉淀用户关系，这也是为什么新版的即刻加入了个人页面、关注关系和动态更新的原因，即刻可以考虑引入第三方用户关系，还可以加入附近的人在看...等这类信息。&br&&br&2.目前即刻的订阅源已经非常丰富了，但这也加大了信息查找和筛选的成本，虽然即刻提供了排行榜、分类查找、猜你喜欢（大部分不喜欢）、最新主题、相关主题、编辑精选、专题推荐、他们在看、最近热门（确定逻辑很重要）等多种方式来帮你减小成本，但成本还是显而易见的，所以搜索的体验就非常重要，即刻可以搜索主题、消息和用户，知乎则是可以搜索话题、内容和用户，其实有异曲同工之效。&br&&br&3.是否增加UGC内容（即刻专栏），是否增加用户间的直接沟通功能（私信），我目前持保留的态度，就目前来讲，即刻并不需要现在做。&br&&br&4.商业化的探索，即刻可以更早地探索商业化的方式，例如付费订阅、广告等形式，这可以形成良好的生态环境，让内容提供方更快地加入进来。&br&&br&最后，即刻是我非常喜欢的产品，它也是我获取信息的主要渠道之一。即刻的初始用户群体有着更强烈的控制信息、获取有用信息、提高获取信息效率、减少信息获取成本的诉求，希望即刻未来能够不忘初心。&br&&br&————————12.28更新————————&br&&br&两个多月过去了，即刻也发生了些变化，特来更新一下回答。&br&&br&&b&即刻为了增加订阅源，推出了「自定义主题」的实验室。&/b&&br&&br&这个动作应该是为了解决官方生产订阅源慢的问题。现有的几个「追踪机器人」看似可以把微博、公众号、知乎等的内容聚合过来，但只是简单搬运的话对用户来说的吸引不大，「过滤后的小颗粒度订阅源」才应该是即刻最核心的地方。&br&&br&增加「自定义主题」实验室的动作还带来了一个变化：即刻开始有了非官方主导的UGC内容。用户通过设置一些条件来创建个性化的提醒，对用户个人使用来说当然是好的。但如果这个提醒想要分享（包括官方推荐），让其他用户去订阅，那么这个提醒所生产的内容就不能只通过条件来过滤。好比即刻官方的订阅源也要有人工审核一样，UGC的订阅源也要支持用户对内容进行审核。再顺着这个思路分析，即刻也许可以实现读读日报的使命，只不过靠的不光是个人品味罢了。&br&&br&另外，不得不提的是，即刻这个动作的运营手法非常不错，用户需要使用「邀请码」才可以使用「实验室功能」，而且这部分用户还得到三个邀请码，就可以再邀请另外的三个人使用。这个手法不仅成功「造势」，还过滤了一部分非核心用户。&br&&br&&b&即刻为了减小使用门槛，在产品上了做了一些优化。&/b&&br&&br&首先，打开即刻时有两个必要步骤，一个是让你打开通知，另一个是让你订阅至少两个主题。这个手法可以让用户打开后就能立即有可看的内容，即使你弃用了即刻，即刻也可以发通知再把你唤回。&br&&br&其次，对小白用户来说，不知道看什么好怎么办？通过引导设置你的性别和兴趣，即刻专门给这部分用户「量身定制」了部分订阅源。&br&&br&再次，不得不提到即刻的小秘书，你想要看什么可以告诉他，回复率100%哦。&br&&br&最后，对于那些导流过来的用户，还没有注册怎么办？即刻不注册也照样可用，而且现在也支持微信、微博、QQ第三方账号登陆啦。&br&&br&————————2.13更新————————&br&&br&即刻实验室结束内测了，新增了「RSS订阅源」的追踪机器人。&br&&br&目前还在使用RSS订阅源的用户已经不多了，但还是有可观的深度用户数量，而且这部分用户的付费意愿要更高。这个追踪机器人尤其适用于订阅国外的网站，因为国内的信息源一般都会有自己的微信公众号、微博、知乎等等。&br&&br&每个即刻用户只可以创建10个提醒，如果还有需求怎么办，估计要付费了....又是一个变现的好方式。
即刻的产品有4个特点： 1.内容都是抓取别人的，而没有UGC的内容； 2.内容的获取需用户主动订阅，而不是被动（智能）推荐； 3.订阅源是通过官方精选的，而不是个人操控的； 4.订阅源的颗粒度非常细，而不是很宽泛的。 这四个特点让即刻不同于以智能推荐为主…
在国内恐怕是：睡你**，起来嗨。
在国内恐怕是：睡你**，起来嗨。
因为你在中国，你用的手机系统基本上不是android系统，如果google强制你使用优雅、省资源的GCM推送系统的话，中国就不会有android手机，所以，感谢google吧，是android的开放让中国大部分人能用上智能手机。这种问题以后就不要再问了，提问之前希望多做做功课，求折叠
因为你在中国，你用的手机系统基本上不是android系统，如果google强制你使用优雅、省资源的GCM推送系统的话，中国就不会有android手机，所以，感谢google吧，是android的开放让中国大部分人能用上智能手机。这种问题以后就不要再问了，提问之前希望多做做功…
这个问题仅是我国内地专有的故障，与Android本身无关。&br&&br&具体地说，gms服务内地不可用，且这个内地销售的行货手机不能搭载gms。&br&&br&如此导致了android应用本应使用的推送机制gcm/fcm不可用，到目前为止没有统一的推送服务。
这个问题仅是我国内地专有的故障，与Android本身无关。 具体地说，gms服务内地不可用，且这个内地销售的行货手机不能搭载gms。 如此导致了android应用本应使用的推送机制gcm/fcm不可用，到目前为止没有统一的推送服务。
我是某公司的Android程序开发。&br&&br&一般情况下讨论用不用GCM，首先需要明确GCM的适用范围，然后我就去查GCM的详细信息，链接如下：&br&&a href=&///?target=https%3A///google/gcm/index.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Google Cloud Messaging for Android&i class=&icon-external&&&/i&&/a&&br&&br&看完功能介绍，感觉好棒！&br&赶快找设计师，设计师也说，“好棒！能不能看下有没有什么限制，毕竟中国对谷歌的服务限制很多。”&br&&br&赶快屁颠屁颠地去继续查文档，服务器有人管，我客户端就看客户端的内容好了，链接如下：&br&&a href=&///?target=https%3A///google/gcm/client.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Implementing GCM Client on Android&i class=&icon-external&&&/i&&/a&&br&&br&看到了下面这么一段：&br&&blockquote&&p&Here are the requirements for running a GCM Android client:&/p&&ul&&li&At a bare minimum, GCM requires devices running Android 2.2 or higher that also have the Google Play Store application installed, or an emulator running Android 2.2 with Google APIs. Note that you are not limited to deploying your Android applications through Google Play Store.&/li&&li&However, if you want to continue to use new GCM features that are distributed through Google Play Services, the device must be running Android 2.3 or higher, or you can use an emulator running Android 2.3 with Google APIs.&/li&&li&On Android devices, GCM uses an existing connection for Google services. For pre-3.0 devices, this requires users to set up their Google accounts on their mobile devices. A Google account is not a requirement on devices running Android 4.0.4 or higher.&/li&&/ul&&/blockquote&&b&翻译：&/b&&br&&div class=&highlight&&&pre&&code class=&language-text&&以下是Android客户端能运行GCM的条件：
1. 最低配置，Android系统2.2及以上并且同时安装有Google Play应用商店，或者是使用了GoogleAPIs，系统在2.2及以上的Android模拟器。请注意你不会被限制需要适用Google Play应用商店来下载App；
2. 然而，如果你想继续通过Google Play Services使用后续的GCM的新特性，设备系统必须等于或高于Android2.3（偷懒，模拟器相关支持就不翻译了）；
3. 在Android设备上，GCM使用Google Services上存在的一个连接。对于3.0之前的设备，需要用户在移动设备上设置好谷歌账号。在Android4.0.4及以上版本则不需要谷歌账号。
&/code&&/pre&&/div&&br&我不要新服务我对账号没要求我只要最低配置，即使只看完第一条我也就Oh shit了，2.2系统完全没问题，问题是国内的手机能有几台安装了Google Play呢（包括后期自己装的）？！&br&这时不是很Geek又懒（买国行Android还不刷机）的我还抱着点希望，打开我买的某国外品牌Android机的国行版本，下载了一个Google Services（Google Play依赖Google Services，没Services时Google Play无法正常使用），然后这个Services就不停地循环报崩溃...崩溃...崩溃...崩溃...然后我就崩溃了（卸掉）！&br&&br&再次找到设计师，不行诶，必须要Google Play支持，但我的手机就不支持...设计师一脸黑线“那不行啊，这么搞的话国内至少一半手机用不了，推送量直接大降我能忍老板也不能忍啊！”&br&&br&&b&于是GCM就此无限期搁置......&/b&&br&&br&－－－－－－－－－－－－－－－补充分割－－－－－－－－－－－－－－－&br&有人提议双推送机制，有GCM用GCM，没有的时候再用Service。&br&答：对于绝大多数Android程序员来说（包括我），这是很无聊的一件事，需求有不少，还有好多BUG等着解，除非特别有必要，否则才懒得搞两套机制。&br&&br&什么，设计师问上述方案能不能实现？&br&能啊，So easy，但你看我还有这么多需求等着实现，这么多BUG等着解，设计师你提个Task吧，Task优先级标记为Low，等俺未来（不知多少年以后）再来实现吧！
我是某公司的Android程序开发。 一般情况下讨论用不用GCM，首先需要明确GCM的适用范围，然后我就去查GCM的详细信息，链接如下：
看完功能介绍，感觉好棒！ 赶快找设计师，设计师也说，“好棒！能不能看下有没有什么限制…
已有帐号？
无法登录？
社交帐号登录}