错怪 Android:比 iPhone 卡顿的锅应该丢给谁?

来源：android 网络用户发布，如有版权联系网管删除　2018-09-09　

[核心提示] 你需要这篇科普文来告诉妹子们，为啥她们的 Android 手机会「耗电感人」，会「卡得让人想摔手机」。

发表微博，邀请好友参加讨论。您可以 @好友昵称通知他们

相信有不少极客们对于 Google 入华都满心期待。

然而 Google 只带回来了些许 Google 服务，这让人感到十分沮丧。对于普通人来说，这些「酷酷的」产品似乎离他们太远。但 Google 推出的 Android 系统却是足以辐射影响半数以上大陆居民的「Google 服务」。Google 的服务体系不能完整地入华，意味着Android 系统设备享受不了一些 Google 功能。

举一个身边最常见的例子，小米手环一时之间风行大江南北，就连不那么极客范儿的叔叔阿姨们都会带上一个。

小米手环的「手环免密解锁」功能当时让无数人印象深刻，当时不少人啧啧称奇，但是让人遗憾的是，小米手环当时只能「免密解锁」小米手机。但谁曾想过，这个功能乃是 Android 5.0 的标配功能。

MIUI 通过修改系统底层的方式在 Android 4.4 上实现了这个功能。如果你的 Android 5.0 设备不能实现「免密解锁」功能，一定是因为没有安装 Google 服务。如果安装了「Google 服务」的极客们，不妨自己探索一下「Smart Lock」，里面提供了不止一种的「免密解锁功能」。

由此可见，作为 Google 的嫡出子 Android 操作系统，功能上的实现，在很大程度上依赖于 Google 服务，尤其是各类海外开发 App 的接口。在海外生活过一段时间的极客们，对此一定感同身受--在国外，不预装 Google 服务的 Android 设备都不能称之为 Android 设备，Google 服务的地位可见一斑。

Android:轮询与互相唤醒

作为 Android 设备的灵魂，Google 服务对于手机的影响，相信大多数不「搞机」的人，都会将之定位于「手机不正常耗电」的元凶。同时，为了确保 Google 服务常驻后台， Android 系统粗放式的「真后台」机制也为「高耗电」、「越用越卡」背上了黑锅。但这样却换来了另一个优势。常驻后台的应用能与应用开发商建立直接连接，这使得推送能够又快又及时。同时后台程序也是真真切切地在后台运行，并可以实现快速切换无需重新加载。

不过，在 Android 不断发展的过程中，Google 也意识到了 APNS(Apple Push Notification Service)的优势。为了减少 Android 后台常驻后台的数量，节省设备 RAM 资源，Google 也推出了自己的类 APNS 服务--GCM(Google Cloud Messaging)，然而由于 Android 开源特性，GCM 并不具有 APNS 那样的强制性。而且由于国内鲜有厂商内置 GMS，以及一堵无形的「墙」的存在，大陆的 Android 用户基本无法体验到它带来的便利之处。但这并没有难住天朝的开发者们，于是一群具有「中国特色」的解决方案雨后春笋般地喷涌而出。有类 GCM 自建服务器推送的，如微信;有挂靠在其他应用服务器的，如使用「极光推送」的应用。其中，推送机制还分为「建立长连接的推送(Push)」、以及「轮询(Polling)」。

当然，无论是哪一种方式，都会消耗 Android 设备的资源，无论是 RAM 方面，还是电池方面。使用过「绿色守护」的极客们，肯定注意到了有些应用会不止一个程序在运行，其中少不了的是带有「.push」后缀的程序--这是用于拉取推送的程序。

其实，这也是 Android 设备无可奈何的地方，毕竟 GCM 并不是强制使用的，而且身处墙内 GCM 推送并不稳定。但不知道，诸位 Android 用户在使用手机的时候，有没有发现如果启动了一个应用，其他应用的通知也会随之而来?这就是所谓的「互相唤醒」。在同系应用之间，简直是家常便饭。一个应用全家总动员，自然会挤占其他应用的使用资源。

更有顽固的应用即使不在活跃状态，依然拒绝被系统回收 RAM(这一部分涉及到更为详细原理，解释起来十分麻烦，表过不提)。它们将 Android 的系统资源消耗殆尽，自然难以给用户带来更好的体验。这也是为什么类似于「绿色守护」、「LBE 清理大师」、「猎豹清理大师」、「360 极客版」等等诸如此类的工具类应用的火热。更有许多极客们坚信「无 Root，不 Android」--Root 之后的设备安全性不如之前，但却将「钥匙」交到了用户手里，让用户自己「好好调教」这些流氓应用。

iOS:伪后台与真推送

早在 iOS 系统早期上线之时，就曾遭到无数的嘲笑。因为 iPhone 不存在有后台这一说法--你按下 home 键的时候，看似应用在「后台运行」，实际上，这个应用已经被「冻结」或者「杀死」了。双击 home 键看到的只是应用被杀死之前的「遗容」。相信 iPhone 用户都有过这样的感受，当你将一个游戏后台运行数分钟之后，再进去发现游戏需要重新加载。原因很简单，游戏已经被杀死，以释放内存了。这就是 iPhone 用了三代 1G RAM 却一点儿也不卡的原因，RAM 回收机制的优化。

当然，有些较真的用户表示，使用 Android 手机的时候，游戏后台运行也会被杀死。其实，游戏被杀死的主要原因与 iPhone 如出一辙，都是为了释放内存。不过，Android 释放内存并不是主动的，而是被动的--要么是被类似于「360 安全卫士」之类的管理软件给「优化」掉了，要么是因为其他的 App 自启动给顶下去了。总而言之，并不是 Android 后台被杀死，并不是其自身的主动优化。

不允许应用后台常驻让 iPhone 既节省了 RAM 又增强了续航，这 iOS 相对于 Android 的优势。可有些小白用户看到这里就不禁疑惑了，既然 iOS 不允许应用后台常驻，那为什么 iPhone 还能接收到五花八门的推送通知呢?稍微对这方面感兴趣的极客们一定知道上文中提到的 APNS，这是苹果为了解决推送问题祭出的大杀器。

简单地解释，就是如果某款应用的服务器需要推送通知，那它先推送给苹果架设的服务器，再由服务器推送给 iPhone。所以在这个过程中，苹果需要维护一个庞大的服务器以保证推送的顺利进行，开发者需要在这个服务器上注册账号，而接受推送的 iPhone 必须保证与服务器建立长连接。实现这个过程是多方协同作用的结果，这也是其伟大的地方--作为一个大企业所应有的担当。

可以说，iOS 设备是真正地实现了「推送」机制--完全是由苹果服务器将信息「喂到」iPhone 上。iPhone 用户在使用微信的时候，往往手机收到了微信的通知，能够显示消息内容，进入微信，还需要经过「连接中」这样的过程，才能读取消息。原因就在于此。虽然 iOS 推送机制看上去天衣无缝，但也不是白璧无暇。一旦苹果服务器宕机，所有的推送都得完蛋。另外，由于消息需要经过中转，设备接收到推送会有一定延迟，具体视服务器连接情况而定。而这一点正是 Android 用户骄傲之处。

移动操作系统的「两大巨擘」

尽管 Android 设备会有这样那样的弊病，Android 系统本身相对于 iOS 系统，并没有占下风。各家用户虽各有所好，相互攻讦却不是理智的行为。例如，为了解决续航问题，Android 更为直接地加大了电池容量，而 iPhone 选择的是系统优化，这本是殊途同归的解决方案，为何一定要引发双方的口水大战?

同理，iOS 系统配合自己的 APNS 既实现了推送，又省下了后台资源和电量。但由于推送需要中转，后台并不存在，在推送时效和应用切换上稍占下风;与此相对的，Android 系统允许后台应用常驻，付出了资源和电量消耗的代价，减少了应用推送上的延迟，免去了应用再加载所消耗的时间与资源。两者各有所长，不必大打出手。

而由于 Android 的开源特性，Google 拿出了 GCM 的解决方案，只是囿于大陆的网络环境和各路开发者的选择文，没有被推广开来，也不能为内地 Android 开发者所用。所以催生了一大批推送解决方案。正是这些解决方案上或多或少的弊病，导致了 Android 设备的卡顿，影响了用户体验。