Compose 是 Android 声明式 UI 框架，运行在 ART 虚拟机内，不管理进程生命周期或内存限制；oom_score_adj 是 Linux 内核对原生进程的 OOM 评分控制参数，受 SELinux 严格限制，应用无权修改，与 Compose 完全无关。
Compose 是 Jetpack Compose，是 Android 的声明式 UI 框架，不管理容器、内存限制或 oom_score_adj。这个参数属于 Linux 内核和 Docker 运行时的底层机制，与 Compose 完全无关。
为什么 Compose 无法配置 oom_score_adj
– 运行环境不同：Compose 运行在 Android 应用进程内（ART 虚拟机），依赖系统 Activity/Fragment 生命周期；而 oom_score_adj 是 Linux 内核对进程（如 pid 1）的 OOM 评分控制，只存在于 Linux 宿主机或容器运行时（如 Docker、containerd）中。
– 权限与层级隔离：Android 应用默认无权写入 /proc/[pid]/oom_score_adj，该路径受 SELinux 和 capability 严格限制；即使 root，也仅影响本进程（如 App 主线程），而非“容器”——Android 上没有 Docker 意义的容器概念。
– 术语混淆：“Compose 中的容器”通常指 Box、Column 等布局组件，不是操作系统级容器；它们不分配物理内存配额，也不参与内核 OOM 判定。
如果你实际想保护 Android 应用不被 Low Memory Killer 杀掉
Android 使用的是 LMK（Low Memory Killer），其优先级由 oom_adj（非 oom_score_adj）决定，但该值由系统根据进程类型（前台服务、可见 Activity、后台进程等）自动设置，应用无法直接修改。
可行的优化方向包括：
- 将核心功能置于 前台服务（Foreground Service） 并调用
startForeground()，获取更高内存保活优先级 - 避免长时间持有大 Bitmap、泄漏 Context 或静态集合，减少自身
dalvik heap和native heap占用 - 监听
ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND等状态，主动降级非关键任务 - 使用
android:process将重要模块拆到独立进程（需权衡 IPC 开销）
如果你真在用 Docker 运行 Android 相关服务（如模拟器、构建环境）
那配置对象是 Docker 容器，不是 Compose UI：
- 启动容器时加
--oom-score-adj=-500 --memory=2g（必须配--memory才生效） - 验证：进入容器执行
cat /proc/1/oom_score_adj，确认输出为-500 - 注意：Android 系统镜像（如
android-build-box）需启用 cgroup v1 或适配 v2 接口，且宿主机内核支持
简单说：Compose 不碰 oom_score_adj，它不负责进程生命周期管理。要保服务，靠 Android 系统机制；要保容器，用 Docker 参数——别把 UI 框架和容器运行时混在一起。
