4.4 KiB
4.4 KiB
WeChat Native UI Phase 2 Design
日期： 2026-03-27
范围： 原生 Android 微信式回退后的第二批细化
前提： 延续 2026-03-27-wechat-native-ui-rollback-design.md 已批准方向，不改一级导航、不改原生路线、不把控制台式信息重新放回主 UI
1. 目标
这一批只做三个方向的补齐：
- 聊天页手感更接近常用 IM，而不是“能发消息但交互生硬”
- OTA 下载与安装链路给出更明确的原生反馈，而不是只靠系统通知
- 根页导航和返回逻辑再收一轮，减少“像功能页、不像 APP”的割裂感
这批不新增新的一级功能，也不改 Boss 的后端技术路线。
2. 保持不变的约束
- 一级导航仍然固定为
会话 / 设备 / 我的 - 会话首页仍是微信式简单聊天列表
- 项目聊天页仍然只保留
项目目标 / 版本记录两个轻入口 运维 / 审计 / 修复 / 线程详情 / 转发仍保留深层入口，但不回到主聊天页和一级我的- 原生 Android 仍使用
BossApiClient + Activity + XML - 登录恢复、OTA API、Boss Web 部署链路都保持现有实现
3. 设计一：聊天页体验细化
3.1 现状问题
- 点击发送后只有整体刷新，用户会感觉“发出去了，但界面没跟手”
- 发送中没有明确状态，输入框和发送按钮的反馈太弱
- 每次刷新后直接滚到底，用户如果在看旧消息，会被强制拉走
3.2 目标效果
- 发送后立即出现一条本地“发送中”气泡，先给到即时反馈
- 服务端成功后，再用真实消息列表替换掉临时气泡
- 如果用户本来就在底部，刷新后继续滚到底
- 如果用户已经往上翻历史，自动刷新不能把用户强行拉回底部
- 发送按钮在空输入、发送中这两种状态下要有明确禁用表现
3.3 设计取舍
- 不做真正的本地离线消息队列
- 不做复杂的消息已读/送达双勾状态
- 只做“发送中 -> 成功刷新”这一层最小原生体验闭环
4. 设计二：OTA 原生反馈细化
4.1 现状问题
- 现在已经能下载并拉起安装，但主页面上看不到清晰下载进度
- 下载失败或权限阻塞时，提示不够聚焦
- 用户回到关于页时，不容易知道“刚才那个下载现在走到哪一步了”
4.2 目标效果
- 关于页能显示当前 OTA 下载状态：未开始、下载中、已完成、失败、等待安装授权
- 下载中能看到百分比或至少看到“已下载 / 总大小”的进度文案
- 下载失败时可直接重试，不需要用户自己猜该做什么
- 如果安装未知来源权限没开，界面要明确告诉用户下一步去哪开
4.3 设计取舍
- 继续使用系统
DownloadManager - 不实现后台自定义下载器
- 不实现增量更新，只优化整包 APK 下载体验
5. 设计三：导航细节细化
5.1 现状问题
- 根页 tab 虽然已经变成微信式，但重新进 APP 时对用户上次停留页的记忆还不稳定
- 根页返回虽然不会直接乱跳，但体验还可以更像成熟 APP
5.2 目标效果
- 记住用户上次停留的根 tab，下次进 APP 优先回到该 tab
- 如果外部显式指定入口 tab，仍然以显式入口优先
- 在根页按返回时，不再像“页面崩掉式退出”；给出更柔和的退后台反馈
5.3 设计取舍
- 不做复杂导航栈框架迁移
- 继续基于现有
MainActivity自己维护 root tab 状态
6. 代码边界
这批预计新增少量纯 Java helper，目的是让关键交互可以用单元测试覆盖，而不是把逻辑都埋进 Activity：
ProjectChatUiState.java- 负责“是否自动滚到底”“发送按钮是否可用”“临时发送中消息”的最小映射
OtaDownloadStateMapper.java- 负责把
DownloadManager查询结果映射成页面文案和状态
- 负责把
活动页主要做接线，不堆业务判断：
ProjectDetailActivity.javaAboutActivity.javaMainActivity.java
7. 验收标准
- 聊天页发送消息后，立刻能看到发送中反馈
- 聊天页刷新不会在用户查看历史消息时强制跳到底
- 关于页能看到 OTA 下载状态和失败重试入口
- 未知来源安装权限未开时，页面能给出明确引导
- APP 再次打开时，根 tab 能恢复到上次停留位置
- 微信式一级 UI 不被破坏，主聊天页仍然只保留
项目目标 / 版本记录