Skip to content

BZBY/wall_app

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

17 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Wall App

介绍

Wall App 是一个壁纸应用项目,旨在展示来自某未知壁纸网站的精选壁纸。项目分为后端服务和前端展示两部分,后端采用 Python Flask 框架开发,前端则使用 Flutter 框架进行安卓开发,未来也将支持 Windows、iOS、Mac 和 Linux 平台。

视频演示

为了更直观地展示应用的功能和用户界面,我准备了一个视频演示:【github 壁纸app开发介绍】 https://www.bilibili.com/video/BV1JC41157s5/?share_source=copy_web&vd_source=761f4110afc46f983836b2ea7ddbca38

Alt Text

后端接口

后端服务实现了以下接口,支持应用的核心功能:

  • 下载图片:POST /download_images
  • 获取图片:GET /images/<filename>
  • 根据标签搜索图片:GET /search_by_tag
  • 获取图片详细信息(慢速):GET /get_detail_slow
  • 获取图片详细信息:GET /get_details
  • 获取特定 ID 的图片详细信息:GET /images_detail/<id>
  • 获取所有图片 ID:GET /get_ids

安卓开发

安卓客户端使用 Flutter 框架开发,实现了以下功能:

  • 图片缓存机制
  • 排行榜内容一览
  • 根据标签搜索图片
  • 图片收藏功能
  • 图片详情查看
  • 主题切换(开发中)

技术细节

  • 后端: 通过爬虫脚本异步下载并存储排行榜上所有图片的相关信息,使用 SQLite 数据库持久化用户收藏列表信息。
  • 前端: 利用 Flutter 框架,首次启动时调用后端脚本 API,加载可能稍慢。但是后续加载速度会显著加快,取决于后端 Web API 与设备的连接速度。

算法与数据结构优化

为了提升 Wall App 的性能和用户体验,我们重点优化了相关算法和数据结构,包括:

  • 图片缓存机制: 采用高效的缓存策略,减少网络请求,加快图片加载速度。
  • 数据库查询优化: 对 SQLite 数据库的查询进行优化,快速检索用户收藏和图片详情信息。
  • 数据加载策略: 实现懒加载和分页加载机制,减少初始加载时间,优化内存使用。

未来计划进一步研究和应用更多高级算法和数据结构,如 AI 标签生成和图片识别,为用户提供更智能化的服务。

未来计划

未来工作计划包括:

  1. 集成 AI 功能,例如通过标签生成 AI 绘制的图片。
  2. 实现通过输入标签直接合成 AI 图片的功能。
  3. 在收藏夹中通过随机标签组合生成 AI 图片。
  4. 持续优化算法与数据结构的使用,提升项目的稳定性和运行效率。
  5. 支持移动平台(包括手表、车机)的客户端软件架构设计和功能开发,采用原生与 Flutter 混合开发方式。

未来的算法与数据结构优化工作

  1. 图片缓存机制
    • 实施LRU(最近最少使用)缓存算法,自动移除最久未使用的图片,保留最近频繁访问的图片在缓存中。
    • 考虑使用布隆过滤器来快速检查一个图片是否已经被缓存,减少对缓存存储的查询时间。
    • 数据压缩缓存?
  2. 数据库查询优化
    • 应用B+树索引结构优化SQLite数据库查询,加快数据检索速度,尤其是在处理大量数据时。
    • 探索图数据库(如Neo4j)来管理复杂的数据关系,比如用户与图片之间的多种关系(收藏、喜欢、分享等)。
  3. 数据加载策略
    • 实现数据分片和懒加载机制,仅加载用户当前需要查看的图片数据,减轻服务器压力,提高响应速度。
    • 使用图形处理单元(GPU)加速数据处理,特别是在处理图像和视频内容时,以实现更快的加载和渲染速度。
  4. 移动平台客户端软件架构
    • 探索微前端架构,使应用能够以更灵活的方式加载和升级特定功能模块,提升应用的可维护性和扩展性。
    • 使用**服务工作线程(Service Workers)**来缓存资产和数据,实现离线功能,提高在弱网环境下的用户体验。
  5. 持续优化算法与数据结构的使用
    • 定期对现有算法进行复杂度分析,识别性能瓶颈,寻找更优解。
    • 探索使用并行计算异步处理技术,尤其是在后端服务中处理大量请求时,以提高效率。

实施细节

图片缓存机制

实施LRU缓存算法

  1. 选择合适的数据结构:结合哈希表与双向链表。哈希表用于快速查找图片,双向链表用于表示缓存中的图片使用顺序。
  2. 操作逻辑
    • 当访问一个图片时,如果图片存在于缓存中,将其移动到双向链表的头部。
    • 如果图片不在缓存中,将其添加到双向链表的头部,并在哈希表中添加相应的记录。如果缓存已满,则移除双向链表尾部的图片,并从哈希表中删除相应记录。

使用布隆过滤器

  1. 初始化布隆过滤器:选择合适的大小和哈希函数数量,以平衡误判率和空间效率。
  2. 操作逻辑
    • 在向缓存添加图片前,先使用布隆过滤器检查图片是否已缓存。
    • 注意,布隆过滤器可能会有假阳性(即错误地认为图片已缓存),因此在布隆过滤器检查通过后,还需要在哈希表中确认。

数据库查询优化

应用B+树索引结构

  1. 优化SQLite数据库查询:针对关键查询路径(如图片的元数据查询)使用B+树索引结构,加快检索速度。
  2. 操作逻辑
    • 分析查询模式,确定哪些列频繁用于查询,并在这些列上创建索引。
    • 定期维护索引,确保其高效。

探索图数据库

  1. 使用Neo4j管理复杂关系:设计适当的图模型来表示用户、图片及其之间的关系。
  2. 操作逻辑
    • 定义节点和边的属性,以支持复杂查询。
    • 利用图数据库的查询语言(如Cypher),实现高效的关系查询。

数据加载策略

数据分片和懒加载

  1. 设计分片策略:根据用户行为和网络条件,动态调整数据分片的大小和策略。
  2. 懒加载实现:监控用户的滚动行为,仅在需要时加载和渲染图片。

使用GPU加速

  1. 集成GPU加速库:利用Flutter的图形处理能力,对图片和视频内容进行加速处理。
  2. 优化渲染流程:减少不必要的渲染和数据处理,确保流畅的用户体验。

移动平台客户端软件架构

微前端架构

  1. 模块化设计:将应用划分为独立的功能模块,每个模块可以独立开发、测试和部署。
  2. 动态加载:根据需要动态加载或更新特定功能模块,以减少初始加载时间和提高灵活性。

服务工作线程(Service Workers)

  1. 缓存策略设计:设计合适的缓存策略,对静态资源和常用数据进行缓存。
  2. 离线支持:实现基本的离线功能,提高弱网环境下的应用表现。

持续优化

算法与数据结构优化

  1. 复杂度分析:定期对现有算法进行时间和空间复杂度分析,识别并优化性能瓶颈。
  2. 算法替换:根据分析结果,考虑更高效的算法或数据结构,如替换成时间复杂度更低的算法,以提升性能。

并行计算与异步处理

  1. 并行化处理:对于可并行处理的任务(如图像处理、数据加载),利用多线程或多进程技术实现并行化,减少处理时间。
  2. 异步化服务请求:后端服务采用异步处理机制,对于IO密集型操作(如数据库访问、文件读写),通过异步IO操作减少响应时间,提高吞吐量。

技术实现建议

  • Flutter端实现建议

    • 利用Flutter提供的ImageProviderCacheManager等类,实现图片的缓存和懒加载策略。
    • 使用Compute函数来在Isolate中执行CPU密集型任务,如图片处理,避免阻塞UI线程。
    • 探索ServiceWorker API,实现资源的预缓存和数据的后台同步,提升应用在离线或弱网环境下的体验。
  • Flask后端实现建议

    • 使用Redis等内存数据库实现LRU缓存策略,快速响应图片缓存的查询和更新。
    • 优化数据库访问,采用SQLAlchemy等ORM工具结合索引优化,提高数据库操作的效率。
    • 利用Flask的异步功能或结合Celery等工具,实现后端服务的异步处理,尤其是在处理耗时的I/O操作时。

持续迭代与优化

  • 性能监测:引入性能监控工具,如Flutter的DevTools和Flask的Flask-Profiler,持续监测应用的性能指标,及时发现和解决性能问题。
  • 用户反馈循环:建立用户反馈机制,收集用户对于应用性能和功能的反馈,根据用户需求和使用习惯持续优化产品。
  • 技术前沿跟进:持续关注新技术和算法的发展,评估其在项目中的应用价值,及时进行技术迭代,保持产品的竞争力。

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published