基于 Python 的安卓应用市场数据可视化分析推荐系统技术实现文档
1. 文档说明
本文档面向课程设计、项目答辩、系统维护与二次开发场景,系统性说明本项目的技术架构、核心模块、数据库设计、业务流程、算法实现、可视化设计与部署方式。
项目名称:
基于Python的安卓应用市场数据可视化分析推荐系统
项目技术栈:
- 后端:
FastAPI - 前端:
Jinja2 + Bootstrap 5 + 原生 JavaScript - 可视化:
ECharts 5 + echarts-wordcloud - 数据库:
MySQL + SQLAlchemy ORM - 数据处理:
openpyxl + jieba + numpy
项目代码目录:
code/
默认数据库配置:
- 数据库名:
design_302_app - 主机:
localhost - 端口:
3306 - 用户名:
root - 密码:
123456
默认账号:
- 管理员:
admin / 123456 - 普通用户:
analyst / 123456
2. 项目目标
本系统以某安卓应用市场 Excel 数据集为基础,构建一个集"数据导入、数据管理、深度分析、可视化展示、智能推荐、权限控制"于一体的综合性应用市场分析平台。
系统主要解决以下问题:
- 将离散的 Excel 应用市场数据自动导入数据库,形成可查询、可维护的数据底座。
- 对应用市场数据进行多维建模,提炼分类规模、评分质量、热度结构、更新时间、文本主题等关键特征。
- 构建专题化图表分析页面,以结构图谱、质量热度、时序演化、文本关系四大主题组织图表。
- 基于评分、安装量、评论量、关键词匹配、收藏偏好和历史行为生成推荐结果。
- 提供管理员与普通用户两类权限,并支持账号维护、应用数据维护和数据刷新。

































3. 系统总体架构
3.1 分层架构
本项目采用典型的分层式 Web 架构:
text
表示层
├─ Jinja2 模板页面
├─ Bootstrap UI 样式
├─ dashboard.js 页面交互与图表渲染
└─ ECharts 可视化引擎
业务层
├─ main.py 路由与控制器
├─ analysis_service.py 分析与推荐服务
├─ user_service.py 收藏/推荐历史/个性化中心
├─ data_loader.py Excel 导入与数据刷新
└─ logo_service.py Logo 抓取与本地存储
数据层
├─ SQLAlchemy ORM 模型
├─ MySQL 数据库
└─ Excel 原始数据文件
3.2 运行架构
系统启动时通过 FastAPI 的 lifespan 生命周期完成初始化:
- 初始化数据库并自动建库建表。
- 自动执行数据导入引导。
- 自动创建默认管理员与普通用户账号。
- 预热分析缓存,减少首次访问延迟。
- 启动后台 Logo 补全线程。
这一设计使系统具备"首次启动即可运行"的课程设计特性。
4. 目录结构设计
项目核心目录如下:
text
code/
├─ main.py # FastAPI 入口、路由、权限与页面控制
├─ requirements.txt # Python 依赖
├─ README.md # 项目说明
├─ 系统技术实现文档.md # 当前技术文档
├─ app/
│ ├─ config.py # 系统配置
│ ├─ database.py # 数据库引擎、会话与迁移
│ ├─ models.py # ORM 数据模型
│ ├─ security.py # 密码哈希、登录态处理
│ ├─ stopwords.txt # 分词停用词表
│ └─ services/
│ ├─ analysis_service.py # 深度分析与推荐算法
│ ├─ data_loader.py # Excel 解析、导入、数据刷新
│ ├─ logo_service.py # Logo 抓取与保存
│ └─ user_service.py # 收藏、推荐历史、个性化中心
├─ templates/ # 页面模板
├─ static/
│ ├─ css/styles.css # 全局样式
│ ├─ js/dashboard.js # 前端交互与图表渲染逻辑
│ ├─ vendor/ # 本地 ECharts 资源
│ └─ uploads/logos/ # 本地 Logo 资源目录
├─ scripts/
│ └─ fetch_app_logos.py # 批量抓取 Logo 脚本
└─ logs/ # Logo 抓取日志
5. 技术栈选型说明
5.1 后端:FastAPI
选用 FastAPI 的原因:
- 路由定义清晰,适合中小型课程设计项目快速开发。
- 与类型注解结合良好,代码可读性高。
- 内置依赖注入机制,便于数据库会话、请求参数与权限控制的组织。
- 运行性能较高,便于同时支持页面与 JSON 接口。
5.2 ORM:SQLAlchemy 2.0
选用 SQLAlchemy 的原因:
- 可同时满足结构化建模和复杂查询需求。
- 与 MySQL 适配稳定。
- 模型、索引、外键与唯一约束可直接以 Python 类方式表达。
5.3 前端:Bootstrap + Jinja2 + 原生 JS
本系统不采用前后端分离方案,而采用服务端渲染 + 局部异步加载模式:
- 页面框架、布局和权限壳层由 Jinja2 渲染。
- 页面数据通过异步接口按页面拉取。
- 图表由 ECharts 在浏览器端渲染。
这样能够兼顾:
- 开发复杂度低
- 页面结构清晰
- 课程设计展示直观
- 对 Python 环境依赖友好
5.4 可视化:ECharts
ECharts 用于绘制:
- 柱状图
- 折线图
- 散点图
- 热力图
- 雷达图
- 旭日图
- 桑基图
- 矩形树图
- 漏斗图
- 箱线图
- 南丁格尔玫瑰图
- 词云图
当前系统共输出 32 张图表,按专题页面集中展示。
6. 配置设计
系统配置集中在 app/config.py 中,采用 dataclass 管理。
6.1 核心配置项
| 配置项 | 说明 | 默认值 |
|---|---|---|
app_name |
系统名称 | 基于Python的安卓应用市场数据可视化分析推荐系统 |
secret_key |
Session 签名密钥 | design-302-app-secret-key |
mysql_host |
MySQL 主机 | localhost |
mysql_port |
MySQL 端口 | 3306 |
mysql_user |
MySQL 用户 | root |
mysql_password |
MySQL 密码 | 123456 |
mysql_database |
数据库名 | design_302_app |
admin_username |
默认管理员账号 | admin |
admin_password |
默认管理员密码 | 123456 |
analyst_username |
默认普通用户账号 | analyst |
analyst_password |
默认普通用户密码 | 123456 |
default_password |
系统默认重置密码 | 123456 |
data_file |
Excel 数据文件路径 | 根目录 某应用市场数据.xlsx |
stopwords_file |
停用词文件路径 | code/app/stopwords.txt |
6.2 配置特点
- 支持通过环境变量覆盖默认值。
- 数据文件路径同时兼容根目录与代码目录启动方式。
- 账号密码、数据库名等可直接用于课程答辩展示。
7. 数据库设计
7.1 数据库初始化策略
app/database.py 中实现了以下数据库初始化机制:
- 使用
pymysql在应用启动阶段确保数据库存在。 - 使用
Base.metadata.create_all自动创建数据表。 - 使用
run_schema_migrations()执行轻量迁移:- 若
install_count不是BIGINT,自动修正。 - 若
app_records.logo_path不存在,自动追加。
- 若
这保证了系统在演化过程中无需手工维护复杂迁移脚本,也能兼容旧表结构。
7.2 数据表总览
当前系统包含 4 张核心业务表:
usersapp_recordsuser_favoritesrecommendation_history
7.3 users 用户表
表名:users
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
id |
Integer |
主键、自增 | 用户主键 |
username |
String(64) |
唯一、索引、非空 | 登录用户名 |
display_name |
String(128) |
非空 | 显示名称 |
password_hash |
String(255) |
非空 | 密码哈希 |
role |
String(20) |
索引、非空 | 角色:admin / user |
is_active |
Boolean |
非空 | 是否启用 |
created_at |
DateTime |
非空 | 创建时间 |
last_login_at |
DateTime |
可空 | 最近登录时间 |
设计说明:
- 密码不以明文存储,仅保存哈希值。
role用于进行页面权限与后台操作权限控制。is_active用于控制账户禁用状态。
7.4 app_records 应用数据表
表名:app_records
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
id |
Integer |
主键、自增 | 应用主键 |
category |
String(64) |
索引、非空 | 一级分类 |
subcategory |
String(128) |
索引、非空 | 二级分类 |
app_name |
String(255) |
索引、非空 | 应用名称 |
logo_path |
String(255) |
可空 | 本地 Logo 相对路径 |
install_raw |
String(64) |
非空 | 原始安装量文本 |
install_count |
BigInteger |
索引、非空 | 标准化安装量数值 |
install_level |
String(32) |
索引、非空 | 安装量等级 |
rating |
Float |
索引、非空 | 评论评分 |
review_count |
Integer |
非空 | 评论人数 |
developer |
String(255) |
索引、非空 | 开发者 |
update_date |
Date |
索引、可空 | 更新时间 |
update_month |
String(7) |
索引、可空 | 更新时间年月 |
description |
Text |
非空 | 应用简介 |
description_length |
Integer |
非空 | 简介长度 |
created_at |
DateTime |
非空 | 记录创建时间 |
附加索引:
- 复合索引:
ix_app_category_subcategory - 复合索引:
ix_app_rating_installs
设计说明:
install_raw保留原始字符串,适合溯源。install_count为数值型,便于排序和分析。install_level为派生特征,便于分层统计。update_month为时间序列分析准备。description_length便于文本密度对比图表绘制。logo_path存储相对路径,前端通过/static/资源路径展示。
7.5 user_favorites 收藏表
表名:user_favorites
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
id |
Integer |
主键、自增 | 记录主键 |
user_id |
Integer |
外键、索引 | 用户 ID |
app_record_id |
Integer |
外键、索引 | 应用 ID |
created_at |
DateTime |
非空 | 收藏时间 |
约束与索引:
- 唯一约束:
uq_user_favorite_app - 索引:
ix_user_favorite_user_created
设计说明:
- 同一用户不能重复收藏同一应用。
- 收藏记录既用于展示,也作为个性化推荐的重要输入。
7.6 recommendation_history 推荐历史表
表名:recommendation_history
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
id |
Integer |
主键、自增 | 记录主键 |
user_id |
Integer |
外键、索引 | 用户 ID |
keyword |
String(255) |
非空 | 搜索关键词 |
category |
String(64) |
非空 | 推荐分类 |
min_rating |
Float |
非空 | 最低评分过滤条件 |
limit_count |
Integer |
非空 | 推荐数量 |
recent_only |
Boolean |
非空 | 是否仅看近期更新 |
result_count |
Integer |
非空 | 实际返回结果数 |
created_at |
DateTime |
非空 | 记录创建时间 |
索引:
ix_recommendation_history_user_created
设计说明:
- 推荐历史支持用户复用检索条件。
- 同时为个性化推荐模块提供历史行为信号。
8. 数据导入与预处理设计
8.1 Excel 数据源
系统默认读取根目录下的:
某应用市场数据.xlsx
程序解析的原始列包括:
分类子分类应用名称安装次数评论分数评论人数开发者更新时间应用介绍
8.2 数据导入流程
app/services/data_loader.py 实现了完整导入链路:
- 使用
openpyxl以只读方式打开 Excel。 - 读取首行表头并建立列名索引。
- 按行迭代生成
AppRecord对象。 - 每 500 条执行一次批量写入。
- 导入完成后提交事务。
8.3 数据预处理规则
1. 安装量标准化
通过 parse_install_count() 将安装量文本转为整数:
- 支持"万""亿"单位换算。
- 支持去除"安装""次安装"等尾缀。
- 支持处理
<、~、约等符号。
2. 安装量等级划分
通过 classify_install_level() 将安装量映射到:
1万以下1万-10万10万-100万100万-1000万1000万-1亿1亿以上
3. 评分处理
通过 parse_rating() 将评分截断到 [0, 5] 区间。
4. 评论人数处理
通过 parse_review_count() 统一为非负整数。
5. 更新时间处理
通过 parse_update_date() 兼容:
YYYY/MM/DDYYYY-MM-DDYYYY/MM/DD HH:MM:SS
6. 派生字段生成
导入时自动生成:
install_countinstall_levelupdate_monthdescription_length
9. 账号与权限控制设计
9.1 密码安全
密码安全逻辑位于 app/security.py:
- 使用
passlib的pbkdf2_sha256进行哈希。 - 登录时通过
verify_password()比对哈希。 - 注册、重置密码、修改密码时统一使用
hash_password()。
9.2 会话机制
系统通过 SessionMiddleware 实现登录态:
- Cookie 名:
design302_session - Session 中保存用户简要信息:
idusernameroledisplay_name
9.3 权限分级
系统分为两类角色:
管理员 admin
可访问:
- 管理总台
- 应用数据管理
- 用户创建与启停
- 密码重置
- 数据刷新
- 应用新增、编辑、删除
- Logo 维护与自动补全
普通用户 user
可访问:
- 综合总览
- 收藏中心
- 智能推荐
- 图表分析
- 账号安全
- 收藏与推荐历史
9.4 默认账号策略
系统启动时通过 seed_default_users() 自动创建或修正:
admin / 123456analyst / 123456
如果账号已存在,则会自动更新显示名、角色和密码哈希,确保默认账户可用。
10. 后端模块设计
10.1 main.py:路由与控制器中心
main.py 承担以下职责:
- 应用启动与生命周期管理
- 路由注册
- 登录鉴权
- 页面渲染
- JSON 接口输出
- 管理员后台操作
- Logo 后台补全调度
10.2 analysis_service.py:分析与推荐核心
该模块是全系统的分析引擎,负责:
- 构建总览指标
- 生成高价值应用榜单
- 生成 32 张图表配置
- 输出推荐结果
- 维护分析缓存
10.3 user_service.py:用户中心服务
负责:
- 收藏切换
- 推荐历史写入
- 用户收藏中心聚合
- 个性化推荐结果构建
10.4 data_loader.py:数据导入与刷新
负责:
- Excel 文件解析
- 批量导入应用记录
- 默认用户初始化
- 全量数据重载
10.5 logo_service.py:Logo 抓取与存储
负责:
- 本地 Logo 目录初始化
- 图片下载
- 文件后缀识别
- 豌豆荚 / Google Play Logo 发现
- 相对路径写回数据库
11. 页面模块设计
11.1 登录与注册模块
页面:
login.htmlregister.htmlforgot_password.html
功能:
- 用户登录
- 普通用户自助注册
- 忘记密码重置为默认密码
11.2 综合总览模块
页面:
overview.html
功能:
- 全局指标总览
- 高价值应用 Top 10 榜单
- 关键洞察
- 精选图表展示
11.3 收藏中心模块
页面:
favorites.html
功能:
- 我的收藏
- 收藏偏好分类
- 个性化推荐
- 推荐历史复用
11.4 智能推荐模块
页面:
recommendations.html
功能:
- 条件筛选
- 推荐结果展示
- Top 10 榜单对照
- 推荐历史记录
11.5 图表分析模块
页面:
analytics.html
功能:
- 按专题分组展示全部图表
- 专题切换
- 图表延迟渲染与重绘
11.6 管理总台模块
页面:
admin_users.html
功能:
- 用户创建
- 用户状态切换
- 单个重置密码
- 全量重置密码
- 数据刷新
11.7 应用数据管理模块
页面:
admin_apps.html
功能:
- 后端分页应用列表
- 每页 9 条数据
- 三行三列卡片布局
- 新增应用
- 编辑应用
- 删除应用
- Logo 展示与维护
- 自定义弹窗表单
12. 路由与接口设计
12.1 页面路由
| 路径 | 方法 | 说明 |
|---|---|---|
/ |
GET | 首页重定向 |
/login |
GET | 登录页 |
/register |
GET | 注册页 |
/forgot-password |
GET | 忘记密码页 |
/dashboard |
GET | 综合总览页 |
/favorites |
GET | 收藏中心页 |
/recommendations |
GET | 智能推荐页 |
/analytics |
GET | 图表分析页 |
/account/security |
GET | 安全中心页 |
/admin/users |
GET | 管理总台 |
/admin/apps |
GET | 应用数据管理 |
12.2 认证与账号接口
| 路径 | 方法 | 说明 |
|---|---|---|
/login |
POST | 登录 |
/logout |
GET | 退出登录 |
/register |
POST | 注册 |
/forgot-password |
POST | 密码重置为默认密码 |
/account/password |
POST | 当前登录用户修改密码 |
12.3 数据接口
| 路径 | 方法 | 说明 |
|---|---|---|
/api/dashboard-data |
GET | 全量仪表盘数据 |
/api/overview-data |
GET | 综合总览页面数据 |
/api/recommendation-page-data |
GET | 智能推荐页基础数据 |
/api/analytics-data |
GET | 图表分析页数据 |
/api/user-hub |
GET | 用户中心聚合数据 |
/api/recommendations |
GET | 条件推荐接口 |
/api/favorites/{app_id} |
POST | 收藏切换 |
/health |
GET | 健康检查 |
12.4 管理员接口
| 路径 | 方法 | 说明 |
|---|---|---|
/admin/users |
POST | 创建用户 |
/admin/users/{user_id}/toggle |
POST | 启用/停用用户 |
/admin/users/{user_id}/reset-password |
POST | 单个重置密码 |
/admin/users/reset-all-passwords |
POST | 全量重置密码 |
/admin/apps |
POST | 新增应用 |
/admin/apps/{app_id}/edit |
POST | 编辑应用 |
/admin/apps/{app_id}/delete |
POST | 删除应用 |
/admin/apps/{app_id}/logo-url |
POST | 通过图片 URL 保存 Logo |
/admin/apps/{app_id}/logo-auto |
POST | 自动抓取单个应用 Logo |
/admin/apps/{app_id}/clear-logo |
POST | 清空 Logo |
/admin/apps/logo-batch |
POST | 批量抓取缺失 Logo 的预留接口 |
/admin/refresh-data |
POST | 重新导入 Excel 数据 |
13. 启动流程设计
系统启动过程如下:
init_db()ensure_database_exists()Base.metadata.create_all()run_schema_migrations()bootstrap_database()AnalysisService().warm_cache(db)schedule_logo_backfill(app)
13.1 warm_cache 预热机制
分析引擎在启动阶段预先计算总览、榜单、洞察与图表,避免首次打开页面时实时计算全部图表数据,提升首屏体验。
13.2 Logo 后台补全线程
系统启动后会持续以守护线程方式执行 Logo 补全:
- 每轮抓取少量缺失 Logo。
- 有成功抓取时短暂休眠。
- 无成功抓取时延长休眠。
- 避免一次性抓取过多导致前台阻塞。
14. 高价值应用榜单实现
高价值应用 Top 10 榜单由 _build_top_apps() 生成。
14.1 评分公式
对每个应用计算综合得分:
text
score = rating_ratio * 0.45
+ install_ratio * 0.35
+ review_ratio * 0.20
其中:
rating_ratio = rating / 5install_ratio = log1p(install_count) / log1p(max_install)review_ratio = log1p(review_count) / log1p(max_reviews)
14.2 排序依据
按以下优先级排序:
- 综合得分
- 安装量
- 评论量
最终取前 10 条,作为榜单展示对象。
15. 推荐系统设计
15.1 条件推荐逻辑
普通推荐由 recommend_apps() 完成,支持以下筛选条件:
- 关键词
- 一级分类
- 最低评分
- 推荐数量
- 是否仅看近 180 天更新
- 自动排除已收藏应用
15.2 推荐评分模型
推荐得分公式:
text
score = rating_ratio * 45
+ install_ratio * 30
+ review_ratio * 20
+ keyword_score * 5
其中:
keyword_score根据关键词在应用名称、分类、子类和简介中的命中比例计算。recent_only=True时,会基于最近更新时间筛选近 180 天记录。
15.3 推荐理由生成
系统会为推荐结果补充说明标签,例如:
- 高评分
- 高安装量
- 评论活跃
- 关键词匹配
- 更新较新
15.4 推荐历史
当推荐接口传入 track=true 时,会将推荐条件写入 recommendation_history,用于:
- 前端历史列表展示
- 快速复用查询条件
- 个性化推荐信号增强
16. 个性化推荐设计
个性化推荐由 build_personalized_recommendations() 实现,输入包括:
- 用户收藏应用
- 收藏分类偏好
- 历史推荐关键词
- 历史推荐分类
16.1 个性化打分思路
基础分:
text
base = rating_ratio * 46
+ install_ratio * 24
+ review_ratio * 15
增益项:
- 分类偏好命中加分
- 子类偏好命中加分
- 历史关键词相关加分
- 近期更新加分
并自动排除用户已收藏应用。
16.2 输出结果
个性化推荐输出到"收藏中心"的:
- 猜你喜欢
- 偏好标签
- 推荐历史联动区域
17. 深度分析引擎设计
分析引擎的核心思想是:先从原始应用数据中抽取统计特征,再统一封装为 ECharts 配置对象,交给前端直接渲染。
17.1 基础统计特征
分析过程中计算的关键统计对象包括:
- 一级分类频次
- 二级分类频次
- 开发者频次
- 开发者-分类联合频次
- 安装等级频次
- 更新时间月频次
- 更新时间年频次
- 更新时间星期频次
- 月均评分
- 月均评论数
- 分类-月份热力矩阵
- 分类内部评分、评论、安装量、简介长度统计
- 文本分词词频
- 分类主题词频
17.2 派生洞察
系统自动生成的洞察包括:
- 样本总量
- 一级分类数
- 二级分类数
- 开发者数
- 平均评分
- 高分应用数
- 亿级安装应用数
- 最大分类
- 最大开发者
- 更新时间范围
18. 图表体系设计
当前系统共生成 32 张图表,分为 4 个专题。
18.1 结构图谱专题
categoryBar:一级分类分布柱状图subcategoryBar:二级分类分布横向柱状图installTierBar:安装量分层柱状图categoryTreemap:分类矩形树图categoryRosePie:分类占比玫瑰图categorySunburst:分类旭日图developerTreemap:开发者供给矩形树图developerCategoryHeatmap:开发者-分类热度矩阵
18.2 质量热度专题
scoreHistogram:评分分布直方图categoryQualityBar:分类平均评分柱状图topInstallAppsBar:安装量最高应用榜reviewScatter:安装量-评分-评论热度散点图scoreBoxplot:评分箱线图installFunnel:安装量漏斗图developerBar:开发者集中度柱状图ratingBandStack:分类评分分层堆叠图installStackByCategory:分类安装层级堆叠图categoryInstallHeatmap:分类安装热度矩阵descriptionLengthBar:分类简介长度对比reviewTierDonut:评论量级环图
18.3 时序演化专题
updateTimeline:月度更新时间序列monthlyQualityTrend:月均评分与评论趋势双折线图updateRecencyBar:更新时效分布柱状图updateYearBar:更新年份分布柱状图updateWeekdayBar:更新星期分布柱状图categoryHeatmap:分类更新热力图
18.4 文本关系专题
wordFrequencyBar:高频词统计柱状图wordCloud:词云图wordThemeDonut:主题词占比环图radarCategory:分类综合能力雷达图categorySankey:分类-子类-安装级别桑基图keywordCategoryHeatmap:主题词-分类热力矩阵
19. 词云与文本分析实现
19.1 分词流程
系统使用 jieba 对以下文本进行分词:
- 应用名称
- 子分类
- 应用简介前 180 个字符
停用词来自:
app/stopwords.txt
19.2 文本清洗策略
分词时会剔除:
- 长度小于 2 的词
- 停用词
- 纯符号
- 纯数字
19.3 词云图实现
词云图基于 ECharts 5 + echarts-wordcloud 2.1.0 实现,前端使用本地静态资源渲染,避免外部 CDN 依赖导致图表异常。
词云数据来源:
description_tokens.most_common(80)
20. Logo 采集与本地存储设计
20.1 设计目标
为提升 UI 完整度,系统支持自动补全应用 Logo:
- 若数据库中已有
logo_path,前端直接显示图片。 - 若无
logo_path,前端显示默认占位头像。 - 后台线程持续尝试补全缺失 Logo。
20.2 抓取策略
自动抓取优先级:
- 豌豆荚搜索页
- Google Play 搜索页
20.3 存储策略
Logo 文件保存到:
code/static/uploads/logos/
数据库保存相对路径,例如:
uploads/logos/app_123.png
20.4 触发方式
- 系统启动后自动慢速补全
- 新增应用后若无 Logo,则单独触发后台抓取
- 编辑后若仍无 Logo,可再次进入补全流程
21. 前端实现设计
21.1 模板层
系统使用 base.html 提供统一壳层:
- 左侧导航栏
- 顶部信息栏
- 页面内容区域
- 静态资源引用
其余页面通过模板继承复用公共布局。
21.2 样式层
所有视觉样式集中在:
static/css/styles.css
样式特性包括:
- 侧边栏后台布局
- Dashboard 卡片风格
- 图表卡片风格
- 登录/注册双栏风格
- 管理后台卡片与弹窗风格
- 响应式栅格布局
21.3 交互层
前端交互集中在:
static/js/dashboard.js
主要功能:
- 页面按需加载数据
- 图表渲染与重绘
- sessionStorage 缓存
- 收藏切换
- 推荐条件提交
- 历史记录复用
- 管理后台自定义弹窗
- 图表专题切换
21.4 管理后台弹窗
应用新增与编辑采用自定义弹窗而非原生 Bootstrap 数据属性弹窗,目的是:
- 避免复杂后台壳层中的层级遮挡问题
- 支持更稳的显示/关闭控制
- 提升后台编辑体验
22. 性能优化设计
22.1 分页面接口拆分
系统没有强制所有页面都请求完整数据,而是拆分为:
- 总览页基础数据
- 推荐页基础数据
- 图表页完整图表数据
- 用户中心聚合数据
这样可避免首屏一次性传输全部内容。
22.2 后端分析缓存
AnalysisService 内部维护:
_cache_signature
当数据量和最大 ID 未变化时,直接复用已有分析结果。
22.3 启动预热
系统启动后先执行 warm_cache(),把复杂分析提前完成。
22.4 前端会话缓存
dashboard.js 使用 sessionStorage 缓存页面数据:
- 缓存版本:
page-cache-v12 - 缓存时长:
5 分钟
22.5 图表多次重绘
图表页面在首次渲染后还会:
requestAnimationFrame再渲染一次- 延迟 180ms 再渲染一次
- 延迟 520ms 再渲染一次
这样可以解决容器初始尺寸尚未稳定时的图表不显示或尺寸错误问题。
23. 后台分页设计
应用数据管理页面采用后端分页,而非前端分页。
核心参数:
ADMIN_APP_PAGE_SIZE = 9
表现形式:
- 每页 9 条记录
- 三行三列卡片布局
后端分页的优势:
- 减少单页数据量
- 降低模板渲染压力
- 提升后台页面可控性
- 支持未来扩展更大规模数据集
24. 业务流程说明
24.1 系统首次启动流程
text
启动应用
-> 创建数据库
-> 创建表
-> 自动迁移字段
-> 创建默认账号
-> Excel 数据导入
-> 构建分析缓存
-> 启动 Logo 后台补全线程
-> 提供页面与 API 服务
24.2 用户登录流程
text
用户输入用户名和密码
-> authenticate_user()
-> 校验账户是否存在且启用
-> 校验密码哈希
-> 写入 session
-> 更新 last_login_at
-> 跳转到综合总览页
24.3 推荐流程
text
用户提交筛选条件
-> /api/recommendations
-> 读取收藏记录并排除已收藏应用
-> 调用 recommend_apps()
-> 返回推荐结果
-> 若 track=true,则写入 recommendation_history
24.4 收藏流程
text
用户点击收藏按钮
-> /api/favorites/{app_id}
-> user_favorites 插入或删除
-> 更新收藏数
-> 前端刷新用户中心与推荐视图
24.5 管理员维护应用流程
text
管理员进入 /admin/apps
-> 后端分页查询应用
-> 前端以卡片方式展示
-> 点击新增/编辑弹窗
-> 提交表单
-> 后端更新 app_records
-> 失效分析缓存
-> 必要时触发单应用 Logo 补全
25. 异常处理与容错设计
系统进行了多处容错设计:
- 未登录访问受保护页面时自动跳转登录页。
- 非管理员访问后台时自动回退到普通页面。
- 登录失败、注册失败、密码不一致等场景使用 Flash 提示。
- Logo 抓取失败不会阻塞主流程。
- 图表容器尺寸未准备好时延迟重绘。
- 数据库旧结构通过轻量迁移自动修正。
26. 系统特色总结
本系统的技术特色主要体现在以下方面:
- 采用
FastAPI + Jinja2 + ECharts的轻量化架构,兼顾开发效率与展示效果。 - 启动即完成"建库、建表、导入、建默认用户、预热缓存"全流程。
- 构建了包含
32张图表的专题化分析中心,图表种类丰富。 - 同时支持规则推荐与基于收藏/历史行为的个性化推荐。
- 提供管理员与普通用户双权限体系。
- 支持应用 Logo 的自动抓取、本地存储与相对路径展示。
- 通过页面拆分、缓存和后台分页控制提升了整体性能与可维护性。
27. 可扩展方向
后续可以继续扩展的方向包括:
- 增加基于协同过滤的推荐模型
- 增加应用详情页
- 增加导出报表功能
- 增加统计看板下载为图片/PDF
- 接入真正的用户行为日志系统
- 为应用管理加入批量导入/导出
- 引入更完整的迁移工具如 Alembic
28. 运行与部署说明
28.1 安装依赖
powershell
cd code
pip install -r requirements.txt
28.2 启动项目
推荐使用你当前指定的 Python 环境:
powershell
cd F:\code\302-基于Python的安卓应用市场数据可视化分析推荐系统\code
& D:/software/anaconda3/envs/python38/python.exe .\main.py
或:
powershell
& D:/software/anaconda3/envs/python38/python.exe -m uvicorn main:app --reload
28.3 访问地址
text
http://127.0.0.1:8000
28.4 健康检查
text
http://127.0.0.1:8000/health
29. 结论
本项目已经完成了从原始 Excel 数据到数据库建模、后台管理、智能推荐、深度可视化展示和权限控制的一整套实现链路。系统既适合作为课程设计展示系统,也具备继续扩展为更完整应用市场分析平台的基础。
30. 系统需求分析
系统需求分析用于回答"系统为什么要做、要解决什么问题、要具备哪些能力"。结合本项目的课程设计目标,系统需求可分为功能需求与非功能需求两部分。
30.1 业务背景
安卓应用市场数据包含分类、子分类、安装量、评分、评论量、更新时间、应用简介和开发者等信息,这些数据天然适合进行:
- 市场结构分析
- 应用质量评估
- 热门赛道识别
- 用户偏好推荐
- 可视化展示与教学演示
传统 Excel 浏览方式存在以下问题:
- 数据量较大时查找效率低。
- 无法直观展示应用市场整体结构。
- 文本、评分、安装量等多维指标难以联动分析。
- 不便于做用户收藏与推荐。
- 无法进行权限控制与后台管理。
因此需要构建一个集"数据管理 + 数据分析 + 可视化 + 推荐 + 权限控制"于一体的系统。
30.2 功能需求分析
30.2.1 用户角色需求
系统用户角色分为两类:
- 普通用户
- 管理员
不同角色需求如下。
30.2.2 普通用户功能需求
普通用户主要面向数据浏览、分析和推荐使用场景,应具备以下能力:
-
用户登录与退出
用户能够使用账号密码登录系统,并在使用完成后退出系统。
-
用户注册
未登录用户能够自助注册普通用户账号。
-
忘记密码与修改密码
用户能够在忘记密码时重置为系统默认密码,也能够在登录后主动修改密码。
-
综合总览查看
用户能够查看应用总量、分类总量、开发者总量、平均评分、高分应用数等核心统计指标。
-
高价值应用榜单查看
用户能够查看综合评分较高的 Top 10 应用榜单,并查看其名称、分类、开发者、评分、安装量、更新时间与应用简介。
-
图表分析查看
用户能够查看分专题组织的多种图表,包括柱状图、折线图、词云图、雷达图、热力图、桑基图、旭日图、矩形树图等。
-
智能推荐
用户能够按照关键词、分类、最低评分、是否近期更新等条件生成推荐结果。
-
收藏功能
用户能够对应用执行收藏与取消收藏操作。
-
个性化推荐
用户收藏应用后,系统能够根据收藏偏好和推荐历史给出更贴近兴趣的"猜你喜欢"结果。
-
推荐历史复用
用户能够查看历史推荐记录,并快速恢复此前的推荐条件。
30.2.3 管理员功能需求
管理员除了具备普通用户全部能力外,还需要承担后台维护职责,故应具备以下额外功能:
-
用户管理
管理员能够创建用户、启用或停用用户、重置单个用户密码、批量重置全部用户密码。
-
应用数据管理
管理员能够查看应用数据卡片列表,对应用数据进行新增、编辑和删除操作。
-
应用分页管理
管理员查看应用数据时,应采用后端分页机制,每页固定显示 9 条记录,提升管理效率。
-
Logo 管理
管理员能够查看 Logo 状态,系统能够自动补全 Logo,数据库中保存 Logo 相对路径。
-
数据刷新
管理员能够重新导入 Excel 数据,实现数据重载。
-
后台概览查看
管理员能够查看用户总量、管理员数量、启用账号数量、应用总量、最近更新时间和头部分类等统计信息。
30.3 功能模块需求归纳
结合上文分析,系统可以抽象为以下功能模块:
- 登录注册模块
- 用户安全模块
- 综合总览模块
- 图表分析模块
- 智能推荐模块
- 收藏中心模块
- 用户管理模块
- 应用数据管理模块
- 数据导入与刷新模块
- Logo 自动补全模块
30.4 非功能需求分析
除了功能需求,系统还应满足以下非功能要求。
30.4.1 易用性需求
- 系统界面需要清晰、现代化、美观,适合课程展示。
- 左侧导航、顶部信息区和图表区域要分层明确。
- 图表页面应按专题拆分展示,避免内容堆叠混乱。
30.4.2 性能需求
- 系统启动后应能够在可接受时间内完成数据加载。
- 页面访问应采用按页面接口加载而非一次性全部加载。
- 图表渲染应尽可能减少因数据量大导致的卡顿。
30.4.3 安全性需求
- 密码不能明文存储。
- 受保护页面必须进行登录校验。
- 管理员后台功能必须进行角色权限控制。
30.4.4 可维护性需求
- 代码应模块化组织,便于后续扩展。
- 数据库字段与模型映射要清晰。
- 分析逻辑、推荐逻辑、数据导入逻辑应相互解耦。
30.4.5 可扩展性需求
- 能够继续增加更多图表类型。
- 能够继续扩展推荐算法。
- 能够后续增加报表导出、应用详情页等功能。
31. 可行性分析
可行性分析用于评估系统方案在技术、经济、操作和时间等方面是否具备实施条件。
31.1 技术可行性分析
本项目的实现技术成熟、稳定,技术可行性较高。
1. 后端技术可行
- FastAPI 路由清晰,适合构建课程设计级 Web 系统。
- SQLAlchemy 与 MySQL 搭配成熟,适合结构化业务数据管理。
- Python 对 Excel 解析、分词和数据分析支持丰富。
2. 前端技术可行
- Bootstrap 能快速构建后台布局与响应式界面。
- ECharts 支持丰富图表类型,能够满足词云、雷达图、桑基图、旭日图、热力图等需求。
- Jinja2 服务端渲染模式开发成本低,适合本项目规模。
3. 数据处理技术可行
openpyxl能稳定解析.xlsx文件。jieba能完成中文分词。numpy能完成箱线图等统计计算。
4. 集成实现可行
系统当前已经完成:
- Excel 自动导入
- MySQL 自动建库建表
- 用户权限控制
- 32 张图表输出
- 收藏与推荐
- Logo 自动抓取与存储
因此从技术角度看,本系统完全具备实现和落地条件。
31.2 经济可行性分析
本系统开发成本较低,经济可行性高。
-
软件成本低
项目主要使用开源技术栈:
- Python
- FastAPI
- SQLAlchemy
- Bootstrap
- ECharts
- MySQL
-
硬件要求低
普通个人电脑即可运行:
- Windows 系统
- Python 环境
- 本地 MySQL 服务
-
数据获取成本低
当前数据来源为已有 Excel 文件,无需额外购买数据服务。
因此从成本投入角度,系统经济可行。
31.3 操作可行性分析
系统面向课程设计与教学演示,操作门槛较低。
- 登录、注册、查看图表等操作符合常见 Web 系统习惯。
- 推荐、收藏、历史复用等功能交互直观。
- 管理员后台采用卡片式管理和弹窗表单,操作路径明确。
- 页面采用中文界面,便于教学和答辩展示。
因此系统具备较好的操作可行性。
31.4 时间可行性分析
本项目需求集中、功能边界明确,适合作为课程设计项目实现:
- 数据来源固定
- 功能模块相对独立
- 技术方案成熟
- 展示目标明确
系统当前已完成主要功能开发,并且结构化程度较高,因此从项目周期角度也具备较强可行性。
31.5 可行性结论
综合技术、经济、操作与时间四个方面分析,本系统具备较高可行性,适合作为课程设计项目进行开发、展示和答辩。
32. UML 用例图
32.1 用例图说明
从 UML 视角出发,本系统主要存在两个参与者:
- 普通用户
- 管理员
其中管理员是普通用户权限的扩展角色。普通用户关注"浏览、分析、推荐、收藏、账号安全",管理员进一步承担"用户维护、应用数据维护、数据刷新"等职责。
32.2 用例列表
普通用户主要用例
- 登录系统
- 注册账号
- 忘记密码
- 修改密码
- 查看综合总览
- 查看图表分析
- 生成智能推荐
- 收藏应用
- 查看收藏中心
- 查看推荐历史
管理员主要用例
- 创建用户
- 启用/停用用户
- 重置用户密码
- 批量重置密码
- 查看管理总台
- 查看应用数据管理
- 新增应用
- 编辑应用
- 删除应用
- 刷新数据集
- 管理 Logo
32.3 UML 用例图 PlantUML 表达
下面给出可直接用于论文或支持 PlantUML 渲染环境的 UML 用例图源码:
plantuml
@startuml
left to right direction
actor "普通用户" as User
actor "管理员" as Admin
rectangle "安卓应用市场数据可视化分析推荐系统" {
usecase "登录系统" as UC1
usecase "注册账号" as UC2
usecase "忘记密码" as UC3
usecase "修改密码" as UC4
usecase "查看综合总览" as UC5
usecase "查看图表分析" as UC6
usecase "生成智能推荐" as UC7
usecase "收藏应用" as UC8
usecase "查看收藏中心" as UC9
usecase "查看推荐历史" as UC10
usecase "查看管理总台" as UC11
usecase "创建用户" as UC12
usecase "启用/停用用户" as UC13
usecase "重置用户密码" as UC14
usecase "批量重置密码" as UC15
usecase "查看应用数据管理" as UC16
usecase "新增应用" as UC17
usecase "编辑应用" as UC18
usecase "删除应用" as UC19
usecase "刷新数据集" as UC20
usecase "管理Logo" as UC21
}
User --> UC1
User --> UC2
User --> UC3
User --> UC4
User --> UC5
User --> UC6
User --> UC7
User --> UC8
User --> UC9
User --> UC10
Admin --> UC1
Admin --> UC4
Admin --> UC5
Admin --> UC6
Admin --> UC7
Admin --> UC8
Admin --> UC9
Admin --> UC10
Admin --> UC11
Admin --> UC12
Admin --> UC13
Admin --> UC14
Admin --> UC15
Admin --> UC16
Admin --> UC17
Admin --> UC18
Admin --> UC19
Admin --> UC20
Admin --> UC21
@enduml
32.4 用例图文字化说明
若论文中不方便插入 PlantUML 图,也可采用如下关系说明:
- 普通用户进入系统后,可完成登录、注册、找回密码、修改密码等账号相关操作。
- 普通用户登录成功后,可查看综合总览、图表分析、智能推荐、收藏中心和推荐历史。
- 管理员继承普通用户的浏览和推荐能力,并额外拥有后台维护能力。
- 管理员可以在管理总台对用户进行创建、启停和密码重置。
- 管理员可以在应用数据管理页面对应用执行新增、编辑、删除和 Logo 管理。
- 管理员还可以重新导入 Excel 数据,实现数据刷新。
33. 数据库 E-R 图
33.1 E-R 模型说明
系统数据库围绕"用户、应用、收藏、推荐历史"四个实体展开。
核心关系如下:
- 一个用户可以收藏多个应用。
- 一个应用可以被多个用户收藏。
- 一个用户可以产生多条推荐历史。
- 一个推荐历史只属于一个用户。
因此系统本质上包含:
-
User与AppRecord的多对多关系通过中间表
UserFavorite实现。 -
User与RecommendationHistory的一对多关系。
33.2 实体说明
实体 1:User
表示系统用户,包含:
- 用户名
- 显示名
- 密码哈希
- 角色
- 启用状态
实体 2:AppRecord
表示应用市场中的应用记录,包含:
- 分类与子分类
- 应用名称
- Logo 路径
- 安装量
- 评分
- 评论人数
- 开发者
- 更新时间
- 应用简介
实体 3:UserFavorite
表示用户与应用之间的收藏关系,是 User 与 AppRecord 的关联实体。
实体 4:RecommendationHistory
表示用户执行推荐操作时产生的历史记录,用于条件复用与个性化推荐。
33.3 数据库 E-R 图 Mermaid 表达
下面给出可直接在支持 Mermaid 的 Markdown 环境中渲染的 E-R 图源码:
收藏
被收藏
产生
USERS
int
id
PK
string
username
string
display_name
string
password_hash
string
role
boolean
is_active
datetime
created_at
datetime
last_login_at
USER_FAVORITES
int
id
PK
int
user_id
FK
int
app_record_id
FK
datetime
created_at
APP_RECORDS
int
id
PK
string
category
string
subcategory
string
app_name
string
logo_path
string
install_raw
bigint
install_count
string
install_level
float
rating
int
review_count
string
developer
date
update_date
string
update_month
text
description
int
description_length
datetime
created_at
RECOMMENDATION_HISTORY
int
id
PK
int
user_id
FK
string
keyword
string
category
float
min_rating
int
limit_count
boolean
recent_only
int
result_count
datetime
created_at
33.4 E-R 关系说明
1. USERS 与 USER_FAVORITES
关系:
- 一个用户可以对应多条收藏记录。
- 一条收藏记录只能属于一个用户。
因此是:
USERS 1 : N USER_FAVORITES
2. APP_RECORDS 与 USER_FAVORITES
关系:
- 一个应用可以被多个用户收藏。
- 一条收藏记录只对应一个应用。
因此是:
APP_RECORDS 1 : N USER_FAVORITES
3. USERS 与 RECOMMENDATION_HISTORY
关系:
- 一个用户可以产生多条推荐历史。
- 一条推荐历史只属于一个用户。
因此是:
USERS 1 : N RECOMMENDATION_HISTORY
33.5 逻辑结构总结
如果从逻辑上简化描述,本系统数据库结构可以表达为:
text
用户(User)
├─ 拥有多个收藏(UserFavorite)
│ └─ 每条收藏关联一个应用(AppRecord)
└─ 拥有多条推荐历史(RecommendationHistory)
即:
- 用户是系统的中心主体。
- 应用是分析与推荐的核心客体。
- 收藏表承担"用户兴趣连接器"的作用。
- 推荐历史表承担"行为轨迹记录器"的作用。