android多功能音乐播放器设计毕业设计(编辑修改稿)

android多功能音乐播放器设计毕业设计(编辑修改稿)内容摘要：

功能需求 根据项目的目标，我们可获 得项目系统的基本需求，以下从不同角度来描述系统的需求，并且使用 例图来描述，系统的功能需求，我们分成四部分来概括，即播放器的基本控制需要，播放列表管理需求，播放器友好性需求和播放器扩展卡需求。 以下分别描述： 图 音乐 播放器基本控制图 播放器的基本控制需求 表 播放器的基本控制需求表 用例名称：播放 参与者：用户 目标：使得用户可以播放在播放列表中选中的歌曲 前置条件：播放器正在运行 基本事件流： “播放”按钮 用例名称：暂停 播放 暂停 停止 上一首 /下一首 音量控制 专辑封面显 示 歌词显示 本地歌曲列表 网络歌曲列表 搜索 相关设置 用户 金陵科技学院学士学位论文 3 系统需求分析 7 参与者：用户 目标：使得用户可以暂停正在播放的歌曲 前置条件：歌曲正在播放且未停止和暂停 基本事件流： “暂停”按钮 用例名称：停止 参与者：用户 目标：使得用户可以停止正在播放的歌曲 前置条件：歌曲正在播放或暂停 基本事件流： “停止”按钮 用例名称：上一首 /下一首 参与者：用户 目标：使得用户可以听上一首或下一首歌曲 前置条件：歌曲正在播放或暂停 基本事件流： “上一首或下一首”按钮 用例名称：播放清单 参与 者：用户 目标：使得用户可以进入播放清单 前置条件：程序在运行 基本事件流： “清单”按钮 播放清单列表管理需求 当用户选中列表中某一项歌曲，就有的需求： 金陵科技学院学士学位论文 3 系统需求分析 8 图 选中列表中某歌曲时需求图 表 播放器的基本控制需求表 用例名称：播放 参与者：用户 目标：使得程序播放选中的歌曲 前置条件：程序运行在播放菜单选项中 基本事件流： “播放”按钮 用例名称： 添加至播放列表 参与者：用户 目标： 将歌曲添加到歌曲列表 前置条件：程序运行在 文件浏览界面 基本事件流： “增加”按钮 SD卡 用例名称： 删除 参与者：用户 目标：使选中的歌曲被 删除 前置条件：程序运行在播放菜单选项中 基本事件流： “ 删除 ”按钮 播放 添加至播放列表 删除 用户 金陵科技学院学士学位论文 3 系统需求分析 9 播放友好性需求 图 播放友好需求图 表 播放友好需求 表 用例名称：播放模式 参与者：用户 目标：使得程序进入播放模式设定状态 前置条件：程序运行在播放器设定界面中 基本事件流： “顺序、随机、单曲”按钮 用例名称：歌词显示 参与者：用户 目标：使得程序进入播放器歌词设置状态 前置条件：程序运行在播设定界面 基本事件流： “歌词开关按钮”按钮 用户 播放模式 专辑封面 单曲循环 循环播放 歌词显示 随机播放 金陵科技学院学士学位论文 3 系统需求分析 10 功能需求 (时序图 )分析 图 音乐播放器的时序图分析如 (图 ) 系统结构图和流程图 1． 音乐播放器的系统流程图（图 ） 金陵科技学院学士学位论文 3 系统需求分析 11 图 音乐播放器系统 流程图 2． 系统功能表（表 ）和系统功能结构图（图 ） 表 播放器 功能表 功能类别 子功能 子功能 播放列表 播放列表菜单 退出播放 从扩展卡寻找歌曲 歌曲菜单 播放 进入播放界面 删除 数据库同步更新 重命名 数据库同步更新 向上、下移动 数据库同步更 新 播放界面 播放 播放歌曲 线程启动 时间更新 暂停 暂停歌曲 线程暂停 时间暂停 停止 停止歌曲 线程停止 时间停止 上一首 播放列表索引变化 寻找上一 ID歌曲 下一首 播放列表索引变化 寻找下一 ID歌曲 播放界面菜单 返回到播放列表 返回到主菜单 从扩展卡寻找歌曲 金陵科技学院学士学位论文 3 系统需求分析 12 退出播放器 隐藏播放界面 主菜单 退出程序 程序退出 进入播放列表 显示播放列表 图 系统功能结构图 系统界面需求 播放器界面要 求布局合理，颜色舒适，控制按钮友好。 （图 ） 金陵科技学院学士学位论文 3 系统需求分析 13 图 播放器界面 系统性能需求 即使所写 代码能够通过世界上所有的性能测试， 此时该 应用仍然有可能使用户陷入狂暴状态。 例如 缺乏响应性 、 反应慢、某些情况会卡、处理输入的时间非常长 的应用就 会使用户体验大打折扣。 在 Android 中，系统通过弹出一个 “ 应用无响应（ ANR） ” 对话框给用户，来对抗一段时间没有相应的应用。 用户可以在这个对话框中，选择 强制关闭还是等待。 但 是用户不会喜欢在用你的应用的时候总是看到这个对话框。 所以，在你的应用中设计响应性是很重要的，系统就不会弹出 ANR 给用户。 一般来说，当应用对用户输入没有相应的时候，系统弹出 ANR。 例如，如果一个应用阻塞在某些输入输出操作（例如频繁地网络请求），应用的主线程就不会继续响应用户的输入事件。 过了一段时间后，系统会认为这个应用已经废了，于是就弹出一个 ANR 来让用户选择是否强制关闭应用。 金陵科技学院学士学位论文 3 系统需求分析 14 在这 种情况下，建立 一 个子线程来完成工作是常用的修复手段。 这样，主线程（响应UI 事件的循环）就会一直运行，系统就不会认为你的代码死了。 一般来说，线程是属于类级别，所以，你可以认为响应性是一个类级别的问题。 因此 根据 Android 手机系统要求无响应时间为 5 秒，所以就有如下性能要求： 1．当要求歌曲播放时，程序响应时间最长不能超过 5 秒 2．当要求歌曲暂停时，程序响应时间最长不能超过 5 秒 3．当要求歌曲停止时，程序响应时间最长不能超过 5 秒 4．当要求歌曲上 /下一首时，程序响应时间最长不能超过 5 秒 5．当要求进行清单列表时，程序响应时间最长不能超过 5 秒 下面谈谈如何达到性能需求 ，即如何避免 ANR、如何增加响应性 ： 如何避免 ANR 通 过上面给出的 ANR 的定义，为什么 Android 应用会无响应，以及如何使你的应用避免这个。 一般来说， Android 应用会整个运行在一个线程（主线程）里。 这意味着，在主线程，任何需要很长时间完成的动作，由于导致了你的应用没机会处理输入事件或者广播的Intent，都会触发 ANR 对话框。 因此，任何在主线程工作的方法，都应该只做最少的事情。 Activity 的关键生命周期方法，例如 onCreate()和 onResume()里，更要做尽可能少的事。 潜在的耗时运算，例如网络或数据库操作，或者进行类似缩放位图这样的大量 的数学运算，都应该在子线程做。 （对于数据库操作，可以通过一个异步方法，而不必放进另一个线程）。 这并不意味着你的主线程应该阻塞住等着子线程，无论是通过 ()还是 ()。 你的主线程应该提供一个 Handler 来给子线程结束后返回结果。 如此设计 的应用，可以让主线程对输入保持小于 5 秒的响应速度，从而避免 ANR 对话框。 如果其它的线程涉及展示 UI，应该遵循同样的实践。 对 IntentReceiver 的执行时间显示，暗示了它应该做的事情，是后台小规模的工作，类似保存设置或者注册 Notification 一类。 所以，跟在主线程的方法一样，应用应该避免在 BroadcastReceiver 中进行潜在的耗时操作或运算。 除了在子线程中处理大量密集任务（因为 BroadcastReceiver 生命周期是很短的）。 当一个潜在的耗时操作需要返回一个广播 Intent 时， 此时 应用应该启动一个 Service。 另 外 ， 应该避免从一个 IntentReceiver里启动 Activity，这将会跳出一个新的界面，并把用户正在做的工作打断。 如果应用收到广播 Intent 之后需要展示给用户什么的话，它应该使用 Notification Manager。 增强响应性 一般来说， 100 到 200 毫秒是用户感到 “ 卡 ” 的门槛。 下面是避免 ANR 以及加快应用响应额外的 方法。 金陵科技学院学士学位论文 3 系统需求分析 15 如果应用需要等着后台工作的结果 （本应用中网络访问较频繁） ， 此时应在前台 展示出它的进度。 （可以使用 ProgressBar 或 ProgressDialog） 来实现， 如果你的应用初始化耗时很长，考虑使用一个 SplashScreen 或者尽快进入主界面然后再异步地慢慢填充。 在这两种情况，你应该提供给用户一个进度条之类的东西，表明你的应用还没死。 运行环境需 求 支持环境： Android 以上 金陵科技学院学士学位论文 4 Android 音乐播放器系统设计 16 4 Android 音乐播放器系统 设计 音乐播放器界面功能实现 音乐播放器界面用了 TableHost 组织 5 个 Activity，每个 Activity 则 用了 Android 5 大布局 （ LinearLayout（线性布局）、 FrameLayout（框架布局）、 TableLayout（表格布局）、AbsoluteLayout（绝对位置布局）、 RelativeLayout（相对位置布局）） 跟常用。