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

选题：🎶音乐软件

​ 我体验Apple Music的具体时间已经无从计量了，从高中时期开始加入网络“拼车”团队一直到现在用着6元一个月的大学生优惠价。Apple Music实实在在地贯穿了我的音乐经历，成为我日常生活中稳定而熟悉的数字服务。因此，以Apple Music作为对象进行一次软件产品分析，不仅具有现实体验基础，也能够从用户视角对其功能设计、产品策略以及用户体验进行较为具体的观察与评价。同时，为了让结果更有普适性，我从软件体验、软件功能等角度调研了身边很多同学和朋友，有的使用Apple Music，有的则使用其他。

​ 相较于iPhone端版本，Mac端 Apple Music在功能设计和使用体验上既有值得肯定之处，也存在一些稳定性方面的问题，例如在实际使用过程中仍能观察到一定数量的bug。因此，本文将主要以 、macOS平台上的Apple Music为研究对象，结合实际使用体验，对其功能设计与存在的问题进行分析。

第一部分 调研评测

1.软件评测

  1. 软件使用

​ 从本人使用MacBook以来，一直使用Apple Music作为PC端的听歌软件，对AM的各种操作非常了解。
截屏2026-03-14 03.01

  1. 软件分析

    登录Apple Music后，用户首先进入应用首页。界面左侧为主要的导航栏，包含以下几个核心模块：

    • 搜索
    • 主页
    • 新发现
    • 广播
    • 资料库
    • 播放列表

    ​ 其中，资料库”用于管理用户已收藏或已添加的音乐内容。默认情况下，资料库按照最近添加、艺人、专辑、歌曲四种不同维度对音乐进行分类，方便用户从不同角度浏览和整理自己的音乐资源。

    ​ 在资料库下方是播放列表区域。默认情况下系统会自动生成一个“喜爱歌曲”列表，用于收集用户标记为喜欢的音乐。同时，用户也可以根据需要自行创建新的播放列表。从功能上看，Apple Music 中的“播放列表”与其他音乐软件中的“歌单”概念基本一致。

    ​ 用户可以在左侧播放列表区域的空白位置点击右键创建新的播放列表，并且还可以创建播放列表文件夹，用于对多个播放列表进行分类管理，从而提升音乐管理的效率。

    ​ 界面左下角用于显示和管理当前账号信息。不过，在Mac端切换账号时，需要通过顶部 Mac 菜单栏中的“账号”选项 才能完成切换。相比之下，iPhone 端通常需要使用与 App Store 绑定的账号，而 Mac 端允许更自由地切换账号，因此在使用灵活性方面体验更好。

    ​ 软件的正下方有一个操作栏，允许用户切换随机播放和循环播放。

    ​ 当用户点击播放某一首歌曲时，系统实际上会创建一个播放队列。这个播放队列的来源取决于用户当前所在的页面。例如：

    • 如果用户在专辑页面点击歌曲，则播放该专辑中的歌曲；
    • 如果在歌手页面点击歌曲，则可能按照歌手的作品列表进行播放；
    • 如果是在搜索结果中点击单曲，则播放队列中可能只包含这一首歌曲。

截屏2026-03-14 14.48

​ 选择了歌曲播放之后，右边栏便出现实时歌词，同时下方显示在放的歌曲。歌曲的封面可以点击后进入迷你播放程序或者全屏幕，以获得更加沉浸式的播放体验。
layout-collage-1773471068043

  1. 改进意见

    • 本地化适配不足

      对于中国人来说，“资源库”、“播放列表”这样的名词术语虽然在产品设计层面具有明确含义，但对于普通中国用户而言，这些表达并不十分直观。

      以“播放列表(PlayList)”为例，“播放列表”这一翻译虽然较为准确，但在国内用户的长期使用习惯中，“歌单”这一称呼已经更加普及。因此，当用户从其他音乐平台迁移到 Apple Music 时，可能需要一定的时间来适应其术语体系。同时“插播”相对于“下一首播放”也不是很直观。

      Apple Music在全球范围内保持了较为统一的产品结构和术语体系，但在部分地区，如果能够根据用户的语言习惯进行更加贴近本地语境的表达优化，可能会进一步降低新用户的学习成本，提高整体的产品易用性。

    • UI设计缺陷

      在我进入迷你播放页面后，我发现能以回到原来的默认页面，经过反复摸索，发现居然需要点击左上角的红色❌才行，反直觉。

      搜索功能有时默认使用资源库，但是我相信大部分用户使用搜索功能时，不是希望从自己的资源库里面找歌，而是希望“全网搜索”

  2. 用户调研

    ​ Apple Music在全球市场份额占比很高(~15%)，仅次于Spotify，但是在国内却一直是不温不火的状态。

    ​ 我身边使用苹果设备的人并不稀缺，但是我发现大部分朋友都没有使用Apple Music。我经过一些采访后发现，有些朋友是由于从小接触QQ音乐等软件带来了路径依赖，有的是因为在其听歌爱好中，Apple Music等曲库并不全，同时新歌上架所需时间有时比较长。而在使用者中，包括我在内的大部分用户都以“大学生优惠便宜”为核心原因，同时还有UI设计简洁，没有广告弹窗和其他冗余功能。

2
从网络数据来看，Apple Music女性用户占比较高(63%)，同时年龄封闭较为均匀。在现实中，往往是使用iPhone或者其他苹果产品的群体才会考虑的软件。

  1. 评测结论

    综合我的长期体验和上述测评，我给 Apple Music 的 Mac 端评价为：d) 好，不错
    首先这款软件保留了 Apple Music 的简洁特点，和其他国产软件相比，没有花里胡哨的直播等功能和各种广告弹窗，使用体验非常舒适。但是其软件优化仍有很大的进步空间，综合给到d评级

2.Bug分析和提交

  • 设备环境 Macbook Air M4 16-512，系统版本macOS tahoe 26.3.1，Apple Music版本为1.6.3.2
    (macos和apple music已经更新至最新版本)

  1. 登陆界面UI设计问题

    在未登陆Apple账号的情况下，在应用的默认窗口(或者更小或更大一点)，之后点击进入“广播”即可

    截屏2026-03-14 02.37

    • bug严重程度：⭐️ ⭐️
    • bug原因：在默认窗口尺寸下，界面文字出现被截断或省略的情况，说明界面布局在不同窗口尺寸下的适配存在问题。
    • bug分析：对于该 bug，更可能的原因在于测试环节的覆盖不足。首先，该界面并非用户首次登录时出现，而是在用户切换账号并进入“广播”界面时才会触发，因此其使用频率相对较低。其次，本人的设备为 13 英寸 MacBook Air，小尺寸屏幕更容易暴露该问题；而在放大页面或开启全屏模式后问题便不会出现。考虑到 macOS 客户端测试通常更侧重于主打的设备（如屏幕更大的 MacBook Pro 系列），这一设备差异也可能导致问题未被及时发现。最后，登录界面本身并不属于用户的核心“黄金流程”，在 macOS 26 版本整体 bug 较多的背景下，此类边缘场景的测试优先级相对较低，因此最终未能在测试阶段被发现。多种因素叠加，导致该 bug 遗漏至正式版本。

  2. AirPods连接bug

    关闭 Apple Music 的后台，之后戴上 AirPods ，按下键盘上的播放按钮，Apple Music有概率直接启动并且开始播放音乐。

    • bug严重程度：⭐️ ⭐️ ⭐️ ⭐️
    • bug原因：可能是 Apple Music 作为系统级应用唤醒权限设置错误导致。
    • bug分析：类似的 bug 我在Safari上也遇到过，但是Chrome上并没有复现过。我个人不认为Apple在发布时没发现这样的bug，而更可能与复现条件复杂、责任边界模糊以及修复优先级较低等因素有关。首先，该 bug 的触发依赖于一系列特定条件：用户需要在Apple Music未运行的情况下佩戴 AirPods，并通过键盘或耳机发送播放指令。这一过程涉及系统硬件事件、系统媒体控制机制以及应用启动逻辑的交互。同时，Apple Music作为系统自带的原生应用，一般具有较高的系统权限，该bug的根本原因可能位于系统媒体控制逻辑与应用注册机制的交互层面，而不完全是 Apple Music 应用本身的问题。这种涉及系统团队与应用团队责任边界的问题，在实际开发流程中往往需要跨团队协作处理，修复周期通常较长。

  3. 全屏幕播放歌词加载bug

    选择一首你从最近在该设备上播放过的音乐，全屏幕模式后歌词可能不会显示，复现率较高

    截屏2026-03-14 02.30

    可以看到我开启了歌词，但是歌词并没有加载出来，并且不断点击歌词按钮也无法加载，复现率较高

    • bug严重程度：⭐️ ⭐️ ⭐️
    • bug原因：在暂停状态下进入全屏界面时，播放器的播放状态与歌词模块之间可能未正确同步，导致歌词模块未触发加载逻辑。
    • bug分析：虑到 Apple 这样规模的团队，这类问题在测试阶段完全未被发现的可能性并不高，更合理的解释可能是该问题已经被发现，但在当前系统更新周期中优先级相对较低。macOS 26 在引入新的 “Liquid Glass” 设计后整体 UI 系统变化较大，在系统层面已经出现了较多与渲染和界面状态相关的问题。在这种背景下，音乐软件在全屏幕这种相对不常使用的界面状态下随机出现的 bug，可能被暂时认为影响范围有限而未被优先修复。

Bug反馈

截屏2026-03-14 02.56

以上bug均已全部反馈给力Apple Music的开发团队。

第二部分 分析

1. 工作量分析

仅仅从软件功能来说，Apple Music的核心主要在于

  • 用户登录与账号管理
  • 音乐搜索与推荐系统
  • 音乐播放与播放队列管理
  • 资料库和播放列表
  • 播放界面和实时歌词显示

对此，从工作量上看，Apple Music的Mac端开发大概需要一下几个阶段

  1. 需求分析与产品设计（约2周）

    ​ 在这一阶段需要确定产品的核心功能、界面结构以及基本交互逻辑，同时设计整体的信息架构和用户流程；同时，开发成员需要选定合适的框架结构：前端原生Swift框架和后端数据库架构，并且搭建好流水线。

  2. UI 设计与原型制作（约2周）

    ​ 在这一阶段需要在专业UI/UX的帮助下完成主要界面的视觉设计和交互设计，并且和开发人员确定实现细节，确保软件的美观性和易用性，为用户创造更好的使用体验。

  3. 核心功能开发（约12周）

    ​ 与部分功能复杂的互联网产品相比，Apple Music在功能设计上相对克制，没有过多冗余或娱乐化功能，这在一定程度上降低了整体开发复杂度。同时，在macOS平台上可以直接使用原生Swift开发框架，许多基础组件可以直接调用系统 API，从而减少底层开发工作量。

    ​ 在这种情况下，开发工作的主要难点更多集中在前端复杂界面的实现、后端逻辑实现以及搜索与推荐算法的实现等方面。

    开发内容主要包括主要包括：

    • 搭建后端基础架构，包括用户信息、音乐资源等相关数据库结构，并实现基本的业务逻辑；
    • 设计并实现后端API接口，同时确保接口访问的安全性与稳定性；
    • 实现音乐搜索与推荐算法，并通过数据库结构优化提升检索与推荐效率；
    • 完成客户端前端界面的开发，实现音乐浏览、播放控制以及资料库管理等功能模块，并保证界面展示效果与交互体验达到较好的水平。

  4. 测试与优化（约6周）

    在核心功能基本完成后，需要进行系统测试、UI 调整以及性能优化，包括：

    • 不同屏幕尺寸的界面适配
    • 播放稳定性测试
    • 网络异常情况处理
    • 用户体验优化

  5. 综合来看，如果一个小型团队从零开始开发一个功能较为完整的Apple Music的Mac端，整体开发周期大约需要5-6个月左右。

    不过需要指出的是，实际中Apple Music的开发并没有那么简单，以上的工作量仅仅是从学生大作业项目的难度考虑的。从整个产品系统来看，其真实开发规模远远超过上述估计。在实际软件中还会遇到更多问题如：

    • 更加复杂的推荐算法与个性化推荐

    • 全球服务器架构

    • 和AirPods等硬件层面的交互和软件优化

2. 软件质量分析

从整体体验来看，我认为Apple Music的Mac端在音乐软件市场中属于质量较高的一类产品。

与国内常见音乐软件（如QQ 音乐、网易云音乐等）相比，Apple Music 的主要优势体现在以下几个方面：

1. 界面设计简洁，占用较小

​ Apple Music 的界面整体延续了 Apple 一贯的简洁设计风格，没有复杂的社交模块或大量广告内容，整体界面较为干净，使用户能够更加专注于音乐本身的体验。

​ 同时，在系统资源占用方面，Apple Music也表现较为优秀。与部分体积动辄达到数GB的音乐软件相比，Apple Music的应用体积仅约60MB左右。在实际运行过程中，其内存占用大约为200MB 左右；整体能耗也相对较低，12小时消耗10%左右的电量，整体能效表现较好。

截屏2026-03-16 13.21

2. 音乐内容质量较高

​ 在我的实际体验中，Apple Music拥有较为完整的音乐版权库(点名批评网易云)，并且在专辑信息、艺术家资料以及空间音频等方面提供了较好的内容体验。

然而，Apple Music的Mac端也还有很多不足：

1. 软件优化不足

​ 即使在较新的 Mac 设备以及最新系统环境下，Apple Music在使用过程中仍然会出现明显的卡顿现象。虽然从系统资源占用的角度来看，该应用并不算庞大，但在当前的功耗和资源使用水平下，其运行流畅度仍然存在进一步优化的空间。

​ 此外，在macOS引入新的Liquid Glass之后，Apple Music中与界面相关的 bug 数量也大幅增加，这在一定程度上影响了软件的稳定性。

2. 本土化适配不足

​ 这一点在上文已经阐述过了，相对于本土音乐软件，Apple Music上的很多交互和用语都较为反直觉。

第三部分 建议和规划

1. 市场现状

  • 市场概括

​ 全球流媒体音乐市场规模持续扩大，整体呈现寡头竞争格局。目前全球在线音乐流媒体付费用户数已突破数亿，其中 Spotify 凭借约 30% 以上的份额稳居第一，Apple Music 紧随其后（约占 15% 份额，超 1 亿用户）。

​ 在中国大陆市场，腾讯音乐（TME，含QQ、酷狗等）和网易云音乐占据了绝对主导地位，用户基数达数亿。Apple Music 在国内属于“重度果粉”或者“大学生优惠”的选择，直接用户规模相对较小，但用户付费率和忠诚度极高。同时，相对于其他软件“AI无损”甚至做出先压缩音质再AI还原的骚操作下，Apple Music的唱片母带能提供高品质无损音源，为追求音质的发烧友提供了一种相对不错的选择。

  • 国内竞品分析

    1. Spotify：曲库最全，非付费用户也可以无广告听歌（广告被墙）；国内推广极少，市场份额忽略不计。
    2. QQ音乐：曲库较全；功能丰富，兼具社交属性；内容臃肿，存储和性能占用都很大。
    3. 网易云音乐：用户社区生态良好，话题度较高；版权问题严重，曲库缺失影响体验。

  • 产品定位

    Apple Music核心功能突出，仅仅作为一个音乐播放平台，适合追求纯粹音乐平台的用户。

    • 优势：作为Apple自带的软件，天生具有流量入口；曲库较全，能满足大多数听歌需求；拥有唱片发行的母带，音质较高；大学生优惠价格较低；内容纯净，无弹窗广告等牛皮鲜和冗余功能。
    • 劣势：订阅制，并且完全不提供免费功能和广告试用；曲库更新较慢，有时一首歌发行后好几周才能上架；本地化适配较差，

2. 市场与产品生态

核心用户群像：

  • 典型特征：年龄分布均匀，学生优惠对大学生吸引力较大；核心用户为Apple设备的使用者以及对音质有较高追求的普通音乐爱好者；同时有为数字内容和版权付费的习惯。
  • 需求洞察：
    • 表面需求：在一个没有广告、排版精美的软件里听无损音乐。
    • 潜在需求：更精准的推送算法、更高效且直观的歌单管理、和ChatGPT等第三方AI的接口层面的高效互动、跨设备的音乐“接力播放功能”、桌面歌词功能。

用户生态结构：

​ 目前Apple Music的用户生态呈现出一种相对私密、甚至有些“孤岛化”的状态，大范围的陌生人关系链极弱。虽然苹果生态内已经支持了“同播共享功能，允许好友之间跨设备实时同步收听音乐，且有基于不同城市和不同类型给出的热门歌曲榜单，但整体而言，这种互动多局限于熟人小圈子。如果要进一步构建用户生态，Apple Music绝不应效仿国内竞品去做“大广场”式的社区。强行引入喧闹的公共社交模块，无疑会严重破坏那些追求纯粹、无打扰听歌体验的核心用户的使用感受。因此，继续深耕基于熟人关系链的轻量级，才是其生态发展的合理边界。

产品生态关联：

Apple Music 拥有极强的软硬一体化产品生态。它并非孤立的软件，其子产品及关联产品包括：

  • 硬件层：AirPods独占“空间音频”与“动态头部追踪”，通过HomePod或Apple Watch进行精细的播放控制与离线同步，构建了完整的音频生态。
  • 软件层：Apple Music拥有macOS媒体控制中心、Spotlight以及 Siri 的最高优先权。它并非一个独立运行的第三方软件，而是系统全局音频管理的一个“原生入口”。利用 FaceTime 和 iMessage 的底层协议，同播共享提供了跨设备的实时音频流同步。
  • 服务层：作为 Apple One 捆绑包的核心成员，Apple Music与iCloud存储、Apple TV+等服务共享订阅逻辑，通过服务间的交叉补贴和统一支付体验，极大地增强了用户的长期粘性。同时，账号和Apple ID绑定，登陆同一Apple账号即可实现资产云端存储。

3. 产品规划

​ 在当前 macOS 版 Apple Music 的基础上，我计划新增核心功能：实时活动歌词显示功能。该功能旨在打破传统音乐软件窗口化的限制，将播放控制与交互逻辑彻底融入系统底层。

功能介绍

  • 该功能将传统“窗口化”的播放器逻辑进化为常驻于 macOS 系统顶栏的“实时活动”模块。

    • 高动态信息显示：在菜单栏直接展示当前曲目的微型进度条与封面缩略图，并支持在顶栏空间进行高频实时歌词滚动。
    • 原生悬浮控制中心：用户点击顶栏图标即可瞬时唤起基于控制浮窗，集成播放/暂停、精准切歌及音量平滑调节，且实现快捷键全局唤起。
    • 高度可控的自主权：在系统设置中提供“沉浸模式开关”，允许用户自主决定该组件的可见性与交互强度。

  • 解决痛点：

    • 交互逻辑重构：针对前文分析中提到的“迷你播放器需点击红色❌才能返回主界面”这一反直觉设计，新的菜单栏组件采用系统级“浮层”交互。用户通过快捷键或点击菜单栏图标呼出/隐藏，彻底消除了“关闭窗口等于退出”的逻辑混乱，实现了更符合 macOS 规范的返回体验。
    • 沉浸式工作流：针对用户在处理编程、文档等重度任务时，需要频繁切换应用（Cmd+Tab）查看歌词或操作音乐的痛点，该功能允许用户在通知区域直接扫视歌词。这种“零干扰”的音乐体验能有效保护工作流，减少视觉和思维中断。

  • NABCD 模型分析

    • **N (Need) **：用户需要一种低侵入性、高响应速度的音乐控制方式，尤其是对实时歌词的快速扫视需求。同时需要修复现有客户端在迷你播放模式下歌词加载缓慢或失败的bug。
    • **A (Approach) **：利用macOS Menu Bar Extras与 Live Activities API 实现组件的底层常驻；采用原生方式优化歌词滚动引擎，确保在系统高负载下 UI 依然保持 60 帧以上的平滑度。
    • **B (Benefit) **：极大地提升了系统的交互连贯性。相比于独立的 App 窗口，菜单栏组件内存占用更低，且能与系统的“专注模式”联动，提供更纯粹的视听体验。
    • **C (Competitors) **：大部分软件的桌面歌词通常以“悬浮窗”形式存在，容易遮挡工作视窗，且视觉风格与原生系统严重割裂。我们的方案是系统原生的，并且更加美观，不会遮挡视线。
    • **D (Delivery) **：配合macOS年度大版本更新进行“生产力组件”专题推介。

  • 6人角色配置

    1. UI/UX 交互设计师 (2人)：负责设计菜单栏组件在不同系统主题（深浅模式）下的视觉规范，以及浮窗交互的动效设计。
    2. macOS 开发工程师 (2人)：核心任务是基于 SwiftUI 开发菜单栏常驻图标、实时歌词滚动引擎以及与主应用的进程间通信逻辑。
    3. 系统优化工程师 (1人)：负责底层渲染管线优化，实现“点击即瞬时渲染”，确保零延迟响应。
    4. 质量保证测试 QA (1人)：测试不同屏幕分辨率的 UI 适配，以及高负载运行环境下的功耗表现测试。

  • 16 周开发里程碑：

    阶段 周次 关键任务与交付物
    UI/UX设计 1-3周 明确用户的需求，设计优良的交互界面和交互逻辑。
    方案定义与原型 4-5周 确定 Live Activities 技术选型；定稿高保真UI原型；定义App Intents全局唤起协议。
    核心功能构建 6-11周 搭建菜单栏常驻框架；开发高性能歌词滚动引擎；集成播放、切歌、音量调节等底层指令。
    性能调优 12-13周 优化毛玻璃渲染效果与内存占用；开发歌词预加载逻辑，解决弱网下的加载断层；。
    功能测试 14周 针对进行多设备，多分辨率适配测试；
    测试与发布 15-16周 完成对Apple Music的全量测试；进行 TestFlight 灰度测试，准备正式封版发布。
posted @ 2026-03-16 17:56  LightALm  阅读(33)  评论(0)    收藏  举报