简历及时处理率
简历处理用时
企业最近登录
交响圈是箭扣科技Arrownock基于IM++云服务平台打造的一系列模板化社交场景，包含朋友圈、聊天圈、论坛圈、客服圈、自媒圈、公告圈等六大常用的社交模版！在APP中嵌入适合业务特点的交响圈模板，实现经典社交图谱结构的有机表现，让每个APP都能快速实现连接用户、取悦用户、活跃用户的诉求！
IM++为APP开发提供了一站式、最专业、最好用的社交SDK公有云服务。
anPushi及时、准确、高效双向的消息推送服务。
anSocial支持复杂交互类型，具有丰富展现形可提供式的消息墙服务。
anIm提供可靠、高效、支持丰富传输格式的即时消息服务。
交响圈原生移动应用 IM++&
现已开放内测（内测名额100名），提供App源代码下载使用，立刻为你的App实现移动社交功能。
箭扣科技Arrownock名自北京最原味的长城片段，寓意将烽火台与现代通讯技术衔接和延承。作为一站式移动社交云服务提供商，箭扣科技的IM++云平台提供推送、提醒、即时通讯、分享、朋友圈等社交功能，交响圈APPO将这些功能集合成六大业务模版。通过API和SDK等云计算和云服务方式，帮助开发者和企业在自己的App中，便捷快速地实现朋友圈、聊天、论坛、客服、自媒、公告等六大常用业务情景。
由箭扣科技 Arrownock 官方打造，集即时通讯、推送、朋友圈、分享、聊天、论坛、公告、客服等各种社交功能于一身，SMaaS核心功能展示的开源移动应用——IM++ 2.2版本正式全新发布！
发布“交响圈”社交模版品牌，从此移动社交进入模版化时代，帮助APP取悦用户，活跃用户！
发布IM++云服务品牌，包含anPush, anIM, anWall, anSocial 后台服务。
发布SMaaS云服务产品线，包含Push，IM。
无社交，不App？Arrownock帮助开发者快速搭建应用社交体系，试图成为应用市场又一个“卖水者&
该公司近2个月内未收到过面试评价
北京市，大兴区
北京绿地财富中心
北京市，朝阳区
北京市朝阳区霞光里66号远洋新干线A座
该公司共有 2 个地址
公司基本信息
移动互联网
CEO, Founder
徐旸，北京箭扣科技有限公司CEO&联合创始人。第一代J2EE Server的开发者，曾任Sybase研发总监，Appcelerator中国区总裁。在美创业经历丰富，涉及领域包括技术咨询、医疗外包、移动云服务。
今天已经反馈足够多了，给产品经理点时间消化下吧~
&&反馈提交成功！
你还没填任何反馈呢杭州英语导游服务热线：& &&
Language--
日本ZEnglish 한국의Fran&aiseDeutschРусскийEspa&olItalianoPortuguêsالعربيةไทยTiếng ViệtBahasa MalaysiaBahasa Indonesia
选择目的地
选择导游语种
您现在的位置：&>&&>&
箭扣长城英语介绍Jiankou Great Wall (Arrow Nock)
If you look carefully at the recent published Great Wall photographic works, you will quickly find that most of the pictures are taken from Jiankou Great Wall. Due to its unique style, steep mountains and beautiful scenery, Jiankou Great Wall has become a photographic hotspot and also a hot travel destination these days. 'Jiankou', is translated as 'Arrow Nock' in English, because the shape of the mountain is like an arrow, with the collapsed ridge opening as its arrow nock.
Located in the mountain ridge of Xizhazi Village, about 30km (19 miles) to Huairou County in Beijing, Jiankou Great Wall was an important section of the wall in Ming Dynasty (1368 - 1644). Owing to the need for renovation, the wall is regarded as one of the most dangerous sections of the Ming's wall. It connects to Mutianyu in the east and joins Huanghuacheng in the west. From east to north, the wall zigzags 9.3 miles from 'The Ox Horn Edge Wall' to 'The Nine-Eye Tower' via 'The Beijing Knot'. Compared with Mutianyu Great Wall, the mountain is higher and steeper, while compared with Simatai Great Wall, it is more winding and varied. It was built from the local material - dolomite. The large pieces of white rock make the wall striking to the eye at a distance.
There are many famous sections of Jiankou Great Wall, such as 'The Nine-Eye Tower', an important command post during the ancient wars. It has three layers, and there are nine holes which look like nine eyes on each side. 'The Beijing Knot' is the meeting point for three walls coming from different directions. 'The Sky Stair', is a precipitous stair whose angle of elevation is 70 to 80 degrees. It leads to 'The Eagle Flies Facing Upward', a watch tower built on the lofty peaks. It is so dangerous that even eagles have to fly facing upward to reach the top. 'Zhengbei Tower' is the right place to appreciate the beauty of the sunrise and the sunset.
旅游百宝箱
Copyright &
QianDaoHu. All rights reserved& 杭州英语导游
外语导游翻译网|杭州英语导游& 地址：中国&浙江&杭州
&杭州英语导游网备案号：浙ICP备号-3&&
</iframe＞&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系统，很有幸我担当了这个…
刚好对 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 除了 即时通讯，还有 统计分析、消息推送、数据存储…
我来答一个，从实际客户角度看，你去看他们官网最下面，合作伙伴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案例的介绍腾讯信鸽肯定不行，没人用，你看他自己主页的合作伙伴，是腾讯分析和腾讯云，没其他第三方了，腾讯自己的业务，为何没微信？然后百度， ，案例，百科，gi…
我是融云的 CTO，LeanCloud 是一家令人敬仰的公司，我个人也是 LeanCloud 的粉丝。&br&LeanCloud 和融云在即时通讯服务方面主要的不同在于：LeanCloud 提供的是一个更加抽象的实时通讯服务，可以非常灵活的实现各种功能场景，这是最大的优势；而融云对即时通讯功能做了非常高级的封装，可以说完全是面向即时通讯业务的，而且提供了开箱即用的界面组件，无疑大大降低了开发成本和门槛。&br&成本角度，融云无论用户量多大，全部是免费的，一些增值服务才付费。&br&以 40 万日活计算，融云成本为零；LeanCloud 是 1.2 万元/月，环信是 2 万元/月。
我是融云的 CTO，LeanCloud 是一家令人敬仰的公司，我个人也是 LeanCloud 的粉丝。LeanCloud 和融云在即时通讯服务方面主要的不同在于：LeanCloud 提供的是一个更加抽象的实时通讯服务，可以非常灵活的实现各种功能场景，这是最大的优势；而融云对即时通讯…
用数据来说话吧，以下是我们自己做的推送到达率测试，测试方法是客户端收到推送后立即向我们自己的服务器发送一个回执请求，以下数据仅供参考：&br&&br&1. 三月份时做的个推、百度、极光这三家的推送到达率的对比：&br&&br&&br&&b&服务商
测试时间&/b&&br&&b&个推
3-13&/b&&br&&b&百度
3-13&/b&&br&&b&极光
3-13&/b&&br&&br&测试说明&br&(1) 3家推送的用户群都是同一个抽样群；&br&(2) 3家的推送是同时进行的；&br&(3) 推送前，我们已经在个推和极光的VIP通道中了，而百度推送是承诺不做限制的，所以排除了服务商限制的可能性；&br&&br&我们当时做了至少3次这样的实验，不同时段的，结果均与以上吻合。所以，我们最终选择了极光推送。&br&&br&2. 前几天做了百度和极光的推送到达率的对比，这次选择的也是同一个用户抽样群，但是用户数量大了很多，结果如下：&br&&br&&b&服务商
测试时间&/b&&br&&b&极光
7-5&/b&&br&&b&百度
7-5&/b&&br&&br&这样的实验连续做了好几天，都和上面的数据差不多，可以看出，极光的效果是远好于百度的。&br&&br&注：第二个对比的推送到达率之所以比第一个低很多，主要是因为有些用户已经把软件卸载了。&br&&br&除了推送到达率，我们还比较了token上传的成功率，个推和百度的差不多，都在90%&br&左右，即100个设备中有90个设备可以取到唯一token，而极光的值是96%-97%，在这一点上，极光也强于个推和百度。而在后台系统、报表统计、API易用性上，以三月份当时的情况来看（三月份选定极光之后就没有关注其余两个了），个推是做的最好的，百度做的最差，很难用，可能和当时百度推送刚出来不久有关吧，不知道现在做的怎么样了，极光介于两者之间。&br&&br&过段时间打算做一下爱心推送、友盟推送、极光推送这三家的对比:)
用数据来说话吧，以下是我们自己做的推送到达率测试，测试方法是客户端收到推送后立即向我们自己的服务器发送一个回执请求，以下数据仅供参考：1. 三月份时做的个推、百度、极光这三家的推送到达率的对比：服务商 推送数 回执数 到达率 测试时间个推 10w 29…
看了楼上某位同学的回复后，环信和LeanCloud都试了下。&br&在这两个中，个人推荐LeanCloud。&br&&br&一、消息送达速度，在wifi环境下都能在秒级送达。暂时没有在各种恶劣条件下测试。&br&&br&二、如果是你自己有用户系统的话，环信的解决方案是你先跑个脚本申请十万个环信ID，然后在自己的后台把你自己的ID和环信ID关联起来............................;&br&而LeanCloud可以用任意的字符串作为ID来发送和接收（ID在自己的应用内唯一就行）。&br&&br&三、关于权限的控制，如果没有这种控制的话如果ipa或apk被解析的话不怀好意的人是可以随意给你们的用户系统发消息的。LeanCloud的解决方案也更优雅，在发送消息前需要watch对方，可以通过自己在后台来控制是否允许&br&环信类似的是好友系统，但缺点是不像LeanCloud的可以控制只允许单向发送，环信的官方文档上说大多数情况下没必要用好友系统来控制权限。&br&&br&四、LeanCLoud还支持推送、文件、统计等服务。环信只有IM方面。不说其他，推送模块基本是国内Android客户端的标配（天国的GCM)，如果用环信的话还得另找个Android推送方案，不过环信的官方文档里也说这样不会多消耗太多的手机电量。&br&&br&五、LeanCloud支持CocasPods,环信不支持。LeanCloud看着专业点。
看了楼上某位同学的回复后，环信和LeanCloud都试了下。在这两个中，个人推荐LeanCloud。一、消息送达速度，在wifi环境下都能在秒级送达。暂时没有在各种恶劣条件下测试。二、如果是你自己有用户系统的话，环信的解决方案是你先跑个脚本申请十万个环信ID，然…
Google 有提供类似的推送系统叫 C2DM，要求是要Android2.2以上，必须有安装Google Play并且有Gmail帐号登录。第一个条件现在大部分Android 手机都可以满足，第二个条件国内所有行货基本都不满足，刷过第三方ROM的手机也都大部分把Google的服务给阉割掉了。即便满足前面两个条件，在我们国家，Google的服务器也会抽风。 &br&&br&很多的Android应用都自己实现一套，在后台启动一个进程，与自己的服务器建立长链接来实现推送的功能，像QQ，微信，等等。&br&由于各程序自己实现，各种的Notification弹出框也不一致，没有iphone上的那种一致的体验。同时，一部手机也会运行着N多的后台进程，浪费电，浪费内存，浪费流量。
Google 有提供类似的推送系统叫 C2DM，要求是要Android2.2以上，必须有安装Google Play并且有Gmail帐号登录。第一个条件现在大部分Android 手机都可以满足，第二个条件国内所有行货基本都不满足，刷过第三方ROM的手机也都大部分把Google的服务给阉割掉了。…
&p&选择IM云服务供应商，其实最重要是有三个因素：费用、技术稳定性、以及后续运维服务。&br&&/p&&br&&p&对于不少创业公司来讲，可能需要找到成本和稳定性的最佳平衡点。目前国内不少IM云服务产品都推出了免费服务项目或者一定期限内的试用。几大主流的IM云服务供应商如下：&/p&&br&&p&&b&阿里悟空：&/b&今年刚刚推出不久，目前为吸引用户，对外免费。据称产品稳定成熟后会探索收费策略。不过近期也有消息传出阿里或将撤销该业务，甚至有论坛曝出其已经停止维护：&/p&&img src=&/ce1bfe1e4c1f_b.png& data-rawwidth=&554& data-rawheight=&314& class=&origin_image zh-lightbox-thumb& width=&554& data-original=&/ce1bfe1e4c1f_r.png&&&br&&p&&b&网易云信&/b&：提供两个月的免费试用。功能较为完善，覆盖IM基础功能以及基于三大通讯运营商的短信、电话等服务，属于网易to B业务的重要项目，倾向于打造收费且稳定的服务品质。&/p&&p&&b&腾讯云：&/b&11月份推出云通讯解决方式，主要提供IM基础功能。可以申请免费试用，但每天有名额限制。&/p&&p&&b&融云：&/b&IM基础服务免费，例如聊天、通话等基础功能。高阶功能收费。&/p&&p&&b&环信、亲加&/b&：根据App日活用户的规模收费，一定日活规模以下免费，达到一定规模，日活用户数量越多，费用越高。&/p&&p&&b&容联云通讯&/b&：IM服务免费，使用平台上其他服务时收费。&/p&&img src=&/dea8b2c785dd_b.png& data-rawwidth=&554& data-rawheight=&354& class=&origin_image zh-lightbox-thumb& width=&554& data-original=&/dea8b2c785dd_r.png&&&p&如果从产品背景来划分，可以说，网易、腾讯、阿里推出的IM云服务属于这个市场上的巨头级产品，尤其腾讯和网易，有着十余年的IM开发运维经验，比较成熟。而融云、环信、亲加、容联云则属于创业公司级产品，多数融资到A轮，为吸引客户做出的免费力度也是最大。&/p&&br&&p&作为资金紧缺的创业公司，可以通过各家开放的免费项目进行测试，从而选择性价比最高的。而对于想要长远发展的产品来说，免费的服务恐怕不能作为长期的IM功能支持，收费且稳定的大公司级产品应该作为重点考虑。&/p&&br&&p&&b&云服务后期技术支持有多重要？&/b&&/p&&br&&p&市场上众多的IM云服务，仅从表面的功能介绍来看，很难判定谁更靠谱。但是当互联网巨头开始进入这个市场后，其带给创业公司的竞争压力就需要做考虑在内，毕竟互联网行业风云变幻，“B轮死”的现象很常见。&/p&&br&&p&另外，凡是接入过IM云服务的开发者都知道，接入IM云服务是很简单的事，基本上1-3天内即可完成接入。但比接入和技术本身更重要的往往是“后期维护”，牵涉到出个问题你能不能找到人、对方技术人员配备是否完善。上述论坛曝光的阿里悟空后期找不到人员维护就会对开发者造成很大损失，甚至造成宕机，影响用户体验。一些创业公司也经常面临人员缺乏的问题。&/p&&br&&p&所以我们才看到，网易推出云信之时，就为其配备了300位资深技术和运维工程师，7*24小时实时运维监控，全天候响应。这在市场上是比较受开发者认可的一点。&/p&&img src=&/14d88a32bf9c3ba01f0ac_b.png& data-rawwidth=&554& data-rawheight=&237& class=&origin_image zh-lightbox-thumb& width=&554& data-original=&/14d88a32bf9c3ba01f0ac_r.png&&&br&&p&拿创业公司里的佼佼者融云、环信和巨头公司的网易云信做比较，有人专门做了评测：《&a href=&///?target=http%3A///4461294.shtml& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&3款IM云服务产品对比 即时通讯云产品横向评测&i class=&icon-external&&&/i&&/a&》&br&&/p&&br&&p&由评测可以看出，在功能上三家各有优劣，但在服务上，网易云信更胜一筹，融云和环信官网上甚至没有找到在线客服的入口。&/p&&br&&img src=&/01d24efb61a09a78ff1504f_b.png& data-rawwidth=&554& data-rawheight=&253& class=&origin_image zh-lightbox-thumb& width=&554& data-original=&/01d24efb61a09a78ff1504f_r.png&&&br&&p&&b&总结：&/b&对于创业公司来说，需不需要接入IM云服务、以及IM云服务能给自己的APP带来哪些变化，可以通过市场上不少免费项目和试用进行测试。一旦准备接入，那么就要做长久打算。天下没有免费的午餐，长远来看，收费且能保证服务品质的巨头级产品将成为选择趋势，也唯有通过收费协议，才能保证产品方精心打造技术力量，提升服务品质。&/p&
选择IM云服务供应商，其实最重要是有三个因素：费用、技术稳定性、以及后续运维服务。对于不少创业公司来讲，可能需要找到成本和稳定性的最佳平衡点。目前国内不少IM云服务产品都推出了免费服务项目或者一定期限内的试用。几大主流的IM云服务供应商如下：阿…
&img src=&/afb0a466d93fffb0c224377_b.jpg& data-rawheight=&144& data-rawwidth=&720& class=&origin_image zh-lightbox-thumb& width=&720& data-original=&/afb0a466d93fffb0c224377_r.jpg&&
&p&&b&安卓平台商最好的服务：Google Cloud Messageing&/b&&/p&&p&Google在Android上标配了自己的推送GCM（Google Cloud Messageing），可以帮助开发人员给他们的Android应用程序发送数据。它是一个轻量级的消息，告诉Android应用程序有新的数据要获取从服务器，或者它可能是一个消息，其中包含了4KB的payload data（像即时通讯这类应用程序可以直接使用该payload消息）。GCM服务处理排队的消息，并把消息传递到目标设备上运行的Android应用程序。&/p&&p&GCM的推送消息的流程如下图：&/p&&p&GCM服务的步骤Google已经在&a href=&///?target=http%3A///guide/google/gcm/gs.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Getting Started&i class=&icon-external&&&/i&&/a&给出了，只要参照着做就行了，我就不再赘述了。&/p&&p&GCM使用比较简单，而且Google的服务器来处理负载均衡、消息队列处理。但有下面三个缺陷也导致了GCM在国内基本不可用：&/p&&p&1)GCM要求Android系统必须是2.2以上的版本，所以对于不少2.2以前的系统没法推送&/p&&p&2)国内服务不稳定。而且不少国内的终端厂商纷纷把Google的服务去掉，替换上自己的。&/p&&p&3)需要用户绑定Google账号，但不少国内用户没有Google账号。&/p&&br&&p&&b&但是但是，重要的是但是，谷歌的服务基本没法在国内使用。&/b&&/p&&br&&p&再来看第三方的推送服务。&/p&&p&目前有不少第三方提供了类似服务，客户端只需要嵌入第三方提供的lib库，由第三方建立长连接，负责消息的接收/发送。同时对于消息都有比较详细的报表数据，可以用于做数据分析挖掘和用户体验的改善。目前比较成熟的有：parse、pubnub、蝴蝶、个推等。国外的parse、pubnub做的很不错，基本版也是免费的，但是国外的服务在国内经常访问不了。国内的靠谱的不多&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&个推&i class=&icon-external&&&/i&&/a&的接入比较简单，新浪微博android上的推送也是他们做的，但和parse比起来用户体验上还有待提升。&/p&
安卓平台商最好的服务：Google Cloud MessageingGoogle在Android上标配了自己的推送GCM（Google Cloud Messageing），可以帮助开发人员给他们的Android应用程序发送数据。它是一个轻量级的消息，告诉Android应用程序有新的数据要获取从服务器，或者它可能是…
个推， 业内做推送挺牛的，大客户都是他们家的
个推， 业内做推送挺牛的，大客户都是他们家的
推荐，leancloud。&br&至于为什么，看文档就知道了。
推荐，leancloud。至于为什么，看文档就知道了。
1、推荐一种IM服务架构&br&&img src=&/19c06afad76bd47cae64f1d624d798b8_b.png& data-rawwidth=&1040& data-rawheight=&563& class=&origin_image zh-lightbox-thumb& width=&1040& data-original=&/19c06afad76bd47cae64f1d624d798b8_r.png&&&br&2、可以实现的基础功能&br&&img src=&/cebf778abc5d_b.png& data-rawwidth=&1147& data-rawheight=&688& class=&origin_image zh-lightbox-thumb& width=&1147& data-original=&/cebf778abc5d_r.png&&&br&3、关于IM的一点想法&br&1）成本高&br&&img src=&/958be031e1a1d2e6e3fd9b_b.png& data-rawwidth=&1055& data-rawheight=&500& class=&origin_image zh-lightbox-thumb& width=&1055& data-original=&/958be031e1a1d2e6e3fd9b_r.png&&&br&2）稳定性差&br&im这块做起来不难，几个工程师花个十天半个月就能做出一套系统来。但是做过IM 的工程师一般不会去做，因为im拾是个坑，功能不全面，而且很容易出bug，比如消息到达不及时、消息记录看不到，尤其是用户量起来后，问题会更多，这个坑很难填完。&br&&br&自己做im稳定性差，除非经验非常丰富。这个感悟是我的两个经历得出的感悟：&br&a.我曾经做过，产品，参与到了一个平台性的产品开发，初期这个产品是团队自研的，功能本身不全面，后来用户越来越多，im这块问题也原来越多，而且影响到了整个web端和移动产品的开发进程&br&b.我后来的工作就是为开发者提供im服务，有很多开发者联系到我们说本来自己做的im，做好之后问题很多。
1、推荐一种IM服务架构2、可以实现的基础功能3、关于IM的一点想法1）成本高2）稳定性差im这块做起来不难，几个工程师花个十天半个月就能做出一套系统来。但是做过IM 的工程师一般不会去做，因为im拾是个坑，功能不全面，而且很容易出bug，比如消息到达不及…
&a href=&///?target=http%3A///14/1128/16/AC5EAG4B001618JV.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&环信致开发者和同业者的一封信&i class=&icon-external&&&/i&&/a&&br&&br&&br&3、 环信的服务确实出现过问题，对此我们是一贯坦诚承认，也是本着对开发者负责任的态度诚实沟通、尽快解决的。11月8日，环信发生了一次“因升级新功能造成系统登录问题”，并不是抹黑者所说的“宕机”。问题发生后，环信技术团队尽快定位并修复了问题。问题发生原因是近期环信新增功能较多，线上版本迭代过于频繁。环信的核心研发工程师大多来自于敏捷开发和开源软件开发背景，信奉产品快速迭代，测试驱动，但对新功能的系统测试，压力测试级别的测试覆盖不足。环信的工程师们对这次问题作了深刻的检查，近期会适度控制新功能上线节奏，并确保严格可靠的新功能测试和上线流程。解决问题后环信并没有掩盖事实，向客户逐一做出了真诚解释和致歉。&br&&br&响应行业自律，友商协同发展。
3、 环信的服务确实出现过问题，对此我们是一贯坦诚承认，也是本着对开发者负责任的态度诚实沟通、尽快解决的。11月8日，环信发生了一次“因升级新功能造成系统登录问题”，并不是抹黑者所说的“宕机”。问题发生后，环信技术…
即时通讯IM工具，目前已知的服务及收费方式：&br&&b&一、专业第三方IM&/b&&br&LeanCloud（按需收费）&br&&a href=&///?target=https%3A//& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&LeanCloud&i class=&icon-external&&&/i&&/a&&br&融云（免费+收费）&br&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&融云即时通讯云&i class=&icon-external&&&/i&&/a&&br&环信（免费+收费）&br&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&环信-即时通讯云领导者&i class=&icon-external&&&/i&&/a&&br&云之讯（免费+收费）&br&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&云之讯—融合通讯开放平台让通讯更简单&i class=&icon-external&&&/i&&/a&&br&&br&&b&二、互联网巨头IM&/b&&br&&p&腾讯云通信IM（暂时免费）&br&&/p&&a href=&///?target=http%3A///product/im.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&云通信 IM - 腾讯云&i class=&icon-external&&&/i&&/a&&br&阿里云旺（免费）&br&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&云旺OpenIM即时通讯&i class=&icon-external&&&/i&&/a&&br&阿里悟空（暂时免费）&br&&a href=&///?target=https%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&阿里悟空 - 移动基础服务平台&i class=&icon-external&&&/i&&/a&&br&网易云信（按需收费）&br&&a href=&///?target=http%3A//netease.im/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&网易云信|真正稳定的IM即时通讯云服务&i class=&icon-external&&&/i&&/a&&br&&br&这些只是其中的一部分，名单有待于更新。
即时通讯IM工具，目前已知的服务及收费方式：一、专业第三方IMLeanCloud（按需收费）融云（免费+收费）环信（免费+收费）云之讯（免费+收费）二、互联网巨头IM腾讯云通信…
找专业一点的第三方来提供对应的技术解决方案呗，像国内就有好几家做推送的，像比较大一点的个推，还有极光、百度以及楼上说的信鸽都是不错的选择，本人目前用的是个推，朋友介绍了用的，感觉是不错的，基本能解决你担心的这些问题
找专业一点的第三方来提供对应的技术解决方案呗，像国内就有好几家做推送的，像比较大一点的个推，还有极光、百度以及楼上说的信鸽都是不错的选择，本人目前用的是个推，朋友介绍了用的，感觉是不错的，基本能解决你担心的这些问题
楼上的知友回答的很好，我补充一点：云巴 &a href=&///?target=http%3A//Yunba.io& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&Yunba.io&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& 也有 IM 功能，比较普遍的应用场景在于 APP 内的社交功能实现，包括私信、群聊、客服等等。除此之外，云巴还提供推送、实时分析、跨设备通讯功能。&br&&br&云巴是基于Erlang/OTP开发的，协议是最精简的MQTT，这种架构和语言的特点是超高并发、易扩展、节省70%以上的流量和耗电量。WhatsApp也是用的 Erlang。&br&&br&目前已有多个千万级和百万级应用使用云巴，欢迎大家测试并提出宝贵意见。&a href=&///?target=http%3A//yunba.io& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&yunba.io&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&
楼上的知友回答的很好，我补充一点：云巴
也有 IM 功能，比较普遍的应用场景在于 APP 内的社交功能实现，包括私信、群聊、客服等等。除此之外，云巴还提供推送、实时分析、跨设备通讯功能。云巴是基于Erlang/OTP开发的，协议是最精简…
谢邀。我主要用腾讯的信鸽推送，还考虑过小米推送。&br&&br&国内的推送SDK不是很好，权限一般要的都很多。我主要就是指信鸽，我们的应用就要七八个权限，其他的十来个全都是信鸽的要的，恶心死人，小米推送的SDK就好得多，就要几个基础的，不知道现在如何了。
谢邀。我主要用腾讯的信鸽推送，还考虑过小米推送。国内的推送SDK不是很好，权限一般要的都很多。我主要就是指信鸽，我们的应用就要七八个权限，其他的十来个全都是信鸽的要的，恶心死人，小米推送的SDK就好得多，就要几个基础的，不知道现在如何了。
核心业务如果不是 IM 不到百万级在线的规模没必要自己搞 IM 基础架构。&br&一大票做云通讯，多问问，几家都写个测试应用自己选型吧。别说开发，各种运维问题就不是小团队搞得定的。&br&网络层：&br&xmpp 在 cellular network 上坑很大，除了3G 各种问题，现阶段还有一大票 移动的 2.5 G
。&br&TCP 的问题很多，UDT 怎么样具体不知道，有没有百度hi 的同学来现身说法。&br&客户端：&br&客户端 ios 还好，android 上各种山寨机不是小团队搞的过来的。实时语音这块没经验天知道坑有多深。&br&服务端：&br&c1000k 看看就算了，真跑业务 单台 gateway
c100k 能稳当就要笑死了。&br&&br&IM 对有分布式系统经验的架构师来说是个很简单明了的业务，但工程量很大。运营的问题比开发的问题多的多。
核心业务如果不是 IM 不到百万级在线的规模没必要自己搞 IM 基础架构。一大票做云通讯，多问问，几家都写个测试应用自己选型吧。别说开发，各种运维问题就不是小团队搞得定的。网络层：xmpp 在 cellular network 上坑很大，除了3G 各种问题，现阶段还有一大…
如果采用应用内的推送通道，应用被清理掉了，推送肯定没法及时了。&br&和 iOS 一样采用系统级推送就好了，可惜 Android 从一开始就没设计好这个环节。
如果采用应用内的推送通道，应用被清理掉了，推送肯定没法及时了。和 iOS 一样采用系统级推送就好了，可惜 Android 从一开始就没设计好这个环节。
已有帐号？
无法登录？
社交帐号登录}