四周目(总结): SukiSU Ultra 的种种问题

各周目合集:

• 一周目
• 二周目
• 三周目
• 四周目(总结)

历史渊源

​

前言

SukiSU Ultra 整个项目里面很难找到没有问题的地方， 代码有问题、设计有问题、项目架构有问题、项目分布有问题、文档有问题，就连 Git 仓库本身问题也是不少 它要是表面上能用还好，可是它很多时候用都用不了啊？

​

各种问题

​

基本架构

​

文档

在作为给用户看、给开发者看的相当于门面的东西，SukiSU Ultra 却做到了完全不能看 SukiSU Ultra 的 GitHub 文档、网站文档 长期并立，谁也没弃用掉谁 但是它们都做到了同一个点: 严重的滞后性，在有较大变动的情况下都做到了数月不更新 也就是说，SukiSU Ultra 该怎么用，已经没有人在表面上能够解释了，只有他们自己知道？ 除了文档的内容长期不更新之外，网站文档的外观也是一言难尽 为了并没有多少差距的速度，各种乱改把好端端的文档框架改得像手写 HTML 一样， 组件乱成一团，完全看不出文档框架本来的样子 看着难受，实际上内容也并不对，中英双语的内容很多都不对应，如果在部分页面切换语言，将直接 404 效果抽象，实际的质量当然也是好不了， 乱写 css 样式不说，就连 node_modules 都能推送上去，具体是个什么能力大概也都清楚了 文档的源到底也是个谜，在组织仓库下有一个仓库，主要维护者也有个仓库， 因为他经常销号又导致仓库又交给了另外一个没什么干系的人部署， 所以同一个文档，有多个独立的仓库，并且之间都没有任何 fork 关系 由于文档也并没有再更新，所以文档以后究竟如何维护，难说，难评

README

就连 README 这么个最基本的东西，实则也是不堪入目 从语法上来讲，好端端的 Note，不去用 > [!NOTE] 这样专门的语法，而是用 > **Note:** 这样硬写的方式 文件的摆放也是令人震惊，已经放在根目录的标志图标，在子目录的多语言 README 不去直接使用父目录的文件， 而是复制一个新的？

这还是一个 PR 实现的，只不过发起者都是内部成员，可见一点审核都没有

作为一个主要维护者是中国人的项目，中文还是机翻的······

​

项目仓库

不光文档的仓库有问题，其他仓库的问题也没好到哪去 主仓库在创建伊始是归属在个人名下，后来转移到了组织里面 可是组织里面的仓库，也就 主仓库、补丁仓库，以及不知有何用处的 文档仓库 而作为可以说是比较重要的库 zakosign，虽然已被弃用，但自始至终都是一个个人仓库，而没有转移为组织仓库 主仓库也并没有在任何地方提及 zakosign 的来源，引入方式也是采用直接放置共享库文件这种特别污染 Git 提交的方式 并且只引入了 debug 版本，就连 release 版本发布的都是 debug 版本， 在代码上没事找事硬扣性能，可是在这种决定性因素上却毫不在意

项目分支

多仓库间的混乱并不是问题的终点，因为就连主仓库自己也是自身难保 大改分支使得原本在文档上的使用方式完全失效，文档的滞后也使得如何使用变成彻底的谜题

选择在社交群组解释分支设立原因，却不在仓库本身作任何解释，不如在仓库上加一句“最终解释请在群组查看”

给仓库设立 main、dev 分支，可是在开发时却是先提交到 main 分支，再同步到 dev 分支， 作为一个毫不稳定的项目，却还要在分支上做做样子，这种行为的意义在哪里？

按我们的成员的话来讲，连 AI Agent 的提示词都要单独提交，更何况提示词内容写的也有问题，连 AI 怎么用都不会

​

具体实现

​

代码质量

硬编码

SukiSU Ultra 代码中最大的问题就是硬编码，同语言硬编码，跨语言也能硬编码 硬编码路径、硬编码信息、硬编码日志等级、硬编码列表大小， 甚至一整个 Shell 脚本 都要硬编码进去，而不是放到 assets/res 硬编码带来的危害是相当严重的，但凡有一个东西要改，其他地方都要手动全都改一遍，可是万一忘了改呢？ 对上下文的理解也是难以想象， 能够在中文的情况下判断语言来输出 中文/英文， 也能在英文的情况下判断语言来输出 Chinese/English 这时候该硬编码了反而不硬编码了，在语言已经判断过的情况下还要二次判断， 在整数 1 与 2 之间选择了浮点数 1.5？

重复封装

多处地方都能看见对同一个内容不止一次的重复封装， 一块代码在一个地方使用了，就算是在一堆代码中的，也不知道提取出来统一使用吗？

Kotlin/Java for Shell

SukiSU Ultra 在代码中总是频繁地滥用 Shell， 完全不用封装完善的 libsu:io 或直接基于 Java 的 libsu:nio， 就连调用都要用 Java 原生 API，而不是 KernelSU 原本在用的 libsu 一个最基本的判断都要滥用 Shell，更何况本身的逻辑也是莫名其妙， 为了判断文件是否存在而写 runCmd("file " + path).contains("No such file or directory")， 采用执行 Shell 然后通过返回的报错内容来判断文件是否存在，可是这个代码是拿来判断文件存在的啊？ （检测 No such file or directory 是判断不存在）

对 Shell 不可理喻地滥用，甚至代码逻辑都是反的，代码写完了自己能看懂是什么意思吗？

脱离 root 的 root

作为一个 root 实现，连管理器有没有 root 都要在肯定需要 root 才可用的功能中检测 也不管功能页面在没有 root 的情况下连进都进不去，就是要添这些没有意义的代码 在自己的代码中调用 root 也总是 Java 原生 API 执行 su -c，完全融入不到 KernelSU 原本的代码里面去

异常捕获滥用

对 try 的滥用也是可见一斑：平铺 try、嵌套 try； 代码块用 try（try { ... }）、定义值用 try（val ... = try { ... }）。 总之全都是各种不合理的用法 用 try 也完全不考虑可行性，每个地方对异常处理的用法也不一样，就连不会报错的代码也要硬捕获 还通过在 catch 返回特定的硬编码内容来判断是否报错，而不是直接判断有没有报错

不治标也不治本

为了修版本号为空的问题，不是找到问题然后直接修复问题，而是改为返回硬编码的 Unknown？

​

功能设计

就实际情况而看，SukiSU Ultra 完全做不到作为一个 KernelSU 的分支而存在，顶多算个意义不大的拓展而存在

胡乱的 UI 设计

SukiSU Ultra 在诞生之初给我的第一印象就是非常难看的 UI，长期存在的乱取色的卡片也是令人反感 在 谷歌的 MD3 上瞎改、乱改，做出来一套自以为美观的主题系统， 还有些没什么用处的 UI 开关 让整套 UI 变得不堪入目，自以为是的美观 比起 实际的可用性 有什么用呢？

虽说用户怎么用是用户的事，可是你既然把这个东西做出来了，主要问题还不是在你？

不成熟

在项目中加入新功能时，完全不考虑实际的可行性，在具体实现上也是搞得一团糟

毫无意义的“标新立异”

zakosign 的存在完全就是错误，要跨平台却使用 C 编写，而且还是一个平台写一套代码的“跨平台”

用了标准库却不使用标准库，连最起码的一个兜底也不做，这样乱写除了被更成熟的取代还能怎样？

能力欠缺

在其他地方对代码的理解也是十分欠缺，例如在默认输出就是 stdout 的情况下，还要把输出重定向到 stdout， 足以证明代码被写出来的时候作者可以说是对代码本身一无所知 在对功能的具体落实上，连日志都不能好好搞， 多种方式来输出同一条日志， 还要每次输出都确保同步到文件系统来不断消耗闪存寿命， 就连日志等级都能通过硬编码等方式搞得一团糟， 还有配置中的日志等级设置是无效等情况， 连个日志系统都能搞成彻头彻尾的烂啊 给可执行上多语言也是不成熟的体现，让维护成本暴增的做法真的是想做就做，肆意妄为啊

更何况是在其他可执行都没有多语言的情况下做一个新东西直接上多语言？ 把一个连玩具都算不上的东西直接搬进来是想干什么啊？

做新功能不是选择做成一个内部接口，而是直接使用在公开接口上，是把 root 实现 当成 Magisk 模块 来写了吗？

就连代码中操作模块的函数名字都是 ...MagiskModule，没错了

命名混乱

自以为和 zako 高度绑定，实际上还不如与 somebody 完全绑定 把 共享库/可执行 命名成 zako/zakozako/zakozakozako 这样乱七八糟的名字， 生怕别人能理解是干什么用的吗？

​

小迷惑

我们无法理解为什么 SukiSU Ultra 要在用 Kotlin 的地方写 Java，在用 Rust 的地方写 C， 总之这个项目再整出什么烂活也都是在意料之内了