不知不觉间 Android 陷入了一个关于「后台」的怪圈：一边各大厂商陆续推出了 12G RAM 的手机，另一边你刚刚放到后台的下载任务没有如预期那样后台挂机下载，打开微信发现还得陪启动画面的孤独小人共赏蓝色星球，按照教程辛辛苦苦做了半个小时的 Tasker 规则、却没有按照计划自动执行……
于是一个耳熟能详的句子开始在我们脑海中成型——我的后台又被「杀」了。
应用开发者的「控诉」
如果你第二天早上醒来发现睡眠追踪应用里的记录数据「一马平川」，并不是因为你「睡得死」，而是睡眠追踪应用根本就没有正常工作。
遇到上述问题的人不止你一个，很多人选择向这些应用的开发者反馈问题，殊不知问题其实不在应用本身。
Android 平台著名睡眠追踪应用 Sleep as Android 的开发团队 Urbandroid Team 不堪其扰，索性上线了一个名为「别『杀』我应用」的网站，矛头直指手机厂商糟糕的后台管理机制。
以三星为例，Urbandroid Team 称，三星的部分机型在升级到基于 Android 9 的 One UI 后「杀后台」现象变得尤为严重，自适应电池〔Adaptive Battery〕机制相比原生 Android 变得尤为激进，3 天内没有启动过的应用甚至无法从后台再次启动。最为糟糕的情况是，如果你安装了一个可以自动跳过周末的第三方闹钟，那这个闹钟应用很有可能不会像系统闹钟那样在下周一早上准时响起……
正如「别『杀』我应用」网站上控诉的那样，拥有类似机制的还包括华为、一加、小米、华硕等等手机厂商的定制版 Android 系统，它们管理后台的方式大同小异，但都秉承着 iOS 上那一套「划掉就杀掉」的原则——当我们把某款应用的任务卡片从多任务界面划去，它们也就彻底从手机后台中抹除掉了。
找出手机「杀后台」的元凶
开发商 Urbandroid Team 在遭遇诸多用户不明就里针对应用给出差评后，除专门制作了网站 Dontkillmyapp 来表达对于「厂商行为，开发者背锅」这一现象的不满，近日该团队又推出了一款同名应用来进一步指导用户手动改善手机杀后台这一情况。
DontKillMyApp 的主界面会给出用户当前机型的基础信息，如厂商名称、机型代号、当前运行段系统等。此外和网站一样，应用内同样针对应用后台莫名被杀这一情况作出了解释并给出了几个通用性的解决方案。
当然，如果我们想要搞清楚自己的手机厂商到底对应用做了什么限制，不妨用 DontKillMyApp「跑个分」吧。
应用的测试原理很简单，应用会启动一个前台服务，这个服务的主进程中包含了唤醒锁、周期计划任务、闹钟等项目，通过监测这些项目的实际工作情况和预期运行状况得出「杀后台跑分」数据。
DontKillMyApp 的测试时长从 1 小时到 8 小时不等，我们可以根据自己的耐心程度来选择，毕竟应用建议我们在测试期间不要使用手机或是给手机充电。
经过漫长的等待后，最终测试结果会以图形 + 百分比的形式呈现出来，这一百分数可以帮助我们衡量手机杀后台的程度，数值越低则说明手机杀后台现象越严重。
你可以通过 Play Store 下载使用 DontKillMyApp。
这里你可能会问很多问题：
- Android 运行内存越来越充裕，为什么会有如此严重的「杀后台」现象？
- 原生 Android 也采用了一套类似的卡片多任务交互方式，有什么区别？
- Android 究竟需不需要借助「一键清理」这样的方式来释放运行内存？
我们得从一些基础的原理说起。
Android 的内存回收机制
在 官方文档 中，Google 将「不受应用自身直接控制的应用进程生命周期」描述为 Android 最为基础也最为独特的核心特性，这里我们不妨将「应用进程生命周期」临时理解为文章开头和第一部分所说的「后台」或「后台进程〔process〕」。
所以 Android 应用的后台进程去留本应是由 Android 系统来决定的。
当可用运行内存空间不足时，Android 系统会自行决定对特定应用后台进程占用的空间进行回收释放，这个过程中 Android 挥舞着的那把大刀，叫做 LMK〔Low Memory Killer〕。那 LMK 又是如何判断哪些应用可以被「杀」掉、哪些应用又该临时放过的呢？
每个应用都有各种各样的组成部分，其中特定组件的运行状态共同组成了一套供 LMK 进行内存回收的「优先级」参考，包括：前台进程、可见进程、服务进程和缓存进程。
前台进程、可见进程和服务进程往往与我们正在手机上执行的操作直接或间接相关，比如正在前台供我们交互和操作的活动窗口〔Activity〕、正在通过广播接收器〔BroadcastReceiver〕等待触发的 Tasker 规则、正在后台通过 Wi-Fi 网络自动上传备份照片的 Google Photos 以及前面提到的有待触发的闹钟等等。这些进程优先级从高到低依次递减，LMK 一般不会触及。
缓存进程则是那些临时放在运行内存中的部分，也是和本文探讨话题主要相关的重点。
在一个正常运行的〔Android〕操作系统中，缓存进程应是内存管理机制唯一需要交互的部分：一个运行良好的 Android 系统通常会在运行内存中暂存多个缓存进程以随时调用，提高应用间的切换效率，同时对那些较为老旧的不活跃进程进行有计划的回收。
只有在极端情况下，比如 Android 系统在回收掉所有缓存进程后发现空闲内存依然不够用〔比如在低内存的「老爷机」上运行《崩坏 3》〕，这时 LMK 才会根据优先级继续对服务进程、可见进程和前台进程采取回收策略。而当这些我们在正常使用中能够直观感受到的进程都不得不被被回收时，文章开头提到的微信重载、音乐中断、下载消失等等现象也就出现了。
谁动了你的后台
在可用内存充裕的情况下遭遇「杀后台」现象，一方面可能是 LMK 这把「大刀」出了问题〔常见于 Android 9 时期的 Pixel 3 用户〕，另一方面则有可能是其它规则额外干预了 Android 系统正常的内存回收机制。
这里提到的「其它规则」主要有两种形式，一种类似部分华为设备上预装的「省电精灵」，它会将所有没有加入后台白名单中的应用后台统统清除，另一种则依托于 Google 推出的后台检查、后台限制和自适应电池等功能进行「魔改」，让这些功能的实际效果远超预期，甚至达到意料之外的负面效果。
根据 Don’t kill my app! 的统计，第二种后台干预机制在三星、一加和早期的诺基亚机型中常见，这里厂商们通常会用到一种类似「白名单」的方法来进行过滤。
以三星手机基于 Android 9 的 One UI 为例，除了微信、QQ 等国内常见应用，One UI 默认会为所有第三方应用关闭「允许后台活动」这一选项，同时开启「优化电池使用量」这一功能。
部分搭载氢 OS 的一加机型则将上面提到的应用进程进行拆分，除了基于原生 Android 的后台限制、电池优化，还有一套名为「自启动管理」的设置来对应用的自启动进行管理以及一套名为「深度优化」的电池优化机制，后者会造成很多智能手表、手环设备在一段时间后丢失与手机的蓝牙连接，最终导致睡眠追踪、运动记录等等功能的失效。
问题在于上述功能埋藏较深，一般用户在安装应用后往往不会第一时间前往设置，一加的氢 OS 更是以系统更新之后自动重置部分用户设置闻名，那些需要在后台正常工作的应用，因此也被都被直接扔进了原生 Android 中用来限制「毒瘤」应用的「黑箱」里。
换句话说，国内大部分定制 ROM 在后台管理这件事情上都选择采用一种「宁肯错杀一千不肯放过一个」的做法。
多任务管理还是后台管理？
从某种程度上来说，国产手机厂商在 Android 后台管理上的做法虽然偏激，但它们都是国内特殊生态下的产物 。
一方面，尽管 Google 为 Android 设想了一套非常理想化的应用运行与后台管理机制，但大多数于原生 Android 中行之有效的后台管理机制在国内似乎都会变成「鸡肋」。
如果 Google 有 100 种提升 Android 应用运行效率，保证后台绿色、纯净的方法，国内毒瘤应用开发商就有 101 种绕过这些限制的方法。
借助共用的第三方推送服务实现链式唤醒、借助透明的悬浮窗保证后台存活、通过不断获取定位的方式来避免进程被系统回收……
不管是出于实现消息推送这样单纯的目的还是为了不断唤醒用户设备以实现 KPI 目标这种下作的行为，在国内 Android 生态中均有出现。
虽然国内外的具体环境有所不同，但这类设计不规范的 Android 应用带来的问题却是一样的，这类应用放在后台不仅不会为我们带来便利，反而还会因为频繁唤醒设备带来不小的耗电问题。
待机续航问题作为悬在国产 Android 机头顶的几把利剑之一，手机厂商不得不各自从系统层面推出自家的应对机制——这就有了上面提到的各种偏激式的后台管理方法。
另一方面，这里还涉及到一个非常重要的概念区分：多任务管理和后台管理究竟是不是一回事？
国内 Android 生态由于早期受 iOS 影响较深，无论是开发商还是用户都更倾向于把「将应用卡片从多任务列表里划掉」的行为理解为清除对应用的后台进程。
在上面提到的特殊生态环境的影响之下，这里被清除的后台进程往往又包括那些用于保证应用后台运行的可见进程、服务进程乃至前台进程在内。
在酷安应用市场，甚至还有得以在原生 Android 上实现类似「划掉卡片即停止运行」效果的应用，iOS 的后台管理理念在国内有多么深入人心可见一斑。
但这种后台管理理念却与 Google 对 Android 的多任务管理设计方式相悖。Google 一直以来都将 Android 手机上呼出任务卡片的那个界面叫做 Recents，最近几个版本的 Android 系统更是将其本地化为「概览」。
结合 Google 在 Android 9 和 Android 10 手势交互上的变革，注重多任务管理而非后台管理的意图也越发明显。
当最近运行的应用以一张张卡片的形式呈现在我们面前时，Google 想要呈现的是一个能够让我们在不同任务间快速切换的多任务交互，而在理想状态下，后台管理则是交由系统处理、完全不应被用户感知的。
至于如何理性看待 Android 平台的后台管理，这里我们不妨借用绿色守护开发者 @OasisFeng 在「Android 多任务界面的划除交互」这个话题上的 答疑 来回答这个问题：
Android 从 8.0 开始大幅度调整了应用的后台控制策略……原则上，只要适配了 Android 8+ 的应用，就不能再持续在后台占据内存……至于耗电，这是一个需要平衡的取舍，你如果的确需要某个应用的后台机制，那就得让它略微耗一点电〔不能既要马儿跑得快，又让马儿不吃草吧〕。
如果你压根不需要它的后台机制，或者它的后台耗电太过分了，那么你可以在应用设置中限制应用的后台能力〔非原生系统可能不一定有这个选项〕。
总之，你并不需要「杀应用」，也没必要为这些破事儿操碎心。
这种关注多任务管理、将后台管理主动权交还给系统的理念，随着本月初 Android 10 的正式放出还将得到进一步强化——Google 将不再允许预装 Android 10 的手机通过清除多任务卡片的方式来终止后台进程，这个要求同样也被加入了 Google 的 CTS 认证流程。
换句话说，今后绝大部分需要在海外市场搭载 Google 服务上市的手机都必须满足这个要求。
小结
就在上周三〔9 月 25 日〕，酝酿已久的安卓统一推送联盟正式宣布收到华为、OPPO、一加和 realme 四家公司的进度确认，虽然 Google 的缺席也让国内 Android 生态也变得异常复杂，但国内 Android 设备也能用上的统一推送服务也算是终于迈出了具有实际意义的第一步。
只是距离转变人们对 Android「杀后台」这件事的看法依然还有很长的路要走。事实上，国内早在四五年前就出现过一次对「Android 需不需要『杀后台』」问题的科普，但收效甚微，盲从 iOS 设计风格和交互逻辑国内 Android 厂商要负很大一部分责任。
希望靠谱、省电的统一推送系统能成为改观的第一步，那个甚至可以跨越设备重启恢复「后台状态」的理想化生态早日到来——至于当下，我们依然只能见招拆招，遇到应用无法正常执行后台任务时打开手机设置仔细翻找、设置，把它们扔进白名单或是给它们的后台卡片套个「锁」……
