谁能举个通俗易懂的例子告诉我IAAS，SAAS，PAAS的区别_百度知道
谁能举个通俗易懂的例子告诉我IAAS，SAAS，PAAS的区别
我有更好的答案
IaaS: Infrastructure-as-a-Service（基础设施即服务）
第一层叫做IaaS，有时候也叫做Hardware-as-a-Service，几年前如果你想在办公室或者公司的网站上运行一些企业应用，你需要去买服务器，或者别的高昂的硬件来控制本地应用，让你的业务运行起来。
但是现在有IaaS，你可以将硬件外包到别的地方去。IaaS公司会提供场外服务器，存储和网络硬件，你可以租用。节省了维护成本和办公场地，公司可以在任何时候利用这些硬件来运行其应用。
一些大的IaaS公司包括Amazon, Microsoft, VMWare, Rackspace和Red Hat.不过这些公司又都有自己的专长，比如Amazon和微软给你提供的不只是IaaS，他们还会将其计算能力出租给你来host你的网站。
PaaS: Platform-as-a-Service（平台即服务）
第二层就是所谓的PaaS，某些时候也...
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁&&&&&& 它们之间的关系主要可以从两个角度进行分析：其一是用户体验角度，从这个角度而言，它们之间关系是独立的，因为它们面对不同类型的用户。其二是技术角度，从这个角度而言，它们并不是简单的继承关系(Saa.....
三种服务模式
根据现在最常用，也是比较权威的NIST(National Institute of Standards and Technology，美国国家标准技术研究院)定义，云计算主要分为三种服务模式，而且这个三层的分法重要是从用户体验的角度出发的：
Software as a Service，软件即服务，简称SaaS，这层的作用是将应用作为服务提供给客户。
Platform as a Service，平台即服务，简称PaaS，这层的作用是将一个开发平台作为服务提供给用户。
Infrastructure as a Service， 基础设施即服务，简称IaaS，这层的作用是提供虚拟机或者其他资源作为服务提供给用户。
&注：此图不是原文配图&
一、SaaS模式
通过SaaS这种模式，用户只要接上网络，并通过浏览器，就能直接使用在云端上运行的应用，而不需要顾虑类似安装等琐事，并且免去初期高昂的软硬件投入。SaaS主要面对的是普通的用户。
主要产品包括：Salesforce Sales Cloud，Google Apps，Zimbra，Zoho和IBM Lotus Live等。
谈到SaaS的功能，也可以认为是要实现SaaS服务，供应商需要完成那些功能?主要有四个方面：
随时随地访问：在任何时候或者任何地点，只要接上网络，用户就能访问这个SaaS服务。
支持公开协议：通过支持公开协议(比如HTML4/5)，能够方便用户使用。
安全保障：SaaS供应商需要提供一定的安全机制，不仅要使存储在云端的用户数据处于绝对安全的境地，而且也要在客户端实施一定的安全机制(比如HTTPS)来保护用户。
多住户(Multi-Tenant)机制：通过多住户机制，不仅能更经济地支撑庞大的用户规模，而且能提供一定的可定制性以满足用户的特殊需求。
二、PaaS模式
通过PaaS这种模式，用户可以在一个包括SDK，文档和测试环境等在内的开发平台上非常方便地编写应用，而且不论是在部署，或者在运行的时候，用户都无需为服务器，操作系统，网络和存储等资源的管理操心，这些繁琐的工作都由PaaS供应商负责处理，而且PaaS在整合率上面非常惊人，比如一台运行Google App Engine的服务器能够支撑成千上万的应用，也就是说，PaaS是非常经济的。PaaS主要的用户是开发人员。
主要产品包括：Google App Engine，，heroku和Windows Azure Platform等。
为了支撑着整个PaaS平台的运行，供应商需要提供那么功能?主要有四大功能：
友好的开发环境：通过提供SDK和IDE等工具来让用户能在本地方便地进行应用的开发和测试。
丰富的服务：PaaS平台会以API的形式将各种各样的服务提供给上层的应用。
自动的资源调度：也就是可伸缩这个特性，它将不仅能优化系统资源，而且能自动调整资源来帮助运行于其上的应用更好地应对突发流量。
精细的管理和监控：通过PaaS能够提供应用层的管理和监控，比如，能够观察应用运行的情况和具体数值(比如，吞吐量和反映时间)来更好地衡量应用的运行状态，还有能够通过精确计量应用使用所消耗的资源来更好地计费。
三、IaaS模式
通过IaaS这种模式，用户可以从供应商那里获得他所需要的虚拟机或者存储等资源来装载相关的应用，同时这些基础设施的繁琐的管理工作将由IaaS供应商来处理。IaaS能通过它上面对虚拟机支持众多的应用。IaaS主要的用户是系统管理员。
主要产品包括：Amazon EC2，Linode，Joyent，Rackspace，IBM Blue Cloud和Cisco UCS等。
IaaS供应商需要在那些方面对基础设施进行管理以给用户提供资源?或者说IaaS云有那些功能?在《虚拟化与云计算》中列出了IaaS的七个基本功能：
资源抽象：使用资源抽象的方法(比如，资源池)能更好地调度和管理物理资源。
资源监控：通过对资源的监控，能够保证基础实施高效率的运行。
负载管理：通过负载管理，不仅能使部署在基础设施上的应用运能更好地应对突发情况，而且还能更好地利用系统资源。
数据管理：对云计算而言，数据的完整性，可靠性和可管理性是对IaaS的基本要求。
资源部署：也就是将整个资源从创建到使用的流程自动化。
安全管理：IaaS的安全管理的主要目标是保证基础设施和其提供的资源能被合法地访问和使用。
计费管理：通过细致的计费管理能使用户更灵活地使用资源。
接下来，稍微给大家介绍一下云的三种形式和云计算好处。
三种模式之间的关系
它们之间的关系主要可以从两个角度进行分析：其一是用户体验角度，从这个角度而言，它们之间关系是独立的，因为它们面对不同类型的用户。其二是技术角度，从这个角度而言，它们并不是简单的继承关系(SaaS基于PaaS，而PaaS基于IaaS)，因为首先SaaS可以是基于PaaS或者直接部署于IaaS之上，其次PaaS可以构建于IaaS之上，也可以直接构建在物理资源之上。
阅读(...) 评论()&b&看到现在还有一些人说iOS没有后台，真是可怕。&/b&&br&&br&（7.10更新：我觉得王飞的回答很有道理，是真正答题了的。）&br&&br&答题：装多了不会卡，除非rom硬件有问题（譬如前几批发货的iPhone 6plus 128G）&br&同时运行了多少个应用会影响到当前app的运行状态，但是操作系统会释放某些应用所占用的资源以适应资源不足的情况。&br&-----------&br&下面的讨论只是针对某个回答（曾经的票第一的回答）而说的，和本问题并没太大关系。&br&&br&1.后台&br&iOS现在有&Background service&，不信你打开 设置-通用-后台应用程序刷新 ，许多应用都注册了这个Capabilities，譬如QQ（实际上QQ不需要，有推送就够了，问题来了，它注册这个服务要干嘛）&br&&br&“十分钟就被系统杀后台”是多少年前的事了。。去年WWDC就说了，系统会自动根据用户的app使用习惯而更好地为应用保留后台驻留时间。（iOS系统有自己的一个后台管理机制，在内存不足时会依据某些规则释放某些应用的内存。用户其实没必要自己手动杀后台。我玩过同学的红米，它的策略是最多8个后台应用，而且是先进先出原则。。）&br&&br&2.编译器&br&Objective-C现在用的LLVM编译器&br&&br&3.优先级&br&iOS系统是会优先响应触摸事件（UIResponder），但是不是优先处理是看开发者的意思（HIG建议优先处理，并把复杂的计算和网络任务放在另一个线程）。&br&&br&“当用户接触到iPhone的触摸屏后，iOS中所有的进程都将停止，UI线程拦截了所有的事件”，这句话完全错了好吧 照这个意思，你在知乎客户端的回答页面点击“发布”的时候你的答案提交进程不就被停止了吗 &br&&br&4.网页渲染&br&Google就是干Chrome开发的，还一直在支持苹果的webkit来源项目…谁说安卓html加载机制不好来着。。&br&&br&5.厂商优化&br&对于安卓来说问题有些特殊，因为问题可能出在“厂商负责任的进行了优化”。安卓机型太多了，厂商对各种分辨率优化了自然就有各种尺寸的资源文件，而对于某个机型，其他的优化文件成了冗余。所以嘛，许多安卓安装包比较大但里面的资源文件有许多是不需要的哇。你看吧，不优化会被骂，优化了也不行，怪谁呢？&br&对于iOS，现在也有许多不同的机型，同理一个安装包里有许多不必要的资源。苹果挺聪明的，今年推出了“App Thinning”技术。&br&&br&6.新的系统在比较老的设备上运行会有卡顿。原因有一部分是，iOS系统涉及到UI的计算都放在了主线程，而老设备对于新系统的UI计算还是有些吃力的。为此，Facebook开发了Async来优化应用在老设备上的运行能力（Github有开源），思想和游戏的节点差不多。。
看到现在还有一些人说iOS没有后台，真是可怕。（7.10更新：我觉得王飞的回答很有道理，是真正答题了的。）答题：装多了不会卡，除非rom硬件有问题（譬如前几批发货的iPhone 6plus 128G）同时运行了多少个应用会影响到当前app的运行状态，但是操作系统会释放…
一定会卡，，，&br&&br&这归根到底是个硬件问题，而非单纯软件问题，很多人只从软件的角度解释这个事情，我觉得有点离谱。&br&&br&iPhone，包括现在所有的智能机，不过就是个 CPU GPU 内存 闪存集成在一起的电脑，你用电脑做个实验，结果也能显而易见。&br&&br&装的越多，闪存就越趋于饱和状态，用过 SSD 都能理解，SSD 一旦到接近满状态时，写数据会变的慢很多，就是因为一个复写 (Rewrite) 的过程。&br&&br&如果你真的测试过 SSD，你会发现数据越满，复写性能越低，这几乎是所有 SSD 的主要性能问题了，抛开这个不谈只谈软件层面，没有意义。&br&&br&但是，这个东西是有个度的，不到阈值可能不会有明显的感觉。并且，iOS 是没有 Swap 的，它并不会出现桌面系统经常发生的系统颠簸态，它会选择直接干掉一些 App，这也就是我们熟知的 Jetsam。iOS 为什么这么做的讨论很多，重要的一点就是由于它的闪存架构其实并不利于实现 Swap，还不如牺牲软件保全硬件性能。&br&&br&说到这里，其实就比较明白了，回复中很多小容量机型用户的回答其实就已经解释这个问题。&br&&br&试想一下，当容量接近满载，一个 App 又需要大量的读写 Cache 或者写入新文件等，这时就是一个典型的 Rewrite，这时会出现什么情况相信我不用说你也能明白。&br&&br&不过，有一点也需要注意，因为本身 iPhone 硬件性能不能与普通 PC 相比，闪存性能就更低了，所以发生这种状态时，体现也可能没有普通 PC 那样明显。&br&&br&不明显不代表没有，这是软件根本解决不了的问题，在普通 PC 上，闪存至少还有 Trim 护法，这对于 闪存的性能至关重要。iPhone 上有没有我不知道，我个人判断它估计没有。但是 Android 从 4.3 开始是支持 TRIM 的，iOS 目前我无法判断。
一定会卡，，，这归根到底是个硬件问题，而非单纯软件问题，很多人只从软件的角度解释这个事情，我觉得有点离谱。iPhone，包括现在所有的智能机，不过就是个 CPU GPU 内存 闪存集成在一起的电脑，你用电脑做个实验，结果也能显而易见。装的越多，闪存就越趋…
下面是我一朋友想要学习openstack，我给他列的一个学习清单，希望对你有所帮助&br&博客：
陈沙克： &a href=&///?target=http%3A///tag/openstack/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&openstack&i class=&icon-external&&&/i&&/a&&br&
quqi99： &a href=&///?target=http%3A//blog.csdn.net/quqi99/article/details/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&如何学习OpenStack与精通OpenStack好书推荐 ( by quqi99 )&i class=&icon-external&&&/i&&/a&&br&
&a href=&///?target=http%3A//blog.csdn.net/lynn_kong/article/details/8829236& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&【OpenStack】学习OpenStack的历程--送给初学者&i class=&icon-external&&&/i&&/a&&br&
Unitedstack: &a href=&///?target=http%3A///blog/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&博客 - UnitedStack&i class=&icon-external&&&/i&&/a&&br&
IBM openstack： &a href=&///?target=http%3A///developerworks/cn/views/cloud/libraryview.jsp%3Fsort_by%3D%26show_abstract%3Dtrue%26show_all%3D%26search_flag%3D%26contentarea_by%3DCloud%2Bcomputing%26search_by%3Dopenstack%26product_by%3D-1%26topic_by%3D-1%26type_by%3D%25E6%E6%259C%%25B1%25BB%25E5%2588%25AB%26ibm-search%3D%25E6%E7%25B4%25A2& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&IBM developerWorks 中国 : Cloud computing : 文档库&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=http%3A///developerworks/cn/views/cloud/libraryview.jsp%3Fsort_by%3D%26show_abstract%3Dtrue%26show_all%3D%26search_flag%3D%26contentarea_by%3DCloud%2Bcomputing%26search_by%3Dopenstack%26product_by%3D-1%26topic_by%3D-1%26type_by%3D%25E6%E6%259C%%25B1%25BB%25E5%2588%25AB%26ibm-search%3D%25E6%E7%25B4%25A2& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&IBM developerWorks 中国 : Cloud computing : 文档库&i class=&icon-external&&&/i&&/a&&a href=&///?target=http%3A///developerworks/cn/views/cloud/libraryview.jsp%3Fsort_by%3D%26show_abstract%3Dtrue%26show_all%3D%26search_flag%3D%26contentarea_by%3DCloud%2Bcomputing%26search_by%3Dopenstack%26product_by%3D-1%26topic_by%3D-1%26type_by%3D%25E6%E6%259C%%25B1%25BB%25E5%2588%25AB%26ibm-search%3D%25E6%E7%25B4%25A2& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&sort_by=&show_abstract=true&show_all=&search_flag=&contentarea_by=Cloud+computing&search_by=openstack&product_by=-1&topic_by=-1&type_by=%E6%89%80%E6%9C%89%E7%B1%BB%E5%88%AB&ibm-search=%E6%90%9C%E7%B4%A2&i class=&icon-external&&&/i&&/a&&br&
IBM 龚永生： &br&
OpenStack官方博客： &a href=&///?target=http%3A//www.openstack.org/blog/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&The OpenStack Blog&i class=&icon-external&&&/i&&/a&&br&
&a href=&///?target=http%3A//blog.csdn.net/lin_victor/article/category/1771599& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&OpenStack - lin_victor的专栏&i class=&icon-external&&&/i&&/a& (待更新)&br&&br&其他：&br&openstack资源整理： &a href=&///?target=http%3A//blog.csdn.net/workdog/article/details/8246914& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&OpenStack资源整理（转自陈沙克）&i class=&icon-external&&&/i&&/a&&br&OpenStack 源码解读及相关：
&a href=&///?target=http%3A//yansu.org//learn-python-stevedore-module-in-detail.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&学习Python动态扩展包stevedore&i class=&icon-external&&&/i&&/a&&br&&br&进阶：&br&
OpenStack 管理员手册： &a href=&///?target=http%3A//docs.openstack.org/admin-guide-cloud/content/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&docs.openstack.org/admi&/span&&span class=&invisible&&n-guide-cloud/content/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&
OpenStack 开发手册：
&a href=&///?target=http%3A//docs.openstack.org/developer/openstack-projects.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&OpenStack Docs: Developers&i class=&icon-external&&&/i&&/a&&br&
HowTo Contribute： &a href=&///?target=https%3A//wiki.openstack.org/wiki/How_To_Contribute& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&How To Contribute&i class=&icon-external&&&/i&&/a&&br&
Final：&br&
1. 官网 + WIKI： &a href=&///?target=http%3A//www.openstack.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Home >> OpenStack Open Source Cloud Computing Software&i class=&icon-external&&&/i&&/a&&br&
2. 邮件列表： &a href=&///?target=https%3A//wiki.openstack.org/wiki/Mailing_Lists& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Mailing Lists&i class=&icon-external&&&/i&&/a&&br&
3. 源码： &a href=&///?target=https%3A///openstack& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&openstack (OpenStack) 路 GitHub&i class=&icon-external&&&/i&&/a&&br&
4. bugs， features， QA： &a href=&///?target=https%3A//launchpad.net/openstack& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&OpenStack in Launchpad&i class=&icon-external&&&/i&&/a&
（选择合适的子项目 （Projects））&br&
5. 代码审核： &a href=&///?target=https%3A//review.openstack.org/%23/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Gerrit Code Review&i class=&icon-external&&&/i&&/a&&br&
文档库： &a href=&///?target=http%3A//docs.openstack.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&OpenStack Docs: Current&i class=&icon-external&&&/i&&/a&&br&
&a href=&///?target=https%3A//wiki.openstack.org/wiki/UsingIRC& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&UsingIRC - OpenStack&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=https%3A//wiki.openstack.org/wiki/IRC& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&IRC - OpenStack&i class=&icon-external&&&/i&&/a&&br&
8. OpenStack会 + IRC： &a href=&///?target=https%3A//wiki.openstack.org/wiki/Meetings& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Meetings - OpenStack&i class=&icon-external&&&/i&&/a&
下面是我一朋友想要学习openstack，我给他列的一个学习清单，希望对你有所帮助博客： 陈沙克：
Unitedstack:
感谢邀请。&br&&br&BaaS是对前端的利好，确定无疑。&br&&br&看一看这些年B/S产品的发展，可以看出这么一个规律：页面逐渐应用化。&br&&br&从最早的B/S产品架构看，页面层属于MVC中的V，是由服务端输出的，服务端的输出结果是页面。&br&&br&［M］－［C］－［V］
浏览器&br&&br&后来逐步AJAX化了之后，也增加了一些输出数据的接口。&br&&br&［M］－［C］－［V / Data］
浏览器&br&&br&但由于现在的产品一般都带移动端了，对于iOS和Android本地应用来说，它对后端的需求是完全接口化的，这就意味着，之前的图里面，数据接口的部分还要扩大。&br&&br&举例来说，之前的页面可能这样：&br&&br&界面有一个列表，列表的初始部分是服务端查好了，用模板生成，发给浏览器，然后如果后续再有增删，通过AJAX去取增量数据。&br&&br&DAO里面有两个接口，一个是getAllItems，一个是addItem，只有addItem会包装出来暴露给前端，而getAllItems没有暴露出来，只在服务端视图模板层调用了。&br&&br&但现在来了移动端，就不同了，它是本地应用，程序在本地，数据在服务端，不可能在服务端渲染模板了，只能把列表数据发给服务端，这时候就得把列表查询接口也暴露出来了。&br&&br&这时候从Web端看，发现你后端已经把所有接口都暴露出来了，而且随着页面的应用化，SPA等相关技术的兴起，他也逐渐把页面改造，改成不需要后端返回HTML，而是也从接口来，逐渐地，后端就只要提供接口了。&br&&br&然后就形成了前后端的天然分离：&br&&br&后端的服务化，API化&br&前端的多样化，静态化&br&&br&对于移动端来说，它的前端是天然静态的，对于Web端来说，它的形态就逐渐变成纯静态HTML，然后整个系统的所有页面代码，都是静态的HTML，JS，CSS，都能往CDN上放，访问更加快速了。&br&&br&在这个时候，BaaS有什么好处呢？&br&&br&最近这些年，我们可以看到一个规律，那就是前端更加多样化，而后端其实更容易抽象。比如说，后端提供的就是数据存取（有模式或者无模式，后者越来越流行），数据推送，实时通信等等，这些都是可以抽象化的，可以以一种比较直观的方式配置出来，生成接口，前端能够专注实现各种拉风效果。&br&&br&这几年创业团队越来越多，对于这些人来说，用IaaS有很大制约，他必须先买服务器，配置子网络，负载均衡，防火墙，IP映射，搭建环境，配置数据库，编写数据访问层，等等等等，而这一切，只是为了能让他的Web界面或者移动端能存储少量数据。这个过程浪费的精力太可怕了，要知道，本来两个人一周能做好的原型，很可能因为这些，又多花了一个月。&br&&br&但是有BaaS就不同了，比如用LeanCloud，就直接用它的SDK，后端存储什么都不用担心。又比如想要应用内社交，即时通信，都可以用现成组件，只需调用即可，除非这个产品有很差异化的需求，80%是不需要再自己搞服务端的，这当然是非常好的事。&br&&br&现在假设有做前端，或者移动端的人创业，之前他不得不拉上一个后端，不然自己就不得不去做那些不熟悉的事情，折腾各种服务器，现在有BaaS，他所有事情都在自己的专业技能范围内，效率当然是很高，对他当然是大大的利好了。
感谢邀请。BaaS是对前端的利好，确定无疑。看一看这些年B/S产品的发展，可以看出这么一个规律：页面逐渐应用化。从最早的B/S产品架构看，页面层属于MVC中的V，是由服务端输出的，服务端的输出结果是页面。［M］－［C］－［V］ ｜ 浏览器后来逐步AJAX化了之…
谢邀。也感谢提问的用户让我有机会来说说这个问题，可能有这个疑问的用户并不是个别。以其说是越来越差，不如说是在用户和流量快速增加后让一些「成长的烦恼」变得明显了。&br&&br&LeanCloud 无论从产品、团队、收入、还是用户规模上都比以往任何时候更好，但因为开发者和应用的增加，让一些问题变得明显了。平台上的应用数目在不断增加，而很多应用本身的用户数和流量也在快速增加，这种增长是叠加在一起的。&br&&br&在 BaaS 领域，LeanCloud 面临着很多没有前人可借鉴的挑战。举个例子，根据 BaaS 先行者 Parse 最近的 Blog 文章 &a href=&///?target=http%3A///learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-sanity/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&How We Moved Our API From Ruby to Go and Saved Our Sanity&i class=&icon-external&&&/i&&/a&，Parse 在用 Go 重写 API 服务之前，用 200 台服务器运行 API 服务，&b&一共&/b&支持每秒 3000 次请求的流量，这还没有算上数据库等其他服务器。而 LeanCloud 上比较大的单个应用每秒请求数就达到了五位数，也就是说 LeanCloud 上一个大的应用的流量就比当时 Parse 整个平台的流量高很多，而 LeanCloud 的所有服务器加起来数量却比 Parse 的 API 服务器还少很多。Parse 团队说从开始重写 API 服务到现在流量增加了十倍，那么也就是说即使是对比现在的数字，Parse 的流量仍然比 LeanCloud 低很多。据我所知，LeanCloud 是全球唯一完全支撑过 App Store 总榜第一 app 的 BaaS 服务（完全支撑指除了 LeanCloud 外没有用任何 app 自己的服务器）。&br&&br&高流量本身并不是挑战的全部。大家都知道数据库查询优化的最重要工作是索引，而通常来说建索引的前提是知道会出现的查询类别，这对做一个具体的 app 来说没什么问题，因为客户端的查询都是自己写的。对于 LeanCloud 这样要支持数万个应用的平台来说，我们无法事先知道可能会收到什么样的查询请求，而因为我们的目的就是减轻后端开发、运维、优化的负担，所以不愿意把优化查询的工作让用户去做。因此 LeanCloud 必须把优化数据库的过程自动化，自动及时创建应该有的索引，同时自动删除不必要的索引（因为会降低数据插入的性能）。&br&&br&除了技术和产品方面之外，LeanCloud 也在 Marketing、Sales、技术支持等各个方面进行着很多新的尝试。我们没有靠关系给客户「制造需求」的销售人员去寻找一个单子几百万元的「大客户」，而是希望能通过降低产品开发的门槛，让更多想法有机会变成现实，支撑起数量众多的成功的 business。在这个过程中我们一定会犯很多错误，但是会努力不让支持我们的用户失望。&br&&br&关于题主说到的工单系统收费问题以及有的答案里提到的最近的服务中断，因为我们发布了专门的说明，就不在这里赘述了。&br&&ul&&li&这里说了我们决定对工单系统收费的原因：&a href=&///?target=https%3A///3270/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/3270/&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&。没有购买工单支持的用户仍然可以使用社区论坛得到支持，另外也可以发邮件到 support 邮箱反馈问题。&br&&/li&&li&这里解释了服务中断的原因及恢复过程：&a href=&///?target=https%3A///3374/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/3374/&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&。&/li&&/ul&为了让团队跟上产品的发展，我们有多个职位在求才。欢迎看到问题的你加入我们，和我们一起解决这些问题，让 LeanCloud 变得更好。→ &a href=&///?target=https%3A///jobs.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&工作机会 - LeanCloud&i class=&icon-external&&&/i&&/a&
谢邀。也感谢提问的用户让我有机会来说说这个问题，可能有这个疑问的用户并不是个别。以其说是越来越差，不如说是在用户和流量快速增加后让一些「成长的烦恼」变得明显了。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…
这是后端技术越来越成熟的表现，越成熟的技术，就有利于复用，复用的最终就是同质化，所有的东西都有现成的，最后用不着写什么代码了。&br&&br&目前后端技术在云出现后的确开始快速的收敛，因为大部分解决方案被云计算直接提供了。&br&&br&所有领域的未来都会是复用程度越来越高，同质化越来越明显，成熟、收敛和过时，我们去研究新的领域。
这是后端技术越来越成熟的表现，越成熟的技术，就有利于复用，复用的最终就是同质化，所有的东西都有现成的，最后用不着写什么代码了。目前后端技术在云出现后的确开始快速的收敛，因为大部分解决方案被云计算直接提供了。所有领域的未来都会是复用程度越来…
iOS成本不高。表面上需要买个Mac很贵，但是7000多的Mac已经很好了，不需要买1万的入门。iOS设备可以买touch或者iPhone 3G，也不贵。
&br&&br& 学习难度很低，只要你有点英文基础。
&br&&br& Android表面上成本低，但是需要买大量手机做适配。而且不好挣钱。
iOS成本不高。表面上需要买个Mac很贵，但是7000多的Mac已经很好了，不需要买1万的入门。iOS设备可以买touch或者iPhone 3G，也不贵。 学习难度很低，只要你有点英文基础。 Android表面上成本低，但是需要买大量手机做适配。而且不好挣钱。
我觉得这几个产品他们的定位和目标是不一样的。&br&&br&Google 收购的 Firebase，重点在于解决不同设备/平台间的数据同步，采用的机制类似于 zookeeper 的监听-通知方式。其优点是 API 简洁易用，非常适合用来构建动态的、数据驱动的网站（或应用），但是其缺点也比较明显：&br&&ol&&li&数据安全机制较弱，只支持根据用户来区分读写权限，没有角色的概念；&br&&/li&&li&数据操作能力较弱，稍微复杂一点的查询或者数据关联，他都无能为力；&br&&/li&&li&数据分析能力更弱，在 dashboard 里面只能查看流量和当前在线人数，要分析一下业务数据那是不可能。&br&&/li&&/ol&&br&而 Facebook 收购的 Parse，则侧重于提供一个通用的后台服务，包含了 schema free 的数据存储和云代码（CloudCode）。其数据存储服务涵盖了结构化的对象存储和非结构化的文件存储（也包括 CDN），并且，与 Firebase 不同，Parse 提供了完善的账户系统和数据访问控制，而且提供了强大的数据关联（一对一、一对多、多对多等）和查询能力。&br&除此之外，由于定位于通用的后台服务，所以在标准化 API 之外，Parse 也提供了方法让开发者可以定制自己的商业逻辑。他们的做法是建立一个 node.js 容器，让开发者使用 javascript 这种广为人知的前端语言来完成数据整合、计算，再将结果返回给客户端。这就是云代码。&br&Parse 还提供了跨平台的消息推送（Push Notification）服务，不过这不是它的重点。相对于 Firebase 的不足，Parse 解决了前两个问题，但是就数据分析来讲，依然非常弱。&br&&br&LeanCloud 的目标是提供一套「完整」的后台服务，不光是面向开发阶段，还需要考虑到产品运营、迭代阶段各方面的诉求，所以在 Parse 的基础上，还加入了 &a href=&///?target=https%3A///docs/bigquery_guide.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&离线分析&i class=&icon-external&&&/i&&/a& 的功能，使用方式上类似于 Hive 之于 Hadoop。这样开发者就可以对存储到云端的数据进行挖掘和分析，完成自己的 BI（商业智能）处理。&br&除此之外，结合国内市场的特点，LeanCloud 还特别推出了 &a href=&///?target=https%3A///features/message.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&消息服务&i class=&icon-external&&&/i&&/a&，Push Notification、实时消息（IM）、短信 三位一体的方式，可以更好地用来支撑应用内聊天以及实时数据同步等多种需求。&br&总体上来看，LeanCloud 是一个更加完善的 BaaS（Backend as a Service）平台。
我觉得这几个产品他们的定位和目标是不一样的。Google 收购的 Firebase，重点在于解决不同设备/平台间的数据同步，采用的机制类似于 zookeeper 的监听-通知方式。其优点是 API 简洁易用，非常适合用来构建动态的、数据驱动的网站（或应用），但是其缺点也比…
目前我在公司是做Android客户端方面的工作，从我近两年的编码经验来看，iOS和Android的比较必须从多个方面来比较，不能过于笼统地断定哪个成本高和低。
&br&&br& 从硬件设备投入来看，通常开发人员都会有PC环境，那么开发Android应用程序的基本条件已经满足了一个，而开发iOS程序最好还是需要一个Mac环境，对于绝大部分开发者来说还是需要另外花费一笔资金的，关于测试机当然肯定是Android会比iOS坑爹，因为Android的机型实在是太多太多了。如果你是个人开发者的话，那么在这个角度上来看你选择iOS是明智的，而对于公司来讲，其实这些并不是非常重要的问题，如果在公司就职的话，公司不论做哪个平台都是需要提供开发环境的，至于测试机也是一样的，如果公司有20个开发者，那么有20个iOS设备和拥有20个Android设备对于机型的覆盖率相差不会那么大的，虽然iOS可以做到百分百覆盖，但是对于Android来说也差不多了，当然小公司的话这个问题可能会稍微尖锐一些，其实从Android机器均价与iOS设备均价来对比，相差无几。
&br&&br& 从学习成本投入来看，Android程序员从Java转过来的是绝大多数，而且可以较为快速得进入状态开始Coding,而iOS开发对于大部分开发者来说是完全陌生的，也就意味着要重新学习，但是对于程序员来讲，即便不是工作需要，我想在不断的工作过程中也会去接触更多的新鲜知识，从这个角度来看这个也不是什么问题，都有不错的官方文档来支撑前期的学习和入门。
&br&&br& 从开发具体应用来看，根据我在公司一年多经历的项目来看，在Android上做应用类产品的难易程度相对简单，因为Android的开放性以及Java界多年来在开源上的积累，项目中需要用到的很多模块都可以找到成熟的开源实现，而iOS近几年逐渐发力，在开源上的积累相对薄弱一些，在做应用时可能很多的模块需要自己造轮子，这个对于个人开发者来说可能比较重要。
&br& 谈到适配机型的问题，对于想做游戏的童鞋们来讲可能会比较痛苦，特别是游戏使用到3D技术的，由于Android不同厂商选用的各种芯片的标准不一致实现不一致，很容易出现在某款机器上完全无法正常游戏的情况，而且游戏需要跟设备尺寸的结合度往往比较高，要完美地适配Android众多尺寸不一的设备确实非常的让开发者头痛，而且设备的选购也是一笔不小的费用，对于个人开发者来讲是比较不现实，而iOS相对来将就比较单纯，而且硬件控制得好，大家碰到的问题大体上都比较一致，社区里面肯定有能解决你问题的人和案例。
&br&&br& 写得比较乱，第一次回答问题，呵呵。
&br& 综合上面的这些，我认为个人开发者选iOS更合适，对于在公司就职的童鞋们，公司对于不同平台的重视程度通常应该都是一致的，不需要考虑过多其他的问题，更多的是做好工作完成任务，做出好的应用和游戏，可以依照自己当前的技术优势和兴趣做出选择，成本公司自然会给你承担。
目前我在公司是做Android客户端方面的工作，从我近两年的编码经验来看，iOS和Android的比较必须从多个方面来比较，不能过于笼统地断定哪个成本高和低。 从硬件设备投入来看，通常开发人员都会有PC环境，那么开发Android应用程序的基本条件已经满足了一个，…
有 BaaS 之后对于很多公司来说需要的后端工程师确实比以前减少了。但很多后端职位是从这些公司转移到了开发包括 LeanCloud/BaaS 在内的各种云服务的公司。另外一些基础后端问题的解决让工程师可以把更多精力放在更加困难，以前无暇顾及的问题上，当然这也对知识和能力提出了更高的水平。我想从整个市场来看的话，应该说这方面的职位数量有一定减少但变化不会很大，而对人的要求在提高。&br&&br&Andy Grove 在 Only The Paranoid Survive（只有偏执狂才能生存）一书里讲述了 Intel 如何从做内存创业起家，到后来日本公司依靠性价比优势快速占据市场，Intel 彻底放弃内存市场并转向微处理器市场反而取得更大成功的案例。连公司都要不断经历这样的 inflection point，一个人更不可能靠一项技能吃一辈子。几年前 iOS、Android 平台的出现，既让很多人丢掉了饭碗，也给了很多人巨大的机会，而属于哪一类其实是自己决定的。在技能方面，应该拥抱变化，带着持续的热情不断学习新东西。&br&&br&最后做个小广告，LeanCloud 的各个技术职位（iOS、Android、前端、后端）都在常年招聘中。对于很优秀的后端工程师来说，职位是不缺的，欢迎投简历（&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&在 LeanCloud 工作&i class=&icon-external&&&/i&&/a&）。:-)
有 BaaS 之后对于很多公司来说需要的后端工程师确实比以前减少了。但很多后端职位是从这些公司转移到了开发包括 LeanCloud/BaaS 在内的各种云服务的公司。另外一些基础后端问题的解决让工程师可以把更多精力放在更加困难，以前无暇顾及的问题上，当然这也对…
目前LBS应用中定位方式有三种：&br&1. GPS或者GPS+AGPS&br&2. 基站定位（通过Cell-id获取位置）&br&3. Wi-Fi定位&br&&br&从精度上来说，GPS是最高的，一般精确定位到10米，但同时也是定位速度最慢的。必须在室外同时搜索到4颗以上的卫星才能定位。不过可以通过AGPS加速定位，AGPS是卫星+基站的定位方式，它会通过网络走流量取到星历，加速GPS的定位，一般来说在半分钟以内，GPS冷启动都可以成功定位。&br&&br&基站定位，每个基站的经纬度已知，且每个基站都有一个独立的Cell-ID，手机通过移动通信基站的CELL-ID即可获知经纬度，实际应用中基站定位的算法各家不一，一般是通过几个基站复合定位，这样定位精度好的时候可达到50米。优点是定位速度快，有信号的就可以定位，缺点是精度差，需要耗费网络流量。&br&&br&WIFI定位，WIFI定位原理和基站定位类似，WIFI结点（如无线路由）的位置是不经常变动的，所以它的经纬度也是确定的，WIFI定位和基站定位不同的是，它可以通过获知WIFI结点的信号强度来定位，但结点的定位精度比基站定位高很多，缺点也是耗费网络流量。
目前LBS应用中定位方式有三种：1. GPS或者GPS+AGPS2. 基站定位（通过Cell-id获取位置）3. Wi-Fi定位从精度上来说，GPS是最高的，一般精确定位到10米，但同时也是定位速度最慢的。必须在室外同时搜索到4颗以上的卫星才能定位。不过可以通过AGPS加速定位，AGP…
（其实新浪微博app有很浓的hybrid开发痕迹，可能并不是原生应用。）&br&Webapp是一条死胡同，即使体验能和原生的一样，推送怎么办？换个浏览器怎么办？&br&所以我猜楼主想问的可能是hybrid app。&br&我们的团队刚刚开始hybrid app开发技术的探索，但是我可以很负责任的告诉你，&br&在“弱交互”的情境下，hybrid app的性能已经很接近native app。&br&给你看一个别人的作品——校信
&a href=&///?target=http%3A//xiaoxin.im/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&校信，重新定义校园社交&i class=&icon-external&&&/i&&/a&&br&如果我没记错的话，这个产品是 &a data-hash=&bfe& href=&///people/bfe& class=&member_mention& data-tip=&p$b$bfe&&@梁灏&/a& 童鞋在校期间独立开发的，&br&从我的观察来看，他的“校信”应该是中国目前为止在技术/用户体验上最成功的一款hybrid app作品&br&在我手机上的运行速度远远快于笨重的native app&br&这至少证明了hybrid app在“弱交互”条件下是可以做到不比native差的。&br&并且也证明了hybrid开发模式的高效性（一个大学生可以完成如此优秀的产品）。&br&&br&当然，对hybrid app的性能不能这么简单的下个结论，&br&因为html5以及js的渲染解析速度直接由各个移动平台的内置浏览器内核决定。&br&也就是说，你的hybrid app到底性能是好是坏，关键看用户的手机。&br&&br&一个好消息是，各大移动操作系统对html5的支持越来越好，&br&苹果就不说了，我们说说Android，&br&Android可以说从4.x开始对html5的支持完全提升了一个等级，&br&至少我的安卓机可以完美的运行上面说的“校信”。&br&并且，各大移动操作系统对hml5的支持，随着时间推移，只会变好，不会变坏。&br&所以说，html5是属于未来的技术。&br&&br&&br&最后，我的观点是：&br&html5不能取代native，但是可以大大降低应用开发的门槛，未来“弱交互”的工具型app可能都会是hybrid app的天下。&br&而native，则用于去实现更为高级和复杂的app。&br&&br&就像C语言较Python来说强大的多，但是对于网络爬虫来说，Python不失为一种更为经济方便的选择。
（其实新浪微博app有很浓的hybrid开发痕迹，可能并不是原生应用。）Webapp是一条死胡同，即使体验能和原生的一样，推送怎么办？换个浏览器怎么办？所以我猜楼主想问的可能是hybrid app。我们的团队刚刚开始hybrid app开发技术的探索，但是我可以很负责任的…
去 LeanCloud 面试是两个月前的事情了，在选择公司的时候看到 LeanCloud 的开放资源（&a href=&///?target=https%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&LeanCloud 开放资源&i class=&icon-external&&&/i&&/a&）网站，就觉得这会是一家很有趣、很有想法的公司。&br&&br&在去面试之前我其实在 LeanCloud 的技术面试指南（&a href=&///?target=https%3A///tech-interview-guide.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&技术面试指南· LeanCloud 开放资源&i class=&icon-external&&&/i&&/a&）上已经看到了上面重点提及了「二分查找」算法，不过我还是没有去看。面试的时候果然提到了二分查找，我大概花了两分钟在纸上用一种介于 CoffeeScript 和 JavaScript 之间的伪代码完成了一个版本。不过马上就被指出一个明显的错误，面试官跟我说不要急，慢一点写。又花了几分钟我又完成了一个版本，不过有没有错误就不知道了。&br&&br&在面试之前的几天我听了 Teahour 的一期关于 Docker 的播客（&a href=&///?target=http%3A//teahour.fm//docker-introduction.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&与马道长聊 Docker&i class=&icon-external&&&/i&&/a&），滚滚姐姐在其中介绍了一些 Docker 在 LeanCloud 的应用场景。我从三年前开始自己开发了一套虚拟主机的管理系统（&a href=&///?target=https%3A///jysperm/RootPanel& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&jysperm/RootPanel · GitHub&i class=&icon-external&&&/i&&/a&），当时还没有 Docker, 我是使用 Linux 非常原始的方式（用户和文件系统的权限机制）来实现权限隔离的。所以后来出现 Docker 之后我就很感兴趣，很想把 RootPanel 重构为基于 Docker 实现，不过一直没有时间。果然在面试的过程中面试官对我的这个项目很感兴趣，一起讨论了还有哪些方面可以改进、如果重新去设计它应该如何设计。&br&&br&在找工作的过程中我去了几家业界有些名气的互联网公司（主要是开发者服务方面的），LeanCloud 的面试过程给我的印象是最好的。没有特别脑残的笔试题或问卷、没有让我等待太久、面试中提出的技术问题都非常专业、没有 HR 来和我谈人生和理想。LeanCloud 也是唯一一家提出可以报销路费的（虽然最后我嫌麻烦并没有报）。&br&&br&我连高中都没有正经地念完，完全靠自己的热情掌握了工作中需要用到的技能（&a href=&///?target=https%3A//jysperm.me/2015/02/programming-from-middle-school/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&jysperm.me/2015/02/prog&/span&&span class=&invisible&&ramming-from-middle-school/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&），LeanCloud 对像我一样的年轻人也有着比较开放的态度。面试结束我就要离开的时候，面试官还拍拍我的肩膀说「没关系，退学没什么的，LeanCloud 也有几个人是中途退学的」。&br&&br&最后点一下题：基础扎实、有实践经验、技术栈和 LeanCloud 相贴合、对技术有热情。
去 LeanCloud 面试是两个月前的事情了，在选择公司的时候看到 LeanCloud 的开放资源（）网站，就觉得这会是一家很有趣、很有想法的公司。在去面试之前我其实在 LeanCloud 的技术面试指南（）上已经看到…
iOS 中程序分五个状态：活跃，不活跃（锁屏，但程序不接受事件），运行结束，后台，挂起&br&&br&特别说一下后台运行跟挂起&br&后台运行：是指不在界面中显示，但是代码还在执行&br&挂起：程序在内存中，但是代码不执行&br&&br&iOS 只允许以下几种程序长时间在后台运行：&ul&&li&Apps that play audible content to the user while in the background, such as a music player app&br&&/li&&li&Apps that keep users informed of their location at all times, such as a navigation app&br&&/li&&li&Apps that support Voice over Internet Protocol (VoIP)&br&&/li&&li&Newsstand apps that need to download and process new content&br&&/li&&li&Apps that receive regular updates from external accessories&br&&/li&&/ul&&b&而其他的程序最多只允许申请&u&十分钟&/u&的后台运行时间，&u&十分钟&/u&一到，就会被系统自动挂起，而在系统内存不足的情况下，才会将挂起程序 Kill 掉；这就最大程度的保证了当前活跃中的程序的系统资源，保证了其流畅性。&/b&&br&&br&&b&而 Android 的多任务则是十个程序在后台，十个程序都在执行代码，抢占资源&/b&&br&&br&参考苹果文档：&a href=&///?target=https%3A///library/ios/%23documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/lib&/span&&span class=&invisible&&rary/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
iOS 中程序分五个状态：活跃，不活跃（锁屏，但程序不接受事件），运行结束，后台，挂起特别说一下后台运行跟挂起后台运行：是指不在界面中显示，但是代码还在执行挂起：程序在内存中，但是代码不执行iOS 只允许以下几种程序长时间在后台运行：Apps that pl…
这个问题把我的思绪拉回到一年多以前，那时我还是个刚毕业的孩纸，如果去掉了「GDG 社区组织者，TechCrunch 大会主持，谷歌女性开发者节策划，ex-简书er，ex-果壳er」等诸多头衔，我纯得就像一张白纸。&br&&br&我面试 LeanCloud 的时候，CEO &a data-hash=&490fc32f098b87e9ccc17& href=&///people/490fc32f098b87e9ccc17& class=&member_mention& data-tip=&p$b$490fc32f098b87e9ccc17&&@江宏&/a&和我说了让我很难忘的一段话：&br&&br&「LeanCloud 不缺聪明的人才，不缺优秀的人才，不缺品德高尚的人才，不缺有管理能力的人才，就是缺你这样长得好看的。」&br&&br&我听了十分感慨，被他的的真诚和实在所感动，我就加入了 LeanCloud ，成为了 LeanCloud 联席 CDO。&br&&br&------以上为虚构，认真回答分割线------&br&&br&关于研发需要具备的技能同事们会一一回复，关于我司其他职能部门我简单说几句。&br&1.发自内心认可我们的产品、企业文化（官网和开放资源网站可见）；&br&2.具备当前职位所需的基本技能、职业热情（job 页面可见）；&br&3.三观正，积极的沟通交流态度、高尚优雅的志趣等；&br&4.简历直投 yyuan#leancloud.rocks 我们有入职奖励 ^_^
这个问题把我的思绪拉回到一年多以前，那时我还是个刚毕业的孩纸，如果去掉了「GDG 社区组织者，TechCrunch 大会主持，谷歌女性开发者节策划，ex-简书er，ex-果壳er」等诸多头衔，我纯得就像一张白纸。我面试 LeanCloud 的时候，CEO 和我说了让我很难…
用数据来说话吧，以下是我们自己做的推送到达率测试，测试方法是客户端收到推送后立即向我们自己的服务器发送一个回执请求，以下数据仅供参考：&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…
1.硬件:华为是一家不错的公司,很野蛮。先是和赛门铁克合作搞了华赛做存储，然后学到赛门铁克软件的真谛后收购华赛（华赛现在应该是国内做存储最牛逼的），之后自己补充服务器产品线先oem ibm和超微的，再把dell当做楷模，dell做什么就跟着做什么，现在做的也很有起色。但华为毕竟起步晚,存储虽说国内还行,但遇到EMC,Netapp,Hitachi,IBM,hp之流完败，EMC是一直主导存储发展方向的牛逼公司,华为和emc竞争是笑话，但在一些项目和客户上华为还是可以拿一些份额的。服务器技术门槛没有存储那么高，不需要软件和产品线的积淀,,但华为在企业这买的真心不好，sales、渠道。。。。太多因素的&br&2软件:再谈重点的软件，中国的大多数人把云计算归结为虚拟化，华为的虚拟化用的开源xen，然后再用citrix的桌面协议做虚拟桌面，ica协议效果是业界最优秀的。华为的云计算（特指虚拟化和桌面）先是疯狂的招人，但貌似盈利不大又xx掉很多。开源的xen,能用好也是一件难事,没能上手体验下华为的产品很遗憾(谁有镜像的话希望share下,),云的管理但貌似也没和openstack/cloudstack扯上关系，个人认为不是主流方向，在vmware和微软、kvm加上各种stack的竞争下市场很难发展。不敢说华为虚拟化做的不好，但和vmware肯定差的很多很多多多多。虚拟桌面是vmware的软肋，用ica的华为桌面确实表现很出众，大的实施运维经验也是其他做桌面的公司不能比的（华为内部也在用，数量也很大，这点确实是优势）但没有xenapp，个人认为还是半个残疾，再者桌面也不太符合中国国情，视频游戏和带宽限制，搞死了桌面。服务器虚拟化最好的肯定是vmware，桌面是citrix，华为在这个市场上想竞争基本没有可能性，市场上到处都是vmware的代理，华为是一个公司很一群不比华为差的公司战斗，能活下来养活自己的产品线就不错了。桌面的市场华为倒是没少拿，但每一个桌面的利润都分给了微软、citrix和升腾，华为也是一个苦逼的打工仔。&br&3.云计算：云计算强调的是服务，国内抄作的太厉害，变成了服务器存储虚拟化分布式。。。。中国模式太独特了，没有充分竞争的市场华为到底能发展成什么样真不好说，希望大家都不要抄概念圈钱圈地，实实在在的都点东西，先把iaas服务做起来再吹别的，国内数据中心一个pue控制好的都没还天天吹节能环保，paas和saas更是吹的没边了，数据库就叫paas，是个软件就叫saas，云电视云手机甚至做个电子狗也叫云狗。。。我现在也懵，什么才是云计算
1.硬件:华为是一家不错的公司,很野蛮。先是和赛门铁克合作搞了华赛做存储，然后学到赛门铁克软件的真谛后收购华赛（华赛现在应该是国内做存储最牛逼的），之后自己补充服务器产品线先oem ibm和超微的，再把dell当做楷模，dell做什么就跟着做什么，现在做的…
&p&作为一个新用户，首先想借此机会感谢LeanCloud。&br&&br&&/p&&p&注册LeanCloud应该是在4月30日左右，我的动机是寻找一个稳定、快速、能够帮助我大幅度提高开发效率的BAAS提供商，以便快速开发出我设想中的在线学习平台。&br&&br&&/p&&p&在两个月的时间里（有些时候我还要处理培训的事情所以不是完全投入，但大多数时候用在了开发上），我发布了Web版，6月10日左右入手人生第一台Mac，6.29日提交了自己写的第一个App到Mac，昨天最后完成了安卓1.0版本的开发。&br&&br&&/p&&p&这是我第一次使用MEAN架构开发Web应用，此前也没有手机端App的开发经验。两个月内达成Web、IOS和Android App的完成，LeanCloud的作用是必不可少的：&br&&br&&/p&&ul&&li&后端API消除了了无聊而浪费时间的编写/生成data access代码以及debug这部分代码的成本，让我可以更加专注于功能的实现&/li&&li&应用中有timeline相关功能，例如提示学员收到的评论。LeanCloud的事件流在这方面提供了基础的API，这样后台的timeline功能分分钟就可以实现了。&/li&&li&Schema Free和管理控制台让快速完成功能和调试变得更容易，可以很快的产生测试结果，在后台通过观察数据完成部分调试工作&/li&&li&不用自己搭建和维护服务器环境&/li&&li&整体来讲文档的质量比较高，逻辑相对清晰而且案例也比较具体，因此降低了上手的成本&/li&&li&Push API让消息推送变得容易，尤其是Android端的SDK，我这个Android小白最后也比较快的实现了推送功能，而且速度在国内很快。没有API这事可能只好外包出去找人做，整个流程恐怕又要慢很多了。在这个过程中也遇到了文档的坑，后面再谈。&/li&&/ul&&p&顺便说一下，开发效率大幅度提升的另外一大利器是Ionic/AngularJS/Cordova。此前用jQuery觉得最大的问题就是难以清晰的分离程序逻辑与dom操作，稍微大一点的应用就搞得很乱。而AngularJS提供了一个完整的框架，让前端开发变得井井有条。数据、界面和控制流程之间的关系变得很清晰。我个人的看法是，有了AngularJS,可以说才有了enterpirse ready的rich browser client framework.&br&&br&&/p&&p&至于Ionic/Cordova，对于我这种没有任何app开发经验的人来讲，可以用Web开发的方式去开发移动端应用，这样理想情况下，甚至可以完全不用学习IOS和Android开发(除了如何搭建开发环境和编译app)，或者有一个比较明确的划分，将Native相关部分外包出去。但在我实现在线学习平台的过程中，为了Push Notification功能，还是涉及到了IOS和Android开发的一些概念，临时抱佛脚补了一些知识。但这些知识远远不足以独立开发native应用。&br&&br&&/p&&p&这个技术组合的另外一个好处，是由于Web端和手机端都是基于AngularJS + LeanCloud Javascript SDK，所以很大部分的代码可以重用。相对而言，如果使用传统方式，Web一套代码、IOS一套代码、Android一套代码，从开发和维护的角度，想想都感觉头疼。&br&&br&&/p&&p&整体来讲，选择LeanCloud让我的开发过程愉快了很多，同时在两个月内搞定了在线学习平台，这样一直以来很多关于培训和教育的想法，就有了实施的基础，非常感谢LeanCloud提供的服务。&br&&br&&/p&&p&谈了好处要谈遇到的问题了。&br&&br&&/p&&p&在6月份有两周左右的时间(LeanCloud长时间罢工那次大概就在这个时间的中间)，从我自己的经历，感觉LeanCloud处在很不稳定的状态。我写着写着代码，测试的时候突然就发现Query Failed，或者长时间没有响应，打开Chrome开发者工具发现服务请求一直处于pending状态。这种状态也没啥规律，有时候刷刷就好，有时候过十来分钟也未必好，严重的话每次可能出现几次比较长(也就是刷几次都解决不了问题)的情况。搞得后来出现这种情况，要是刷一次不work，我就去走一走、喝杯茶或者干脆睡一觉了。对于开发进度的延误也就算了，关键是这种状态如果维持的话，显然应用都没法用了。&br&&br&&/p&&p&所以当时第一天我很镇定，第二天也OK，但第三天这样心里就开始打鼓了。我靠要这样下去不是做无用功了么。而且BAAS服务商这件事情，一旦选择了基本上绑定了，更换成本巨大，所以也就纠结了一下。但凭对LeanCloud的感觉，我还是相信他们有能力处理好这件事情，而且也没什么别的更好的选择。都快临产了咋办呢，还是把娃生出来再说吧。于是就继续开工。还好最近一段时间，LeanCloud的运作正常。&br&&br&&/p&&p&这件事情之所以重要是因为从选择BAAS服务的角度，速度和稳定性是重中之重。这上面出了大问题其它任何优点恐怕都难以弥补。事实上当初最开始选择的时候，就觉得LeanCloud的速度很快而且稳定，所以很有好感。&br&&br&&/p&&p&在LeanCloud服务罢工那次，看到一些客户有强烈的意见，尽管我觉得有些语气值得商榷，但情绪可以理解。毕竟对于BAAS提供商而言，可能失败了是丢掉了一个客户；但对于客户尤其是资源有限产品单一的startup而言，可能选择供应商失败，就意味押上了身家性命。就像江宏说的有客户当天准备做活动却出了这事，想想也是影响巨大。&br&&br&&/p&&p&江宏谈到“希望能通过降低产品开发的门槛，让更多想法有机会变成现实，支撑起数量众多的成功的 business。在这个过程中我们一定会犯很多错误，但是会努力不让支持我们的用户失望”。我觉得这个愿望非常好而且也切身感觉到了LeanCloud带来的便利，但有些时候可能顾鱼和熊掌还是难以兼得，需要考虑取舍的问题。&br&&br&&/p&&p&建议LeanCloud考虑划分服务和价格层次，考虑设置不同的Service Level和quota，收取不同的价格。让用户自己有的选，对错误容忍度更低的花钱买保障，反过来便宜甚至免费就得接受一些潜在的风险。这样用户的期望值好控制，同时后台的运维规划也比较好做。&br&&br&&/p&&p&回到这个问题的描述：“现在工单也要收钱了，他们并不是作免费服务，难道流量费里不应该包含服务吗？系统使用过程中，坑是越来越多，更操蛋的是，竟然调用api后返回错误信息出现\u7890\u...的unicode编码，网上找了个unicode转码才看到汉字说，“系统错误，请提交工单”，妈呀？我没钱提交工单啊。”&br&&br&&/p&&p&我个人是支持LeanCloud提供收费技术支持的，因为收费是有效的区分问题重要性的方式。例如有些人获取支持是为了学习，有些人获取支持是要上线业务攸关的系统。高质量的技术支持是宝贵的资源，如果没有有效的区分，就很可能砸到不产生价值的地方，而且客户期望高容易不爽。事实上LeanCloud现在的支持服务，200块个人包月，500块团队包月(后者如果我没记错的话)，这个价格恐怕不足以弥补成本，应该算是象征性的。&br&&br&&/p&&p&在商业社会里，Show me the money是区分客户对问题重视程度的简单有效法门。&br&&br&&/p&&p&但凡事两头说，尽管我支持收费技术服务，但从目前LeanCloud整体的技术支持架构来看，也存在比较大的问题。&br&&br&&/p&&p&这个问题的核心，我觉得是LeanCloud的文档。尽管整体质量还可以，但其中依然有一些坑，或者语焉不详的地方。以我自己的感觉，如果是自己个性化的需求，收费支持是相对容易理解接受的。但对于基本的使用教育，举个例子使用LeanCloud的In App Search，我需要按照关联的对象来筛选，应该怎么写代码。这种问题从客户期望上来讲，通常应该是文档应该写清楚的，而不应该是要花钱的。&br&&br&&/p&&p&但文档质量并非毕其功于一役的事情，关键在于，除了有一个高质量的起点，还需要有一个高效的沟通机制，能够快速的得到客户的反馈，然后基于反馈改进。&br&&br&&/p&&p&从这个角度，我个人建议LeanCloud还是需要提供一个免费的技术支持服务，但这个服务的限制应该是关于LeanCloud开发的基本How to。就像上面的例子，&LeanCloud的In App Search，我需要按照关联的对象来筛选，应该怎么写代码&。这个其实本身就应该是文档的部分，当用户能够快速的提交问题获取支持，其实反过来也就促进了内容的完善。&br&&br&&/p&&p&那么这个服务应该以何种方式提供呢？最好的方式大概就是在相关文档本身。就像在PHP的文档里，每个页面下面都有讨论区，这样用户有问题可以直接交流。以前在PHP开发时，一些文档中遗漏的内容，在下面的讨论区里面可以看到。这其实是技术支持内容的UGC。&br&&br&&/p&&p&但比PHP文档可以做的更好的是，LeanCloud可以提供官方的快速支持（例如工作日工作时间1小时内的初次响应）。当有用户在讨论区评论的时候，快速的进行相应。这样一来，用户满意、LeanCloud知道了文档存在的不足之处，而且交流的内容都保留在了相关的文档中，下一个人采坑/抓狂/茫然的概率就小了很多。&br&&br&&/p&&p&这个就像我最近碰到的一个坑，是关于LeanPush Android SDK中，使用CustomerReceiver。文档中提到，要在manefest文件中标记receiver，并且指定4个action给它。但其实操作下来是有问题的。搞定这个问题花了我2天的时间，但如果前面已经有人遇到过，并且在文档或者文档后面的讨论区中提到的话，应该直接就绕过了。反过来，如果LeanCloud提供这种类别的支持，可能整个沟通过程直接被记录下来，后面的人也就不用走弯路或者弯了能快速发现。这样整体上也许可以大幅度提升用户的体验、节省用户时间，同时也可以避免LeanCloud工程师的各种重复劳动。&br&&br&&/p&&p&顺便说一下看了这个问题下的所有回答，发现有人贴了这个链接&a href=&///?target=https%3A///t/196538& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&LeanCloud 太渣了&i class=&icon-external&&&/i&&/a&。&br&&br&&/p&&p&其中可能是LeanCloud员工的回答：&br&&br&&/p&&p&晚饭前，突然收到服务报警。一个个服务器 Crash，各种磁盘满，微信消息和用户电话接踵而至。这次服务挂起影响了较大范围的业务，而且问题原因当时也不明确，工程师们立刻开始检查服务器。停掉 Crash 的内存，扩容有问题的磁盘，切换不同的机器，重启所有服务。这个过程却远比我们想象的漫长，每个工程师都竭尽全力，终于重新让服务正常。但还是耗费了很长时间，导致用户们的产品处于不稳定的状态，对此我们表示深深的歉意。&br&&br&&/p&&p&LeanCloud 永远把服务稳定当做第一要务，要替用户把好这道关，也替用户搞定复杂繁琐的运维工作。但百分之百的稳定谁也不敢保证，虽然我们竭尽所能的避免，还是遇到像今天这样服务挂掉，在此再次对一直以来信任我们的用户表示深深的歉意。我们不会逃避问题，会写出详细的问题报告发布在博客上面，会成为我们的又一个经验教训。&br&&br&&/p&&p&马云常说「如果有一天，我要写关于阿里巴巴的书，将是《阿里巴巴的一千零一个错误》，30年前大家认为阿里巴巴不靠谱，但我知道阿里巴巴并不烂」。以前觉得他说这句话只是一句玩笑，现在对这句话更多的是敬佩。错误是成长最好的老师，公司成功有各种各样的幸运，但优秀公司一定都是历经多次灾难，从错误中吸取教训，才屹立不摇，对于 LeanCloud 也一定会是如此，所以我们会把今天的事故铭记于心，以后继续为用户们提供优质的服务，「为开发加速」是我们不变的使命。&br&&br&&/p&&p&感谢所有一直支持 LeanCloud 的用户，其中绝大多数也都是和我们一样的创业者，我们想成为你们强大的后盾。对于未来我们一定还会如临深渊，如履薄冰。&br&&br&&/p&&p&最后，引用《肖申克的救赎》 中的一句话「今天，让你难过的事情，有一天，你一定会笑着说出来。」&br&&br&&/p&&p&共勉。&br&&br&&/p&&p&LeanCloud 工程师 2015 年 06 月 06 日&br&&br&&/p&&p&这种心情可以理解，出了事情急切的想要沟通。但从客户关系的角度，这种类型的回复恐怕是把客户情绪引向更糟。比如教育客户“错误是成长最好的老师”，这话make sense的客户可以说来安慰供应商，但供应商这种情况下说这话，客户听了没有火都容易上火。&br&&br&&/p&&p&说到马云老师，我看到另外一位匿名用户的答案中提到：&br&&br&&/p&&p&“LeanCloud 自己也看不下去了，为了提高回复质量和响应速度，开始对工单系统提问收费。本来靠收费以提高更好地服务无可厚非，但在工单系统顶部，写上 “80% 的问题都可以通过仔细阅读文档解决。—— 马云” ，这句话实在让人窝火。这句话本身没错，但我不知道 LeanCloud 自己有没有好好审视自己的文档？能不能正视自己文档所存在的问题？”&br&&br&&/p&&p&恩，这句话我也看到过。当时在想，这不是很容易被理解为“你有问题是没有认真读文档”吗？无端得罪客户啊（虽然以我的经验来看，大多数开发人员阅读文档的能力和意识需要提升，但什么环境说什么话还是要考虑的）。马云老师还说“别低头皇冠会掉，别流泪坏人会笑”呢。&br&&br&&/p&&p&最近一段时间的观察，LeanCloud在客户沟通上还是不够有经验。例如上次的服务罢工事件，一开始貌似说二十分钟恢复，然后后来延期延期...这种违背了基本的客户沟通法则。&br&&br&&/p&&p&一个基本的原则是，当出现了这样的问题是，不要给客户承诺最后的期限（例如什么时候恢复），只能承诺行动和保持及时进度更新（我们会每隔5分钟更新当前的修复状况；我们已经有3位工程师到场处理，另外5位也已经在路上...)。&br&&br&&/p&&p&当机了是一次伤害，承诺20分钟恢复却没有实现是二次伤害，再承诺再没有实现是三次......尤其考虑到很多时候客户还要跟他们的客户、老板做沟通，所以承诺没实现的后果是连带他们丢掉了信任而且被批。这样还能有好心态的人真是少之又少。&br&&br&&/p&&p&做IT Service从某个角度也是挺委屈的，做的好的不一定是众口称赞，而可能是大家完全感觉不到，或者习以为常。例如网页刷的一下就出来了。但反过来除了问题，那就是众人围观了。毕竟鉴于IT Service的性质，可能出问题大家都没法干活了。没办法，这是工作的性质。但整体来说，群众的眼睛还是亮的。&br&&br&&/p&&p&Anyway写了这么多，本文的中心思想是我对LeanCloud还是很满意的，也希望LeanCloud更好。毕竟在一起都有3个娃了，虽然其中一个还在等待水果计划生育委员会发准生证。那么还是首先考虑如何更好的走下去。所以有些想法提一下，希望能够有所帮助。&br&&br&&/p&&p&===== 广告时间 =====&br&&br&&/p&&p&从这次LeanCloud事件，也暴露出在处理客户关系、沟通方面的一些问题。这种问题其实在技术思维导向的IT人中普遍存在。&br&&br&&/p&&p&在基于LeanCloud上线了新的在线学习系统后，我也推出了&a href=&/sales/& class=&internal&&顶级关系&/a&在线课程，用来帮助人们实现人际关系(也包括客户关系)和沟通能力上的突破。对于希望在“如何构建一流的关系”上实现突破的IT人，欢迎参加。&/p&
作为一个新用户，首先想借此机会感谢LeanCloud。注册LeanCloud应该是在4月30日左右，我的动机是寻找一个稳定、快速、能够帮助我大幅度提高开发效率的BAAS提供商，以便快速开发出我设想中的在线学习平台。在两个月的时间里（有些时候我还要处理培训的事情所…
推荐题主了解下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协议。 网络上有很多开源的实现方案。 上述两个协议都是移动端消息推送协议， 刚好毕业设计与实习是做相关的东西， 所以做了点技术调研，分享给题主。 看问题题主应该是想要实现移动端的即时通信。首先，大概把系统分为以下两个…
已有帐号？
社交帐号登录
无法登录？
社交帐号登录