cpu多核利用能够实现Android推送的吞吐量。
讲明白这点，我们需要了解Android推送的基本原理了。如果实现C(客户端)与server（客户端）实时通讯了。这里有两种思路了：
1.一种是定时去server查询数据，通常是使用HTTP协议来访问web服务器，称Polling（轮询）；
2.还有一种是移动端和服务器建立长连接，使用XMPP长连接，称Push（推送）。（按照本人理解：客户端的实现时：
while(true) { request(timeout); request(timeout); } 客户端发出一个“长”请求，如果服务器发送消息或者时间out了，客户端就断开这个请求，再建立一个长请求从耗费的电量、流量和数据延迟性各方面来说，Push有明显的优势。但是使用Push的缺点是：对于客户端：实现和维护相对成本高，在移动无线网络下维护长连接，相对有一些技术上的开发难度。对于服务器：如何实现多核并发，cpu作业调度，数量庞大的长连接并发维护等技术，仍存在开发难点。在讲述Push方案的原理前，我们先了解一下移动无线网络的特点。移动无线网络的特点：
因为 IP v4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯.如图所示：
GGSN（Gateway GPRS Support Node 网关GPRS支持结点）模块就实现了NAT功能。因为大部分移动无线网络运营商都是为了减少网关的NAT映射表的负荷，所以如果发现链路中有一段时间没有数据通讯时，会删除其对应表，造成链路中断。
Push在Android平台上长连接的实现：
既然我们知道我们移动端要和Internet进行通信，必须通过运营商的网关，所以，为了不让NAT映射表失效，我们需要定时向Internet发送数据，因为只是为了不然NAT映射表失效，所以只需发送长度为0的数据即可。注意这种定时发送的时间又叫心跳时间。 分析：Timer:可以按照计划或者时间周期来执行相关的任务。但是Timer需要用WakeLock来让CPU保持唤醒状态，才能保证任务的执行，这样子会消耗大量流量；当CPU处于休眠的时候，就不能唤醒执行任务，所以应用于移动端明显是不合适。
AlarmManager：AlarmManager类是属于android系统封装好来管理RTC模块的管理类。这里就涉及到RTC模块，要更好地了解两者的区别，就要明白两者真正的区别。RTC（Real- Time Clock）实时闹钟在一个嵌入式系统中，通常采用RTC 来提供可靠的系统时间，包括时分秒和年月日等;而且要求在系统处于关机状态下它也能够正常工作（通常采用后备电池供电），它的外围也不需要太多的辅助电路，典型的就是只需要一个高精度的32.768KHz 晶体和电阻电容等。（如果对这方面感兴趣，可以自己查阅相关资料，这里就说个大概）好了，回来正题。所以，AlarmManager又称全局定时闹钟。这意味着，当我用使用AlarmManager来定时执行任务，CPU可以正常地休眠，只有在执行任务是，才唤醒CPU，这个过程是很短时间的。 下面简单来说明其使用： 1.类似于Timer功能： //获得闹钟管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //设置任务执行计划 am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000, sender);//从firstTime才开始执行，每隔5秒再执行 2.实现全局定时功能： //获得闹钟管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //设置任务执行计划 am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 5*1000, sender);//从firstTime才开始执行，每隔5秒再执行 总结：在android客户端使用Push推送时，应该使用AlarmManager来实现心跳功能，使其真正实现长连接。 在服务器端的实现： 在服务器端，可以使用很多语言来实现，如C/C++,java,Erlang等等，如我们国内比较好的极光推送（C开发）,openfire(java开发)等等。 最近我看了极光推送的介绍和原理，下面我就说说他们是遇到什么难题，然后使用什么技术或者方案来解决呢。 当有大量的手机终端需要与服务器维持长连接时，对服务器的设计会是一个很大的挑战。 假设一台服务器维护10万个长连接，当有1000万用户量时，需要有多达100台的服务器来维护这些用户的长连接，这里还不算用于做备份的服务器，这将会是一个巨大的成本问题。那就需要我们尽可能提高单台服务器接入用户的量，也就是业界已经讨论很久了的 C10K 问题。 这是他们怎么做的了，他们是非常巧妙的利用cpu中多核的原理，利用多核来唤起了相应核数个线程了，并且利用非阻塞的消息队列的机制，大大提高了服务器的吞吐量了，这样能够是一个服务器维持200个左右的长连接了，这样有效突破了业界一个瓶颈了。可见多核实现了android消息推送重要性。相应的思维导图如下：
这就是对android推送的分析。