|
|
2a6ad93ec0
|
feat(harmony): P4 —— 外观（主题 + 壁纸）跟着账号走
服务端 2026-09-13 起就是外观的权威（账号级 `/api/v1/me/appearance`），WebUI 接好了，
**鸿蒙这边此前完全没接**。这一期补上，并把"谁覆盖谁"的规则做成可判据的纯逻辑。
## 改了什么
- `api/AppearanceApi.ets`：`GET/PUT /me/appearance`、`POST /me/appearance/image`、
`GET /me/appearance/image`（图片带认证取回本体：不用 `?token=`，也不让 Image 直连 http）。
- `api/ApiClient.ets`：新增 `getBytes()`（按 ARRAY_BUFFER 收）—— 复用 `request<T>` 会当场炸，
因为它假定响应是 JSON（`JSON.parse`）。
- `model/Appearance.ts`（纯逻辑，判据直接执行）：归一化 / PUT 报文 / **合并决策** /
模糊值→系统材质档次 / 主题→系统色彩模式 / 遮罩浓度 / 状态文案。
- `common/AppearanceStore.ets`：落地副作用 —— 主题交给**系统**（`setColorMode`，不自己维护
深色色值）、壁纸取回 `PixelMap`、缓存**按账号**分键（`appearance.<accountId>`）。
- 入口两处：`MainPage`（进主界面就应用 —— 只在设置页生效的话"一进主界面就变回去"，
WebUI 侧踩过）与 `SettingsPage` 新增「外观」段（三档主题 + 同步状态「已同步 / 仅本机」）。
## 为什么这么写（两条最贵的规则）
1. **服务端"没有记录"时以本地为准**（`saved === false`）：服务端这时回的是一份*默认值*，
拿它覆盖本地 = 把用户已有的主题/壁纸抹掉（WebUI 原话：每个老用户升级后第一次登录
都会发现被重置）。正确动作是把本地那份推上去。
2. **降级必须可见**（`local-only` → 显示「仅本机」）：否则用户以为换设备也能带走。
## 判据（新增 11 条，已接进 run-all；套件 10 → 11 个判据文件）
归一化（脏值/越界/小数/NaN 退回默认）；`image` 档无图 → 退回 `none`；PUT 报文蛇形字段名；
★服务端无记录 → 以本地为准且**一个字段都不能被默认值顶掉**；服务端有记录 → 以服务端为准但
**不擦掉**本地那张服务端还没有的图；离线状态可见且三种状态文案互不相同；
★模糊值→系统材质档次（与 SDK 的 `BlurStyle` 成员**逐一比对**）；
主题→色彩模式（数值与 SDK 的 `ConfigurationConstant.ColorMode` **逐一比对**）；
★路径必须**相对基地址**（WebUI 那条"整套同步从来没生效过而单测全绿"的坑）；
缓存键**带账号**；两处入口都真的应用。
变异验证（6 种，均判红）：默认值覆盖本地 / 不管"image 档但服务端无图" / 材质档次自造名字 /
路径多写 `/api/v1` / 缓存键不带账号 / 深浅色彩模式数值写反。
## 判据抓到的两个真 bug
- `snapshotFromResponse` 在字段缺失时给 `bgDim = 0`，而 WebUI 语义是退回 12 ——
ArkTS 反序列化把缺失字段留成**类里写的默认值**，"字段不在"与"字段是 0"分不开。
已把默认值对齐 WebUI 的 `clamp(..., dflt)` 语义（并让 `saved` 默认 false = 安全的那一侧）。
- 主题落地按"0=浅色、1=深色"写的 `setColorMode` —— **正好反了**
（SDK：`COLOR_MODE_DARK = 0`、`COLOR_MODE_LIGHT = 1`），选深色会切成浅色。
靠判据去 SDK 枚举文件读数比对发现；映射已搬进纯逻辑 `colorModeValue`，
从"某处有个 setColorMode 调用"变成"可判据的行为"。
## 验证 / 未验
`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0（11 个判据文件全绿 + vitest 258/258）。
套件自检又抓到一次"判据写好没接进套件"（新文件第一版漏了 run-all），已修。
**未做**：壁纸**上传**入口（选图 → `POST /me/appearance/image`）—— 需要 picker，API 与命名已就位。
**未验**：壁纸在真机上的渲染 —— 需真机或模拟器。
|
2026-09-14 14:19:26 +08:00 |
|
|
|
4d226be056
|
test(harmony): 「用系统方案」的地基 —— 系统资源名与 BlurStyle 取值离线可校验（判据先于替换）
jianf 追加要求「鸿蒙要求用系统方案」（§二·五）。难点是**没有设备**：
`$r('sys.color.写错了')` 编译期不报、只有真机运行到那一行才炸 —— 这块会变成谁都验不了的区域。
SDK 里其实带着答案：`sdk/default/openharmony/toolchains/id_defined.json` 列了全部系统资源名
及其类型（本机 API 26：7826 条，color 1059 条）；BlurStyle 取值在 `component/common.d.ts` 的
`declare enum BlurStyle` 里。两边都能离线查，所以"名字写对没有"可以变成构建期判据。
新增 `test/harmony-system-api.test.mjs`（4 条，已接进 run-all）：
1. SDK 名表/组件声明找不到时**判红并给出替代做法**（会静默跳过的判据等于没有这条判据 ——
本仓库已栽过四次同类问题）；
2. 源码里每个 `$r('sys.<type>.<name>')` 必须存在且**类型相符**；
3. 每个 `BlurStyle.<MEMBER>` 必须在 SDK enum 里；
4. 替换计划要用的那批系统色**先核过再写代码**，并且钉住一条边界：名表里没有
`brand`/`confirm`/`success` —— 权限三档、预算三档这些**业务语义色没有系统对应物**，
继续用自定义令牌，不许"为了系统化"把 plan 档画成 warning 色（那是丢语义换形式）。
变异验证：拼错色名 `ohos_id_color_list_cad_bg` → 报「查无此名」并指出文件；
写错 `BlurStyle.COMPONENT_不存在` → 报出可用取值。顺带修掉解析精度问题：
早先的宽松正则把文档里的 `T`、`R` 也当成了枚举成员，现在精确到 `,`/`=` 分隔符。
验证：`npm test` 退出码 0（10 个判据文件全绿 + vitest 258/258）。
|
2026-09-14 13:56:43 +08:00 |
|
|
|
5ce711fbcd
|
test(suite): 自检 3（判据不得埋在 process.exit 之后）+ TMPDIR 固化 + API 同名不同义表
## 自检 3（pi 提议）
自检 1/2 管"文件没接线"，管不到"检查写在 `process.exit()` 之后"—— 而那正是实际发生的
第 4 例（4 条玻璃判据被并发写入落到文件末尾）。成因是**结构性**的（并发写入总是往文件末尾
追加），所以它一定会再发生，而它下一次仍然不报错。静态扫一遍即可：`process.exit(` 之后
若再出现 `check(`，直接判红并指出文件。变异验证：往 `theme.test.mjs` 尾部追加一条 check → 判红。
## TMPDIR 固化（pi 建议，采纳）
"记得加 TMPDIR"这种约定活不过两次踩坑（hvigor、fpm 各一次）。所以不再靠口径：
- `npm run build:linux` 自带 `mkdir -p .tmp && TMPDIR=${TMPDIR:-$PWD/.tmp}`；
- `BUILD.md` 的 deb 一节写明这条前置与原因（`/tmp` 是 tmpfs、占内存、常年近满）。
## `docs/API.md`：`total` 不是总封数 + 同名不同义表
`GET /me/mail/inbox` 的 `total` 是**未读总数**（`repo.CountUnread`），不是本页/全部邮件数 ——
鸿蒙端曾因此写出「共 7 封」和「未读 7」两行自相矛盾的字。在人类接口开头加了醒目提示，
并新增一张表：`total`（未读数）/ `status`（邮件=unread|read，会话=active|archived）/
`status` 与 `is_read` 同义不同名。
## 验证
`npm test` 退出码 0：9 个判据文件全绿 + vitest 258/258（安装包已按判据要求重打，
AppImage 与 deb 均为最新）。
|
2026-09-14 13:53:34 +08:00 |
|
|
|
f6feb7c0df
|
test(webui): 「滑动硬截断」诊断脚本（自带浏览器，不依赖共享实例）
用户：「webui 大片界面存在滑动硬截断」。
## 现状：这一轮我**没能复现**
量法是"内容溢出但没有可滚动祖先"⇒ 候选 0 个；换成用户视角四问
（有没有可滚动容器 / 能不能滚到底 / 末尾有没有被切 / 页面自己溢不溢出）后：
390×700 通信 ✅ 日历 ✅ 联系人 ✅ 我的 ✅
1400×700 通信 ✅ 日历 ✅ 联系人 ✅ 我的 ✅
（造了 12 个会话、正文都很长；验完已归档）
即按这四种量法都测不到硬截断。**长正文详情页**那一块我的探针超时没跑完 ⇒
**未判定**，不能算"没问题"。
## 这次的交付物
`client/electron/test/manual/scroll-cut-verify.mjs`：把上面这套量法固化下来，
并且**自带浏览器**（不连共享 9222）—— 共享实例被历次被中断的运行留下僵尸上下文后，
`connectOverCDP` 会一直超时（我这个会话里已经遇到三次），诊断脚本必须在
"共享实例状态未知"时也能跑。
## 我需要的（否则只能继续猜）
请指一下**具体页面 + 具体手势/位置**：哪一屏、滚轮还是触摸拖动、硬截断出现在
列表末尾还是详情正文？也可以直接看截图。我上一轮"窄屏显示不全"也是同样情况 ——
我量不出来、但你说有，那多半是我量的维度不对。
|
2026-09-14 13:43:11 +08:00 |
|
