简单的理解一下这三个策略的区别 是玩转 KernelSU Next 和 Zygisk Next 的关键。
简单来说，这三个选项决定了 Zygisk Next 模块如何对待你加入“排除列表”的应用。
核心概念：Zygisk Next 如何工作？
在解释策略之前，我们先要明白 Zygisk Next （是做什么的 请自行百度，这里不做赘叙）模块通常通过两种方式影响一个 App：
-
挂载修改：模块不直接修改系统文件（如
/system/framework/framework.jar），而是创建一个修改后的副本，然后在 App 启动时，将这个副本“覆盖”在原始文件之上。App 看到的就是被修改过的文件。 -
进程注入：在 App 进程创建的早期，模块将自己的代码（通常是
.so库或 Java 代码）注入到 App 的内存空间中，从而可以 Hook（劫持）系统调用、修改 App 行为。
现在，我们来看这三个策略是如何处理这两种方式的。
1. 关闭
- 作用：排除列表完全无效。
- 原理：无论一个 App 是否在排除列表中，Zygisk Next 都会一视同仁。
- 效果：所有 App 都会受到所有已启用 Zygisk Next 模块的影响。它们会看到所有被模块修改过的文件，并且进程也会被注入代码。
-
适用场景：
- 你希望所有 App 都被模块修改。
- 你不需要对任何 App 进行隐藏或兼容性处理。
- 调试模块时，确保模块对所有应用生效。
2. 强制
- 作用：最严格的排除模式。强制让列表中的 App 运行在一个“完全干净”的环境中，就像设备没有 Root 和模块一样。
-
原理：对于列表中的 App，Zygisk Next 会：
- 还原所有挂载：让 App 看到原始的、未经任何修改的系统文件。
- 阻止所有进程注入：不允许任何模块向该 App 的进程注入代码。
- （通常还会）隐藏 Root 相关的文件和进程。
- 效果：列表中的 App 将完全感知不到 KernelSU、Zygisk Next 和绝大多数模块的存在。这是隐藏性最好的模式。
-
适用场景：
- 银行、金融类 App：这些 App 对 Root 环境检测极为严格。
- 带 DRM 保护的官方游戏：如 Google Play 的许多游戏，会检测系统完整性。
- 任何需要通过 Play Integrity 认证的应用：这是最推荐的选项。
3. 仅还原挂载
- 作用：一个折中的、有针对性的排除模式。只处理文件系统层面的修改，不干预进程内存。
-
原理：对于列表中的 App，Zygisk Next 会：
- 还原所有挂载：让 App 看到原始的系统文件。
- 但仍然允许进程注入：模块依然可以向该 App 的进程注入代码。
- 效果：App 看到的文件系统是干净的，但它的运行时行为可能仍然被模块修改。这可以绕过一些基于文件完整性检测的 App，但无法绕过那些在进程内存中检测的 App。
-
适用场景：
- 兼容性修复：某个 App 因为某个模块修改了系统文件而闪退，但你仍然希望另一个模块（如 LSPosed 框架）能对这个 App 生效。
-
精细控制：你只需要隐藏文件层面的修改，但需要利用进程注入来实现某些功能（例如，给某个 App 开启高刷新率，但不想让它看到被修改的
build.prop）。 - 高级调试：用于区分问题是出在“挂载修改”还是“进程注入”上。
总结与对比
| 策略 | 进程注入 | 挂载修改 | 隐藏效果 | 适用场景 |
|---|---|---|---|---|
| 关闭 | ✅ (允许) | ✅ (允许) | 无 | 无需隐藏，全局生效 |
| 强制 | ❌ (阻止) | ❌ (还原) | 最高 | 银行、游戏、Play Integrity |
| 仅还原挂载 | ✅ (允许) | ❌ (还原) | 中等 | 兼容性修复、精细控制 |
建议
- 日常使用：对于需要隐藏的 App（如银行、游戏），优先使用“强制”。这是最安全、最省心的选择。
- 遇到问题：如果某个 App 在“强制”模式下仍然无法运行，或者你确实需要某个模块（如 LSPosed）对它生效，可以尝试切换到 “仅还原挂载” 模式，看看是否能解决问题。
- 默认设置：如果你不确定，可以先将排除列表的策略设为“强制”，然后把有问题的 App 加进去，这是最常见的用法。
