真正的后台是要付出代价的
再来说说Android。Android系统的运行方式是这样的：当你运行了一个应用，就进入了该应用相应的层面；当你又运行了一个应用时，就又进入了这个应用的层面。新的层覆盖在旧的上面，相互叠加，周而复始。谷歌为开发者提供了7个API，来调整应用层之间的切换和运行，它的用途主要是用来设置如何切换，以及切换后要做怎样的操作。
当新的层活动时，会叠加到下面的层上，下面的层就会冻结，或者说是被挂起。新的层处于激活状态。这时按返回键的话，所有不可见的层就全部被冻结。
在Android系统后台冻结中的应用
在后台运行上，谷歌提供了两种解决方案：
服务类（Service）：
可为应用提供一个内容由程序自身决定的服务，应用可以将需要在后台执行的操作写入服务中。当这个应用被切回后台，它的所以活动都被冻结。但写入服务的那些操作仍然可由系统继续执行。如QQ这样，只运行该应用的某个活动。
广播接收类（Broadcast receiver）：
它可以让应用在后台完整运行，而不像服务类，只能运行某一部分活动。但前提是应用必须给系统一个既定的运行时间和目标，当应用消耗完时间，或达成了目标后，系统就会结束并冻结该应用的所有活动。这个类普遍存在于闹钟和GPS类的应用当中。
当然，这两种类并不是随便给予的，还是要有一定限制条件，在某种用途中可以指定分配服务类或广播类。广播类还会根据需求限制最大时间，从而防止被应用随意使用，造成系统拖慢。
理论上Android系统没有运行程序的数量限制，只要内存足够，可以无限制的开启任意多个应用。最后，当后台中运行的应用越来越多，运行内存吃紧，系统便会强制结束冻结中的活动。优先结束没有服务类和广播类的活动，其次是服务类，如果内存还是不够，最后就会结束广播类的活动。
总结：
从上面两个系统的多任务的描述来看，IOS和Android都是支持多任务的，而且机制几乎相同——大体上都是，前台运行后台挂，特殊情况有权限。
比较起来，Android系统给予应用的特殊权限比IOS要多些（这也是为什么IOS用起来比较顺滑的原因）。这还得说IOS有比较先进的推送系统，而Android就比较惭愧了。
所以为了让更多活动及时的从后台推送到前台，Android就必须让更多的应用在后台运行，也就需要占用更多的内存和处理能力，自然需要付出更高的电力和更好的硬件作为代价。
