Android 手机越用越卡？我们可能真的错怪它了
大约 5 小时前
糖直销_Orz
[核心提示] 你需要这篇科普文来告诉妹子们，为啥她们的 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 设备的灵魂，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 系统早期上线之时，就曾遭到无数的嘲笑。因为 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 设备的卡顿，影响了用户体验。
所以 Android 卡顿这个锅，被国内的那堵「墙」和被催生出的各种「解决方案」所扛起来了，当然撤出大陆的 Google 也难辞其咎。
联系客服
