安卓厂商瞎搞后台机制，谷歌罕见震怒！

杀后台，是安卓系统永远绕不开的一个话题，这个话题有意思的地方就在于有的人痛斥杀后台让他无法得到流畅的日常使用体验，而有的人则是痛斥 App 的后台驻留，破坏了自己的日常使用体验。
随着不少手机厂商将手机的运行内存提高到 12G，甚至 16G 的时候，杀后台的问题也再次成为了热点，拥有如此大内存的手机，真的还有必要杀后台吗？实际上，不仅仅是用户为此头疼，软件开发者和安卓系统的开发者谷歌也在为此头疼。
近日，谷歌就正式启动了针对第三方定制系统杀后台的情况调查，希望软件开发者能够提供相关的信息给他们，他们将在汇总完信息后，找到相关系统的负责人，探讨如何让用户的体验得到更好的保证。




对于谷歌来说，杀后台的问题其实更多的原因并不在安卓系统身上，而是各大定制系统厂商根据自己的需要所制定的一系列后台管理机制。
至少就安卓系统本身，他们对于系统后台的管控并不严苛。按照谷歌发布的原生版安卓的设计，只有当系统回收了所有的缓存后发现依然不足以提供足够的内存来维持系统和新 App 的流畅运行后，才会开始根据打开顺序强制关闭部分 App，将他们占用的内存回收。
而在近期，也许是开发者们的投诉终于累积到了一定的程度，谷歌也决定站出来给出一些回应，另外，一部分定制系统厂商的后台管理机制可能也违反了部分的谷歌条款。



根据公开文档显示，最早在 2018 年，AOSP（Android 开放源代码项目）上就已经有开发者提交了关于定制系统厂商滥用 Android 核心权限，施行严苛的后台管控机制的文档，并且获得了不少开发者的支持。同时，一些致力于开发为特殊人士提供辅助的无障碍 App 开发者也在文档中大倒苦水，表示自己开发一款无障碍服务 App，在不少系统上都被封杀了后台运行权限，让使用这款 App 的特殊人士无法得到应有的服务。
对于一些存在视力障碍的用户来说，他们需要用到一些无障碍软件来帮助他们在没有旁人的情况下操控手机。通常情况下，类似的无障碍软件都是在后台静默运行的，而当他们的无障碍软件在后台被杀死后，这些用户将很难再次把软件打开。
如此看来，严苛的杀后台机制确实是影响到了一批用户，对于一般的用户来说，也许只是丢失之前浏览的页面而已，而对于这些特殊人士来说，也许就会成为生活中的一个大麻烦。



既然谷歌打算出手管控杀后台的问题，那么谷歌打算做什么呢？至少，目前谷歌还没有公开说明自己打算在杀后台的问题上做出怎样的限制或者要求，只是启动了一系列的调查程序，比如要求受影响的开发者提供以下细节：受影响的应用程序的名称 ?
他们观察到问题的 ?OEM? 和设备型号的名称 ?
安卓操作系统版本 ?
重现该问题的步骤，以及预期结果和观察到的结果
受影响的 ?API
他们是否能够在 ?Pixel? 设备 ( 或其他运行相同 ?Android? 版本的设备 ) 上重现相同的问题。
谷歌出手管控杀后台的问题，对于一部分用户来说也许是好事，但是从所有用户的角度来看，也许并不是没有坏处的。




这个问题，我想大家应该都知道答案，系统杀后台的原因很简单，就是为了保证系统以及当前正在使用的软件的流畅性。在前几年，系统后台的问题对于国内的安卓手机用户来说也算是一个绕不开的头疼问题，不过，当时头疼的并不是后台被杀，而是后台杀不尽。
彼时的安卓手机厂商们对于后台的管控还不像今天这样严苛，虽然在一定程度上也给出了限制，但是在国产 App 的开发者眼中形同虚设。更让人气愤的是，当时的许多 App 不仅仅自己要驻留后台，而且在唤醒后还会进行关联唤醒，将一系列用户没有点击的 App 也启动并且让他们在后台驻留。
正是因为这些问题，让当时的安卓用户几乎把刷机当成了必备技能，因为只有获取了系统的 ROOT 权限后才能安装后台管控 App，将这些一直驻留和自启的软件统统干掉，还系统一个流畅。
不过，也正是因为国产 App 肆无忌惮地后台驻留和自启，让国内的定制系统厂商只能一直加强后台管理机制，同样的，其它在国内有市场布局的海外手机厂商也是如此，甚至已经到达了宁可错杀，不可放过的程度。
除了一部分记录在案的重点软件会被系统保留，比如微信、QQ 等，其余的软件则通通干掉，除非用户提前把软件加入到白名单之中。但是，对于大部分用户来说，他们并不会倾向于主动把软件加入到白名单，不少用户甚至压根不知道白名单的存在。
以至于部分需要长时间驻留后台提供服务的 App，不得不在设置页面主动引导用户将 App 加入到白名单中。比如一些与智能穿戴设备保持连接的 App，为了能够随时反馈用户的操作和记录数据，这些 App 都是必须驻留后台的。所以如果你常常听到有人在抱怨自己的智能手表老是不起作用，那么十有八九就和杀后台有关。



另外，在后台管控方面，最为严苛的大概就是 MIUI 以及索尼，其中 MIUI 的杀后台问题在前段时间已经是闹得沸沸扬扬，同时官方也出面回复，表示将会对后台机制进行调整。实际上，MIUI 杀后台的问题主要源自上次更新版本后推出的照明弹功能，该功能主要针对的就是软件频繁自启的问题，希望能够让用户的系统变得更加流畅。照明弹功能主要针对的是 App 无下限地索取用户权限和信息的问题，针对性的返回空白信息和权限，本意并非阻止软件自启。但是，在国内有不少的软件在自启和驻留后台上使用的是将服务设置为粘性 service 的方法。而 service 正是此次照明弹重点监督的区域，于是许多软件就因此被照明弹给封死了驻留后台的可能，在用户将其缩小后，迅速被系统干掉。
而另外一部分 App 则使用的是父子进程，这部分软件则不在照明弹功能的限制范围内，所以能够在后台驻留一段时间，这也是为什么 MIUI 12 的杀后台问题只在某些软件上出现的原因。
不过，后续谷歌和 MIUI 都对开发者的困扰做出了回应，表示将会针对性的修改相关机制，保证软件的正常使用体验。不管怎么说，系统杀后台的初衷都是为了能够让用户正常的使用手机，但是如果这个机制过于严苛，又会反过来影响到用户的正常使用，确实是进退两难的一个问题。
如果想要让后台管理机制变得更合理，需要的不仅仅是定制系统厂商和谷歌的努力，软件开发商的责任也相当重大，毕竟如果不是软件开发商为了利益不停自启和强行驻留后台，也不会让系统厂商的后台管控机制变得更加严苛。




至少就目前来说，严苛的后台机制还是有必要的，特别是在一些运行内存较小的手机上，如果任由软件驻留和关联自启，恐怕是真的无法正常运行。但是在拥有 12G 甚至更高运行内存的手机上，也许可以考虑放松后台管理，让用户的多 App 使用体验变得更好。
另一方面，还是得看谷歌能否对 Android 的后台管理进行一次大改，如果能够模仿苹果设计一个类似的机制，那么后台问题也就可以得到更好地解决。
因为苹果的 iOS 系统实际上是没有后台的，iPhone 上的 App 之所以能够在重新唤醒后回到刚关闭前的状态，实际上是因为 iOS 系统保留了一段关闭时的信息快照，在 App 重新回到前台时根据快照将其还原到之前的状态，该机制被称为 " 墓碑 "，倒是颇为形象。
不过，想要在 Android 上实现墓碑机制，所面临的难度恐怕相当大。

『本文转载自网络,版权归原作者所有,如有侵权请联系删除』