Android 商户端运动场馆 SaaS 应用

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 并切换文案