[I.2] 个人作业：软件案例分析

[I.2] 个人作业：软件案例分析

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.2] 个人作业：软件案例分析
我在这个课程的目标是	了解现代软件工程的思想和开发方法
这个作业在哪个具体方面帮助我实现目标	学会系统地分析软件的功能质量、开发周期，为后续开发自己的软件积累经验

---

在上个学期中，我将自己的电脑开发环境切换到了Arch Linux，如果想获得一个较好的日常使用体验，还需要配置相应的桌面环境，本次作业我选择分析的软件就是一款新兴的轻量级桌面环境—— Niri，并选取业界主流的KDE Plasma与之进行对比。

第一部分 调研，评测

软件评测

1.软件使用

图 1: 我配置的Niri桌面环境(DE显示KDE是还没刷新过来)

这个是我简单配置的桌面环境，我所配置的项目包括且不限于：

• 手动设置了分辨率和刷新率
• 安装了一个开箱即用的waybar
• 手动设置系统语言
• 手动设置开机自启的若干软件

2.软件分析

Niri有以下特点：

• 启动：可以通过在终端运行niri-session来启动，无需配置登录管理器。
• 配置：采用声明式配置，所有的修改都通过配置config.kdl这个文件实现。
• 窗口：使用平铺式窗口，用户打开新窗口时，会自动生成到当前窗口的右侧，窗口可以“无限”延展，垂直方向上可以新建工作区，可以将窗口合并到同一列，甚至可以开启标签页，这让niri可以同时做到mater布局、网格布局和标签页布局窗口和工作区切换时都比较丝滑，没有明显卡顿。
• 操作：依赖键盘快捷键，需要一定时间的熟悉才能上手。

图 2: Niri的配置文件

图 3: Niri 的无限水平滚动布局展示，窗口之间保持动态圆角

总结一下，Niri可以满足用户在Linux上配置桌面环境的需求，但是学习曲线较陡，有一定的上手门槛，操作熟悉后可以大大提高开发效率。

下表为不同维度Niri的优缺点总结

维度	优点	缺点
性能表现	极低资源足迹：基于 Rust 开发，冷启动内存占用仅约 80MB，IO 响应延迟极低。	调试门槛高：缺乏图形化日志工具，故障排查高度依赖 journalctl 抓取回溯信息。
界面逻辑	空间一致性：窗口相对位置固定，关闭相邻窗口不会触发其他窗口的剧烈“跳变”，减少了视觉干扰。	多屏任务：平铺式的窗口管理，与多屏扩展状态兼容性较差。
功能扩展	协议领先：原生支持 ext-idle-notify 等最新 Wayland 扩展协议，录屏与电源管理兼容性极佳。	生态孤岛：不提供内置的任务栏、启动器，用户需具备较强的第三方组件选型与脚本整合能力。
用户体验	极致流畅感：物理动效提供了极佳的心理预期反馈，操作逻辑极其专注。	肌肉记忆门槛：完全依赖键盘快捷键，学习曲线陡峭，对非技术用户极度不友好。

3.改进意见

1. 构建“配置沙箱校验与非阻塞回滚”机制：

   • 问题：目前 KDL 配置文件若存在致命语法错误，虽有提示但可能导致交互逻辑中断。
   • 方案：引入 预校验机制。在应用新配置前，由独立线程进行语法树验证。若验证失败，应保持当前稳定运行状态，并弹出一个不可遮挡的错误提示，实现系统的容错性设计。

2. 预设“最小可行性环境”引导：

   • 问题：Niri 初始启动的“黑屏”状态严重影响体验，容易让潜在高价值用户流失。
   • 方案：在发行版包中内置一套基础的 default-waybar-config 和快捷键提示层。当检测到用户未创建配置文件时，自动加载该配置，确保用户在“折腾”前拥有最基本的网络、电量显示及操作指引。

4.用户调研

本次调研的用户是一名同样来自计算机学院的大二学生。自从被我安利完Arch Linux，她在了解各方资料后毅然选择了Niri作为桌面环境，让我们来看一下她对于这款软件的评价如何呢？

图 4: 这位同学的Niri桌面

从调研来看，她使用 Niri 的需求是用于项目开发和计算机学习，Niri在这里确实满足了她的需求，并且对于一个有计算机基础的用户来说，学习门槛大致需要一周，还算可以接受。但从她的反馈来看，在使用 Niri 时也遇到了一些让人烦恼的Bug，这一部分是需要持续优化的。

5.测评结论

Niri的特殊性让我很难给到一个具体的评价，因为Niri的门槛注定了只有一小部分人会选择它。

• 对于计算机学院的同学们，如果喜欢折腾，我认为Niri还是很值得一试的，可以给到d) 好，不错的评价，相信你可以在Niri上获得一个与其他桌面环境完全不同的开发体验。
• 但如果你是计算机小白，我是不建议你来使用Niri的，因为Niri的配置真的是非常耗费精力，需要相当扎实的计算机基础。

不过既然是软件测评，仅从软件性的角度来看，我仍觉得Niri是一款不错的软件，他向我们展示了桌面环境和窗口管理的另一种形态，使用Rust编程安全性有保障的前提下占用也很低，如果能改善显示协议的历史包袱并且对基础形态稍加优化的话，相信Niri可以做到更好。

---

Bug分析和提交

测试环境：硬件是Thinkpad T14 Gen1(amd 4650u)，操作系统是Linux 6.19.8-arch1-1，Niri版本为niri 25.11 (b35bcae)。

Bug严重性评价体系：

• 致命⭐⭐⭐⭐⭐：全系统瘫痪或核心流程中断。软件无法启动、频繁崩溃（Panic）、核心输入/输出功能失效，且无任何替代方案。
• 严重⭐⭐⭐⭐：主要功能障碍或严重环境兼容性问题。功能实现与预期严重不符，或在特定硬件切换下导致工作流断裂，需重启进程方可恢复。
• 一般⭐⭐⭐：次要功能失效或交互逻辑错误。软件核心路径可用，但在边界条件下出现异常，存在繁琐的临时规避方案。
• 轻微⭐⭐：用户体验瑕疵或界面不一致。功能完整，但存在视觉上的小缺陷、不符合习惯的操作逻辑。
• 建议⭐：优化类需求。不属于程序逻辑错误，而是从易用性、可访问性角度提出的改进建议。

Bug1、fcitx5导致gtk应用无法弹出窗口

1. Bug描述：如果启用了fcitx5输入法，在使用nautilus等gtk应用时，会无法弹出窗口，比如nautilus的“重命名”，easyeffects的“添加效果”。

2. 可复现性：稳定复现。在Niri配置文件中启动fcitx5守护进程，打开nautilus，右键点击重命名，没有反应。

图 4: 开启fcitx5后，这里的重命名是没有反应的

3. Bug分析

• 成因：由于 Niri 是一个平铺滚动合成器，它对窗口位置有严格的控制。当 GTK 应用通过text-input协议请求显示候选框时，如果协议版本不匹配或xdg-popup约束失效，候选框要么被 Niri 误认为是一个普通窗口进行平铺（导致布局混乱），要么因为坐标丢失而无法渲染。
• 严重程度：⭐⭐⭐⭐。输入法是中文用户的核心功能。如果开了输入法就无法显示窗口，则该软件对于该群体几乎处于不可用状态。
• 未修复的原因：社区因素。这不是 Niri 单方面能修复的。它涉及到 GTK 开发团队对 Wayland 协议的支持态度，以及 Fcitx5 社区对不同合成器行为的适配。这种 “三方责任模糊” 的 Bug 往往是开源软件中最难推动修复的。

4. Bug改进建议

• 正常行为评估：输入法候选框应作为子表面精确锚定在光标下方，且不应触发 Niri 的平铺逻辑。
• 解决方案：Niri 应增强对 text-input-v3 协议的鲁棒性处理，并在发现非法的 xdg_popup 请求时提供默认的回退位置，避免窗口完全消失。

Bug 2：休眠后通过蓝牙设备唤醒导致系统卡死

1. Bug 描述：当系统进入休眠状态后，如果尝试通过蓝牙鼠标或蓝牙键盘点击/按键来唤醒系统，Niri 界面会由于无法正确处理唤醒后的输入事件流或显示输出重置，导致整个合成器界面冻结，用户无法进行任何操作，通常只能通过强制重启或 TTY 杀死进程解决。

2. 可复现性：满足特定条件下发生。在连接蓝牙输入设备的情况下，执行 systemctl suspend。休眠完成后，持续点击蓝牙鼠标按键触发唤醒。有较高概率出现唤醒后屏幕亮起但鼠标光标无法移动、快捷键失效的现象。

图 5: 由于黑屏无法截图，仅提供日志截图

3. Bug 分析

• 成因：这属于同步竞态条件。在系统唤醒过程中，蓝牙子系统恢复连接的速度可能快于显示驱动和 Wayland 合成器的初始化。当蓝牙设备在 Niri 尚未准备好输入事件处理上下文时发送大量位移或点击数据，可能导致 Niri 内部的事件循环（陷入死锁。此外，若蓝牙唤醒触发了错误的显示输出轮询，会导致渲染线程被阻塞。
• 严重程度：⭐⭐⭐⭐。该 Bug 直接导致系统在唤醒后处于不可用状态，严重破坏了 Linux 笔记本用户的移动办公体验（挂起-恢复流程断裂）。根据评价体系，属于严重功能障碍。
• 未修复的原因：底层驱动复杂度高。蓝牙唤醒涉及内核态驱动、用户态守护进程与 Wayland 合成器三方的时序同步。Niri 作为一个轻量级合成器，在处理这种复杂的硬件异步唤醒序列时，缺乏像 GNOME/KDE 那样完善的电源管理集成层，导致在极端时序下鲁棒性不足。

4. Bug 改进建议

• 正常行为评估：系统唤醒后，蓝牙设备应能迅速重连，且 Niri 应在显示输出准备就绪后，平滑地接收并处理来自输入设备的缓冲区数据，不应出现线程阻塞。
• 解决方案：Niri 应在唤醒逻辑中引入事件延迟处理机制。在检测到系统从休眠中恢复时，先暂停处理非关键输入事件，优先完成显示输出的重新扫描与验证，待渲染引擎完全恢复后再开启输入事件监听，从而规避因硬件初始化时序不一导致的死锁。

---

第二部分 分析

工作量分析

我们将开发过程分为四个核心阶段，按 6 人团队 的并行协作模式计算：

开发阶段	核心任务	预计耗时	人力分配
第一阶段：内核与渲染架构	基于 Smithay 搭建后端，处理 DRM、渲染循环（Render Loop）与 OpenGL/Vulkan 缓存交换。	6 周	2 名后端（内核/驱动方向）
第二阶段：线性滚动布局算法	实现 Niri 独特的无限水平滚动逻辑、窗口跨列合并、物理弹簧动画引擎。	8 周	2 名算法/图形逻辑
第三阶段：Wayland 协议适配	实现 xdg-shell、layer-shell、输入法协议（Text-input-v3）及分层显示控制。	10 周	2 名协议/系统接口
第四阶段：配置解析与 IPC	KDL 声明式配置解析、niri msg 进程间通信、多显示器热插拔逻辑优化。	6 周	全员参与（含 UI 协同）

假设团队由 6 名优秀的计算机专业毕业生（具备 C/Rust 基础、了解操作系统原理）组成，达到 Niri 目前的成熟度，预计需要 24 - 32 周（约 6 - 8 个月）。

---

软件质量分析

产品质量排名预测

在当前的 Wayland 独立合成器（平铺类） 市场中，我给出的质量与成熟度排名如下：

1. Sway：作为工业级标准的替代品，其协议兼容性和稳定性目前无可撼动。
2. Hyprland：凭借强大的社区推广和极致的视觉表现力，占据了大量流量。
3. Niri：名列第三。

依据：虽然 Niri 的架构选择（Rust）非常先进，且交互逻辑（无限平铺）具有创新性性，但由于其处于早期起步阶段，在处理复杂的时序逻辑和各种协议适配上，与前两名仍有代差。它目前是一款有趣的玩具，但暂时无法当作一款实用的生产力工具。

软件工程改进建议

虽然 Niri 的底层架构（非常优秀，但在软件工程的和用户体验上，它欠缺的点在于过于强调技术，反而忽略了用户可能不具备与使用 Niri 配套的水准。

核心建议：提供一套“开箱即用”的最小可行性环境

1. 现状痛点：安装完只有一个黑屏界面，需要自己根据教程一步步配置。这就导致大量想尝试新架构的用户，在第一分钟看到黑屏的时候就直接被劝退了。

2. 改进方案：内置一套基础组件。从软件工程的角度看，一个成功的产品不应该只管核心逻辑，还得管“用户能不能用起来”。建议 Niri 团队在发行版里内置一个极简的状态栏和启动器。当用户第一次启动，至少拥有最基本的网络、电量显示及操作指引。

---

第三部分 建议和规划

市场现状

1.1 市场概况

• 直接用户：目前主要是像我这样使用 Arch Linux、NixOS 等滚动发行版，且追求极致性能和新型交互的 Linux Power Users。估计全球活跃用户在几十万量级。
• 潜在用户：广大程序员、数据分析师以及拥有超宽屏显示器的办公族。随着 Wayland 协议彻底取代 X11，所有寻找轻量级桌面环境的用户都是潜在受众，规模在百万级。

1.2 竞争产品与定位

目前 Wayland 平铺合成器市场呈现“三足鼎立”态势：

产品	定位	优势	劣势
Sway	行业标杆，i3 继承者	极度稳定，文档齐全，生态位无敌。	交互逻辑传统（树状平铺），创新不足。
Hyprland	特效天花板	动画极其华丽，社区插件非常丰富。	C++ 编写，偶尔有内存安全隐患，配置较乱。
Niri	垂直领域的变革者	滚动布局极具创新，Rust 编写，安全性高。	上手门槛极高，生态几乎为零，Bug 较多。

市场与产品生态

2.1 核心用户群画像

• 典型用户：某大学计算机系学生（如我）或后端开发工程师。
• 基本特征：年龄 18-35 岁，高学历，CS 相关专业，爱好折腾系统、极致定制化。
• 表面需求：窗口不重叠、键盘流操作、占用资源低。
• 潜在需求：“掌控感”。希望每一行配置、每一个窗口的跳动都在自己的预期内。

2.2 用户与产品生态

• 用户关系：这群人通常活跃在 Reddit、Arch 论坛或 GitHub，有极强的社区属性。
• 产品关系：Niri 依赖于 Waybar、Fuzzel、Mako 等组件。这种“拼积木”的关系构成了一个微型生态，Niri 作为“大脑”，指挥其他肢体工作。

产品规划

3.1 新功能设计：NABCD 分析

我要设计的功能是：“一键式 MVP 引导与图形化配置校验器”。

• N (Need 需求)：解决新用户“开箱即黑屏”的恐惧感，以及改错配置导致系统挂掉的挫败感。
• A (Approach 做法)：在 Niri 内部集成一个极简的状态提示层，并开发 niri-check 工具，在应用配置前进行沙箱验证。
• B (Benefit 好处)：把上手时间从“几小时”缩短到“几分钟”，极大提升用户留存。
• C (Competitors 竞争)：对比 Sway 的纯文本和 Hyprland 的复杂逻辑，我们的改进重点是“防错”和“引导”。
• D (Delivery 交付)：通过 AUR 发包，并在 V2EX、Reddit 等技术社区发布“新手友好版”宣传。

3.2 团队配置（6 人团队，16 周）

假设我是 PM，我会这样分工：

• PM（1人，我）：负责需求对齐、进度管控、文档编写。
• 后端开发（2人）：深挖 Rust 核心，解决休眠唤醒 Bug 和协议适配。
• 工具链开发（2人）：开发配置校验器和 IPC 接口增强。
• UI/UX（1人）：设计内置状态层的视觉规范，确保“极简但不简陋”。

3.3 16 周详细规划表

周次	阶段	核心任务
W1-W2	调研	深度分析 GitHub Issue，找一些 Niri 主力用户做访谈。
W3-W5	骨架	完成配置校验器的 Demo，重构硬件感知逻辑。
W6-W9	开发	后端优化 Wayland 协议适配；UI 完成内置状态层。
W10-W12	集成	将各组件合并，进行 6 人内部交叉测试。
W13-W14	公测	发布 Beta 版给社区核心玩家，收集反馈。
W15-W16	发布	修复残留 Bug，录制演示视频，正式发布 v1.0 改进版。