Shizuku 与传统 root shell 的差别：为什么它更快更稳
传统方案的执行路径
以「禁用一个应用组件」为例，过去需要 root 的应用通常这样干：在 su shell 里执行 pm disable 命令。完整链路是——申请 su 授权、执行 pm disable、必要时用 app_process 启动 Java 进程或调用原生 cmd 程序、解析命令输出的文字、拿到结果。
官方文档逐条指出了这套流程的问题：
- 极慢：每「执行一次」都意味着新建一个进程；su 内部还要通过 socket 与守护进程来回沟通，时间大量耗在流程本身。设计不佳的应用甚至每执行一条指令都重新申请一次 su；
- 解析文本拿结果：命令输出是给人看的字符串，程序去解析既不可靠也容易出错；
- 功能受制于可用命令：命令行没暴露的能力，应用就做不了；
- 权限错位：明明 adb 权限就够用的事，应用却必须拿 root 才能执行。
Shizuku 方案的执行路径
Shizuku 把这条链路压缩成了「一次握手，全程直连」：
- 用户提前激活服务进程（这一步只做一次）；
- 应用启动时收到指向服务进程的 binder；
- 此后所有高权限操作都通过 binder 直接转发给系统服务，不再起新进程、不再解析文本。
官方总结的优点非常直白：极小的额外时间与性能消耗，且应用开发者的调用体验与直接使用系统 API 几乎一致——只需添加少量代码。
一张表看懂两种路线
| 对比维度 | 传统 su shell | Shizuku |
|---|---|---|
| 每次操作的耗时 | 反复建进程、走 su 通道，开销大 | 复用常驻服务进程，开销极小 |
| 结果获取 | 解析命令文本输出 | binder 结构化返回 |
| 能力边界 | 只限于命令行暴露的功能 | 系统服务暴露的接口基本都可用 |
| 对 root 的依赖 | 应用自己申请 su | adb 模式完全不需要 root |
| 对系统的改动 | 需要已 root 的环境 | 不改系统分区，重启后权限清零 |
用户视角的意义
这套差异落到日常使用上，就是三句话：授权一次之后操作是「秒完成」的；依赖它的高级工具很少再出现「执行一半卡住」；不需要 root，也就不必承担解锁 Bootloader 带来的风险与代价。