[2022 更新] 管好 Android 应用后台，Thanox 基础使用教程
2022 更新：，刚好一整年后，Thanox 在这过程中变化不小。新增 Magisk 模式激活 Thanox，修改了部分 Magisk 24 后 Zygisk 与 Riru 分家后影响的描述。
从 Android 9 更新待机机制、新增「应用限制」开始，我一度也认为 Android 后台管理将不再需要第三方工具协助也可达到一个可接受的状态。但且不提部分深度定制 ROM 隐藏「应用限制」开关，许多国产 ROM 还会给某些毒瘤 App 开后门、加入白名单等。
由于各种原因不得不接触些毒瘤 app，在每次给手上 Android 设备初始化的时候都会顺手装个绿色守护，然后让它管理所有应用的所有后台行为，并把一些不打开就完全不需要它有任何行为的 App 开启系统的「应用限制」。绿色守护较为温和的后台介入策略让我放心将所有 App 添加到需要它管理的名单里，也不用太担心它会杀得太过。
然而，绿色守护在 Android 11 上的黑屏 Bug 十分影响体验，再加上黑屏一小时 10%+ 的耗电甚至让我怀疑它究竟有没有在工作。没办法，至少现在后台还是不能放着不管，我开始寻找其它替代品。黑阈 算是同类产品中比较有名气的了，也经常被拿来与绿色守护比较。但不知黑阈是有何特殊理念，ADB 模式能免费用的功能 Root 模式却要支付专业版才能用，虽然价格一样且一次付费解锁所有功能，但……还是算了吧。
最后，还是在论坛上不经意留意到 Thanox，好家伙，同样有划掉后台卡片即杀死进程的后台管理逻辑，除此以外还有一系列管理应用的使用工具，算是比较好地继承了「应用管理」的衣钵。折腾大概一周时间后，我决定弃用绿色守护、完全依靠 Thanox 管理应用行为。
初始化
想要用上 Thanox 可不是那么轻松，特别对于还没怎么折腾过 Android 的用户来说。这一部分将不厌其烦地介绍从最初状态到顺利用上 Thanox 全流程。
安装 Magisk
上一代 Root 神器 SuperSU 止步 Android 7，万能框架 Xposed 停于 Android 8。
而这两位的接班大旗竟被同一人抗下——Magisk。Magisk 的挂载机制，让 Root 更为优雅，同时还支持刷入模块。
为了能让 Thanox 充分发挥功效，仅靠系统给的那点权限恐怕远远不够，还是需要动动手争取更多，Magisk 肯定是绕不过的啦。
这里介绍两种安装 Magisk 的方法——卡刷与线刷。但不论用哪种方法，都需要你提前解锁 Bootloader 才能继续操作。
九成的劝退 Android 玩家不是不会操作，而是连 Bootloader 都不被允许解锁。
——《这次 OTA 翻车后，我开始思考退烧这件事》ChrAlpha
卡刷
与 ROM 的卡刷类似，需要将 Magisk 安装包 传到手机内置储存卡里，然后借助第三方 Recovery 进行刷入。
较为著名的第三方 Recovery 有 TWRP，你可以在 TWRP - Devices 页面中看看你的设备是否有官方支持。若否，也可以前往 XDA 论坛 上找找有没有其它第三方 Recovery 替代。截止本文写作时，TWRP 还未支持 Android 11，Android 11 用户只能通过线刷安装。
（如果已经配置好 ADB 环境的请跳过这一步，且之后的命令不需要加相对路径符号）在电脑上 下载 platform-tools，然后在解压好的文件夹内打开命令行。将刚刚下载好的第三方 Recovery 放进这个目录，不妨改个名字方便后续输入，注意别手贱把文件后缀改了。
手机进入开发者模式（连点 7 下版本号），打开 USB 调试并用和规格的数据线将手机与电脑相连。输入命令检查连接情况：
./adb devices第一次连接需要在手机上确认。之后输入命令进入 Bootloader 页面：
./adb reboot bootloader由于近几年发布的手机大都支持 A/B 分区，直接用 fastboot 刷入第三方 Recovery 可能在下次重启又没了。更好的方法是先驱动临时第三方 Recovery 刷入 Magisk，然后再在进入系统后通过拥有 Root 权限，的 TWRP 程序安装第三方 Recovery，这样默认在两个分区都会安装。当然，这超出本文需要探讨的范畴了。
通过命令进入临时第三方 Recovery：
./fastboot boot recovery.img最后就可以在 TWRP（或其它第三方 Recovery）中刷入手机内置存储中的 Magisk 安装包了。安装完成后重启即可。
线刷
上面有提到，并非所有设备都有 TWRP 官方支持，而各路第三方 Recovery 质量往往良莠不齐，反正我是不想涉足。更何况截止本文写作时 TWRP 仍未适配 Android 11，这就不得不采用线刷的方式。总之，线刷泛用性更广，可予以重任。
线刷稍微麻烦一点。先需要获得系统的 boot.img，可以从系统全量包中解压得到的 payload.bin 中提取，提取需要用到 Payload Dumper 这个依赖 Python 的工具。
安装 Python 环境与
protobuf（pip install protobuf）下载 Payload Dumper 核心程序
payload_dumper.py与update_metadata_pb2.py将解压得到的
payload.bin移至payload_dumper.py同一目录下然后输入命令执行
payload_dumper.py：python payload_dumper.py payload.bin
完成上述步骤后从 payload.bin 中提取的镜像会保存至该路径下的 output 文件夹内，找到我们需要的 boot.img 并将其传到手机存储中。
之后安装 Magisk Manager（无需 Root），进入后依次点「安装 - 修补 boot 镜像文件」，然后选择刚刚提取的 boot.img 镜像文件，并将生成的 patch.img（或者别的什么文件名）传回到电脑 platform-tools 文件夹下。
最后回到电脑命令行，重启手机进入 Bootloader、刷入 Magisk 修改过的 patch.img（注意文件名）：
# 重启进入 Bootloader
./adb reboot bootloader
# 刷入 patch.img
./fastboot flash boot patch.img
# 重启进入系统
./fastboot reboot这样就成功安装好 Magisk 了。注意安装完 Magisk 后，系统 OTA 更新流程需要做出调整，详情请参考《每个 Android 玩家都不可错过的神器（二）：保留 Magisk 进行「无痛 OTA」》。
安装 Thanox
单单是安装 Thanox 其实很无聊。如果你是从零开始，最麻烦的还属前面的铺垫。
Magisk v24 后更新了 Zygisk，它与 Riru 实现类似，但是两者互斥、只能二选一，LSPosed 也更新了通过 Zygisk 实现的 Magisk 模块，请留意 GitHub Release 中的文件名。
我们倒不去讨论 Zygisk 抑或 Riru 孰优孰劣，但这两者分家敦促 Thanox 加急献上 Magisk 模式。虽说文档中提到必须正确安装 Riru 框架，但是我实测 Zygisk 也可以正常激活。而这确实让只想用 Thanox 无意安装其它 Xposed 模块的用户不用再操心 LSPosed 之类的额外工具。
这里只介绍更为便捷的 Magisk 模式激活。你可以在安装完 Thanox 应用后进入「设置 - 关于 - 补丁状态」导出 Magisk 补丁模块，或者直接将 Thanox.apk 重命名为 .zip 格式补丁模块，然后将获取到的模块使用 Magisk 刷入并重启设备。
至此，Thanox 安装算是完成了。不过，为了后续能流畅使用 Thanox，建议将 Thanox 放入系统优化白名单，不同设备请参考 Don’t kill my app! 。
使用
这次我并没有深究诸如权限管理等同样挺好用的功能，主要是平时专人专用——权限管理有专门的 App 负责，就不劳 Thanox 费心了。接触 Thanox 就重要的原因，前文也有提到，就是用它来管理后台的。
相信许多其他 Thanox 用户也是如此，这里只展开 Thanox 用于限制应用后台偷跑的几种情形，以供参考。Thanox 还有更厉害且复杂的情景模式，我还没玩明白，就先不介绍了。
这个部分主要围绕「自启动」、「后台运行」、「任务清理」三个选项展开，介绍三种使用情况。理解后结合自己平时的 App 使用习惯，相信就能知道该如何设置。而玩转这三个选项，后台基本都能压住了。
首先打开这三个功能的总开关。
然后在「后台运行」的设置中关闭「不清理最近任务的应用」。
类型一：不支持 FCM 的 IM
某一天，直到 17:03 我无聊地打开微信，才收到组长 14:00 左右通知的「在 16:30 第一次集体调试」的信息时，我内心是崩溃的。
之前有和网友探讨过微信的推送，结论相当一部分是「WeChat is 💩（shit）」，还有「你还能有什么不容错过的消息吗？😂」。前者我无比同意，但环境如此我无力回天；至于后者，诚然一年下来也很少有在微信发布的重要信息，本着「足够重要的信息一定不会只在微信发布」的侥幸心理屡试不爽，但只要经历一次事故就会受不了、会频繁焦虑是否又漏了什么信息。
说回来，由于 Google（或类似 Google 之于 Android 地位的组织）在大陆的长期缺席，大陆的 Android 生态可谓一盘散沙各玩各的。安卓绿色公约、统一推送联盟画饼两三年都还仍未真正惠及用户，许多应用不愿意、或者说没有动机接入 Google 的 FCM 推送服务。甚至有微信、QQ 这种仗着体量不接入任何诸如小米推送服务等第三方推送服务的应用。想及时收到消息？行啊，留后台！
行吧，留后台！不过等等，我可没打算就完全撒手不管。这就引出这一类 App 的设置策略：「自启动」关、「后台运行」开、「任务清理」开。
还记得之前打开过「不清理最近任务的应用」吗？只要将应用留在最近任务中、不将其划掉，那么即便关闭屏幕 Thanox 都不会对这应用下手。但是只要将其从最近任务中划掉，「任务清理」就会彻底杀死这个应用。这样一来，也算是可控地将应用留在后台。
我的习惯是起床后看一眼昨晚有没有漏掉的消息，然后把 App 丢在最近任务里（没有清后台的习惯），实测确实可以及时收到消息并通知亮屏。需要休息或者专注的时候直接从最近任务中划掉这个 App 即可，免打扰都省了。
不过要注意，可以把应用加入系统优化白名单。毕竟 Thanox 留着它在后台活蹦乱跳，系统可能站起来把应用杀了。
类型二：支持 FCM 的 IM
正是由于在这个部分绕了点弯路，本文一直拖着没能发出来。不过探索的过程中算是暴露我之前关于后台的一点误解，也让我对后台有更深刻的认识。
回到最初的问题——为什么要管理后台？对，是因为耗电。我记得一晚上（不到 8 小时）耗电 3、40% 的惊悚，也记得一番整治后 13 小时息屏耗电 7% 的成就感。
那么留在 Thanox 最上方「后台运行」列表内的应用算不算「后台管理漏网之鱼」？如果单从省电角度出发，只要是在「缓存的后台进程」一列，就（几乎）不算，因为它（几乎）不耗电。
应用耗电的真正罪魁祸首是调用处理器工作，其它都是小巫见大巫。上面的表述中加上「几乎」这个限定，是因为在内存中写入数据后会周期性的施加电脉冲，刷新来保持数据。如果你真的很在乎这一点点耗电量，那就使用 Android 系统中的「强行停止（Force Stop）」完全停止应用，这样也会使 App 丧失通知唤醒的能力。
目前 Android 设备搭载 6G、8G 乃至 12G 的内存已经司空见惯。除非几个大型游戏后台运行，否则内存往往还是比较充裕的。就我而言，内存空余一半已是家常便饭。这种情况下真的没那么在乎应用缓存占用的那一点点内存空间。如果既希望 App 能及时唤醒响应通知推送，又希望 App 在没有 FCM 推送提醒时连内存都不占，这就有点不让马吃草又催马儿跑，太强人所难了吧。
前面不支持 FCM 的 IM 管理策略是两个极端——希望收到通知时就完全保留后台，即便它会一直或周期很短地频繁调用处理器资源；而不希望收到通知时就完全不保留后台，即便连内存都不让占。释放内存并不是出于耗电考量，毕竟即便将进程缓存至内存中也无法得知何时应该唤醒推送（即丧失通知能力），那还不如完全停止应用。
显然对于支持 FCM 的 IM 就不能化用类似的策略，目前我摸索出的最简单的组合是「乖巧模式」限制配合「情景模式」FCM 唤醒。此外「自启动」要打开。
「情景模式」FCM 唤醒配置的配置文件（JSON）：
[
{
"name": "FCM Push",
"description": "响应 FCM 推送",
"priority": 2,
"condition": "fcmPushMessageArrived == true",
"actions": [
"activity.launchProcessForPackage(pkgName);"
]
}
]而「FCM 推送到达」这个事实需要由「通知推送」引擎来发布，按下图操作打开「通知推送」引擎。
之后在通知到达的时候就能及时响应并推送通知。且推送完这次通知后应用的进程会被缓存，由上分析知这些缓存交由系统控制即可、无需再操心，更何况 Thanox 的「乖巧模式」也会助其一臂之力。
至于时效性，比起驻留后台推送大概会慢几分钟，但一般不会有感知。话说真要紧急到连这几分钟都无法耽搁的话，为什么不是直接打电话呢？
支持 FCM 的 IM 这类就不得不提到 Telegram 了。注意到 Telegram 设置中有 Keep-Alive Service 和 Background Connection，这两项关闭对通知推送影响不大。它们更多是保证消息最及时地推送至，但这几分钟延迟对我其实没什么影响，故没有打开。
类型三：纯工具类应用
纯工具类应用，指的是仅仅在使用的时候工作即可、不使用的时候完全不需要工作。
这类应用放心限制（毕竟不需要推送）：「自启动」关、「后台运行」关、「任务清理」开。
更进一步，对于使用频率极低的应用，还可以尝试冻结这个 App，需要的时候再解冻。还记得无法卸载的系统应用有个「停用」选项吗？「冻结」一个 App 与停用效果类似，不过是针对其他应用而非系统应用。冻结完这个 App 会使其从手机上消失，即便数据还保留着。直至下次解冻（启用）前，这个应用都不会有任何动作。
需要注意的是，这个功能是调用系统接口实现的，即便之后卸载 Thanox，已被冻结的应用依旧无法解冻，不要到时候找不到了。
后
作为 Tornaco 大佬又一力作，Thanox 算是很好地继承了「应用管理」的衣钵。但「Thanox」这个名字显然没有「应用管理」让用户对其功能一目了然。将「Thanox 教程」丢进搜索引擎，翻了几页都没能找到心仪的文章介绍下这个好用的工具。是的，有时候看教程未必真就是不会用，而只是在用之前了解它究竟能怎么用。
「能用上 Thanox 的那还需要这篇文章？」，确实，本文介绍的程度还是太浅了，能做好准备工作（刷 Magisk，借助 LSPosed 激活依赖 Xposed 框架的应用）的用户肯定不会只想看到这种程度的。那其他不能用上 Thanox 但又希望人为介入优化后台管理的用户怎么办？Android 玩机不应该建立壁垒、突出区分度，而更应该惠及每一个有想法的用户。这也是为什么本文不厌其烦地说明那些准备工作（还显得本文写作重心偏移）、为什么有这篇文章。
附录：通过 LSPosed 激活 Thanox
尽管我认为仅仅为了使用 Thanox 没必要专门安装 LSPosed，但当然有些用户还有别的需求，那么通过 LSPosed 激活 Thanox 确实可选。更何况截止本文二稿时，通过 Magisk 模块激活 Thanox 仍为实验性实现，Thanox 作者反而更熟悉 Xposed 工作。
是的，原本需要借助 Xposed 框架的应用，现在或许可以通过 Magisk 模块的刷入来实现。甚至挂载一个 Xposed 本身，从而使 Xposed 未适配的 Android 9 之后的系统也可以曲线救国用上 Xposed。
而 LSPosed 正是这样的工具，它良好地支持了从 Android 8.1 直至 Android 13 Beta 1 的系统（截止于本文二稿）。配图暂时没精力更新了，还是要信任 LSPosed 开发团队总是能第一时间跟进的。
Magisk v24 后更新了 Zygisk，它与 Riru 实现类似，但是两者互斥、只能二选一，LSPosed 也更新了通过 Zygisk 实现的 Magisk 模块，请留意 GitHub Release 中的文件名。
当然，开发团队仍在更新 Riru 模式可供选择。如果你很早开始使用 App Ops、存储空间隔离等，想必已经安装过 Riru Core。否则可以在 Magisk Manager 中搜索 Riru，或者去它们的 GitHub Releases 页面 下载模块 ZIP 文件，然后从本地选择文件刷入。
终于来到 LSPosed 的安装，完成上述准备后其实已经几近结束了，在 LSPosed GitHub Releases 页面 下载模块 ZIP 文件，然后从本地选择文件刷入。
单单是安装 Thanox 其实很无聊。如果你是从零开始，最麻烦的还属前面的铺垫。如果你之前已经就有配置好 Magisk 与 LSPosed，剩下就只需要：
- 下载安装 Thanox（从 GitHub Releases 或者 Google Play）。
- 在 LSPosed 中激活 Thanox 应用对应的模块，其中模块的「作用域」选择「系统框架」。
- 重启
关于第二点操作中的「作用域」，LSPosed 模拟的 Xposed 框架并非默认使模块全局生效，而是需要规定模块特定的生效领域，模块仅在此领域内生效，这个领域就是作用域。
这么做或许是出于稳定性考量，当然也可以在设置中默认全局生效，尽管不建议如此。
手动规定作用域的另一个好处是，对于一些不需要对系统动手脚的模块，比如仅仅是修改一个安装 App 的行为，则无需重启便能使其生效，算实现了半个模块「热启动」。
