1)立项背景和目标
随着本地运动健身、球类场馆等线下商户数字化经营需求增长,传统电话预约、线下收款方式效率低、对账难。项目旨在为场馆商家提供一站式移动端经营工具,覆盖入驻开户、门店信息维护、订单与收益管理等核心场景,帮助商户快速上线、提升门店曝光与订单转化,降低运营成本。
2)软件功能、核心功能模块介绍
GG运动商家版是面向 B 端商户的 Android 原生应用,采用模块化架构,主要包含:
账号体系:验证码/密码双模式登录、商家入驻注册、协议勾选、会话持久化与切换账号;
个人中心:个人信息展示与编辑(头像、姓名、手机号、登录账号)、修改密码、钱包入口、品牌管理、隐私协议等;
店铺装修:装修概览评分、展示信息(Logo/封面/店内环境/自定义分组)、店铺资质(营业执照上传 + OCR 识别)、基础设施标签维护;
钱包模块:余额与待结算展示、结算流水/提现记录分页列表、支付宝提现申请与协议确认;
其他协同模块:商家首页、订单、核销、场地与价格配置等(团队协作)。
3)业务流程、功能路径描述
典型商户使用路径如下:
1.新商户入驻:打开 App → 注册(手机号 + 验证码 + 密码)→ 登录进入商家首页;
2.完善门店信息:首页 → 店铺装修 → 概览页查看完善度评分 → 分别进入「展示信息」「店铺资质」「基础设施」上传图片、填写资质并保存;
3.账号与资料维护:首页 → 个人中心 → 个人信息 → 修改头像/姓名/手机号/登录账号/密码;
4.收益管理:个人中心 → 钱包 → 查看余额与待结算 → 切换「结算流水 / 提现记录」→ 发起提现 → 填写支付宝信息并提交。
1)整体架构和设计思路
项目采用 多模块 + 分层架构,按业务拆分为 feature:login、feature:profile、feature:storedecorate、feature:wallet 等独立模块,底层由 core 层提供网络、存储、通用 UI 等能力,模块间通过 Navigation3 路由解耦,避免循环依赖。
语言 / UI:Kotlin + Jetpack Compose(Material3)
架构模式:MVVM(ViewModel + UiState + Action 单向数据流)
网络:Retrofit + OkHttp + 统一 SafeResult 封装
本地存储:MMKV(登录态、门店 ID、用户信息)
各 Feature 模块遵循统一规范:ScreenRoot 负责组合 UI 与生命周期,ViewModel 处理业务逻辑,Repository 层对接 API,组件按页面目录拆分并支持 Compose Preview。
2)我负责的模块和结果(量化)
本人独立负责 注册登录、个人中心、店铺装修、钱包 四个 Feature 模块的设计与开发,主要成果:
交付 4 个独立 Feature 模块,涵盖 15+ 页面/子流程,编写 Kotlin 代码约 150+ 文件;
实现 10 个 ViewModel,覆盖登录/注册、个人信息编辑(5 个子页)、店铺装修(概览/展示/资质/基础设施)、钱包与提现;
完成 登录态全链路:注册/登录 → Token 持久化 → 切换账号清会话 → 首页刷新用户信息;
店铺装修支持 图片上传 + 营业执照 OCR 自动回填(企业名称、法人、信用代码),减少商户手工录入;
钱包模块实现 双 Tab 分页列表 + 日期筛选 + 提现表单校验,对接结算/提现 API;
修复并优化 10+ 项体验问题(如:新用户进入店铺装修误弹 Toast、登录模式切换残留数据、OCR 识别 loading 状态、相机/相册权限弹窗样式统一等),提升新商户 onboarding 体验。
3)我遇到的难点、坑和解决方案
难点一:多模块登录态与页面刷新不一致
切换账号或重新登录后,首页仍显示旧用户头像/昵称。
方案:封装 AuthSessionStorage 统一读写会话;登录/注册成功后触发 SellerHomeRefreshBridge 刷新首页;切换账号时清空登录表单与会话缓存,保证 UI 与存储一致。
难点二:店铺装修图片上传 + OCR 状态管理复杂
营业执照需「上传 → 识别 → 回填表单」,中间状态易闪烁或重复提交。
方案:在 CertificationImageState 中增加 isUploading / isRecognizing / isBusy 状态机,上传成功后延续 Loading 并切换文案