抽屉最底下那台 R11s 已经躺了三年，屏幕边缘有细微的烧屏痕迹，电池健康度掉到七成多，插上充电器照样能开机、能进桌面。我把它翻出来，本来只想当个蓝牙音箱的替代品，结果两件事凑到一起，就成了这篇东西的由来：一是想给这台老机器装一套能用命令行干活的 Linux 环境，二是我一直对当年厂商力推的那套系统加速引擎（Hyper Boost）心存疑问——它到底在哪个层面上动了手脚，为什么同一颗芯片、同样 4GB 内存，开了它和关掉它，体感差异会那么大。
这两个需求看着不搭界，其实是一条线上的。你要在一台 2017 年的安卓机上跑 Linux，最大的敌人不是 CPU 性能不够，而是系统层的资源调度策略——也就是加速引擎这类机制——会在你完全不知情的时候把你的进程降权、回收、甚至直接杀掉。反过来说，把 Linux 跑起来之后，你手上就有了很多可以直接观察 /proc、/sys 的手段，反过来能把加速引擎的行为看得清清楚楚。本文适合两类人：手里有闲置老安卓机想折腾成小型 Linux 终端的，以及对安卓系统层性能调优机制好奇、想动手验证的。全文基于我在 R11s 这一代机型上的实际操作记录，涉及硬件参数和引擎机制的部分，来自公开资料和实测观察；涉及具体命令和配置的，都是我反复跑通过、能照着抄的。
1. 把两件事拆开：一台老机器凭什么值得折腾
1.1 R11s 这一代机型的硬件底子，决定了什么能做、什么做不了
先把硬件摆清楚，因为这决定了后面所有路线的可行性。R11s 用的是当年那颗中端八核平台，14nm 工艺，四个大核最高 2.2GHz、四个小核 1.8GHz，GPU 是 Adreno 512，内存 4GB 或 6GB LPDDR4X，存储 64GB eMMC 5.1，屏幕 6.01 英寸 AMOLED、2160×1080，接口是 microUSB，电池 3205mAh。出厂是 Android 7.1，后来官方推到了 Android 8.1。
这份配置里有三个点对"装 Linux"这件事影响极大：
- eMMC 5.1 而不是 UFS。顺序读写大概在 280/200 MB/s 上下，随机 4K 读写是硬伤。这意味着任何需要大量小文件读写的操作（比如 apt 装包、编译、解压 tar 包）都会明显慢于同期旗舰，你心理预期要放低。
- 4GB 内存是天花板。安卓系统本身常驻要吃掉 1.8GB 到 2.2GB，剩下的空间跑一个精简 Debian 命令行还算宽裕，但一旦上桌面环境，会非常难受。
- 官方不给解锁引导程序。这一条是致命的，我在第 3 节会详细说。简单讲：这台机器上你几乎不可能刷第三方内核或第三方系统，所有"装 Linux"的方案都必须建立在"原厂系统 + 用户态"的基础之上。
这里还有一个容易被忽略的细节：microUSB 接口供电能力有限，边充边跑高负载任务时，如果用的是劣质线材，实际输入电流可能只有 500mA 左右，边跑边掉电是常有的事。我后来换了一根支持大电流的短线，情况才好转。
1.2 系统加速引擎究竟在加速什么，别被营销词唬住
当年的宣传口径里，这套引擎被拆成三块：System Boost（系统资源调度）、Game Boost（游戏场景优化）、App Boost（应用专项提速）。营销词听着玄，落到技术实现上，它做的事情其实就四件：频率调度、内存回收与进程优先级、渲染链路的帧提交时机、以及场景识别。
也就是说，它并没有"凭空变快"，而是把有限的 CPU 时间、GPU 时间、内存页，在"它认为重要的时刻"优先分给"它认为重要的进程"。这套逻辑在玩游戏、扫码支付、打开相机时确实有效——你按下快门的那一刻，它会把大核频率提前拉起来，把相机进程的优先级顶到最前。但反作用同样明显：你后台跑的编译任务、你的 SSH 会话、你的 Python 脚本，在这套体系里都属于"不重要"，随时可能被降权或冻结。
我做过一个很直观的验证：在 R11s 上跑一个单线程的纯计算循环，前台运行时八个核有三到四个在 1.8GHz 到 2.2GHz 之间跳；切到后台不到二十秒，频率就掉到 633MHz 的小核档位，计算吞吐直接腰斩。这不是 CPU 不行，是调度策略主动把它压下去了。理解这一点，你就明白为什么后面每一节都在讲"怎么让你的进程被系统当成重要进程"。
1.3 两条路线的真实关系：一个改上层调度，一个换底层内核
很多人把"装 Linux"和"系统加速引擎"当成两件互不相干的事，实际上它们在同一台机器上是互相拉扯的关系。加速引擎工作在用户态服务 + 内核调度策略这一层，它管理的是"谁先跑、跑多久、占多少内存"。你要跑的 Linux 环境，无论是 proot 容器还是 chroot，本质上都是一堆用户态进程，天生处于这套调度的食物链底端。
所以真正的思路应该是：先搞清楚加速引擎的判定规则，再想办法让容器进程挤进它的白名单，或者绕开它的管控。这比无脑刷一个"性能优化脚本"有用得多。后面第 2 节拆机制，第 3、4 节讲落地，第 5、6 节讲我在这个过程中踩的坑和调优手段，逻辑是顺着这条线走的。
2. 系统加速引擎的四个抓手，拆到能动手验证的粒度
2.1 频率调度：从"按需拉满"变成"按场景给档"
早期的安卓调度器比较简单，负载上来就拉频率，负载下去就降频，响应快但功耗高、发热大。加速引擎这类方案的核心改动，是引入了一层"场景识别"：它不再单纯看 CPU 负载，而是结合当前前台应用包名、触摸事件、屏幕刷新状态，判断"现在是什么场景"，然后给一个预设的频率档位。
你可以在/sys/devices/system/cpu/cpu0/cpufreq/下面直接观察到这个过程。里面有scaling_governor、scaling_min_freq、scaling_max_freq、time_in_state几个关键文件。time_in_state会记录每个频率档位累计停留的时长，这是最诚实的数据源——它不会骗人。
我的实测方式是：清空统计，前台刷十分钟信息流，再切到后台静置十分钟，然后读一次time_in_state。结果很清楚，前台状态下 1.8GHz 以上的档位占比超过 60%；后台静置时 90% 以上的时间停在最低两档。这套机制对省电是好事，但意味着你后台跑的任何长任务，实际算力只有标称的三分之一左右。
提示：读
time_in_state前后做对比时，记得先把屏幕亮度、网络状态、音量都固定住，否则变量太多，数据没法解读。我头两次测出来的数据完全对不上，就是因为中间来了一条推送把屏幕点亮了。
2.2 内存与后台：LMK 阈值和进程冻结才是真正的杀手
内存这块是最容易出问题的地方。安卓的低内存回收（LMK）机制会给不同优先级的进程打分，分数高的先被杀。加速引擎在上面又加了一层"进程冻结"——不杀你，但把你挂起，你既不占 CPU 也不推进，看起来像活着，实际上已经停摆了。
我在 R11s 上跑 proot 版 Debian 时，遇到过一个很典型的现象：apt install正在装包，我切出去看了眼消息，回来发现进度条冻在那儿了，ps能看到进程，但 CPU 时间是零。这不是卡死，是被冻结了。判断方法很简单，看/proc/<pid>/status里的State字段，如果是T（stopped）或者D长时间不动，基本就是被挂起了。
真正有价值的经验是：这套判定不只看内存占用，还看进程的"前台关联度"。一个进程只要和前台可见的界面有关联（比如有一个可见的通知、或者被某个前台应用持有），被冻结的概率就会大幅降低。这就给了我们操作空间，后面 6.1 节会讲具体做法。
2.3 触控与渲染：从触摸中断到帧提交的那条链路
游戏场景优化的宣传里经常提"响应速度提升多少毫秒"，这个数字的来源是把触摸中断到画面刷新之间的链路压缩了。常规链路是：触摸屏上报中断 → 内核输入子系统 → 应用主线程 → 渲染线程 → GPU 提交 → 屏幕刷新。加速引擎的做法是在中间插入高优先级的调度通道，让这条链路上的线程跳过普通排队。
对我们在老机器上跑 Linux 的人来说，这条链路的意义不大，但有一个衍生的坑必须知道：这套机制会抢占 CPU 时间片。当你在前台滑动屏幕时，系统会临时把大核优先给渲染相关的线程，你后台的编译任务会被挤到小核上。我在编译一个小型 C 项目时，只要手指在屏幕上划两下，编译进度就明显变慢，这不是错觉。
2.4 游戏白名单机制的副作用，比你想的严重
这类引擎通常带一个应用白名单，名单内的应用会走全套加速策略。名单本身不对外公开，但通过观察行为可以大致反推：主流游戏、支付类应用、相机、主流社交应用基本都在里面；而终端模拟器、IDE、编译器、SSH 客户端这类，一个都不在。
这里有个很微妙的副作用：白名单外的应用，在某些系统版本上会被施加更激进的限制。因为系统按照"非白名单 = 非关键"的默认假设来做资源分配，你在白名单外跑重负载任务，反而比在一台没有这套引擎的机器上更难受。我在一台没有同类引擎的老机型上跑同样的 proot 环境，apt update的耗时比 R11s 少了将近四成，这个差距不是硬件造成的，是策略造成的。
| 观察项 | 前台运行 | 后台运行 | 说明 |
|---|---|---|---|
| 大核频率（标称 2.2GHz） | 1.8~2.2GHz 波动 | 长期 633MHz~1.1GHz | 通过time_in_state统计得出 |
| 单线程计算吞吐（相对值） | 100 | 约 35~45 | 同一段 C 循环，前后台各跑 60 秒 |
| 进程被冻结概率 | 低 | 高，尤其在内存占用超 1.5GB 后 | 观察/proc/<pid>/status的 State |
| apt 装包 100MB 耗时 | 约 6 分钟 | 约 14 分钟（多次中断重试） | 同一镜像源，同一天测试 |
这张表里的数字不是精确基准，环境差异会影响结果，但量级差异是真实存在的，方向也很明确。
3. 在老机器上装 Linux：三条可行路线与它们各自的代价
3.1 路线 A：Termux 加 proot，零风险但性能打折
这是最保守、也是我最后主要采用的路子。Termux 是一个终端模拟器加软件包管理环境，它不依赖 root，装在一个普通应用沙盒里；proot 则是一个用户态的 chroot 实现，靠 ptrace 系统调用拦截文件路径访问，把一套完整发行版的根文件系统"映射"成一个看起来像根目录的东西。
它的好处很实在：不需要解锁、不需要 root、不动系统分区、卸载了干干净净，出问题最多是删掉重来，不会把机器搞成砖。代价也很实在：所有系统调用都要经过 ptrace 拦截，文件操作和进程创建的开销显著上升，重度 IO 场景下性能损失能到三四成。对我这种拿它当 SSH 客户端、跑跑 Python 脚本、看看日志的用法来说，完全够用。
3.2 路线 B：chroot，需要 root 但接近原生
chroot 是内核直接支持的能力，没有 ptrace 那层开销，性能基本等于原生。但前提是你得有 root 权限，而 Android 上拿 root 意味着要解锁引导程序、刷入修改过的启动镜像——这条路在 R11s 上走不通，原因见下一小节。
就算你搞到了 root，chroot 方案也不是一键搞定。你得自己准备一个根文件系统镜像（用dd造一个 ext4 镜像，再用 debootstrap 或直接解压官方 tar 包），然后手动挂载/proc、/sys、/dev、/dev/pts，配好 DNS，最后才能chroot进去。每一步都有坑，第 4.4 节我列了完整命令。
3.3 路线 C：换内核、刷第三方系统，在这台机器上基本是死路
这条路线本来是体验最好的——直接跑一个为移动设备适配的 Linux 发行版，性能损失最小。但 R11s 这一代机型有个绕不过去的坎：官方不提供引导程序解锁通道，社区也没有可用的解锁方式，因此没有第三方 Recovery、没有可编译的内核源码、没有设备树。
我花了整整两个晚上在各种论坛翻资料，结论很明确：这台机器上想刷第三方系统，成功的可能性接近于零。任何声称"一键刷入"的工具，要么是针对别的机型，要么是拿旧版本固件做文章，风险极高。我把这条路线标记为"不建议尝试"，不是因为它难，而是因为它在这个具体型号上根本没有入口。
注意：如果你手上的老机器是同期其他品牌、官方开放了解锁通道的型号，路线 C 是值得一试的，体验会比前两条好很多。判断标准很简单——去官方开发者页面看有没有"解锁"入口，有没有内核源码仓库，两样都有再动手，缺一样就别浪费时间。
3.4 三条路线的横向对比
| 维度 | 路线 A（Termux + proot） | 路线 B（chroot） | 路线 C（换内核/第三方系统） |
|---|---|---|---|
| 是否需要 root | 不需要 | 需要 | 需要解锁引导程序 |
| R11s 上可行性 | 完全可行 | 不可行（无 root 途径） | 不可行（无解锁通道） |
| 性能损失 | 中到高，IO 密集场景明显 | 低，接近原生 | 最低 |
| 操作风险 | 极低，卸载即恢复 | 中，误操作可能损坏数据分区 | 高，可能变砖 |
| 适合场景 | 命令行工具、脚本、远程连接 | 需要跑编译、数据库等重负载 | 想当主力 Linux 设备用 |
| 我的实际选择 | 采用 | 未采用 | 放弃 |
这张表是我在动手之前画的，实际走下来结论没变。对绝大多数人来说，路线 A 是唯一理性的选择；路线 B 和 C 更适合"手上刚好有一台开放解锁的机器"的情况。
4. 实操：在 R11s 上把一套 Debian 跑起来
4.1 前置准备：先把退路留好
动手之前有三件事必须先做，一件都不能省。
第一是备份。照片、聊天记录、通讯录全部导出来。我见过太多人折腾到一半发现系统起不来，数据全在里面。R11s 的 64GB 存储里，系统分区大概占 20GB，可用空间四十来吉，够用但不宽裕。
第二是关闭系统的自动清理。设置里找到电池相关的选项，把"智能省电""后台应用管理""自动清理"这类开关全部关掉。这一步不做，后面容器跑到一半被清掉的概率极高。
第三是确认存储路径。Termux 装完后，它的主目录在/data/data/com.termux/files/home，这个路径在应用沙盒内，其他应用访问不到。如果你想让容器里的文件和你电脑上的文件互通，需要用 Termux 的termux-setup-storage命令申请共享存储权限，它会在主目录下建一个storage软链接指向共享目录。但注意，共享目录（/sdcard）在 Android 8.1 上是 FUSE 挂载的，不支持 Unix 权限位和符号链接，往里面装 Debian 根文件系统会失败——这是我在第 5.3 节要讲的坑之一。
4.2 Termux 基础环境与软件源配置
Termux 的安装渠道有讲究。应用商店里的版本往往更新滞后，而且从 Android 8 开始，系统限制了非 SDK 接口的调用，旧版本 Termux 在 8.1 上跑起来会有一堆莫名其妙的报错。我的建议是从项目的官方发布渠道下载最新的 APK，不要用商店版本。
装完之后第一件事是更新包索引，然后换成就近的镜像站点。Termux 内置了一个换源工具，直接敲termux-change-repo，它会给出一个文本界面让你选镜像组，选完自动改配置，比手动 sed 安全得多——手动改sources.list很容易把格式弄错，导致后面所有pkg命令都报解析错误。
# 更新索引并升级基础包 pkg update && pkg upgrade -y # 换源（交互式，选就近的镜像组） termux-change-repo # 换完再更新一次，确认源可用 pkg update # 装常用工具 pkg install -y proot-distro openssh git python nano curl wget这里有个小细节：pkg upgrade的时候如果提示配置文件冲突（通常出现在/etc/passwd、/etc/group这类文件上），选"保留现有版本"就行，别图省事全选覆盖。我有一次手滑全选了覆盖，结果 Termux 的用户名和 HOME 变量全乱了，只能重装。
4.3 proot-distro 装 Debian 的完整流程与常见报错
proot-distro 把安装发行版的流程脚本化了，命令很短，但背后的动作不少：下载根文件系统压缩包、解压到$PREFIX/var/lib/proot-distro/installed-rootfs/下、生成启动脚本、配置/etc/resolv.conf。
# 查看可安装的发行版列表 proot-distro list # 安装 Debian proot-distro install debian # 登录 proot-distro login debian # 登录并携带当前用户环境变量和共享存储 proot-distro login debian --termux-home装完之后进去第一件事不是装软件，是换 Debian 自己的源。默认源在境外，apt update经常卡在Waiting for headers上，一卡就是几分钟。编辑/etc/apt/sources.list，把主源和更新源都换成就近的镜像，再apt update && apt upgrade。
我自己在这步遇到过的报错，按出现频率排：
| 报错信息 | 原因 | 处理方式 |
|---|---|---|
E: Could not get lock /var/lib/dpkg/lock-frontend | 上一次 apt 进程没退干净 | rm掉 lock 文件，再dpkg --configure -a |
E: The repository is not signed | 导入密钥失败或镜像不同步 | 重新导入发布密钥，或换一个镜像 |
Failed to fetch ... Temporary failure resolving | DNS 没配好 | 手动写/etc/resolv.conf，加两行nameserver |
No space left on device | 应用沙盒空间被占满 | 清理$PREFIX/var/lib/proot-distro下多余镜像，或把根文件系统移到共享存储（不推荐） |
proot warning: can't sanitize binding | proot 版本与内核的挂载行为不兼容 | 升级 proot 包，或忽略（多数情况下不影响使用） |
那个can't sanitize binding的警告我一开始以为是致命错误，查了半天资料才发现它只是个提示，容器照样能正常跑。这种"看着吓人但不影响使用"的报错在老安卓上特别多，判断标准是：只要apt能正常装包、ls /能列出根目录，就不用管它。
4.4 chroot 方案的关键几步（给有条件的人备着）
虽然 R11s 走不通 chroot，但把步骤写下来是有价值的——万一你手上是一台开放了解锁的机器，照着做能省不少时间。前提是已经拿到 root 权限。
# 1. 造一个 4GB 的 ext4 镜像文件，放在数据分区 dd if=/dev/zero of=/data/local/debian.img bs=1M count=4096 mke2fs -t ext4 /data/local/debian.img # 2. 挂载到临时目录 mkdir -p /data/local/mnt/debian mount -o loop /data/local/debian.img /data/local/mnt/debian # 3. 解压根文件系统（这里以官方提供的 tar 包为例，解压前先清空挂载点） tar -xzf /data/local/debian-rootfs.tar.gz -C /data/local/mnt/debian # 4. 绑定必要的虚拟文件系统 mount -t proc proc /data/local/mnt/debian/proc mount -t sysfs sys /data/local/mnt/debian/sys mount -o bind /dev /data/local/mnt/debian/dev mount -o bind /dev/pts /data/local/mnt/debian/dev/pts # 5. 写 DNS cat > /data/local/mnt/debian/etc/resolv.conf << 'EOF' nameserver 1.1.1.1 nameserver 8.8.8.8 EOF # 6. 进入 chroot /data/local/mnt/debian /bin/bash这六步里有三个容易翻车的地方。第一是mke2fs之后如果直接解压，确保挂载点里确实是空的，否则老数据会混进去。第二是/dev用 bind 方式挂载，别用mount -t devtmpfs，后者在某些安卓内核上会报权限错误。第三是退出 chroot 之后要按顺序卸载，先卸/dev/pts、/dev、/sys、/proc，最后卸镜像，顺序反了会提示device is busy。
4.5 桌面环境可以缓一缓，先把命令行跑通
我见过太多人一上手就装 XFCE 或者 LXQt，最后卡在启动黑屏、内存不足、VNC 连不上，挫败感直接劝退。我的建议是：头两周只用命令行，把 SSH、git、python、tmux 这几样跑顺，把性能基线测出来，再考虑图形界面。
真要上图形界面，也别用 VNC 那套老方案，改用 Termux X11 加本地显示的方式，性能好一些。但即便这样，在 4GB 内存的 R11s 上开一个完整的桌面环境，可用内存会掉到 300MB 以下，随便开个浏览器就 OOM。老机器上跑图形界面这件事，我的态度是：能跑，但没什么实用价值，真要用还不如拿它当一个瘦客户端，把图形界面放到别的设备上去算。
4.6 实测性能数据，让你对预期有个锚点
下面这组数据是我在 R11s（6GB 内存版本）上跑出来的，环境是 Debian 12 的 proot 容器，系统版本 Android 8.1，室温 24 度，机器平放在桌面上，没有额外散热。
| 测试项 | 结果 | 备注 |
|---|---|---|
| 单核计算（sysbench CPU，单线程） | 约 62 秒完成 10000 次素数判断 | 放在 chroot 下大约是 45 秒 |
| 多核计算（sysbench CPU，8 线程） | 约 21 秒 | 大核调度上来了，但受温度墙影响 |
| 随机 4K 写（fio，QD1） | 约 1.2 MB/s | eMMC 的固有短板，加上 proot 开销 |
| 顺序写（dd，1GB） | 约 88 MB/s | 比原生慢约 30% |
| apt 安装 100MB 软件包组 | 约 6 分钟 | 前台保持屏幕常亮 |
| 解压 500MB tar.gz | 约 4 分 20 秒 | 全程无中断 |
| SSH 连接到远端编辑文件 | 无明显延迟 | 这是最实用的场景 |
这组数字看着不漂亮，但够用来干活。我日常用它做什么？写脚本、跑 git、连远端服务器改配置、临时起一个 Python 小服务测试接口，这些场景对性能不敏感，完全够用。指望它跑容器集群或者编译大型项目，那就是为难它了。
5. 踩坑链路还原：三次失败和我的定位过程
5.1 卡在 Permission denied 的那一晚
第一次装完 proot-distro，登录进去，apt update报了一堆Permission denied，指向/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/var/lib/apt/lists/partial。我一开始以为是源配置错了，换了两三个镜像，问题照旧。
排查思路是这样的：先用ls -l看目录权限，发现partial目录的所有者是u0_a2xx，权限是drwx------，而容器内看到的用户是root（uid 0）。问题就出在这——proot 做了 uid 映射，但 Android 的/data/data分区是强制按实际 uid 做访问控制的，映射出来的 root 在这个分区上没有权限。
定位过程走了三步：第一步在容器里执行id，确认映射后的 uid；第二步在 Termux 里执行stat -c '%u %a' 目标目录，看实际的所有者和权限位；第三步对比两者，确认是权限位不匹配。解决办法是把相关目录的权限放宽：
# 在 Termux 里执行，不要进容器 chmod -R 755 $PREFIX/var/lib/proot-distro/installed-rootfs/debian/var/lib/apt/ chmod -R 755 $PREFIX/var/lib/proot-distro/installed-rootfs/debian/var/cache/apt/这件事给我的教训是：在安卓上跑 Linux 容器，八成的问题都是权限映射和分区挂载属性造成的，跟发行版本身没关系。后来我形成了一个条件反射——遇到报错先看是哪个路径，再看那个路径属于哪个分区，最后看分区挂载时带了什么参数。
5.2 进程被加速引擎悄无声息地干掉
第二次失败更隐蔽。我在容器里跑一个耗时较长的npm install，切出去回了两条消息，回来发现终端还在，但命令没了，jobs也是空的。没有任何报错，没有任何提示，进程就那么消失了。
这次排查花的时间最长。我先怀疑是内存不够被 OOM 杀了，dmesg里确实有几条 lowmemorykiller 的记录，但被我杀的那个进程内存占用才两百多兆，不在被杀的列表里。然后我怀疑是网络超时，重跑了一遍，盯着看，发现在屏幕熄灭后大约四十秒，进程就没了。
关键线索是在/proc/<pid>/status里。我改成让命令在前台跑，同时用另一个终端不停采样状态，发现在屏幕熄灭后，State从S变成了T，CPU 时间停止增长，再过一会儿进程直接消失。这基本可以确认是"先冻结、后回收"的两段式处理。
解决办法在第 6.1 节详细讲，核心是三件事：把 Termux 加入电池优化的白名单、在前台挂一个常驻的唤醒锁、用tmux或nohup把任务托管起来。三件事做完之后，同样的npm install再跑一次，全程无中断。
5.3 共享存储上的符号链接陷阱
第三次踩的坑比较低级，但很典型。我嫌应用沙盒空间小，想把 Debian 根文件系统放到共享存储/sdcard下面，结果解压的时候报了一连串Operation not permitted，全是符号链接创建失败。
原因前面提过：共享存储是 FUSE 实现的，为了兼容性和安全性，它不支持 Unix 权限位、不支持符号链接、不支持设备文件。而一个完整的 Debian 根文件系统里，符号链接少说上千个（各种libxxx.so.1 -> libxxx.so.1.2.3之类的），少了这些链接，系统根本跑不起来。
我的处理方式是放弃这个想法，老老实实放在应用沙盒里。容量不够就清理：$PREFIX/var/lib/proot-distro/下面每个已安装的根文件系统大概占 400MB 到 1.2GB，装两三个就吃掉不少空间。另外下载缓存$PREFIX/var/cache/和服务日志也会堆积，定期清一下能腾出不少。
5.4 温度墙和降频，跑重负载时绕不过去
第四个问题算不上失败，算是一个必须接受的事实。R11s 是金属机身，散热靠被动传导，跑持续负载大约十二到十五分钟后，核心温度会升到 60 度以上，然后触发降频保护。我在/sys/class/thermal/thermal_zone*/temp下面能实时读到温度值，配合time_in_state一起看，规律非常明显：温度超过阈值之后，大核基本不再上到最高档位。
实测影响是：一个理论上需要 100 秒完成的编译任务，前 90 秒跑得很快，后面就明显拖慢，总耗时可能到 160 秒。这个没法从软件层面解决，物理限制。我的做法是把它当间歇性任务用，跑十分钟歇五分钟，反而总效率更高。另外机器平放在桌面上散热效果差，垫高一点、去掉手机壳，温度能降个三四度，攒下来的可用性能相当可观。
6. 让老机器跑得舒服的几个调优动作
6.1 让容器进程被系统当成"自己人"
这是整篇文章最有用的一节。前面说了，加速引擎判定优先级看的是"前台关联度"，那我们就把关联度做出来。三个动作，效果立竿见影。
第一，把 Termux 从电池优化里排除。设置里的电池相关页面能找到"不受限制"的选项，把它加上。这一步能避免系统在熄屏后给应用加限制。
第二，用 Termux 的唤醒锁。装termux-api包之后，可以调用termux-wake-lock命令申请一个部分唤醒锁，让 CPU 在你熄屏后继续保持运行状态。用完记得termux-wake-unlock释放，否则一晚上能把电池耗光。
# 申请唤醒锁，防止熄屏后进程被冻结 termux-wake-lock # 跑你的任务，建议套 tmux，断开连接也不影响 tmux new -s build # ... 在 tmux 里执行任务 ... # 任务结束后释放 termux-wake-unlock第三，有了 root 的话（R11s 上没有，但有解锁条件的机器可以），可以用dumpsys把应用加进待机白名单。这个命令不需要 root，但加白名单的效果在部分系统版本上会被上层策略覆盖：
# 把 Termux 加入待机白名单（普通权限即可执行） dumpsys deviceidle whitelist +com.termux # 查看当前白名单 dumpsys deviceidle whitelist这三招组合下来，我这边从"熄屏四十秒进程消失"变成了"熄屏两小时任务照跑"。代价是待机耗电从每小时 1% 涨到 3% 左右，我觉得值。
6.2 zram 与 swap 的取舍，别盲目开
网上很多教程一上来就教你怎么开 zram、调swappiness，我得泼点冷水。老机器上开 zram 的收益，取决于你的工作负载。zram 是压缩内存，把不常访问的页压缩后放在内存里，相当于用 CPU 换内存。R11s 的 CPU 本来就不宽裕，压缩解压的开销会吃掉一部分收益。
我的实测结论是：如果你的任务集中在网络 IO 和交互式操作（SSH、编辑器），不开 zram 更好；如果任务是编译或者处理大量文本，开 512MB 到 1GB 的 zram 有帮助，内存吃紧时能少崩几次。参数方面，vm.swappiness从默认的 60 调到 30 左右，减少不必要的换页；zram 的压缩算法选 lz4，比 lzo 快，压缩率略低但在这种场景下提速更重要。
调整 zram 需要 root 写/sys/block/zram0/下的文件，没有 root 就只能在容器里用 swap 文件，但 proot 环境下 swap 文件的行为不太可靠，我不太建议。
6.3 用轻量方案替代完整桌面
如果你确实需要图形界面，别装完整桌面环境。我试过的一个组合是：窗口管理器用 i3 或者 openbox，终端用 urxvt 或者 st，浏览器就别想了，用w3m或者干脆不装。这样一套下来，内存占用能控制在 200MB 以内，在 4GB 机器上还留有余地。
另一个更实用的思路是干脆不要本地图形界面，把 R11s 当成一个终端节点：本地只跑 tmux 会话，需要图形化的任务通过 SSH 转发到别的设备上执行。这样既省资源，又不用忍受小屏幕加软键盘的输入体验。我现在基本是这个用法，R11s 的作用就是一个随身携带的、随时能连上远端的终端。
6.4 电源和散热的物理处理，比软件优化有用
最后说点不技术的。这台机器折腾了大半年，我换过三根数据线、两个充电头，最后发现影响最大的是散热和供电这两件物理层面的东西。
散热方面，去掉手机壳、把机器垫高两厘米（我用的是一个旧手机支架）、避免放在床铺这类隔热表面上，核心温度能低三到五度。别小看这几度，它直接决定了你跑重负载时大核能不能上到最高档位。
供电方面，microUSB 接口在跑高负载时功耗会上来，如果数据线质量不行，实际输入电流不够，电池会边充边掉。我最后的方案是用一个支持 5V/2A 输出的充电头配一根短线，实测跑满负载时电量能稳住不降。
还有一个小技巧：把屏幕亮度调到最低、关掉自动亮度、开飞行模式只用无线网络，待机功耗能降一大截。这些调整看着琐碎，加起来对续航的影响能到 30% 以上。
最后分享一个我摸索出来的习惯：给这台机器做一个"用途单一化"的定位。我一开始什么都想让它干，结果每个场景都差点意思；后来我把它定位成"随身 SSH 终端 + 轻量脚本执行环境"，其他花哨的用法全砍掉，反而天天在用，从来没闲置过。老设备折腾的乐趣在于过程，但真正让它有价值的，是找到一个它恰好能干、而且你确实需要的具体场景。
后续如果还想往下走，一个有意思的方向是把容器里的资源监控做成一个脚本，定时采集/proc/stat、/proc/meminfo、time_in_state，画成图表，这样能直观看到加速引擎在不同场景下的调度变化——相当于给自己做了一个黑盒观测工具，比看任何评测文章都来得实在。
