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

项目 内容
这个作业属于哪个课程 2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里 [I.2] 个人作业：软件案例分析
我在这个课程的目标是 学习软件工程相关的基础知识，并在实战中运用这些知识
这个作业在哪个具体方面帮助我实现目标 加深对开源软件，以及对软件开发流程的理解

我本次作业选择了一个开源的鸿蒙版通用音乐客户端作为分析对象。

首先要在这里点名批评网易云，为什么到现在都没有鸿蒙版

调研、评测

软件使用

该软件支持多种音乐软件的数据源，包括但不限于网易云、QQ音乐、酷狗音乐等等。

使用该软件的前提是自己有数据源，可以自己搭服务器，也可以在网上寻找公开数据源。

添加数据源后才能进行登录等一系列操作。

这是登录后的主页面，主要内容有：

  • 歌单、下载等二级页面入口
  • 个性化推荐歌单（今日推荐、私人FM）的二级入口
  • 推荐歌曲
  • 推荐歌单
  • 推荐艺人

以下为歌单界面：

支持一键播放歌单内所有歌曲、一键下载歌单内所有歌曲、收藏歌单

以下为歌曲播放页面：

支持通过点击歌词跳转到相应位置

软件评测

软件使用流程

  1. 登录

    • 首先，正如上文所说，使用该软件必须有自己的数据源
    • 扫码登录，获取用户token

  2. 探索

    • 浏览首页推荐的歌单、歌曲，或进入网易云提供的今日推荐、私人FM
    • 利用顶部搜索框搜索指定歌曲、歌单或歌手

  3. 音乐播放与控制

    • 点击页面底部的播放栏可以进入播放与控制界面
    • 使用播放控制面板进行操作：播放、暂停、切换上一首下一首、调整播放模式（单曲循环、列表循环、随机播放）
    • 点击歌曲头图切换到歌词界面
    • 点击红心，将当前播放的音乐加入到心动歌单；

  4. 歌单管理

    • 目前该软件的歌单管理功能比较简陋，支持的功能仅有：播放歌单内全部歌曲、下载歌单内全部歌曲。

这个软件目前的状态只能说是能用，绝对说不上好用。它仅仅能满足用户“听”的需求，因为其歌曲的播放、切歌，歌单的播放，以及歌曲个性化推荐功能是较为完善的。但对于歌单的操作，例如收藏/取消收藏歌单，将歌曲添加至歌单/从歌单中删除歌曲，通通是没有的。

下面简单分析该软件的优缺点：

首先是优点：

  • 界面：完全由ArkTS编写而成，界面简洁清晰
  • 用户体验：
    • 免费、无广、响应迅速
    • 切歌时支持淡入淡出，切歌体验良好
    • 支持翻转静音，即将手机扣在桌上时自动停止播放歌曲，翻转至正面时再自动开始播放，人性化的设计
  • 功能：
    • 支持均衡器功能，可以对音质进行微调
    • 有方便的清理缓存功能，节省手机空间

再说缺点：

  • 界面：

    • 鸿蒙系统向来以丝滑著称，但该软件在歌单内滑动浏览歌曲列表时，能够感受到明显卡顿，可能与歌曲信息载入的优化有关
    • 感觉首页缺乏一定设计感，上部的圆角矩形和胶囊形状有割裂感

  • 功能：

    • 正如上文所说，没有支持对于歌单的操作
    • 没有支持歌曲评论功能
    • 没有歌词翻译功能
    • 其他诸如听歌识曲等更加现代化的功能更是不可能有

  • 用户体验：

    • 用户体验和功能是挂钩的，这么多我认为必要的功能的确实，必然会导致用户体验的下滑。

分析与改进意见

其实写这么多缺点，归根到底还是功能不足导致的。希望开发组尽快实现更多常用功能吧~

当然，这个软件完全是一群华为用户为爱发电写出来的，能写成这个样子已经很不容易了，毕竟我目前没有听说过第二个能听网易云歌的软件(

用户调研

  1. 采访对象背景：我采访的对象是我的高中同学，现北京交通大学软件学院本科生项重善同学。选择采访他，首先是因为他是我认识的最爱听歌的人，对于音乐软件有着较为深刻的理解，其次就是他的专业背景让他能够在体验一款全新的软件时快速的给出中肯且细致的评价。需求这块比较简单，就是能听歌就行。

  2. 实际使用栏目：由于该软件目前功能较少，因此我让他把所有功能都体验了一遍

  3. 问题和亮点：

首先说亮点：软件打开速度很快，没有广告；推荐艺人栏目ui设计合理好看；歌单上拉能够直接返回，小巧思；歌曲播放界面干净简洁；如果有多个数据源，那么可以仅下载一个软件享受多个软件的音乐库。

再说问题：首页的“专属于你”栏目与其他栏目加载不同步，一般会慢半拍，很奇怪；一级二级页面切换时存在明显掉帧现象；主页上方按钮很难看，按钮设计（包括按钮图案和按钮上的名称）不具有指明按钮功能的能力；下载歌曲成功时没有反馈，仅在再次点击下载按钮时反馈“当前歌曲已被下载”；歌曲的定时关闭功能处输入数字的含义不明确；

  1. 需要改进的地方：

这位同学认为最要紧的是面子工程：应该优先解决软件的掉帧问题以及对首页的UI进行美化。

评测结论

我的结论是：不推荐。如果你不是像我一样，充了网易云的会员，用着鸿蒙手机，又不愿意用那个锁了90帧的卓易通，那我不会推荐你使用这款软件。

Bug 分析

  1. 播放列表删除正在播放的歌曲后，音乐未停止且无法自动切歌
  • 测试环境：
    系统为HarmonyOS 6.0.0.130，软件版本为2.5.1
  • 可复现性及具体复现步骤：
    该Bug为必然发生的逻辑错误。具体复现步骤如下 ：
    • 播放歌曲
    • 在不暂停的情况下，将歌曲从播放列表中移除（或情况播放列表）
  • Bug具体描述：
    UI 层面的播放列表已经移除了该歌曲的节点，但音频引擎仍在持续输出该歌曲的音频流。当该歌曲播放完毕后，由于当前播放索引已经失效，播放器进程陷入停滞，不会自动播放下一首

如图所示，在播放歌曲《New York》时，将播放列表清空后，该歌曲会持续播放直到结束。此时，由于播放列表已经清空，无法进行上一首/下一首的切歌操作，且当前歌曲播放结束后不会自动播放下一首歌曲。

在常规的用户心智模型中，“从列表中删除”等同于“销毁该对象的生命周期”。一个已经被删除的对象依然在占用音频输出通道，违背了对象生命周期管理的常理，且导致后续的自动连播功能失效，因此我认为这是一个功能性Bug，而非产品特性。

  • Bug分析

该bug可能是UI层与数据层解耦不彻底导致的。UI层的播放列表可能只是一个数组或链表，当用户执行删除操作时，程序仅更新了链表结构，忘记向音频播放线程发送停止信号。

这个bug破坏了连续播放逻辑，会让用户感到程序失控，但不会使软件崩溃闪退，综合来看我给该bug的评分为3/5.

该bug为修复的原因大概就是测试把关不严。测试时可能只覆盖了“暂停状态下删除”或“删除非当前播放歌曲”的常规用例，忽略了“并发状态下修改正在消费的数据源”这种边界测试用例。

  • Bug改进

当播放音乐时，用户将该歌曲从播放列表中删除，则应该立即停止播放当前音乐，随后播放器应该自动加载并播放更新后列表中的下一首歌曲。

为解决该bug，应该在播放列表的删除方法中添加逻辑判断，如果targetSong.id == curPlayingSong.id，则应该调用播放器中的停止播放方法。在将当前歌曲从播放列表删除后，则应调用播放器中的播放下一首方法。

  1. 重复点击正在播放的歌曲导致播放器卡死
  • 测试环境：同上
  • 可复现性和具体复现步骤：

该bug也为必然发生的bug。具体复现步骤如下：

  • 在歌单中选择一首歌曲进行播放

  • 在该歌曲播放过程中再次点击歌单中的该歌曲，则会触发此bug

  • Bug具体描述：

重复点击同一首正在播放的歌曲后，播放器实例进入了一种不可逆的阻塞状态，正在播放的歌曲会停止播放，无论点击底部控制栏的“播放/暂停”按钮，还是拖动进度条，均无法恢复播放，必须重启应用或点击另一首歌曲才能恢复。

该bug可能需要视频才能够有较好的展示效果，因此这里不再配图

  • Bug分析：

从系统功能上看，核心的播放链路被中断；从用户体验上看，用户必须进行额外的应用重置操作（切歌或重启）才能脱离卡死状态，极其影响使用心情。因此我认为这是一个较为严重的bug（4/5）.

该bug反映出软件的设计质量不高。开发团队在编写播放器控制器时，没有严格按照防御性编程的原则设计状态机，缺乏对非法状态转换的容错拦截机制。

  • Bug改进：

再次点击正在播放的歌曲时，合理的反馈应该是切换该歌曲的播放/暂停状态，或者直接忽略本次点击。

在列表点击事件的Listener中，应该增加一层路由分发逻辑：获取用户点击的 song_id，与全局维护的 current_playing_id 进行比对，如果两者相同，则调用播放器暂停方法；如果不同，才执行销毁当前播放器并重新初始化与播放。

bug反馈

以通过云享社意见反馈平台反馈这两个bug

分析

工作量分析

制作该软件的核心工作可分为：API 对接、播放、歌单、推荐、下载这几部分内容。总体评估，完成该软件大约需要 6 到 8 周（约 1.5 到 2 个月） 的时间。

  • 阶段1（1-2周）：对接网易云音乐的民间 API。这部分需要处理登录授权（Cookie/Token 管理）、接口联调以及错误重试机制
  • 阶段2（2-4周）：完成基础设施：调用鸿蒙原生的媒体播放接口，实现基础的播控逻辑，大概包括播放、暂停、上一首、下一首、进度条拖拽。同时，适配鸿蒙的后台任务机制和媒体会话，确保锁屏和通知栏可以正常控制音乐。
  • 阶段3（4-6周）：基础设施完成后，开展各项业务模块的开发：对接推荐歌单、每日推荐歌曲 API，完成歌曲列表渲染；实现用户个人歌单的获取、展示以及歌曲的“红心”收藏/取消收藏功能。
  • 阶段4（6-7周）：调用鸿蒙的文件系统 API，实现音频文件和专辑封面的本地持久化。
  • 阶段5（7-8周）：进行高强度交叉测试

软件质量分析

该软件的最大优势就是其不可替代性，除了自己新写一个以外，你找不到第二个鸿蒙原生的网易云播放器（因此排名对该软件来说也是没有意义的）。而劣势也很明显，就是功能不完善、bug较多。

基于前文提到的bug，我认为在开发核心的媒体播放模块前，这个软件团队可能没有建立过严谨的有限状态机模型来分析所有可能发生的调用链。但退一步来说，如果该团队能够在发布软件前进行有效的、高覆盖率的软件测试，那么这些bug也是能够规避掉的。所以总的来说，我认为该团队目前最应该强化的是其测试环节，针对音频播放等核心且复杂的模块，不能仅依赖手工点按测试，应该编写自动化单元测试脚本，且特别要增加针对状态机边界情况的测试用例。

建议和规划

市场规划

  1. 市场概况：随着纯血鸿蒙的不断推进，原生应用生态正处于红利期。该应用的直接用户是目前已经升级鸿蒙系统、且苦于没有官方网易云原生App的尝鲜者，以及希望通过一个App享受各个数据源的人。潜在用户则是未来数以亿计的鸿蒙设备使用者。只要官方应用一天不完善，这种轻量级、无广告的第三方播放器就永远有着庞大的长尾市场。
  2. 竞争产品： 目前市场上的主要竞品包括：网易云安卓版、华为系统自带的华为音乐，以及其他可能存在的开源第三方播放器。与官方 App 相比，我们的劣势是功能匮乏、版权获取依赖第三方 API；但优势在于极致的轻量化、纯粹的“听歌”体验以及优秀的系统底层契合度。

市场与产品生态

这个产品的典型用户主要是 18-35 岁的大学生或年轻职场人。他们通常具备一定的折腾能力，能够自己配置或寻找开源的数据源，并且对流氓软件和无孔不入的广告深恶痛绝。他们的表面需求是“在鸿蒙手机上流畅地听网易云的歌”，而更深层次的需求则是获得一个符合现代UI审美的、“纯粹”的音乐app。

这是一个开源项目，用户群体之间天然存在着社区互助的关系。这些用户不仅是消费者，更可以是贡献者。我们可以鼓励用户提交issue、分享自己搭建的公开数据源（我现在用的就是大佬分享的自建数据源），甚至提交代码优化UI，形成一个“开发者-核心用户-普通用户”的良性开源闭环生态。

这个产品没有也很难有子产品，不过因为其基于鸿蒙的ArkTS与ArkUI进行开发，天然的能够实现“一次开发多端部署”，依靠鸿蒙的生态构建起手机端-PC端-车机端的软件生态。

产品规划

新功能设计

针对前文评测中提到的最大痛点——“对歌单的操作通通没有”，我计划开发“高级歌单管家”功能 。

我认为该软件的最大痛点在于没有歌单相关的操作。因此我希望首先在该软件基础上开发歌单管理功能。

  • Need：使用音乐软件听歌的用户们想要的远不仅仅是一个能听歌的软件。歌单是音乐软件最核心的用户粘性来源。用户迫切需要将发现的好歌添加到自己的各个歌单中，或者对既有歌单进行删减、排序，这是音乐软件最核心的交互闭环。

  • Approach：在本地构建一套小型的映射数据库。当用户对网易云数据源的歌单进行操作时，一方面调用 API 同步云端，另一方面在本地数据库进行状态缓存，确保即使在弱网环境下也能流畅完成增删改查，并支持多选批量操作。

  • Benefit：歌单功能是打造一个完整音乐推流app的必要路径，能够极大提升用户的留存率

  • Competitors：目前来看网易官方可能永远无法退出他们的官方鸿蒙版app，这就是我们的核心竞争力）

  • Delivery：在github上发布release版本

角色配置

既然是要发布改进版本，那么就既要修复前文发现的bug，又要添加新的功能。

  • 1名PM：把控全局进度，同时需要梳理AVPlayer的状态机边界逻辑
  • 2名前端开发：负责ArkUI的编写。一人负责设计并重构首页UI，解决圆角矩形割裂感和按钮指代不明的问题，另一人负责重写列表渲染逻辑，解决一二级页面切换过程中的掉帧问题
  • 2名后端开发： 负责数据库搭建、网络请求队列封装，同时开发“高级歌单管家”的业务逻辑
  • 1名测试：编写单元测试，针对切歌、断网、快速重复点击进行高强度自动化与黑盒测试，并兼顾UI设计审核
posted @ 2026-03-14 15:55  owpeter  阅读(1)  评论(0)    收藏  举报