团队作业3--需求改进&系统设计

团队作业3：需求改进 & 系统设计

这个项目属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/
作业要求	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/homework/13482
作业的目标	修改完善需求规格说明书，完成Alpha任务分配和测试计划
Github链接	https://github.com/BearSur/Video-compression-app

---

1. 需求 & 原型改进 (20分)

1.1 针对课堂讨论及反馈的修改 (5分)

针对上周课堂展示环节中老师和其他小组提出的建议，我们对需求进行了深度的反思和修正，具体如下：

序号	课堂/同行提出的问题与建议	针对性的修改/改进内容
1	性能与发热担忧： 老师指出，在手机端进行高强度的视频压缩（尤其是批量处理）极易导致设备过热，甚至导致 App 被系统强杀，影响用户体验。	修改：增加“智能温控与动态流控”模块。 在非功能性需求中加入温度监控机制。当检测到设备温度超过阈值（如 42°C）时，自动降低压缩线程优先级或暂停队列，并给用户友好的“降温保护中”提示。
2	原文件安全风险： 有同学提问，如果用户选择了“压缩后删除原视频”，万一压缩文件损坏或画质不满意，原文件又找不回怎么办？	修改：引入“安全沙箱回收站”机制。 即使主要需求是“替换”，系统逻辑修改为：先将原文件移动到 App 内部的临时回收站保留 24 小时（或用户手动清空），确认用户对新视频满意后，再进行物理删除。
3	用户分层不清： 建议区分“小白用户”和“极客用户”，目前的参数设置界面对老年人或非技术用户太复杂。	修改：界面交互分级设计。 默认界面仅保留“一键瘦身”大按钮（智能模式）；将分辨率、码率、帧率等参数折叠进“专家模式”开关中，避免信息过载。

1.2 目标用户与场景 (加分项 - 5分)

为了更好地理解需求，我们深入调研了典型用户群体。

• 典型用户： 李阿姨 (52岁)

• 身份： 退休教师，广场舞领队，孙子的主要照看者。

• 设备情况： 3年前购买的 Android 手机，存储空间 128GB (剩余不足 2GB)。

• 痛点 (Pain Points)：

  • 存不下： 想给孙子拍视频，手机总弹窗“空间不足”，被迫删照片，非常心疼。
  • 发不出： 广场舞长视频录完有 800MB，微信限制 100MB 传不出去，也不会用百度网盘。
  • 不敢用： 试过网上的压缩工具，全是英文或者广告，还担心孙子的视频传到网上泄露隐私。

• 用户场景 (User Story) 与原型展示：

场景：李阿姨的“一键自救”

1. 发现问题： 李阿姨在录制广场舞时，手机再次提示“存储空间已满”，录制中断。
2. 使用产品： 她打开“视频瘦身大师”。首页醒目的“一键清理大视频”按钮还在跳动，提示她“检测到 15GB 可优化视频”。
3. 操作： 她不需要理解什么是“1080P”或“H.264”，直接点击按钮。
4. 过程： App 进入后台运行，李阿姨切出去回微信消息。10分钟后，通知栏提示“瘦身完成，为您节省了 10GB 空间！”。
5. 验证与解决： 她点开预览，发现画质在手机上看几乎没区别，但那个 800MB 的视频变成了 85MB。她直接点击“分享到微信群”，视频瞬间发送成功。

以下是针对李阿姨这一场景设计的 App 首页原型图：

1.3 需求规格说明书完善 (10分)

针对上周《需求规格说明书》初稿的不足，我们在随笔中进行了更新：

• 改进点 1 (功能补全)： 补充了“存储空间预判”功能。在压缩前计算预计大小，如果手机剩余空间连压缩后的文件都放不下，提前拦截并提示清理。
• 改进点 2 (描述细化)： 完善了非功能性需求中的兼容性描述，明确支持 Android 10.0 - 14.0 系统，以及对鸿蒙系统的适配测试计划。
• 改进点 3 (异常流程)： 增加了“断电/崩溃恢复”的需求描述。App 重启后应能自动检测未完成的任务队列，并提示用户是否继续。

1.4 功能分析四象限 (2分)

参考《构建之法》，我们将功能定位如下：

象限	功能定义	本项目对应功能
必须 (Must-Have)	核心功能，没有则产品不可用	视频导入/扫描、核心压缩算法 (H.264/H.265)、保存到相册、权限管理。
线性 (Linear)	越多越好，越快越好	压缩速度 (FPS)、压缩率 (体积减小程度)、支持的视频格式数量 (MP4, MOV, AVI...)。
魅力 (Attractive)	惊喜功能，提升口碑	后台断点续压、智能温控变速、压缩前后画质实时 A/B 对比。
保持 (Indifferent)	基础设置，用户不太关注	App 主题换肤、复杂的关于页面、非核心的社交分享文案编辑。

1.5 WBS 与进度计划调整 (3分)

基于上述需求变更，WBS 进行了如下调整：

• 新增任务： Android ThermalService (温度传感器) 接口调研与对接 (4h)。
• 新增任务： 本地回收站 (Local Recycle Bin) 文件管理逻辑开发 (6h)。
• 调整任务： UI 开发时间延长，需增加“专家模式/简单模式”的切换逻辑。

---

2. 系统设计 (50分)

2.1 系统架构设计

为了保证视频压缩的高性能（利用 GPU/DSP）和跨平台的可维护性，本项目采用 MVVM 架构 + Native 核心层 的分层设计。

架构分层图解

以下是本项目的系统架构图：

架构描述：

1. 表现层 (Presentation Layer - Java/Kotlin):
   • Activities/Fragments: 负责 UI 展示。
   • LiveData/Flow: 观察压缩进度状态，实现 UI 的实时刷新。
2. 业务逻辑层 (ViewModel Layer):
   • CompressViewModel: 处理用户交互，调度压缩任务，不直接持有 View，防止内存泄漏。
   • SettingsViewModel: 管理用户配置（画质偏好、保存路径）。
3. 服务与数据层 (Service & Repository):
   • CompressService (Foreground Service): 核心组件。作为前台服务驻留，确保 App 切到后台时进程优先级高，不易被系统杀掉。
   • VideoRepository: 封装对本地文件系统 (MediaStore) 的读写操作。
   • LocalDatabase (Room): 存储任务历史记录和配置。
4. 原生核心层 (Native Layer - C++/JNI):
   • JNI Bridge: Java 与 C++ 通信的桥梁。
   • Core Engine: 封装 FFmpeg (软编解兼容) 和 MediaCodec (硬编解加速)。
   • ThermalMonitor: 底层温度监控。

2.2 数据库设计

本项目为纯本地应用，主要使用 SQLite (通过 Android Room 框架) 存储任务队列和设置。

核心实体关系图 (ER) 描述

以下是本项目的数据库 ER 图：

1. 任务记录表 (TaskRecord)

用于记录用户的压缩历史，支持断点恢复和历史查询。

字段名	类型	约束	说明
id	UUID	Primary Key	任务唯一标识
source_path	String	Not Null	原视频绝对路径
dest_path	String	-	输出视频路径
status	Integer	-	状态枚举 (0:等待, 1:进行中, 2:暂停, 3:成功, 4:失败)
progress	Integer	Default 0	当前进度 (0-100)
create_time	Long	-	创建时间戳
saved_size	Long	-	节省空间大小 (用于成就统计)

2. 应用配置表 (AppConfig)

Key-Value 结构，存储用户偏好。

字段名	类型	说明
config_key	String (PK)	配置项名称 (如 default_resolution)
config_value	String	配置值 (如 1080p)

---

3. Alpha 任务分配计划 (20分)

3.1 Product Backlog 选取 (5分)

Alpha 阶段目标： 实现核心功能的闭环，即“选视频 -> 压缩 -> 保存”，确保在主流机型上不崩溃。

选取的 P0 级功能：

1. App 权限获取 (存储/读写) 与相册视频扫描。
2. 核心压缩算法 (基于 MediaCodec 的硬编码实现)。
3. 前台服务 (Foreground Service) 及其通知栏进度更新 (保活机制)。
4. 压缩完成后的结果预览与保存/替换逻辑。
5. 简单的参数设置 (分辨率档位选择)。

3.2 Sprint Backlog (任务分解与认领) (5分)

Sprint 周期： 1周 (7天)
估算单位： 小时 (h)

模块	具体任务 (Task)	预估工时	负责人
Native核心	搭建 NDK 环境，集成 FFmpeg/MediaCodec 库	8h	刘瑞康 (后端/算法)
	编写 C++ 压缩逻辑封装与 JNI 接口暴露	10h	刘瑞康
Android服务	实现 CompressService 前台服务与多线程队列	6h	刘泽昊 (后端/算法)
	编写 VideoRepository (MediaStore 扫描与文件读写)	5h	刘泽昊
UI/交互	首页视频列表 UI 开发 (RecyclerView + Glide)	6h	伊尔番 (PM/UI)
	压缩中状态页、结果对比页 UI 开发	5h	伊尔番
	产品交互细节调整与素材切图	4h	伊尔番
测试	全员冒烟测试与 Bug 修复	6h	全员

3.3 迭代冲刺计划 (甘特图) (10分)

注：本计划针对 Alpha 阶段的第一周冲刺。

以下是 Alpha 冲刺计划的甘特图：

每日计划说明：

• Day 1 (11-23):
  • 全员：Git 仓库初始化，分支规范确立。
  • 刘瑞康：NDK 环境配置完毕，Hello-JNI 跑通。
  • 伊尔番：高保真 UI 原型定稿。
• Day 2-3 (11-24 ~ 11-25):
  • 刘泽昊：完成本地视频扫描功能，能读取手机视频列表。
  • 刘瑞康：完成核心压缩函数 demo，输入文件->输出文件。
  • 伊尔番：完成首页 UI 布局。
• Day 4-5 (11-26 ~ 11-27):
  • 联调阶段：Java 层调用 JNI 接口，进度条能真实跳动。
  • 全员：解决核心 Bug（如 Android 11+ 的 Scoped Storage 权限问题）。
• Day 6 (11-28):
  • 测试：在华为、小米、Pixel 真机上进行安装测试。
• Day 7 (11-29):
  • 发布：打包 Alpha v0.1 版本，准备演示。

---

4. 测试计划 (10分)

4.1 测试总纲

鉴于视频压缩属于计算密集型应用，测试重点将放在兼容性（不同厂家魔改的 Android 系统）和性能稳定性（发热与耗电）上。

4.2 测试内容与标准

测试类型	测试内容	通过标准
功能测试	全流程：导入 -> 选择参数 -> 压缩 -> 预览 -> 保存	视频画面正常（无花屏/绿屏），声音同步，文件体积明显减小。
性能测试	1080P / 5分钟视频压缩测试	中端机型耗时不超过原视频时长的 50%；App 无 ANR (无响应)；CPU 占用率波动平稳。
压力测试	连续压缩 10 个视频	App 不崩溃，手机温度未触发系统强行关机，内存无泄漏。
兼容性测试	覆盖 Android 10, 11, 12, 13, 14	核心功能在小米 (MIUI)、华为 (HarmonyOS)、OPPO (ColorOS) 上均能正常运行，权限获取正常。

4.3 资源安排

• 测试工具： Android Profiler (监控 CPU/内存/温度), JUnit (单元测试)。
• 测试设备： 团队成员个人手机 (覆盖不同品牌) + 模拟器 (测试旧版本 Android)。