Android 和 iOS 孰优孰劣：真实应用开发过程告诉你答案 - 文章 - 伯乐在线
& Android 和 iOS 孰优孰劣：真实应用开发过程告诉你答案
随便搜索一下“Android vs. iOS”，都会出现很多关于哪个平台更好的争论，大多数的争论点都是关于市场占有率、易用性和设备分化等问题。当然也有一些“以开发者的角度”去比较这两个平台的文章，但是很少有从技术上做深入的比较，通常也只是用一个简单的示例应用介绍一些基本的特性。缺少这种深入的比较其实是有原因的：一个公司要做一个足够复杂的移动应用，通常需要一个人或团队做Android，另外一个人或团队做iOS。这两个平台使用不同的编程语言（Java和Objective-C），提供不同的SDK，使用不同的开发工具，所以人力资源分配上各做各的平台也就不奇怪了。
GQueues是一个在线任务管理器，之前只有一个HTML5版本。最近我完成了GQueues for Android 和GQueues for iPhone & iPad 的开发。虽然这两个应用的复杂程度不能和第一人称射击游戏相提并论，但也绝不简单 — 为用户存储和管理数以千计的任务信息、支持多账户、提供到WEB端的后台同步、复杂的过滤、排序和分组功能。通过这次的实践，我希望透过独特的视角，分析和比较为这两个平台开发GQueues应用的过程。
Android App
Sept 21, 2012
Mar 2, 2013
第一个可测的Beta版本
Dec 22, 2012
June 10, 2013
应用发布日期
Jan 31, 2013
July 18, 2013
项目总耗时
4.25 months
4.5 months
Ramp Up Time
870 hours (approx)
960 hours (approx)
Beta测试&Bugfix
Beta测试人员人数
26,981 lines
23,872 lines
我已经写了12年的代码，但这是我写的第一个Android应用，也是我写的第一个偏向数据处理的iOS应用（2010年我做过两个iOS 3上的游戏，但那两个游戏主要只涉及一些动画和蓝牙连接）。 我最后一次用Java是在研究生阶段，而我的Objective-C也仅限于那两个游戏。所以对于这两个平台，我基本上可以算是从零开始。
简单讲，只需要花一半学习iOS的时间来学习Android，我就能开始Android开发。对于Android，我花了一周时间用来看书、跟着一些教程做一些测试应用，这些测试应用包含了GQueues将会用到的一些核心功能。做完这些，我基本上算是打好了为GQueues设计架构的基础，同时也可以开始为这个项目写代码了。在接下来的一周我可以很轻松自如地基于Android做开发，而不再需要依赖某个资源去实现新特性了。
对于iOS，我同样按照上面的流程，但我花了两周时间做各种测试/实验，才让自己觉得可以开始为这个项目写一些基础代码了。其中大部分的时间都花在研究CoreData各种复杂的API上面。搞清楚怎么设置、怎么在线程安全的前提下，为每个用户集中管理和也花了些功夫，最重要的是要支持多账户（这个话题可能需要另一篇博客来单独讲讲）。为开发一个可扩展的架构花了更多时间，用于支持可被用户查看以及操作的任务表单、队列和分类。最后又过了两周（总共花了一个月）自己才能比较轻松自如地基于iOS写代码。
总的来说，Android的文档（官方文档、第三方教程、图书、代码示例、StackOverflow）质量都非常高。我从一些著名的开源Android应用中学到了很多架构上的最佳实践，如Google开放给开发者的2012 Google I/O app。此外，Android本身就是开源的，必要时我可以自己查看Android的平台代码，弄清楚一些疑难问题。虽然iOS也有很多文档，但由于iOS5和iOS6相比之前的版本改动非常大，大部分文档都已经过时，其中包括ARC入门一文（）。因此，大部分的示例代码（包括Apple官方示例）和一些问题的解决方法都是不正确的，需要使用新的方法取而代之。搞清楚这些肯定也需要花更多的时间。
从上面的统计表中也可以看出，开发GQueues for Android要比开发 iOS 版的快十分之一的时间，尽管在开发Android版的期间我重新实现了之前用于支持GQueues HTML5版的整个后端服务器同步代码。而开发一个不采用原始iOS6风格UI的应用也需要多花些时间，单单比较这个数据，Android开发就是比iOS开发快。
用到的资源
Android App
上面列出来的书其实用处很有限，因为跟大部分的技术类书籍一样，书的内容都有点过时了，而且大部分书只停留在入门级别的概念介绍。不过，在一开始的前几天看一下这些书，能够比较快地理解平台上的一些核心功能。就目前来讲，对于这两个平台，在线资源仍然是最有价值的。
接下来我只简单说一下这两个平台的开发工具，因为关于这个话题已经有很多的讨论。我不是Eclipse或者XCode的脑残粉，它们有各自的强项和弱点（其实我最喜欢的还是Vim）。Eclipse的搜索暴慢而且很繁琐。XCode Organizer的文档搜索也卡爆了。Eclipse中使用log tags（通过Android插件的logcat集成）过滤日志超级实用。两个IDE的代码补全都很不错，XCode的Interface Builder一点用处都没有（后面细讲）。不过XCode Instruments就非常有用了，可以用它做优化分析、调试等等。我开始做GQueues for Android的时候，Google还没发布Android Studio，不过在GQueues的后续更新版本中我会拿它来试试。
如果你一边写代码一边测试，用Android的模拟器简直就是浪费时间（真不敢相信它能慢成这个鸟样）。在开发过程中，我都是直接部署到真机上测试的，用真机快很多。iOS的模拟器则很不同，跟Android相比简直就是火箭跟蜗牛赛跑，这也让整个开发过程更加高效。每写一小段代码我都会在模拟器上跑一下，等到整个功能完成了我就会部署到真机上玩玩。
对于Android，我有各个版本的测试机器（除了Gingerbread，即Android 2.3），除此之外，就要倚靠beta测试过程中各种设备的覆盖了。对于iOS来讲就要简单很多了，我只需要拿GQueues需要支持的最旧的和最新的机器来测试就够了。
Android App
Samsung Infuse (Froyo 2.2)
Nexus S (ICS 4.0.3)
Galaxy Nexus (Jelly Bean 4.2)
Samsung Galaxy Tab 10.1 (Honeycomb 3.2)
Nexus 7 (Jelly Bean 4.2)
iPhone 4 (iOS 6)
iPhone 5 (iOS 6)
iPad 2 (iOS 6)
iPad 4th generation (iOS 6)
GQueues的其中一个需求就是必须同时支持任意尺寸的手机和平板，并且针对不同的表单元素进行优化布局。由于各种各样的设备都运行着Android系统，Android也理所当然地有着成熟的UI组件帮助开发者支持各种尺寸。例如从Android第一个版本开始，RelativeLayout提供了View之间相对布局的支持，可用于创建灵活、响应迅速的布局。另外，在Android中所有的布局都由XML定义，这设计界面的方式非常简洁、简单并且高效，试过iOS中创建布局之后这种体会就更加深刻了。
相对于Android的RelativeLayout，iOS有Auto Layout，这种布局方式比较新（iOS 6新引入的），集成到了Interface Builder(IB)中，但是太难用了。我花了好多天学习IB中怎么用Auto Layout，跟任何iOS 6开发者一样，仅靠IB为视图（View）设定各种精确的约束，完全改变了我自己的标准，这是因为IB所谓的“智能”系统时刻维持（纠正）着视图布局相对位置。我学了很多技巧，想着弥补IB的短板，但是没啥作用。最后我只能放弃IB，转而用冗长的代码实现所有布局。如果你放弃IB和富有极客范的ASCII art style来写布局，使用Auto Layout来实现还是很强大、很直接的。希望苹果在iOS 7中已经改善这些，不过我还木有试过。
如果一个应用需要同时针对小屏设备和大屏设备进行优化，最关键的就是基于屏幕的真实尺寸进行动态组合视图，这种方式被称作“适配性布局(Adaptive Layout)”，平板电脑可以在一屏中显示两个或三个视图，而手机上一屏则只显示一个视图。Android通过Fragments支持这种设计，Fragment是一个独立的、自包含的的模块，能够在需要的时候直接丢到Activity中去用。通过使用Fragments，只需要调整几行XML代码就可以让GQueues的布局适配不同分辨率的屏幕。对于我来讲，Fragments是一种非常自然的解决方案，因为它是基于面向对象里面两个众所周知的准则设计的 – 高内聚和低耦合。
通过Custom Container View Controller（你也可以用Master-Detail模板，当然这种方式宽度是固定的，也不支持个性化定制），iOS支持一屏使用多个ViewController。对于这个不成熟的特性，我觉得Apple的文档显得很复杂和不完整，最好的资源还要数Ray’s iOS5 tutorials和WWDC视频。我花了比预计要多的时间，终于搞好了在iPad上同时显示多个View、在iPhone上显示单个View的布局架构。
简单说，在Android上支持设备翻转需要做很多工作，这些工作也是最终导致很多bug的源头，而在iOS上，支持屏幕翻转只需要做一点点工作，剩下就是系统帮我们搞定了。在Android上，屏幕翻转会直接销毁现有整个视图栈（Activity栈），屏幕翻转完成后再重建每个视图。所以在GQueues中支持屏幕翻转，我需要无时无刻保存好所有当前状态，随时保证翻转后能正常恢复状态。而在iOS上，系统会帮你管理所有屏幕翻转相关的细节，唯一需要我关心的就是翻转之后，我需要调整那些没有被Auto Layout处理好的视图的位置。
“复杂”布局
网页开发上有一些常见的布局在GQueues上实现起来非常困难，不管是Android还是iOS。其中一个例子是在任务详细界面显示标签。每个标签都是变长的，在必要时标签需要自动换行。在网页上实现这个只需要设置CSS的float值就可以了。但不管是Android还是iOS对这种“流式布局”（Flow Layout）都没有原生的支持，这也意味着我需要写很多代码自己去计算和摆放这些标签，以达到“流式布局”的效果。最后Android的代码是基于的演讲内容和的flow layout实现的。在iOS上也采用了类似的方法，基于容器的总宽度，计算每个标签的宽度，最后设置auto layout的参数。对于这个布局的实现在两个平台上都耗了很大的工作量。
旧设备支持
关于Android的生态系统常被人吐槽的就是严重的系统分化。运营商推送更新的步伐总是很慢，所以现在仍有大量运行着旧系统的设备，这也就意味着如果要保证应用足够大的设备覆盖率，开发者就不能使用新版系统带来的新特性。不过好在现在针对这个问题，Android社区做了很大的努力，提供了一些用于在旧系统上支持新特性的库。通过使用Android官方的 和Jake Wharton的 Library，我几乎可以在Android 2.2上使用Jelly Bean（4.2）中所有的新特性。
对于iOS来说，支持旧系统一说几乎不存在，或者说根本就不是关键。在准备阶段我花了一些时间考虑从哪个iOS版本开始支持，而当时的统计数据显示使用iOS 6系统的设备已经达到，而当时对于放弃支持iPad一代我也有一些疑虑，因为我老爸老妈老姐用的就是iPad一代，他们将是GQueues的铁杆支持者。最后我决定还是只支持iOS 6+，这样我可以放开手使用Auto Layout，而不需要浪费大量时间实现任何过时的布局技术。当然，我解决了iPad一代的问题（至少对我家里人说来说已经解决），就是换掉他们的iPad一代，给他们每人买一个iPad四代（作者有钱银）。
数据存储和管理
对于GQueues来说，数据是核心 – 把数据保存到设备上然后同步到WEB端。Android和iOS有着完全不同的数据管理系统。Android提供了ContentProvider，它是SQLite数据库上层的一个可被继承的应用接口，作为一个结构化框架被用于所有应用的数据处理。ContentProvider学习起来比较难，搞定一个GQueues可用的实现，前期需要花很多工作。一旦搞定了第一步后面的扩展和个性化定制都变得简单多了。
一些背景信息，GQueues的web service是基于的，这是一个高扩展性的分布式NoSQL存储系统，而SQLite则是一个标准的关系型数据库，扩展性明显也比较差，但这完全不需要考虑，因为这个应用只存储一个用户的数据。（顺便说一下，架构上我采用了“一个用户对应一个数据库”的设计，这对于快速简单地实现多用户切换有重要意义，不过实现细节可能得再开一博来聊了）。不管怎么说，Android的一个很大的优点就是可以创建来支持。为了支持，搞清楚各种复杂的表关联查询和子查询也花了写功夫，但是这也让Smart Queues的加载更加高效和快速，因为过滤不是在代码里面实现的（在SQL里面）。
在iOS上，我用的是，它是iOS上的“schema驱动数据图形管理和持久化框架”，基本上它可以被看做是一个NoSQL存储，不过有趣的是，Core Data背后实际上是SQLite数据库（呃…实际上SQLite也是几个可选项中最合理的选择）。iOS也允许用户直接创建SQLite数据库，但只支持通过纯C代码来操作，对于其他iOS组件没有原生集成。Core Data的学习起来也比较困难，但最后我还是选择Core Data而不用SQLite，因为这样我可以轻松实现很多功能，包括缓存、数据模型迁移支持，还有通过 NSFetchedResultsController，可以非常简单地为界面中的table（列表）提供数据。
管理数据集的关键就是使用事务，尤其重要是做数据同步的时候 – ACID，即：atomic（原子性）、consistent（一致性）、isolated（隔离性）、durable（持久性）。Android上实现事务似很直观，跟大部分关系型数据库管理系统的实现方式是一样的，因此，保证数据完整性并不困难。另外，用好SQLite中的UNIQUE
REPLACE语句，在数据同步的过程中建表、对记录进行原子更新的时候几乎不需要做任何额外工作。
严格来讲，Core Data并不完全支持事务。通过使用单独的子ManagedObjectContexts做后台线程处理，再加上@synchronized，能够处理好数据更新和同步，同时避免不正确的写操作覆盖(overwrite)。关于，iOS给的建议帮助很小，总的来说，CoreData给我的赶脚很笨重，并没有它声称的那么好用。另外，在Android上，SQLite可以轻松实现快速加载Smart Queues，而在iOS上，所有的过滤都必须在代码中实现，就算用了大量的缓存，速度仍然很慢。
在GQueues for Android上增加强大的全文搜索功能很简单，我模仿Google I/O应用里面的搜索实现，使用了SQLite的特性。首先创建一个虚拟表，然后在一个存储了用户任务的表上设置几个触发器，由这些触发器填充数据到虚拟表。做完了这些，剩下的就是设计一个搜索界面和为搜索历史添加存储。
iOS的Core Data对于全文搜索并没有原生支持，所以我通过在谓词（Predicate）中使用LIKE语句，实现基本的任务描述和日记的搜索功能。这个实现当然没有全文搜索那么强大，但我认为它已经能够覆盖现实生活中大部分的使用场景了。
用于比较，我只会列举在GQueues中使用到的几个API。
快速添加（Quick Add）
正则表达式在实现GQueues中解析的时候扮演着一个非常重要的角色，幸运的是，Android和iOS对于正则表达式都有着原生的支持。Android中的Pattern和Matcher从第一个版本起就开始支持，同时也包含了很多正则语法，其中包括前向断言（look-ahead assertion）和后向断言（look-behind assertion）。iOS则从iOS 4开始引入类，令人高兴的是，我可以把我在Android上辛辛苦苦写好的正则表达式几乎原封不动地搬到了iOS上。
在设计界面的时候，我希望用户在查看任务详细的时候左右滑动切换。在Android上我用了 和新的类，FragmentStatePagerAdapter还处于试验阶段，并且只能通过支持库（Support Library）来使用。我花了几天的时间实现了一个绑定好数据的初级版本，同时解决了几个关于重复菜单项的bug和在数据发生变化后的处理。这些比我预想的要困难很多，要不是因为左右滑动切换任务的用户体验那么好的话，我真不想实现这个功能。iOS上的就简单很多了，虽然也有一些奇怪问题要解决，并且需要自己再加上缓存支持使滑动复杂视图的时候达到可用状态。
Android提供了了一个先进但很容易使用的speech-to-text API，只用20行代码，我就把集成到GQueues，提供了一个。但很遗憾，iOS并没有提供支撑SIRI背后技术的API，开发者只能使用第三方库，依赖键盘上的麦克风提供语音输入的支持。我找了各种第三方库，包括 – SIRI语音识别的提供商，但发现没有免费版本，收费版本价格不菲。所以最后GQueues只能靠用户自己使用键盘上内置的麦克风选项来进行语音输入，其实这也已经足够了，只要用户还记得有这么个功能。
分享/插件(小部件)
通过使用Intent，在Android上可以很容易就可以把我的应用集成到安装在用户手机上的其他应用。同样地，只需要很少的代码，通过支持 intent，我就能够让用户在其他应用中创建GQueues任务。Android同时也提供了一个小部件平台，于是我也做了几个小部件，以后还会增加一些。iOS对于跨应用集成和桌面小部件的支持度为零，完全不支持这两个功能。
测试和发布
在上面的统计概况表中已经指出，beta版面向真实用户测试了一个多月。两组测试人员都非常棒，帮我找到了数十计的bug，提出了增加一些特性的建议，对一些UI上不合理的地方提出了反馈。我通过私有的Google Group组织beta测试，这样的beta测试保证了最后发布的应用对人们是真正有用的。在每次beta测试的最后，通过调查问卷我收集到了很多有建设性的反馈，也帮助进一步判断我的应用是否达到了可发布的状态。
让测试者开始测试只需要发个APK的链接，让他们下载到他们机器上（呃..他们还需要在设置界面中开启“允许安装Google Play以外的应用”的选项）。Google很方便地支持用真实用户来进行alpha和beta测试，可在中进行设置。在未来的版本更新中我想用用这两个功能。
iOS中的beta测试困难得多，就算用了服务，虽然TestFlight很大程度地简化了流程。为了满足Apple的控制欲，每部测试设备的UUID都要加到用于签名beta版应用的证书当中。因此，每次要添加beta测试者的时候，不论是添加一个人还是一群人，我都需要重新build一遍我的app。除此之外，Apple还限制了你一年最多只能注册100个测试设备。所以我要小心利用好这100个坑，这也是为什么GQueues的iOS测试者只有Android的一半。
当然，不谈谈发布流程，Android和iOS的比较都不算完，在Google Play上发布GQueues是一件很好玩的事情，只要我认为已经准备好了，我随时可以发布我的应用。点下按钮之后，30分钟内，我的应用就能在Google Play上被全世界的用户找到并安装到他们的设备上。而在App Store上发布一款应用，相信每个iOS开发者都有同样的感受，那是一个令人感到郁闷的经历。经过了数月紧张严密的编码，我只能把我的创作提交给Apple，然后等7天，7天之后审核人员花2分钟看看我的应用，最后拒绝了我的提交。我只能按要求做了修改之后再次提交，我又得等8天才在最后通过了审核。当然还有很多关于提交应用到App Store的恐怖故事，跟他们比起来，我就像是公园里逛了一圈。尽管如此，在自己的商业控制上要对这样一个“情绪化的第三方平台”做出那么多的让步，仍然让我觉得很不爽。
获胜的平台
从上面的分析来看，做GQueues的过程中，并没有出现平台A完胜平台B的情况。Android和iOS在某些领域各有千秋，也都有需要改进的地方。从这两个平台的历史来看，貌似目前Android势头更猛一些，不止体现在市场占有率上，而是看到了Android近两年在UI上的改进和开发平台的稳步提升。而Apple则是封闭的王者，我也坚信他们在很努力地做着他们认为是下一代移动计算革命的事情。不管怎么说，当我想想这6年间所兴起的app生态圈，我为自己在这个移动技术快速更新的时代，能在这两个平台上做开发感到荣幸。
关于作者：
可能感兴趣的话题
很不错的分析贴
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2016 伯乐在线iOS 和 Android 的后台推送原理各是什么？有什么区别？
按投票排序
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。（更多请看本回答评论区里面
的补充）所以你大概看出来区别，iOS 的消息推送机制面世之时是一种全新的解决方案（堪称平台中的平台），应用本身不能有常驻的后台进程，系统的开销少，内存使用更少，电量也更少（把更多的运算和资源开销放在云端，非设备端）。而 Android 的特点，虽然开销大，优点是更稳定快速，但不明显。更多请阅览话题：APNs - 知乎 | 以及开发文档：Apple Push Notification Service (APNs) |
我感觉以上的回答，并没有正点地谈到“原理“，并且我对其评判断观点也不认同，所以尝试来回答下这个问题。我的观点是：APNs 是 iOS 成功的一个非常重要的设计！先说原理。iOS 的推送：就是 Apple 官方的 APNs （Apple Push Notification service）。Android
的推送：Google 官方的是 GCM (Google Cloud Messaging）。本质上，APNs 与 GCM 是类似的技术实现原理：即系统层有一个常驻的 TCP 长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。这里对于大部分人来说，最不理解的就是，休眠时候都保持在那里的 TCP 长连接，不会耗电很厉害么？答案是：不会。这是手机的设计来做到的。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。这里有篇文章以 Android 为例做原理解释：再说 APNs 的设计成功处。iOS 为了真正地为用户体验负责，不允许应用在后台活动。有了这个限制，但是对于终端设备，应用又是有必要“通知”到达用户的，随时与用户主动沟通起来的（典型的如聊天应用）。这就是 APNs 的逻辑所在：iOS 自己做个长驻后台保持连接。所有应用，有必要（申请）并且被允许（用户可以改设置）的话，可以通过 APNs 中转到达用户。这样就完善了！有可能很多人没有真正地体会到 iOS 不允许后台应用的好处。我是 Android 开发人员，Android 手机上一般只保留几个常用的应用，不常用就卸载。但是我的 iPhone / iPad 上则是，除非空间不足，一般不会删除应用。Android 就像 Windows，你要真的很费心去维护：有软件在干背后干坏事么？设备又给拖慢了，要清理。要考虑杀毒了。。。Android 因为后台可以长驻，尤其是国内的 Android 的手机上 Google自家的推送服务 GCM 处于基本不可用的状态。所以，各App各显神通。聊天类应用的话，大多数直接借用 XMPP 规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与 APNs / GCM 没有本质的区别，但有一定的技术门槛。而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现。其实，国外如 Urban Airship 自己实现了 Android 上的第三方提供的推送平台。近期国内如极光推送也实现了第三方的推送平台（技术与微信、GCM、APNs类似）。理论上，如果一个 Android 设备上多款应用都使用极光推送这种第三方推送平台的话，也可以如 APNs 一样达到节省电量、流量消耗的效果。
iOS 的推送iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。然后，系统分别通知这些 Apps 。这个消息的内容是这样的：应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。 因为：1 使用久经考验的协议，技术风险小。2 苹果勇于承担责任：他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。这，只能说是公司决策者的功劳。（从侧面说明有个懂技术的 VP 是多重要。。。而 Scott 走人了。。）他们带给用户的好处也是实实在在的。1 安全。只有登录过的开发者可以通过苹果的服务器推送。2 快速，稳定，可靠。苹果掌控推送服务器和 OS 。3 更省电。4 让整个系统的体验更统一和简单。不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。5 开发容易。当然，开发者还是要做些事情，比如维护个服务器什么的： 。但是复杂度无疑降低很多了。Android 的推送Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。用户的电池？ Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是：没人真正为用户的电池负责。但是， Google 的方案也并非全是悲剧：也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。最后的话强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。所以，如果说苹果的推送方案有何创新？我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有 BB 的专用网络， Kindle 的全球 3G ）个人相信，担负起这些“额外”的责任，是值得的。。。只要是为了用户。PS勇于承担责任的公司也更像个可靠的成年人，而不是一个随意胡闹的孩子。
可参考这个：另外，google最近开始提供一个叫做GCM(google cloud message)的服务，如果一个应用的推送采用这种模式的话，就和 讲到的iOS推送一个样了。GCM相关的程序应该是集成在所谓的Gapps中。 除了GCM外，还有别的公司提供android的推送基础设施的服务。
现在手机主流的几个平台都有自家提供Push的功能，让应用开发者能够很方便地把Push能力集成到应用中。Android 上有 GCM (Google Cloud Messaging）iOS 上有 APNs（Apple Push Notification service）Windows Phone 上有 MPNs（Microsoft Push Notification service）。但是由于Windows Phone的市场占比不高，所以一般也就没有人会专门做wp系统的推送。至于Android的GCM在国内基本上是不可用的。原因主要有以下两点： 一、国内大部分Android手机都不带Google服务，也就用不了GCM，这是主要的问题。 二、在国内Google的服务一般都不太稳定，原因你懂的。所以现在在做消息推送的时候Android平台采用服务器与设备直接拉一条长连接的方式实现功能，而IOS平台则采用苹果自己的APNs服务。在分别说这两个平台推送原理的时候，先回答一下题主关于服务器如何先找到设备、再找到app的问题。每一个设备都有一个自己的设备号，而设备中的app又都有一个唯一的包名。所以服务器只需要找到设备号与包名就可以定位到某个设备的某个应用，而这设备号与包名会一起构成一个标识符，叫做device_token，因此问题就简化为把device_token与消息内容等信息交给服务器，服务器把内容发到唯一的device_token上。这就好像你在上海要通过顺丰寄送一个快件儿给某某小区的某某房间，那么快件儿首先会邮递到顺丰公司在北京的总站点，之后再根据小区的地址投递/路由到某某房间，这样一个寄件过程就算完成了。在这里，你要寄送的快件儿就是你要发的“消息”，送达房间相当于最终“接收消息的App”，顺丰公司在北京的总站点相当于这里提到的“设备”，送达房间的房间号就相当于这个环节里面提到的“包名”。接下来分别简单说一下这两个平台的推送实现原理。首先是IOS平台，IOS的推送是通过苹果自己的APNs服务进行的，用户需要将device_token以及消息内容等推送信息交给APNs服务器，剩下的均由苹果自己来完成。iOS应用的推送大部分情况下都要依赖苹果生态提供的APNs（）服务。下边用两幅图来简要说明其推送原理首先作为设备标识的device-token是由APNs颁发的，App开发者或者第三方推送平台(图中的Provider)做的工作是收集这个device-token，APNs的推送是要求基于APNs颁发的device-token来推送的。只有正确的device-token会被APNs接受，如果是一个错误的、或者无效的device-token(比如App已经卸载了)，APNs就不会接受。接着开发者使用第三方推送平台（图中的Provider）在将推送内容与范围选定之后进行推送，第三方推送平台将信息提交给APNs，剩下的操作全部都由APNs来进行完成，整个过程第三方推送平台就不能控制了。但是如果提供的device_token是失效的（app被卸载、系统版本升级导致device_token变化等情况）那么推送过程就会被中断，频繁的断线重连甚至会被APNs认为是一直DoS攻击。详情可以参考接下来是Android平台，Android平台在不使用GCM的情况下就需要将自己的服务器或是第三方推送服务提供商的服务器与设备建立一条长连接，通过长连接进行推送。但是不建议自己设置服务器实现推送功能，一是因为成本太高（开发成本、维护成本），自己搭建的服务器无论是稳定性还是速度上都比不了第三方推送服务提供商的效果。另一个是因为自己的数据量较小，使用第三方推送服务提供商可以用他们的维度进行推送，实现精准推送。友盟推送就是做的比较好的，可以根据用户分群、地区、语言等多维度进行推送，最大程度减少对于用户的干扰，仅把消息推送给相关用户。下图是Android平台消息推送的简单示意图。开发者通过第三方推送服务提供商将信息直接下发给需要的设备，第三方推送服务提供商与设备建立一条长连接通道，并且将消息路由到APP中（图中的设备1与设备2），对于像设备3这种无网络连接或是没有成功建立长连接通道的设备，会在设备3连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息，保证消息不会丢失。对于消息推送想要了解更多，可以关注各推送服务提供商（友盟推送、百度云推送、极光推送等）的官网及论坛。、
以jar的方式出现，集成于第三方客户端，解析第三方下行的数据，并把结果透传给第三方客户端；也可以上行第三方定制的客户端信息。服务器：一侧负责维护与成千上万的个推SDK的长时连接，另一侧与第三方服务器对接，将第三方定制数据下行推送至个推SDK。第三方服务器：数据推送的发起者，通过对接服务器，将数据发送至第三方客户端。第三方客户端：第三方集成SDK的客户端，推送数据正真的接收者和展现者。
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。推送服务因为支持平台的不同和链路，耗流量等指标不同而受众也不同，这里有很多的推送服务，你也可以通过他们的特点和配置过程了解对比下，
听楼上说的苹果的推送机制很好用的样子，为什么我同学IPHONE QQ在线，我给他发消息，过了一个下午他才被推送到
Android的消息推送有AndroidPN，极光推送，推聊等，可以看下这个
大概可能也許是這樣吧
已有帐号？
无法登录？
社交帐号登录}