基于Tomcat与Android的简易在线音乐播放器系统

2025-11-27 12:49:43 分类：tomcat 热度：1K 评论： 0

本文还有配套的精品资源，点击获取

简介：本项目“基于Tomcat与Android的简易在线音乐播放器系统”是一个典型的前后端分离移动应用实践，结合Apache Tomcat、SpringMVC、MyBatis构建后端服务，通过Android客户端实现音乐在线播放功能。系统利用Tomcat作为Java Web服务器处理HTTP请求，SpringMVC实现请求调度与业务逻辑控制，MyBatis完成与MySQL数据库的交互，存储歌曲信息；Android端使用MediaPlayer类实现音频播放，并借助nat123内网穿透技术使本地服务器暴露至公网，实现跨网络访问。该项目涵盖了Web开发、数据库操作、移动端音视频处理及网络通信等核心技术，适合全栈与移动开发学习者进行实战训练。

1. Tomcat服务器搭建与配置

在本地开发环境中部署Apache Tomcat是构建Java Web应用的首要步骤。首先，从官网下载对应版本的Tomcat（建议选择9.x稳定版），解压后配置环境变量 CATALINA_HOME 指向安装目录。Tomcat的核心目录包括： bin （启动脚本）、 conf （配置文件）、 webapps （Web应用部署路径）和 logs （日志输出）。关键配置文件 server.xml 用于修改端口（如将默认8080改为8081）、设置编码及连接器参数； web.xml 则定义全局Servlet行为。启动服务可通过执行 startup.bat （Windows）或 startup.sh （Linux/macOS），随后访问 http://localhost:8081 验证是否显示Tomcat欢迎页。最后，将项目WAR包或 exploded 目录复制到 webapps 下，即可完成初步部署，为集成SpringMVC奠定运行基础。

2. SpringMVC框架集成与请求处理

在现代Java Web开发中，SpringMVC作为Spring生态中最核心的Web层解决方案，凭借其高度模块化、松耦合和注解驱动的设计理念，广泛应用于企业级后端服务构建。尤其在构建RESTful风格API时，SpringMVC提供了从请求映射、参数绑定到视图解析的一整套完整机制，极大提升了开发效率与系统可维护性。本章将深入剖析SpringMVC的核心组件及其工作原理，详细讲解如何将其集成至基于Tomcat运行的音乐播放器项目中，并实现标准化的请求处理流程。

通过本章的学习，开发者不仅能掌握SpringMVC的工作机制，还能理解其与前端控制器模式之间的内在联系，进而设计出结构清晰、扩展性强的后端架构。更重要的是，我们将以实际业务场景为驱动——例如歌曲信息查询、用户行为记录等——逐步搭建起一个支持JSON数据交互的轻量级Web接口体系，为后续与Android客户端进行高效协同奠定坚实基础。

2.1 SpringMVC核心组件与工作原理

SpringMVC 的核心在于它遵循了经典的“前端控制器（Front Controller）”设计模式，所有HTTP请求首先被统一拦截并交由中央调度器处理，从而实现职责分离与流程控制的集中化管理。该框架围绕几个关键组件展开运作： DispatcherServlet 、 HandlerMapping 、 HandlerAdapter 和 ViewResolver ，它们共同构成了一个闭环的请求处理流水线。

2.1.1 DispatcherServlet前端控制器的作用机制

DispatcherServlet 是整个 SpringMVC 框架的入口点，继承自 HttpServlet ，负责接收所有的 HTTP 请求，并协调其他组件完成请求分发、处理器执行以及响应生成。当容器启动时， DispatcherServlet 会初始化 Spring 容器上下文（通常是 WebApplicationContext），加载配置文件或注解定义的 Bean，并准备就绪监听请求。 

sequenceDiagram
    participant Client
    participant DispatcherServlet
    participant HandlerMapping
    participant HandlerAdapter
    participant Controller
    participant ViewResolver
    participant View

    Client->>DispatcherServlet: 发送HTTP请求(GET /songs)
    DispatcherServlet->>HandlerMapping: 查询匹配的处理器
    HandlerMapping-->>DispatcherServlet: 返回Controller方法引用
    DispatcherServlet->>HandlerAdapter: 调用适配器执行处理器
    HandlerAdapter->>Controller: 执行@RequestMapping方法
    Controller-->>HandlerAdapter: 返回ModelAndView或@ResponseBody
    HandlerAdapter-->>DispatcherServlet: 回传结果
    alt 返回视图名
        DispatcherServlet->>ViewResolver: 解析逻辑视图名
        ViewResolver-->>DispatcherServlet: 返回具体视图对象
        DispatcherServlet->>View: 渲染模型数据
        View-->>Client: 输出HTML响应
    else 返回JSON
        DispatcherServlet->>MessageConverter: 序列化对象为JSON
        MessageConverter-->>Client: 直接写出JSON字符串
    end

如上图所示， DispatcherServlet 在请求到达后依次调用各个组件，形成一条完整的处理链路。其内部处理流程如下：

  1. 请求预处理 ：对请求编码、多部分表单（multipart/form-data）进行标准化处理；
  2. 查找处理器（Handler） ：通过 HandlerMapping 根据 URL 查找对应的控制器方法；
  3. 执行处理器 ：使用 HandlerAdapter 调用目标方法，完成业务逻辑；
  4. 结果处理 ：若返回 ModelAndView ，则交由 ViewResolver 进行视图渲染；若带有 @ResponseBody ，则通过 HttpMessageConverter 将对象序列化为 JSON/XML；
  5. 响应输出 ：最终将结果写回客户端。

这一机制保证了不同类型的请求可以灵活地路由到不同的处理器，同时保持整体架构的一致性和可扩展性。

配置方式对比
配置方式 特点 使用场景
XML配置 显式声明bean，适合老项目迁移 传统企业应用
注解驱动 简洁高效，推荐使用 新建Spring Boot或Spring MVC项目
Java Config 类型安全，便于测试 微服务架构

2.1.2 HandlerMapping、HandlerAdapter与ViewResolver职责分析

这三个组件是支撑 DispatcherServlet 实现请求分发与结果处理的关键协作单元，各自承担明确且独立的职责。

HandlerMapping：请求映射决策者

HandlerMapping 接口用于根据请求的URL、HTTP方法、Header等条件决定应由哪个处理器来处理请求。常见的实现类包括：

  • RequestMappingHandlerMapping ：基于 @RequestMapping 注解进行路径匹配；
  • BeanNameUrlHandlerMapping ：将URL映射到Bean名称；
  • SimpleUrlHandlerMapping ：通过配置方式手动指定URL与Controller的映射关系。

例如，在启用注解驱动模式下，Spring 会自动注册 RequestMappingHandlerMapping 来扫描所有带有 @Controller 或 @RestController 的类，并建立URL到方法的映射索引。 

@Configuration
@EnableWebMvc
@***ponentScan(basePackages = "***.musicplayer.controller")
public class WebConfig implements WebMv***onfigurer {

    @Bean
    public HandlerMapping handlerMapping() {
        RequestMappingHandlerMapping mapping = new RequestMappingHandlerMapping();
        mapping.setOrder(0); // 设置优先级
        return mapping;
    }
}

代码逻辑逐行解读 ：

  • 第1行： @Configuration 表示这是一个Java配置类，替代XML；
  • 第2行： @EnableWebMvc 启用SpringMVC默认配置（如消息转换器、校验器等）；
  • 第3行： @***ponentScan 扫描控制器包路径；
  • 第6–10行：显式注册 RequestMappingHandlerMapping 并设置优先级顺序（数值越小优先级越高），确保其最先参与映射判断。

此配置确保Spring能够正确识别带有 @RequestMapping 的控制器方法，并建立起高效的查找机制。

HandlerAdapter：处理器执行桥梁

HandlerAdapter 负责调用具体的处理器方法，屏蔽底层差异。例如，某些处理器可能是实现了 Controller 接口的传统类，而另一些则是基于注解的方法。Spring 提供多种适配器来兼容这些情况：

  • RequestMappingHandlerAdapter ：处理 @RequestMapping 标记的方法；
  • HttpRequestHandlerAdapter ：适配实现了 HttpRequestHandler 接口的对象；
  • SimpleControllerHandlerAdapter ：调用实现了 org.springframework.web.servlet.mvc.Controller 接口的类。

其中， RequestMappingHandlerAdapter 功能最为强大，支持参数解析、数据绑定、类型转换、验证等功能。它依赖于一系列辅助组件，如 ArgumentResolver （参数解析器）、 ReturnValueHandler （返回值处理器）等。 

@Bean
public HandlerAdapter handlerAdapter() {
    RequestMappingHandlerAdapter adapter = new RequestMappingHandlerAdapter();
    adapter.setMessageConverters(customMessageConverters()); // 自定义JSON处理器
    adapter.setWebBindingInitializer(webBindingInitializer());
    return adapter;
}

参数说明 ：

  • setMessageConverters() ：注入自定义的消息转换器（如Jackson、Fastjson），用于处理 @RequestBody 和 @ResponseBody ；
  • setWebBindingInitializer() ：设置全局的数据绑定规则，比如日期格式、字段白名单等。
ViewResolver：视图解析引擎

尽管当前主流趋势是前后端分离（返回JSON而非页面），但在某些场景下仍需服务器端渲染（如Thymeleaf、JSP）。此时 ViewResolver 起到了将逻辑视图名（如 "songList" ）转换为真实视图资源（如 /WEB-INF/views/songList.jsp ）的作用。 

<bean id="viewResolver" 
      class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/" />
    <property name="suffix" value=".jsp" />
</bean>

上述配置表示：当控制器返回 "songList" 时，视图解析器将自动拼接为 /WEB-INF/views/songList.jsp 并进行渲染。

逻辑分析 ：

  • prefix 和 suffix 属性简化了视图路径管理；
  • 若未配置 ViewResolver ，Spring 将无法解析字符串视图名，导致 404 错误；
  • 对于 REST API，通常不启用视图解析，而是直接返回 JSON。

2.1.3 注解驱动开发模式（@Controller、@RequestMapping）详解

SpringMVC 支持基于注解的编程模型，极大降低了配置复杂度，提高了开发效率。最核心的两个注解是 @Controller 和 @RequestMapping 。

@Controller 与 @RestController 
@RestController
public class SongController {

    @Autowired
    private SongService songService;

    @GetMapping("/api/songs")
    public List<Song> getAllSongs() {
        return songService.findAll();
    }
}
  • @Controller ：标记该类为Spring MVC控制器，纳入IoC容器管理；
  • @RestController ：组合注解，相当于 @Controller + @ResponseBody ，表示所有方法默认返回数据而非视图；
  • @GetMapping("/api/songs") ：等价于 @RequestMapping(value = "/api/songs", method = RequestMethod.GET) ，语义更清晰。
参数绑定示例 
@GetMapping("/api/songs/{id}")
public ResponseEntity<Song> getSongById(@PathVariable Long id) {
    Song song = songService.findById(id);
    return song != null ? ResponseEntity.ok(song) : ResponseEntity.notFound().build();
}

代码解释 ：

  • @PathVariable ：提取URI中的变量 {id} 并注入到方法参数；
  • ResponseEntity<T> ：封装状态码、头信息和响应体，提供细粒度控制；
  • 若ID不存在，返回 404 Not Found ，符合REST规范。

此外，SpringMVC 还支持大量便捷注解：

注解 用途
@RequestParam 获取查询参数（如 ?name=abc）
@RequestBody 绑定JSON请求体到Java对象
@RequestHeader 提取HTTP头字段
@CookieValue 获取Cookie值
@SessionAttribute 访问Session属性

这些注解使得开发者无需手动解析 HttpServletRequest ，即可快速获取所需数据，显著提升编码效率。

请求映射高级特性

SpringMVC 支持通配符、Ant风格路径、正则表达式等多种映射策略： 

@RequestMapping("/api/songs/*/detail") // 匹配 /api/songs/123/detail
public String detailWildcard() { ... }

@RequestMapping("/api/songs/{id:\\d+}") // 正则限制id为数字
public String detailRegex(@PathVariable("id") Long id) { ... }

这种灵活性让API设计更具表现力，同时也便于后期维护与版本迭代。

综上所述，SpringMVC 的核心组件形成了一个高内聚、低耦合的请求处理管道，每个环节各司其职又紧密协作。理解这些组件的工作机制，有助于我们在实际开发中做出更合理的架构选择与性能优化决策。

3. MyBatis持久层设计与数据库映射

在现代Java Web开发中，持久层是连接业务逻辑与数据存储的核心桥梁。对于一个音乐播放器系统而言，如何高效、稳定地从MySQL数据库中读取歌曲信息、专辑详情以及用户行为记录，直接决定了应用的整体响应速度和用户体验。本章将深入探讨基于MyBatis框架的持久层设计方法，涵盖其核心工作机制、DAO层构建策略、与Spring框架的整合方式，以及关键性能优化手段。通过本章内容的学习，开发者不仅能够掌握MyBatis的基本用法，还将理解其在复杂查询场景下的动态SQL能力，并能结合Druid连接池实现生产级的数据访问控制。

3.1 MyBatis框架基础与执行流程

MyBatis作为一款优秀的持久化框架，相较于传统的JDBC操作，极大地简化了数据库交互过程，同时保留了SQL语句的灵活性。它通过XML或注解的方式将Java对象与SQL语句进行映射，避免了ORM框架常见的“黑盒”问题，特别适用于需要精细控制SQL执行的项目场景。理解MyBatis的内部执行流程，是合理使用该框架的前提。

3.1.1 SqlSessionFactory与SqlSession的工作机制

在MyBatis中， SqlSessionFactory 是整个框架的入口点，负责创建 SqlSession 实例。 SqlSession 则代表一次数据库会话，可用于执行SQL语句、提交事务或回滚操作。这两个组件构成了MyBatis运行时的基础结构。

SqlSessionFactory 通常由 SqlSessionFactoryBuilder 构建而来，而构建过程中依赖于一个全局配置文件—— mybatis-config.xml 。该文件定义了数据源、事务管理器、类型别名、插件设置等核心参数。一旦 SqlSessionFactory 被初始化，就可以重复使用来生成多个 SqlSession 实例。

下面是一个典型的 mybatis-config.xml 配置示例： 

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
    <typeAliases>
        <package name="***.musicplayer.entity"/>
    </typeAliases>

    <environments default="development">
        <environment id="development">
            <transactionManager type="JDBC"/>
            <dataSource type="POOLED">
                <property name="driver" value="***.mysql.cj.jdbc.Driver"/>
                <property name="url" value="jdbc:mysql://localhost:3306/music_db?useSSL=false&amp;serverTimezone=UTC"/>
                <property name="username" value="root"/>
                <property name="password" value="password"/>
            </dataSource>
        </environment>
    </environments>

    <mappers>
        <mapper resource="mapper/SongMapper.xml"/>
    </mappers>
</configuration>

代码逻辑逐行解读分析：

  • 第2~4行：标准XML声明及DOCTYPE定义，确保文档符合MyBatis 3.0 DTD规范。
  • <typeAliases> 标签用于为实体类设置别名，避免在映射文件中频繁书写完整包路径。例如 <package name="***.musicplayer.entity"/> 表示该包下所有类可直接以类名引用。
  • <environments> 定义不同环境下的数据库连接配置， default="development" 指定默认使用开发环境。
  • <transactionManager type="JDBC"/> 表示采用JDBC事务管理机制，适合与Spring集成时交由容器统一管理。
  • <dataSource type="POOLED"> 使用内置的连接池实现，提升连接复用效率。
  • 最后 <mappers> 注册具体的Mapper XML文件，告知MyBatis哪些SQL映射需要加载。

通过此配置文件，可以构建出 SqlSessionFactory ： 

String resource = "mybatis-config.xml";
InputStream inputStream = Resources.getResourceAsStream(resource);
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);

随后获取 SqlSession 执行操作： 

try (SqlSession session = sqlSessionFactory.openSession()) {
    Song song = session.selectOne("SongMapper.selectSongById", 1);
    System.out.println(song.getTitle());
}

上述代码展示了原始的命名空间+ID调用模式，但在实际开发中更推荐使用Mapper接口代理方式（见下一节），以增强类型安全性。

参数说明与扩展性讨论
参数 作用
typeAliases 减少冗余类名书写，提高配置可读性
transactionManager 控制事务边界，JDBC模式常用于非Spring环境
dataSource 支持UNPOOLED、POOLED、JNDI三种类型，POOLED适用于中小型应用

此外，MyBatis允许通过 Properties 外部化数据库连接信息，进一步提升配置灵活性。

3.1.2 Mapper接口与XML映射文件的关联方式

MyBatis支持两种方式定义SQL映射：纯XML方式和接口+XML组合方式。推荐使用后者，即定义一个Java接口（如 SongMapper ），并在对应的XML文件中编写SQL语句，两者通过命名空间绑定。

假设我们有如下接口： 

public interface SongMapper {
    Song selectSongById(Integer id);
    List<Song> selectAllSongs();
    void insertSong(Song song);
}

对应的 SongMapper.xml 文件应位于 resources/mapper/ 目录下： 

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="***.musicplayer.mapper.SongMapper">

    <select id="selectSongById" resultType="Song">
        SELECT * FROM song WHERE id = #{id}
    </select>

    <select id="selectAllSongs" resultType="Song">
        SELECT * FROM song
    </select>

    <insert id="insertSong" parameterType="Song">
        INSERT INTO song(title, artist_id, album_id, duration, file_path, upload_time)
        VALUES(#{title}, #{artistId}, #{albumId}, #{duration}, #{filePath}, #{uploadTime})
    </insert>

</mapper>

代码逻辑逐行解读分析：

  • namespace 必须与接口全限定名一致，MyBatis据此建立接口与XML的映射关系。
  • <select> 标签中的 id 对应接口方法名， resultType 指定返回结果映射到的Java类（借助typeAlias可省略包名）。
  • #{} 是预编译占位符，防止SQL注入； ${} 则是字符串拼接，存在安全风险，慎用。
  • <insert> 的 parameterType 声明输入参数类型，MyBatis自动通过反射提取属性值填充SQL。

当调用 sqlSession.getMapper(SongMapper.class) 时，MyBatis会返回一个动态代理对象，拦截方法调用并委托给底层SQL执行引擎处理。

映射机制流程图（Mermaid） 
graph TD
    A[Java Application] --> B[调用SongMapper.selectSongById(1)]
    B --> C{MyBatis代理拦截}
    C --> D[查找Mapper XML中对应SQL]
    D --> E[解析SQL并填充参数]
    E --> F[执行PreparedStatement查询]
    F --> G[将ResultSet映射为Song对象]
    G --> H[返回结果给调用方]

该流程体现了MyBatis“接口即契约”的设计理念，既保持了面向对象编程的清晰结构，又不失对底层SQL的完全掌控力。

3.1.3 动态SQL标签（if、where、foreach）使用场景解析

MyBatis的一大优势在于其强大的动态SQL功能，能够在运行时根据条件拼接SQL语句，有效应对复杂的查询需求。常见标签包括 <if> 、 <choose> 、 <when> 、 <otherwise> 、 <where> 、 <set> 和 <foreach> 。

条件查询示例：带筛选的歌曲列表 
<select id="findSongsByCriteria" parameterType="map" resultType="Song">
    SELECT * FROM song
    <where>
        <if test="title != null and title != ''">
            AND title LIKE CONCAT('%', #{title}, '%')
        </if>
        <if test="artistId != null">
            AND artist_id = #{artistId}
        </if>
        <if test="albumId != null">
            AND album_id = #{albumId}
        </if>
        <if test="minDuration != null">
            AND duration >= #{minDuration}
        </if>
    </where>
</select>

逻辑分析：

  • <where> 标签智能处理WHERE子句：若内部无条件成立，则不添加WHERE；若有，则自动去除首个AND/OR。
  • <if test="..."> 实现条件判断，表达式语法基于OGNL（Object-Graph Navigation Language）。
  • #{} 仍用于参数绑定，保证安全性。
批量插入示例：使用 <foreach> 
<insert id="batchInsertSongs" parameterType="list">
    INSERT INTO song(title, artist_id, album_id, duration, file_path) VALUES
    <foreach collection="list" item="song" separator=",">
        (#{song.title}, #{song.artistId}, #{song.albumId}, #{song.duration}, #{song.filePath})
    </foreach>
</insert>

参数说明：

属性 含义
collection 传入参数集合名称，List类型时固定为 list
item 当前遍历元素的别名
separator 每项之间的分隔符，此处为逗号，形成多值插入

此语句可在一次请求中插入多条记录，显著减少网络往返次数，提升批量操作性能。

动态SQL应用场景对比表
场景 推荐标签 优势
单条件过滤 <if> 灵活控制是否加入某条件
多选一逻辑 <choose><when><otherwise> 类似Java switch-case
批量操作 <foreach> 支持IN查询、批量增删改
更新字段选择性赋值 <set> 自动剔除末尾逗号

动态SQL的设计使得MyBatis既能胜任简单CRUD，也能优雅处理复杂报表查询和条件组合搜索，是构建高可用后端服务不可或缺的能力。

3.2 数据访问对象（DAO）层构建

DAO（Data A***ess Object）层是应用程序与数据库之间的隔离层，职责是封装所有数据访问逻辑，使上层服务无需关心具体数据库实现细节。在MyBatis中，DAO通常表现为Mapper接口及其XML映射文件的组合。

3.2.1 定义SongMapper接口及对应XML映射规则

继续以音乐播放器为例，我们需要围绕 Song 实体构建完整的CRUD操作接口。以下是增强版的 SongMapper 接口定义： 

public interface SongMapper {
    @Select("SELECT * FROM song WHERE id = #{id}")
    Song selectById(@Param("id") Integer id);

    List<Song> selectByArtistId(@Param("artistId") Integer artistId);

    int insert(Song song);

    int update(Song song);

    int deleteById(@Param("id") Integer id);

    List<Song> searchSongs(Map<String, Object> params);
}

其中部分方法可通过注解方式直接写SQL，如 @Select ，但复杂语句仍建议放在XML中维护。

对应的XML映射文件补充如下： 

<!-- resources/mapper/SongMapper.xml -->
<update id="update" parameterType="Song">
    UPDATE song SET
        title = #{title},
        artist_id = #{artistId},
        album_id = #{albumId},
        duration = #{duration},
        file_path = #{filePath}
    WHERE id = #{id}
</update>

<delete id="deleteById" parameterType="int">
    DELETE FROM song WHERE id = #{id}
</delete>

代码解释：

  • @Param 注解用于指定参数别名，在多参数传递时尤为必要，否则MyBatis无法识别形参名。
  • <update> 和 <delete> 返回受影响行数，可用于判断操作是否成功。
  • SQL语句尽量避免全字段更新，仅更新必要字段以提升性能并减少锁竞争。

3.2.2 实现歌曲列表查询与条件筛选语句编写

为了支持前端分页展示和模糊搜索功能，需实现分页查询和多维度筛选。这里引入物理分页概念，借助MySQL的 LIMIT 子句实现： 

<select id="findPaginatedSongs" resultType="Song">
    SELECT s.id, s.title, s.duration, a.name as album_name, ar.name as artist_name
    FROM song s
    LEFT JOIN album a ON s.album_id = a.id
    LEFT JOIN artist ar ON s.artist_id = ar.id
    <where>
        <if test="keyword != null and keyword != ''">
            AND (s.title LIKE CONCAT('%', #{keyword}, '%')
                 OR ar.name LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="genreId != null">
            AND ar.genre_id = #{genreId}
        </if>
    </where>
    ORDER BY s.upload_time DESC
    LIMIT #{offset}, #{limit}
</select>

该SQL实现了跨表联合查询，并支持按关键词检索歌名或歌手名，同时可根据流派过滤结果集。

分页参数说明表
参数 类型 说明
offset int 起始位置，计算公式：(pageNum - 1) * pageSize
limit int 每页数量
keyword String 搜索关键字
genreId Integer 可选流派ID

配合PageHelper等分页插件，可进一步简化分页逻辑，但原生LIMIT仍是高性能首选。

3.2.3 结果集resultMap自定义映射避免字段错位问题

当数据库字段名与Java属性名不一致时（如 create_time → createTime ），简单的 resultType 映射将失效。此时需使用 <resultMap> 显式定义映射关系。 

<resultMap id="SongResultMap" type="Song">
    <id property="id" column="id"/>
    <result property="title" column="title"/>
    <result property="duration" column="duration"/>
    <result property="filePath" column="file_path"/>
    <result property="uploadTime" column="upload_time"/>

    <!-- 关联映射 -->
    <association property="artist" javaType="Artist">
        <result property="name" column="artist_name"/>
        <result property="birthDate" column="artist_birth"/>
    </association>
    <association property="album" javaType="Album">
        <result property="name" column="album_name"/>
        <result property="releaseYear" column="album_year"/>
    </association>
</resultMap>

<select id="findDetailedSong" resultMap="SongResultMap">
    SELECT 
        s.id, s.title, s.duration, s.file_path, s.upload_time,
        ar.name AS artist_name, ar.birth_date AS artist_birth,
        a.name AS album_name, a.release_year AS album_year
    FROM song s
    LEFT JOIN artist ar ON s.artist_id = ar.id
    LEFT JOIN album a ON s.album_id = a.id
    WHERE s.id = #{id}
</select>

优势分析：

  • 解决驼峰命名与下划线命名不匹配问题。
  • 支持嵌套对象映射（ <association> ）、集合映射（ <collection> ）。
  • 提升SQL可维护性，便于后期扩展字段。

通过 resultMap ，即使面对高度归一化的数据库设计，也能轻松构建出层次分明的领域模型。

自定义映射流程图（Mermaid） 
graph LR
    A[执行SQL查询] --> B[获取ResultSet]
    B --> C{是否存在resultMap?}
    C -- 是 --> D[按resultMap规则映射字段]
    D --> E[处理association/collection关联]
    E --> F[构造完整Java对象]
    C -- 否 --> G[尝试自动匹配property-column]
    G --> F
    F --> H[返回结果]

该机制保障了数据映射的准确性与可扩展性，是大型项目中不可或缺的最佳实践。

4. MySQL数据库设计与音乐数据存储

在现代Web应用开发中，数据库作为系统的核心组成部分，承担着持久化业务数据、支撑高并发读写访问以及保障数据一致性的关键职责。特别是在构建一个音乐播放器这类以内容展示和用户交互为主的系统时，合理的数据库设计不仅直接影响到后端服务的性能表现，也决定了前端功能实现的灵活性与扩展性。本章将围绕 MySQL数据库的设计与音乐数据存储机制 展开深入探讨，从实体建模、表结构定义、约束设置到数据初始化与安全策略，全面构建一个高效、可维护且具备生产级特征的数据层基础设施。

通过科学的数据模型分析，可以有效识别出系统中的核心业务对象及其相互关系；借助规范化设计原则，能够避免冗余存储并提升查询效率；而结合索引优化、外键约束与权限管理等技术手段，则能进一步增强系统的稳定性与安全性。整个过程不仅仅是“建几张表”的简单操作，而是贯穿需求理解、架构规划和技术落地的综合性工程实践。

4.1 音乐播放器数据模型分析

在进行任何数据库设计之前，首要任务是明确系统所涉及的核心业务实体，并理清它们之间的逻辑关联。对于一个典型的音乐播放器系统而言，其主要功能包括歌曲浏览、专辑查看、歌手信息展示、搜索推荐以及播放记录追踪等。这些功能的背后依赖于一组结构清晰、语义准确的数据模型支持。

4.1.1 核心实体识别：歌曲（Song）、专辑（Album）、歌手（Artist）

音乐播放器中最基本的三个业务实体为： 歌曲（Song） 、 专辑（Album） 和 歌手（Artist） 。这三个实体构成了整个系统的主干数据结构。

  • Song（歌曲） ：表示一首具体的音乐作品，包含如标题、文件路径、时长、上传时间、封面图URL等属性。
  • Album（专辑） ：代表由多个歌曲组成的集合，通常具有统一的主题或发行背景，包含专辑名、发行年份、封面图片等信息。
  • Artist（歌手/乐队） ：指创作或演唱歌曲的个人或团体，拥有姓名、简介、头像链接等元数据。

此外，还可能存在其他辅助实体，例如：
- Genre （音乐类型）
- User （用户账户）
- Playlist （播放列表）
- PlayHistory （播放历史）

但在当前阶段，我们聚焦于最核心的三者关系建模。

为了更直观地表达这些实体间的联系，以下使用 Mermaid 流程图描述其E-R关系： 

erDiagram
    ARTIST ||--o{ ALBUM : "发布"
    ARTIST ||--o{ SONG : "演唱"
    ALBUM ||--o{ SONG : "包含"

    ARTIST {
        int artist_id PK
        varchar name
        text bio
        varchar avatar_url
        datetime created_at
    }
    ALBUM {
        int album_id PK
        varchar title
        int artist_id FK
        year release_year
        varchar cover_url
        datetime created_at
    }

    SONG {
        int song_id PK
        varchar title
        varchar file_path
        time duration
        int album_id FK
        int artist_id FK
        varchar cover_url
        datetime upload_time
        boolean is_deleted
    }

上述E-R图清晰展示了三者之间的多重一对多关系：
- 一位歌手可以发布多张专辑（1:N）
- 一张专辑可以包含多首歌曲（1:N）
- 一首歌可以归属于某位歌手和某个专辑（N:1 → N:1）

这种建模方式既符合现实世界的认知逻辑，也为后续SQL查询提供了良好的结构基础。

4.1.2 E-R图设计与关系建模原则

在完成初步实体识别后，下一步是对整体数据模型进行规范化设计。遵循 第三范式（3NF） 是保证数据库结构合理的重要准则，即：

  1. 每个字段都应原子化（第一范式）
  2. 所有非主键字段完全依赖于主键（第二范式）
  3. 不存在传递依赖（第三范式）

以 Song 表为例，若我们将“歌手姓名”直接存入该表而非仅保留 artist_id ，就会导致数据冗余——当同一歌手有多首歌曲时，其名字会被重复存储。一旦需要修改该歌手名称，就必须更新所有相关记录，极易引发不一致性问题。

因此，采用 外键引用的方式分离实体 ，正是解决此类问题的标准做法。同时，这也便于后期实现灵活的联表查询，例如获取“某专辑下所有歌曲及其对应歌手信息”。

此外，在设计过程中还需注意以下几点建模原则：

原则 说明
单一职责 每张表只负责一类实体的信息存储
主键唯一性 使用自增整数或UUID作为主键确保每行数据可唯一标识
外键完整性 在必要处添加外键约束以维持引用一致性
可扩展性 预留字段或设计中间表以便未来功能拓展（如支持多位歌手合作）

值得一提的是，虽然严格的范式设计有助于减少冗余，但在某些高性能读取场景下，适度反范式化（denormalization）也是可行的。例如，在 Song 表中额外缓存 artist_name 字段，可用于避免频繁JOIN查询带来的性能损耗，但需配合触发器或应用层逻辑来保持数据同步。

4.1.3 字段类型选择与索引策略制定

字段类型的精确选择不仅影响存储空间占用，还直接决定查询效率与数据精度。以下是针对各核心表的关键字段选型建议：

Song 表字段设计说明
字段名 类型 是否为空 默认值 说明
song_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT 主键，唯一标识
title VARCHAR(255) NOT NULL - 歌曲名称，最大长度255字符
file_path TEXT NOT NULL - 存储音频文件服务器路径或CDN地址
duration TIME NOT NULL ‘00:00:00’ 播放时长，格式 HH:MM:SS
album_id BIGINT UNSIGNED NULL - 外键，允许为空（单曲无专辑）
artist_id BIGINT UNSIGNED NOT NULL - 外键，必须指定演唱者
cover_url VARCHAR(512) NULL - 封面图链接，支持较长URL
upload_time DATETIME NOT NULL CURRENT_TIMESTAMP 自动记录上传时间
is_deleted TINYINT(1) NOT NULL 0 软删除标志位

💡 提示：使用 TINYINT(1) 实现布尔型字段是MySQL常见做法，配合JPA/Hibernate可自动映射为Java中的boolean类型。

索引策略设计

索引是加速查询的核心手段，尤其在大数据量环境下至关重要。以下是推荐的索引配置方案：

表名 字段 索引类型 目的
Song title 普通索引 (INDEX) 支持按歌名模糊搜索
Song artist_id 外键索引 加速按歌手过滤
Song album_id 外键索引 提升专辑内歌曲查询速度
Song upload_time B-Tree索引 支持按上传时间排序
Artist name 唯一索引 (UNIQUE INDEX) 防止重名歌手冲突（可根据业务调整）

特别地，对于高频使用的全文检索场景（如“搜索单曲名”），可考虑引入 FULLTEXT索引 并结合 MATCH...AGAINST 查询语法： 

ALTER TABLE song ADD FULLTEXT(title);
-- 使用示例
SELECT * FROM song WHERE MATCH(title) AGAINST('夜曲' IN NATURAL LANGUAGE MODE);

该方式比 LIKE '%xxx%' 性能更高，尤其适用于百万级数据量以上的文本匹配。

4.2 数据库表结构创建与约束设置

完成了数据模型设计之后，接下来进入实际的DDL（Data Definition Language）阶段，即编写SQL语句创建物理表结构，并施加必要的完整性约束以保障数据质量。

4.2.1 创建song表并设定主键、非空、唯一性约束

以下为完整的 song 表创建语句，包含主键、外键、默认值及约束条件： 

CREATE TABLE IF NOT EXISTS song (
    song_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(255) NOT NULL ***MENT '歌曲名称',
    file_path TEXT NOT NULL ***MENT '音频文件路径',
    duration TIME NOT NULL DEFAULT '00:00:00' ***MENT '播放时长',
    album_id BIGINT UNSIGNED NULL ***MENT '所属专辑ID',
    artist_id BIGINT UNSIGNED NOT NULL ***MENT '演唱者ID',
    cover_url VARCHAR(512) NULL ***MENT '封面图URL',
    upload_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ***MENT '上传时间',
    is_deleted TINYINT(1) NOT NULL DEFAULT 0 ***MENT '软删除标记：0=正常, 1=已删',
    -- 添加索引
    INDEX idx_title (title),
    INDEX idx_artist_id (artist_id),
    INDEX idx_album_id (album_id),
    INDEX idx_upload_time (upload_time),

    -- 外键约束（需确保父表存在）
    CONSTRAINT fk_song_artist FOREIGN KEY (artist_id) REFERENCES artist(artist_id) ON DELETE CASCADE ON UPDATE CASCADE,
    CONSTRAINT fk_song_album FOREIGN KEY (album_id) REFERENCES album(album_id) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ***MENT='歌曲信息表';
代码逻辑逐行解析：
  • BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY ：使用无符号大整数作为主键，支持海量数据增长（约184亿条记录上限），并启用自动递增。
  • VARCHAR(255) ：适合短文本字段，超过此长度建议使用 TEXT 。
  • TEXT NOT NULL ：用于存储较长的文件路径或URL，不可为空以防播放失败。
  • DEFAULT '00:00:00' 和 DEFAULT CURRENT_TIMESTAMP ：自动填充默认值，减轻应用层负担。
  • is_deleted TINYINT(1) ：实现软删除机制，便于数据恢复与审计。
  • ON DELETE CASCADE ：当删除某个歌手时，其名下所有歌曲一并删除（级联删除）。
  • ON DELETE SET NULL ：删除专辑时，歌曲仍保留，但 album_id 设为NULL（避免数据丢失）。
  • ENGINE=InnoDB ：选用支持事务、外键和行锁的存储引擎，更适合Web应用场景。
  • CHARSET=utf8mb4 ：完整支持emoji表情和中文字符，避免乱码问题。

⚠️ 注意事项：外键约束要求被引用的父表（如 artist , album ）必须已存在且同样使用 InnoDB 引擎，否则会报错。

4.2.2 文件路径、时长、上传时间等关键字段的设计考量

在 song 表中，以下几个字段对系统运行尤为关键，需重点设计：

1. file_path —— 音频资源定位

该字段存储的是音频文件的实际访问路径。考虑到部署环境差异，建议遵循如下规范：

  • 若使用本地文件服务器：格式为 /uploads/audio/song_123.mp3
  • 若使用云存储（如阿里云OSS、腾讯COS）：存储完整HTTPS URL，如 https://music-cdn.example.***/songs/123.mp3

优势在于：
- 统一接口返回路径格式
- 支持CDN加速与防盗链配置
- 易于迁移至分布式文件系统

2. duration —— 时间格式处理

尽管MySQL提供 TIME 类型，但在实际开发中常遇到前后端时间格式转换问题。Java中常用 java.time.Duration 或秒数（Long）表示，因此有两种处理方式：

  • 方案一：继续使用 TIME ，配合 MyBatis TypeHandler 自动转换
  • 方案二：改为 INT 存储总秒数（如 245 秒），简化计算与传输

推荐使用第二种方案，因其更利于移动端解析与进度条计算。

3. upload_time —— 时间戳语义明确

使用 DATETIME 而非 TIMESTAMP 的原因在于：
- TIMESTAMP 受时区影响，可能造成跨服务器时间偏差
- DATETIME 固定存储具体时间点，更适合日志类字段

若需记录毫秒级精度，可升级为 DATETIME(3) 。

4.2.3 外键关联与级联删除策略的应用

外键不仅是数据一致性的保障，还能通过级联操作自动化处理关联变更。以下是不同级联策略的适用场景对比：

策略 语法 适用场景
CASCADE ON DELETE CASCADE 删除父项时，子项也应随之清除（如用户注销→删除其收藏）
SET NULL ON DELETE SET NULL 子项可独立存在，但失去归属（如专辑下架，歌曲仍可播放）
RESTRICT ON DELETE RESTRICT 禁止删除仍有子项的父项（保护核心数据）
NO ACTION 同RESTRICT 兼容性写法

在本项目中：
- 删除歌手 → 删除其所有歌曲（CASCADE）：体现强依赖
- 删除专辑 → 歌曲保留但脱离专辑（SET NULL）：提高容错性

此举既能防止孤儿数据泛滥，又能避免误删重要资源。

4.3 数据初始化与操作验证

表结构建立完成后，必须插入初始测试数据以验证CRUD操作的正确性，并为前后端联调提供基础支撑。

4.3.1 插入测试数据集用于前后端联调

执行以下SQL批量插入若干歌曲、专辑与歌手数据： 

-- 插入歌手
INSERT INTO artist (name, bio, avatar_url) VALUES 
('周杰伦', '华语流行天王，创作型歌手', 'https://cdn.example.***/images/jay.jpg'),
('邓紫棋', '实力唱将，香港女歌手', 'https://cdn.example.***/images/gem.jpg');

-- 插入专辑
INSERT INTO album (title, artist_id, release_year, cover_url) VALUES 
('七里香', 1, 2004, 'https://cdn.example.***/covers/qilixiang.jpg'),
('摩天动物园', 2, 2019, 'https://cdn.example.***/covers/zoo.jpg');

-- 插入歌曲
INSERT INTO song (title, file_path, duration, album_id, artist_id, cover_url) VALUES 
('七里香', '/audio/jay_qilixiang.mp3', '04:56', 1, 1, 'https://cdn.example.***/covers/qilixiang.jpg'),
('发如雪', '/audio/jay_faruxue.mp3', '04:17', 1, 1, 'https://cdn.example.***/covers/qilixiang.jpg'),
('光年之外', '/audio/gem_guangnian.mp3', '04:38', 2, 2, 'https://cdn.example.***/covers/zoo.jpg');

以上数据覆盖了常见场景：
- 同一歌手多首歌曲
- 同一专辑多首歌曲
- 正确的外键引用关系

4.3.2 使用Navicat或命令行工具执行查询验证逻辑正确性

可通过如下SQL验证数据完整性与查询能力： 

-- 查询所有未删除的歌曲及其歌手、专辑信息
SELECT 
    s.title AS song_title,
    a.name AS artist_name,
    al.title AS album_title,
    s.duration,
    s.upload_time
FROM song s
LEFT JOIN artist a ON s.artist_id = a.artist_id
LEFT JOIN album al ON s.album_id = al.album_id
WHERE s.is_deleted = 0
ORDER BY s.upload_time DESC;

预期输出结果：

song_title artist_name album_title duration upload_time
光年之外 邓紫棋 摩天动物园 04:38 2025-04-05 10:00:00
发如雪 周杰伦 七里香 04:17 2025-04-05 09:59:00
七里香 周杰伦 七里香 04:56 2025-04-05 09:58:00

该查询体现了：
- 多表LEFT JOIN的正确性
- 时间倒序排列
- 软删除过滤机制生效

开发者可在 Navicat、DBeaver 或 MySQL CLI 中运行此语句，确认结果无误后再推进至接口开发阶段。

4.4 数据安全与备份机制

数据库不仅是数据仓库，更是系统的命脉所在。一旦发生误删、入侵或硬件故障，可能导致不可挽回的损失。因此，建立健全的安全防护与灾备体系至关重要。

4.4.1 用户权限分配与远程访问控制

MySQL通过用户账号+主机白名单+权限粒度控制实现访问隔离。建议创建专用应用连接账户，而非使用root。 

-- 创建专用于应用连接的用户
CREATE USER 'music_app'@'192.168.1.%' IDENTIFIED BY 'StrongPass123!';

-- 授予最小必要权限
GRANT SELECT, INSERT, UPDATE, DELETE ON music_db.* TO 'music_app'@'192.168.1.%';

-- 刷新权限
FLUSH PRIVILEGES;

参数说明：
- 'music_app'@'192.168.1.%' ：限定该用户只能从内网IP段登录，阻止公网直接访问
- 权限范围限定在特定数据库 music_db ，禁止跨库操作
- 不授予 DROP , ALTER , FILE 等高危权限，防注入攻击

同时，在操作系统层面关闭MySQL的外部监听（除非必要）： 

# 修改 my.***f
[mysqld]
bind-address = 127.0.0.1  # 仅允许本地连接

4.4.2 定期导出脚本与恢复方案设计

定期备份是应对灾难的最后一道防线。推荐采用“全量+增量”结合的策略。

全量备份脚本（daily_backup.sh） 
#!/bin/bash
BACKUP_DIR="/data/backup/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="music_db"
USER="root"
PASS="your_root_password"

mysqldump -u$USER -p$PASS --single-transaction --routines --triggers $DB_NAME > $BACKUP_DIR/${DB_NAME}_full_$DATE.sql

# 保留最近7天备份
find $BACKUP_DIR -name "*.sql" -mtime +7 -delete
恢复流程 
mysql -u root -p music_db < /data/backup/mysql/music_db_full_20250405.sql

🔐 安全建议：备份文件加密存储，传输过程使用SCP/SFTP，避免明文暴露。

此外，还可结合 binlog 实现增量恢复，定位到某一时刻的状态，极大提升恢复精度。

5. 后端RESTful接口开发与Android客户端协同实现

5.1 RESTful API设计规范与路由规划

在构建现代Web服务时，遵循RESTful架构风格是实现高可用、易维护接口的关键。REST（Representational State Transfer）强调资源的表述性状态转移，使用标准HTTP动词对资源进行操作，并通过URL定位资源。

5.1.1 资源命名、HTTP动词匹配与状态码使用准则

  • 资源命名 ：应使用名词复数形式表示集合，如 /songs 表示所有歌曲资源。
  • HTTP动词语义化 ：
  • GET /songs ：获取歌曲列表
  • GET /songs/{id} ：获取指定ID的歌曲详情
  • POST /songs/search ：条件搜索（因查询复杂，不适用GET）
  • PUT/PATCH /songs/{id} ：更新歌曲信息（本项目暂未开放编辑）
  • 状态码规范 ：
  • 200 OK ：成功响应
  • 400 Bad Request ：参数错误
  • 404 Not Found ：资源不存在
  • 500 Internal Server Error ：服务器异常
HTTP方法 接口路径 功能说明
GET /api/songs 分页获取歌曲列表
GET /api/songs/{id} 获取单首歌曲详细信息
POST /api/songs/search 按歌名或歌手模糊搜索
GET /api/songs/latest 获取最新上传的5首歌曲

5.2 接口编码实现与JSON数据封装

5.2.1 构建统一响应体Result 结构支持前端解析

为提升前后端协作效率，定义通用响应格式： 

public class Result<T> {
    private int code;
    private String message;
    private T data;

    public static <T> Result<T> su***ess(T data) {
        Result<T> result = new Result<>();
        result.code = 200;
        result.message = "su***ess";
        result.data = data;
        return result;
    }

    public static Result<Void> error(int code, String msg) {
        Result<Void> result = new Result<>();
        result.code = code;
        result.message = msg;
        return result;
    }
}

5.2.2 Controller层调用Service→DAO完成完整链路调用

示例控制器代码： 

@RestController
@RequestMapping("/api/songs")
public class SongController {

    @Autowired
    private SongService songService;

    @GetMapping
    public Result<List<Song>> getAllSongs() {
        List<Song> songs = songService.findAll();
        return Result.su***ess(songs);
    }

    @GetMapping("/{id}")
    public Result<Song> getSongById(@PathVariable Long id) {
        Song song = songService.findById(id);
        if (song == null) {
            return Result.error(404, "歌曲不存在");
        }
        return Result.su***ess(song);
    }
}

Song 实体字段包含：

字段名 类型 描述
id Long 主键
title String 歌曲名称
artist String 歌手
album String 专辑
duration Integer 时长（秒）
coverUrl String 封面图片URL
audioUrl String 音频文件网络地址
uploadTime Date 上传时间

5.2.3 返回包含封面URL、歌名、歌手、播放链接的JSON格式

请求 GET /api/songs 示例响应： 

{
  "code": 200,
  "message": "su***ess",
  "data": [
    {
      "id": 1,
      "title": "晴天",
      "artist": "周杰伦",
      "album": "叶惠美",
      "duration": 248,
      "coverUrl": "http://localhost:8080/images/ye.jpg",
      "audioUrl": "http://localhost:8080/audio/qingtian.mp3",
      "uploadTime": "2025-04-05T10:00:00"
    },
    {
      "id": 2,
      "title": "七里香",
      "artist": "周杰伦",
      "album": "七里香",
      "duration": 267,
      "coverUrl": "http://localhost:8080/images/qilixiang.jpg",
      "audioUrl": "http://localhost:8080/audio/qilixiang.mp3",
      "uploadTime": "2025-04-04T15:30:00"
    }
  ]
}

该结构可直接被Android端Gson库反序列化为Java对象。

流程图展示请求处理链路： 

sequenceDiagram
    participant A as Android App
    participant S as SpringMVC Controller
    participant SV as SongService
    participant DM as SongMapper
    participant DB as MySQL Database

    A->>S: GET /api/songs
    S->>SV: songService.findAll()
    SV->>DM: songMapper.selectAll()
    DM->>DB: SELECT * FROM song
    DB-->>DM: 返回结果集
    DM-->>SV: List<Song>
    SV-->>S: 数据返回
    S-->>A: JSON响应（Result<List<Song>>）

每个环节均通过依赖注入解耦，便于单元测试和扩展。

此外，在MyBatis映射文件中配置动态SQL以支持多条件筛选： 

<select id="selectByCondition" parameterType="map" resultMap="songResultMap">
    SELECT * FROM song
    <where>
        <if test="title != null and title != ''">
            AND title LIKE CONCAT('%', #{title}, '%')
        </if>
        <if test="artist != null and artist != ''">
            AND artist LIKE CONCAT('%', #{artist}, '%')
        </if>
    </where>
    ORDER BY upload_time DESC
</select>

此设计允许Android端传递搜索关键词灵活查询。

接下来将在Android端接收并渲染这些数据。

本文还有配套的精品资源，点击获取

简介：本项目“基于Tomcat与Android的简易在线音乐播放器系统”是一个典型的前后端分离移动应用实践，结合Apache Tomcat、SpringMVC、MyBatis构建后端服务，通过Android客户端实现音乐在线播放功能。系统利用Tomcat作为Java Web服务器处理HTTP请求，SpringMVC实现请求调度与业务逻辑控制，MyBatis完成与MySQL数据库的交互，存储歌曲信息；Android端使用MediaPlayer类实现音频播放，并借助nat123内网穿透技术使本地服务器暴露至公网，实现跨网络访问。该项目涵盖了Web开发、数据库操作、移动端音视频处理及网络通信等核心技术，适合全栈与移动开发学习者进行实战训练。


本文还有配套的精品资源，点击获取

转载请说明出处内容投诉
CSS教程网 » 基于Tomcat与Android的简易在线音乐播放器系统
金大虾

金大虾

分享到：

发表评论

欢迎 访客 发表评论

一个令你着迷的主题！

查看演示 官网购买