NyaZygisk WebUI 使用说明：每个功能是做什么的、怎么用

顶部：版本与刷新#

标题下方的小字是 NyaZygisk 版本 · Root 方案與版本，例如 v2.5 · KernelSU …。右上角的圆形箭头是刷新，会重新读取所有状态并重新加载应用清单，成功后底部会弹出「已刷新」。

状态卡片：Zygisk 现在到底有没有在运作#

最上面的大卡片用颜色和图标直接告诉你结论，下面列出三个组件的状态：

每个组件的状态字样分两类：

• 正常（绿）：運行中、已注入、追蹤中
• 异常（红）：已停止、已退出、已崩潰、未注入
• 其他（灰）：未知

大卡片的总结按下面的规则决定，这是前端 overallTone 的逻辑：

设备与环境#

这张卡片列出：

• Root 方案：侦测 APatch / FolkPatch / KernelSU / Magisk，能取得版本时一并显示。做法是检查 apd、fpd、magiskd 进程与 /data/adb/ksu 目录，SukiSU 这类会显示为 KernelSU 或 SukiSU。
• 系统：只有侦测到厂商 ROM 才会出现。目前认得 ColorOS / OxygenOS、HyperOS、MIUI、One UI，版本取自各家的系统属性。AOSP 类系统这格会隐藏。
• 内核、Android SDK、ABI：直接读自守护进程回报的数据。

回报问题时，把这张卡片截屏附上最省事，维护者不用再追问你的环境。

已激活模块#

列出目前激活中、并且是 Zygisk 或 ZN 模块的项目，右上角的数字是总数。每个模块显示名称、版本、说明、作者，以及标签：

• Zygisk：走 Magisk Zygisk API 的模块（例如 LSPosed 这一类）
• ZN：走 Zygisk Next API 的模块。若它的注入目标不是 zygote，会多显示一行「目标：xxx」
• Companion：这个模块有使用 companion 进程

清单的来源是两份数据合并：

1. 扫描 /data/adb/modules/*，跳过有 disable 或 remove 标记的目录，只保留含有 zygisk/<abi>.so 或 zn_modules.txt 的模块，并读它的 module.prop。
2. 守护进程回报的模块清单，补上类型（Zygisk / ZN）、目标和 companion 信息。

所以如果某个模块没出现在这里，先检查它是不是被禁用了，或者它根本不是 Zygisk 模块（没有 zygisk/ 目录也没有 zn_modules.txt）。反过来，刚激活还没重开机的模块，可能已经在清单里但还没真正加载，要以重开机后的状态为准。

设置#

匿名内存（Anonymous memory）——「特化后隐藏模块的内存映射」，预设关闭。

打开后，App 进程完成特化（specialize）之后，NyaZygisk 会把 /proc/self/maps 里由模块产生的映射（路径名含 jit-cache-zygisk、zygisk-module、zn-module 的私有映射）改成匿名映射，同时把 rwx 的映射去掉写入权限。目的是让侦测 App 扫描 maps 时，看不到这些带有模块特征的名字。

• 适合：你的 App 会扫 maps 找 Zygisk 痕迹，且你已经确认需要这个功能。
• 不适合：没有这种需求的情况不用开。它会改动进程的内存属性，有用户反馈打开后出现过系统界面进不去、状态显示 Monitor: NO 等问题。遇到类似状况，先把它关掉确认是不是原因。
• 开关改动后即写入设置，对之后启动的 App 进程生效，已经在跑的 App 要重新启动。

自订链接器（Custom linker）——「不经过系统链接器加载模块（实验性）」，预设关闭。

一般情况下，模块是交给系统的动态链接器（android_dlopen_ext）加载的，加载后会登记在链接器的 solist 里。打开这个开关后，NyaZygisk 改用自己内置的 ELF 加载器把模块映射进内存并完成重定位，模块不会进入系统链接器的纪录；搭配匿名内存时，还能直接映射成匿名页面，不留下 memfd 的名字。

• 适合：想进一步减少模块在系统链接器里留下的痕迹，并且愿意承担实验性功能风险的人。
• 不适合：一般使用。它是实验功能，所以预设不激活。加载失败或遇到不支持的模块时，会自动退回系统链接器；但如果打开后出现闪退或模块异常，请先关掉它再回报。
• 同样对之后启动的 App 进程生效。想确认模块是由哪个加载器加载的，可以用 debug 版看日志里的 modloader: 纪录。
• 从 v2.5-r2 起，没有设置这个键时视为关闭；先前版本在没设置时是打开的，更新后如果还要用，需要在 WebUI 重新打开。

语言（Language）——EN / 繁中 / 简中，切换后立刻生效，选择记在 WebUI 自己的本机保存里，不影响模块本身。

怎么用#

1. 切到底部的应用排除分页（分页标签上的数字是目前已排除的 App 数量）。
2. 在列表里找到目标 App：
   • 搜索框支持依名称或套件名搜索；
   • 上方有「全部 N / 已排除 N」两个筛选，可以只看已排除的。
3. 打开该 App 右侧的开关。每次切换都会立刻保存，并弹出「已保存」。
4. 重新启动那个 App（建议从最近任务里彻底滑掉再开）。排除只在 App 下次启动时生效，已经在跑的进程不受影响。尚未生效的项目旁边会显示「待重启」标签。

列表中已排除的项目会排在最前面，其余依名称排序。切换时列的位置不会跳走，所以连续勾选多个不会点错。

「同时卸载模块挂载」#

分页上方的这个开关（Unmount for excluded apps），预设打开。

• 开：被排除的 App 除了不加载模块之外，还会像 DenyList 一样，把 Root 与模块的挂载从它的 mount namespace 里卸掉。
• 关：只是不加载模块，挂载痕迹不处理。

也就是说，开着这个开关时，勾选一个 App 的效果等于「既不让模块进去，又让它看不到挂载」。如果你本来就用 Root 管理器的「卸载模块」功能（APatch / KernelSU）或 Magisk 的 DenyList 处理过这个 App，这个开关和它们是并行的，不冲突。

它的限制#

界面顶部的提示已经写了，这里再展开：

• 只列出用户安装的 App（pm list packages -3）。系统 App 不会出现，也不能排除，这是刻意的：system_server 和系统 UID 永远不受影响，避免把系统搞坏。
• 共用 UID 的 App 会一起切换。 如果多个套件共用同一个 UID，排除其中一个等于排除全部，列表里会标出「与另外 N 个套件共用 UID，会一起切换」。
• 与系统套件共用 UID 的 App 无法排除。 这类项目开关是灰的，并注明「与系统套件共用 UID，无法排除」。原因是守护进程只有在同一 UID 下所有套件都在排除清单里才会排除，而系统套件不允许被列进去。
• 已卸载的套件会被自动清掉，不会留下看不见的残留项目。
• 显示 App 名称需要管理器提供套件信息界面（KernelSU 系的 WebUI 有）；没有时只显示套件名，功能不受影响。